Composition API 相比 Options API 解决什么？
先理解原理和示例，再练习完整口述与追问。
回答要点
可按业务功能组织状态、派生值和副作用，便于组合、复用与类型推导；并非自动让代码更快或更简单。Options API 仍可用，函数拆分也要保持职责和依赖清晰。
原理拆解
Options API 按 data、computed、methods、watch 等选项组织，简单组件直观；复杂功能会被拆散到多个选项，组合式 API 可把同一个业务能力的状态、派生值、动作和清理放在一起，再按能力复用。它解决代码组织和依赖显式性，不改变单向数据流原则，也不意味着所有组件必须拆出很多 useXxx。
示例与推演
一个商品查询功能可封装 useProductSearch，内部维护 query、rows、loading、error 和取消，返回必要状态及 search/reset。页面仍负责 UI 和业务组合。调用两次通常产生两份独立状态，只有显式使用外部共享状态才共享；这与把 mixin 的方法名隐式并入宿主不同。
易错点
不要把组件全部原样搬进一个巨型 composable。Vue2.7 也有组合式能力，但旧构建、插件和 SSR 使用限制需要另核实，不能宣称 Composition API 只存在于 Vue3。
参考回答可直接练习口述
Options API 按 data、computed、methods 等选项组织代码，简单组件很直观；Composition API 可以把同一业务能力的状态、计算和副作用放在一起，并通过组合函数显式复用和推导类型。它解决的是逻辑组织与复用问题，不是要求所有代码函数化，也不自动提高性能。两种 API 可以按项目风格使用。
面试官可能继续问追问与完整解答展开收起
追问
一个组合函数里请求、路由、权限全包是否合理？与 mixin 相比依赖和返回值如何更显式？
追问回答
一个函数把权限、路由、表单、请求都包起来，会变成难理解的隐式模块。应围绕单一业务能力拆分，并用参数表达依赖、返回值表达能力；相比 mixin，组合函数的调用位置、输入和命名来源更明确。