Options API与Composition API架构对比

考察点分析 link

本题主要考察以下核心能力维度：

1. 框架机制理解：对比两种API设计范式的实现原理与设计哲学
2. 工程化思维：评估代码组织方式对复杂系统维护的影响
3. 逻辑抽象能力：判断对逻辑复用模式的理解深度

具体技术评估点：

• Options API的碎片化问题（数据/方法/生命周期分散）
• Composition API的函数式编程优势
• 基于功能组织的代码封装策略
• 响应式系统在两种模式下的实现差异
• 逻辑复用的实现路径差异（Mixins vs Composition函数）

技术解析 link

关键知识点 link

Composition API > 逻辑聚合 > 响应式API > 代码可维护性 > TypeScript支持

原理剖析 link

Options API通过对象选项（data/computed/methods）组织代码，导致同一功能逻辑分散在不同选项块中。例如用户验证功能可能涉及：

• data中的表单字段
• methods中的提交方法
• watch中的字段校验
• mounted中的初始加载

Composition API通过setup()函数实现：

1. 使用ref/reactive集中声明响应式数据
2. 将相关逻辑封装为独立函数（如useFormValidation）
3. 通过return暴露必要属性和方法

这种基于功能组织的模式类似乐高积木，开发者可以自由组合逻辑模块。同时由于函数闭包特性，组合函数内可直接使用相关响应式API，解决了Options API中必须通过this访问实例属性的限制。

常见误区 link

• 认为Composition API只是语法糖（实际改变了代码组织范式）
• 在setup中过度使用逻辑混合（应保持单一职责）
• 忽视生命周期钩子的使用差异（onMounted代替mounted）

问题解答 link

Options API与Composition API的核心差异在于代码组织范式：

1. 横向切割 vs 纵向聚合：Options API按功能类型切割代码（数据归data，方法归methods），Composition API按业务功能聚合代码
2. 逻辑复用方式：Options API依赖mixins（存在命名冲突风险），Composition API通过可组合函数实现精准复用
3. 类型推导：Composition API的函数式结构更利于TypeScript类型推导

示例：用户定位功能在Options API中的实现：

  // 分散在多个选项块
export default {
  data() {
    return { coords: null }
  },
  mounted() {
    navigator.geolocation.watchPosition(
      pos => this.coords = pos
    )
  },
  methods: {
    formatCoords() { /* 格式化逻辑 */ }
  }
}
  

使用Composition API重构：

  // 逻辑聚合的函数封装
const useGeolocation = () => {
  const coords = ref(null)
  const format = () => { /* 格式化逻辑 */ }
  
  onMounted(() => {
    navigator.geolocation.watchPosition(
      pos => coords.value = pos
    )
  })
  
  return { coords, format }
}

// 组件使用
export default {
  setup() {
    const { coords, format } = useGeolocation()
    return { coords, format }
  }
}
  

解决方案 link

编码示例：跨组件复用逻辑 link

  // 封装网络请求逻辑
import { ref } from 'vue'

export function useFetch(url) {
  const data = ref(null)
  const error = ref(null)
  const loading = ref(false)

  const execute = async () => {
    loading.value = true
    try {
      const response = await fetch(url)
      data.value = await response.json()
    } catch (e) {
      error.value = e
    } finally {
      loading.value = false
    }
  }

  // 自动执行或按需执行
  onMounted(execute)

  return { data, error, loading, execute }
}

// 组件使用
export default {
  setup() {
    const { data } = useFetch('/api/user')
    return { userData: data }
  }
}
  

可扩展性建议 link

1. 复杂场景：通过provide/inject实现嵌套逻辑共享
2. 性能优化：使用computed缓存组合函数计算结果
3. 类型安全：为组合函数添加TS泛型支持
4. 调试支持：使用Vue DevTools的composition API调试功能

深度追问 link

1. 与React Hooks的异同？ 答：相似逻辑封装能力，但基于Vue响应式系统实现，无Hook顺序限制

2. 如何迁移Options API组件？ 答：渐进式重构，优先提取独立功能模块

3. 性能差异具体表现？ 答：运行性能接近，但组合式代码更易优化