shallowReactive的核心作用是仅使对象顶层属性响应式，跳过所有嵌套层级代理；适用于数据结构深但仅表层变动、初始化卡顿或嵌套内容只读的场景。
shallowReactive 的核心作用是：让对象的顶层属性具备响应式能力，同时跳过所有嵌套层级的响应式处理。它不是“更快一点”的 reactive，而是“不递归代理深层结构”的轻量替代方案——适合数据结构深、但实际只在表层变动的场景。
什么情况下该用 shallowReactive？
关键看数据变更模式是否符合以下特征：
- 你频繁增删数组项、替换整个子对象（如
list[i] = newItem或obj.config = newConfig），但几乎不修改obj.config.theme.color这类深层字段 - 数据量大（比如含上千条记录的表格源、深度嵌套的菜单配置树），初始化时 reactive 会卡顿或内存飙升
- 嵌套内容本身是只读展示用途（如用户 profile、日志详情），不需要监听其内部变化触发更新
和 reactive 相比，性能优势在哪？
差异不在“速度”，而在“代理范围”：
Ainative React Sdk
下载
使用 @ainative/react-sdk 为 React 应用添加 AI 聊天和积分。适用于 (1) 安装 @ainative/react-sdk，(2) 使用 useChat hook 实现聊天完成。
- reactive 遇到对象会递归遍历，为每个嵌套对象创建 Proxy 实例 + 依赖收集系统；一个含 500 个子项的数组，可能生成数千个 Proxy
- shallowReactive 只给最外层对象加一层 Proxy，内部所有值（包括对象、数组、class 实例）都保持原始状态，不触发任何嵌套代理逻辑
- 结果是：初始化耗时从 O(n) 降为 O(1)，内存中 Proxy 实例数量锐减，GC 压力明显降低
怎么用才安全、有效？
避开常见陷阱，才能真正发挥价值：
立即学习“前端免费学习笔记（深入）”；
- 只用于组件顶层状态，不要把它嵌套在 reactive 对象里——否则响应行为不一致，调试困难
- 深层字段修改不会触发更新，如果偶尔需要手动触发（比如编辑了
state.user.profile.bio），应配合triggerRef或改用ref封装该字段 - 含第三方类实例、DOM 节点或已有状态的对象，建议先用
markRaw包裹再传入 shallowReactive，彻底避免误代理 - 若数据整体替换频繁（如
chartData.value = newBigDataSet），优先考虑shallowRef，它比 shallowReactive 更轻量
搭配 readonly 实现更精细控制
很多场景其实只需要“表层可变、深层只读”：
- 用
shallowReactive确保数组长度变化、项替换能响应 - 再用
shallowReadonly包裹其子对象（如shallowReadonly(state.items[0])），防止误改深层字段 - 组合写法示例：
shallowReactive({ list: shallowReadonly(largeItems) })
