深层对象嵌套本身不慢，慢的是反复访问、遍历、响应或序列化时的额外开销；关键在识别“谁在何时以何种方式触碰它”，扁平化本质是缩短高频操作路径。
深层对象嵌套本身不慢，慢的是你反复访问、遍历、响应或序列化它时付出的额外成本。识别性能问题的关键，不是看“有没有嵌套”，而是看“谁在什么时候以什么方式触碰了它”。扁平化状态树，本质是把高频操作路径变短、变直、变可控。
从访问模式中识别性能隐患
以下信号往往预示嵌套结构已开始拖累性能：
-
循环中重复写长路径：比如
item.user.profile.settings.theme.color在 for 循环里被读取十次——现代引擎虽优化了属性缓存，但路径解析+多层查表仍比单层访问多出数倍指令周期 -
响应式框架频繁触发依赖收集：Vue 或 React + Redux 中，一个
{a: {b: {c: {d: value}}}}的对象，修改d可能导致四层代理 trap 被逐级调用，而扁平结构如{a_b_c_d: value}一次就能定位 - 序列化/深克隆耗时明显：JSON.stringify 或 structuredClone 对含 10 层嵌套的对象，耗时可能是同数据量扁平结构的 3–5 倍，尤其当存在循环引用或大量 null/undefined 时
- 调试器展开卡顿或 DevTools 显示缓慢：这不是错觉——Chrome 和 VS Code 在渲染嵌套过深的对象树时，会主动限制递归深度并延迟加载子节点，说明底层已有性能规避机制
扁平化不是去掉嵌套，而是重构访问契约
扁平化不是强行把所有对象拍成一维数组，而是让“数据如何被使用”决定“数据如何被组织”。核心原则是：把经常一起读、一起改、一起传输的字段聚合成逻辑单元，再用可预测的键名访问。
-
用语义化键替代路径导航：例如将
user.addresses[0].street改为user_primary_street，或更进一步，按业务场景建模：shipping_address_street、billing_address_street -
分离读写关注点：展示层需要扁平字段（如
fullName），而编辑表单仍可保留原始嵌套结构；通过 selector 或 computed 层做一次转换，避免每次渲染都现场拼接 -
对 ID 关联型嵌套直接转为查找表：比如
posts: [{ author: { id: 1, name: 'A' } }]→ 扁平为posts: [{ authorId: 1 }], users: { 1: { name: 'A' } }，既节省内存，又支持按需加载和复用
何时可以保留嵌套？明确它的代价
嵌套不是原罪，但必须清楚它被使用的上下文：
- 配置类静态数据（如 theme、i18n messages）：层级合理（≤3 层）、不频繁更新、不参与响应式追踪，嵌套可读性反而更高
- 临时中间结构（如 API 请求体组装）：生命周期短、不进状态树、不被多次遍历，无需过度扁平
- 工具函数入参（如 deepMerge、treeFlatten 输入）：这些函数本就为处理嵌套设计，反而是扁平化后要先 re-structure 才能传入，得不偿失
验证扁平化是否有效：两个轻量指标
改完别只靠感觉，用两分钟验证：
- DevTools Performance 面板录一次典型操作：对比前后 “Scripting” 时间占比，若减少 15% 以上，说明 V8 的属性访问/代理开销确有改善
-
打印 JSON.stringify 后的字符串长度与嵌套深度：用
JSON.stringify(obj, null, 2).split('\n').filter(l => l.includes('{')).length粗略估算最大嵌套深度；降到 ≤4 通常意味着大部分路径已足够短
