状态碎片化源于项目中状态随意分散、过度拆分、缺乏业务收敛，如用户信息多处冗余存储、订单字段跨多个store管理；应按业务边界归一化归属、切断无效响应链、统一通信路径，并用工具验证真实瓶颈。
状态碎片化不是 Vue 本身的缺陷，而是项目中把状态随意分散、过度拆分、缺乏收敛导致的——比如同一份用户信息在 Pinia store、组件 data、localStorage、URL query 里各存一份，互相不同步；或者一个表单的状态被拆到 3 个 store 模块 + 2 个组合式函数 + 1 个父组件 data 中。结果是修改一处、多处失效，调试时找不到源头，内存也悄悄上涨。
按业务边界收敛状态归属
状态该放在哪，不看“能不能放”，而看“谁最该负责”。一个订单编辑页的状态，不应拆成 userStore（用户）、productStore（商品）、formStore（表单）、routeStore（路由参数）四家共管。
- 把强关联字段收进同一个 store 模块：比如 订单草稿 应包含 buyerInfo、items、shipping、paymentMethod 等全部字段，而不是每个字段挂靠不同模块
- 避免“为复用而复用”：userStore 里不需要暴露
currentUser.avatarUrl给所有组件读取，头像只在个人中心、评论区等明确需要的地方按需获取 - 对临时性、页面级状态（如搜索关键词、表格排序字段、弹窗开关），优先用组件
data或ref管理，不进全局 store
切断无效响应式链路
碎片化常伴随大量低价值响应式对象：比如把整个后端返回的原始数据直接塞进 state，其中包含千条日志、base64 图片、嵌套 10 层的配置对象——这些字段根本不会被模板读取，却持续消耗 Watcher 资源。
Ainative Vue Sdk
下载
使用 `@ainative/vue-sdk` 为 Vue 3 应用添加 AI 聊天功能。适用于以下场景：(1) 安装 `@ainative/vue-sdk`，(2) 在 Vue 组件中使用 `useChat` 组合式函数，(3) 提供……
- 用
markRaw()包裹纯数据容器：如state.rawLogs = markRaw(res.data.logs)，阻止 Vue 追踪其内部变化 - 静态或只读配置走
Object.freeze()：枚举列表、API 常量、权限码映射表，初始化后就冻结 - 避免在 state 中存函数、定时器、EventSource、Canvas 实例等非序列化对象——它们既无法持久化，又容易引发内存泄漏
统一通信路径，减少状态“搬运工”
当状态必须跨组件使用时，别靠 props 层层透传 + emit 层层上抛，更别用事件总线手动同步多个副本。
立即学习“前端免费学习笔记（深入）”；
- 父子组件间：用
v-model或v-bind="state"扁平传入，子组件内部用defineModel()（Vue 3.4+）双向绑定 - 深层嵌套或兄弟组件：用
provide/inject传递只读状态，或注入一个封装好的操作函数（如inject('updateOrder')），而非暴露整个 store - 跨路由/模块：Pinia 中通过
storeToRefs+computed派生精简字段，让组件只订阅真正关心的值，避免监听大对象全量变更
用工具验证是否真“碎”了
别凭感觉说“状态太碎”，要看到真实瓶颈：
- 打开 Chrome DevTools → Memory 面板 → 录制堆快照，筛选
Proxy和VueComponent实例数量是否异常增长 - 在 Pinia 的 action 中加简易日志：
console.log('[order] update called, payload size:', JSON.stringify(payload).length) - 用 Vue Devtools 的 Timeline 查看 state 变更频率：如果每秒触发几十次
updateOrder，但 UI 几乎不动，说明状态更新逻辑没收敛
