实际开发中优先选ref：数据常整体替换时ref支持安全赋值，基础状态原子化管理更自然，解构传递不丢失响应性，typescript类型推断更稳定；reactive适合强关联业务对象，但需注意赋值断代理、解构失响应等问题。
实际开发中选 ref 还是 reactive，关键不是“类型匹配”，而是看数据怎么用、怎么变、怎么传。
数据是否常被整体替换？
如果变量会频繁被整个赋新值（比如接口返回新列表直接覆盖旧数据、表单重置为全新对象），优先用 ref。
-
ref 支持安全替换：
list.value = response.data，响应性不丢 -
reactive 直接赋值会断代理：
user = { name: '李四' }→ 变成普通对象，后续修改不触发更新 - 若坚持用 reactive，必须用
Object.assign(user, newData)或逐个赋值，麻烦且易漏
变量是独立存在，还是逻辑成组？
单个基础状态（开关、计数器、输入框值）统一用 ref；多个强关联字段组成的业务对象（如用户资料、商品详情），适合 reactive。
-
ref 天然适合原子化状态：
const loading = ref(false)、const searchKey = ref('') -
reactive 更贴近“数据模型”思维：
const profile = reactive({ name: '', avatar: '', bio: '' })，读写清爽，结构清晰 - 混合使用也常见：用 reactive 管理主对象，其中某个字段（如时间戳）用 ref 单独控制
是否需要解构或透传给子组件？
要解构属性或作为 props 拆开传递时，ref 更省心；reactive 解构后默认丢失响应性，需额外处理。
-
ref 解构后仍可操作：
const { value: count } = ref(0)→count++有效 -
reactive 解构即“脱钩”：
const { name } = user→name = '新名'不更新视图 - 要用 reactive 解构，必须配合
toRefs：const { name, age } = toRefs(user)
团队协作与 TypeScript 体验
在 TypeScript 项目中，ref 的类型推断更稳定直观，尤其对基础类型和泛型数组；reactive 对深层嵌套对象的类型支持稍弱，且容易因解构破坏类型完整性。
-
const items = ref<string>([])</string>—— 类型明确，.value 访问时自动补全 -
const form = reactive({ email: '', password: '' })—— 类型依赖上下文，解构后可能失去 readonly 或响应式标记 - Volar 插件对 ref 的 .value 自动补全已非常成熟，减少手误
