options api因逻辑碎片化、复用困难、类型推导弱、错误边界薄弱，导致代码可维护性差、健壮性低；组合式api通过逻辑聚合、组合函数复用、typescript友好及setup隔离，系统性解决这四大痛点。
在现代组件化开发中，options 对象的管理之所以成为系统健壮性的红线，核心在于它直接决定了逻辑组织是否可预测、错误是否可收敛、配置是否可验证。一旦 options 被随意拼接、隐式覆盖或跨层级裸传，轻则导致状态不一致、调试困难，重则引发白屏、无限循环或静默失败——而这些恰恰是健壮性崩塌的典型征兆。
逻辑耦合与碎片化：健壮性的结构性隐患
Options API 的 data、methods、computed 等字段强行按类型切分逻辑，使本应内聚的业务流（如“用户登录→校验→存储→跳转”）被拆散到五个不同区块。这种结构天然阻碍防御性设计：
- 无法在一处集中做参数校验或 fallback 处理
- 生命周期钩子中访问未初始化的 data 字段极易触发 undefined 错误
- mixins 或 extends 引入的 options 合并规则复杂，容易覆盖关键配置而不报错
配置漂移与类型失守：健壮性的安全缺口
当配置以字符串 key（如 config["api.timeout"]）方式硬编码在 options 中，就等于放弃编译期检查和 IDE 提示。这类写法在运行时才暴露问题：
- 拼写错误（"apit.timeout"）导致配置读取为 undefined，后续调用 .then() 报错
- 环境变量未注入时，options 里仍保留空字符串或 null，但组件未做兜底，直接渲染异常 UI
- 缺乏 Options 模式中的 IValidateOptions 或组合式 API 的 ref/validate 钩子，校验逻辑散落在各处，难以统一拦截
异常传播无边界：健壮性的执行断点
Options API 的错误边界能力薄弱。一个 computed 属性抛出异常，可能让整个组件树停止响应；一个 beforeCreate 中的异步配置加载失败，不会自动触发 errorCaptured，而是静默中断初始化流程：
- 没有显式的 setup() 执行上下文隔离，异常会穿透至父组件
- watch 或 created 中发起的请求若未包裹 try/catch，错误将冒泡至全局 unhandledrejection
- 缺乏类似 OptionsManager 的监听与重试机制，配置变更后无法自动恢复稳定态
真正健壮的系统，不是靠运气避开异常，而是靠结构掐住风险源头。把 options 当作不可变契约来定义、校验和注入，比在每个组件里补 catch 更有效。这不单是写法选择，是健壮性能否落地的第一道闸门。
