用 ref 替代 reactive 是为统一访问、降心智负担、避解构陷阱；适用于独立状态、单字段传递、动态结构对象及 TS 类型友好场景，并需按约定平滑过渡。
用 ref 代替 reactive 并不是为了“替代”它，而是为了在特定场景下统一访问方式、降低心智负担、避免解构陷阱。核心思路是：当响应式数据需要频繁拆解、单点传递、类型灵活或逻辑分散时，用 ref 更可控。
适合用 ref 替代 reactive 的典型场景
这些场景下，强行用 reactive 反而增加复杂度，ref 反而更轻量、更一致：
-
组件内多个独立状态变量：比如
loading、error、searchQuery、page—— 它们彼此无强关联，各自生命周期和更新逻辑不同。用ref声明，语义清晰，修改不互相干扰。 -
需要把单个字段传给子组件或 composable：例如把
user.name作为 prop 传入子组件。若用reactive，必须先toRefs或手动解包；而用ref，直接传userName即可，子组件接收后仍是响应式，无需额外处理。 -
存在动态 key 或运行时结构不确定的对象：比如表单项由后端配置生成，字段名不固定。用
reactive({})初始化后，新增属性可能触发不了响应（Proxy 对已有对象新增属性默认可响应，但某些嵌套或深层赋值路径仍易出错）；而用ref({})+value赋值，逻辑更显式、更可预测。 -
与 TypeScript 类型推导配合更友好：例如
const filters = ref({})，类型明确、补全精准；而reactive在泛型推导上有时会丢失细节，尤其涉及嵌套或联合类型时。
如何平滑过渡并保持一致性
统一用 ref 不代表放弃 reactive 的优势，而是有策略地收口。关键是建立团队可遵循的约定：
- 所有基础类型（
string、number、boolean、null）一律用ref，不讨论是否“该用 reactive”。 - 对象/数组若只作为整体使用（如整个
formState传给一个表单组件），可用reactive；但一旦出现解构、单字段暴露、watch 某个子属性等需求，立刻改用ref包裹。 - 对外暴露的状态（如 composable 返回值）优先返回
ref，哪怕内部用reactive管理，最后也通过toRef或computed转成 ref 输出，保证调用方接口统一。 - 模板中保持简洁：无论脚本里是 ref 还是 reactive，模板写法完全一样（
{{ count }}、{{ user.name }}），无需关心背后实现。
一个实际对比示例
假设管理一个搜索面板：
不推荐（混合风格，易出错）：
const state = reactive({
keyword: '',
page: 1,
loading: false,
results: [] as Item[]
})
// 解构后失去响应性
const { keyword, page } = state // ❌
推荐（全 ref，清晰可控）：
const keyword = ref('')
const page = ref(1)
const loading = ref(false)
const results = ref<Item[]>([])
// 传递给子组件或 watch 都直接可用
watch(keyword, () => { /* ... */ })
代码行数略增，但可读性、可维护性、可测试性显著提升，且消除了 toRefs、.value 混用带来的混乱。
