解决全局状态变更问题的关键在于精准控制影响范围、隔离更新路径、按需同步，具体包括：按功能域分片管理状态、避免无差别广播式更新、控制更新粒度与时机、引入中间层做变更过滤与路由。
大型应用中全局状态变更容易引发不必要的重渲染、跨组件连锁更新、响应延迟等问题。解决的关键不在于“禁止全局状态”，而在于精准控制变更影响范围、隔离更新路径、按需同步。以下是几个切实有效的方向：
按功能域分片管理状态
把庞大全局状态拆解为逻辑独立的模块，每个模块只暴露自己负责的数据和操作接口。 - 分片后，一个模块的状态变更不会触发其他模块的监听器响应 - Bilibili-Evolved 就采用“分片自治”架构，配合 Proxy 深层代理，确保只有真正被读取或修改的字段才触发更新 - Vue 中可用 Pinia 的 store 模块化，React 中可搭配 Zustand 的 `create` 多实例或 Redux Toolkit 的 `createSlice`
避免无差别广播式更新
全局状态库默认可能让所有订阅者响应任意变更，这是性能隐患源头。 - 使用 `React.memo` + `useSelector` 的自定义 selector（Redux），只订阅关心的字段 - Pinia 中用 `storeToRefs` 或直接解构计算属性，避免整个 store 对象变化引发组件重绘 - 鸿蒙 V2 的 `RefreshMode.PARTIAL` 是个好参考：仅当组件自身或其直接依赖状态变化时才刷新，需配合 `@State` / `@Prop` 正确声明
控制状态更新粒度与时机
频繁小变更比批量大变更更伤性能，尤其涉及跨层级传递或序列化时。 - 合并连续变更：如输入框防抖后提交，而非每次 keystroke 都 dispatch - 避免将整个对象（如数组、嵌套结构）作为 `@Prop` 传入子组件——鸿蒙文档明确指出这会导致“系统判定整个对象已变”，从而强制重绘 - 对高频更新字段（如计时器、鼠标位置）单独抽离为局部状态，不纳入全局 store
引入中间层做变更过滤与路由
在状态写入与视图响应之间加一层轻量协调逻辑，实现“有选择地通知”。 - 类似 Vuex 的模块命名空间 + action 类型前缀，让组件可精确订阅 `user/*` 或 `cart/*` 类型变更 - 使用事件总线（如 mitt）替代全局 store 订阅，对非核心状态走松耦合通信 - 跨端场景下，用 `BroadcastChannel` 或平台中间件拦截 action，只同步必要字段，跳过 UI 相关临时状态
不复杂但容易忽略
