对象过度嵌套本身不是错误，但当嵌套层级超出业务语义所需或缺乏明确边界时，会拖慢查找效率、抬高理解与修改成本；识别关键在于观察运行是否卡顿、结构是否反映真实领域关系、协作是否频繁绕过、历史是否被动累加。

对象过度嵌套本身不是错误，但当嵌套层级超出业务语义所需、或缺乏明确边界时，会直接拖慢查找效率、抬高理解与修改成本。识别这类问题，关键不在于数“有多少层”，而在于观察它在运行和协作中是否开始“卡住”。

看运行时：查找路径是否在反复穿透

当一个常用字段需要写成 obj.a.b.c.d.e.value 才能访问，且该路径在多处高频出现，就已暴露风险：

• 每次访问都触发多次属性检查和空值判断，容易引发 TypeError: Cannot read property 'x' of undefined
• 调试时无法快速定位数据来源——你得逆向查清 a 从哪来、b 是否总存在、c 是计算所得还是原始字段
• 如果其中某层（如 c）是异步加载的，整个链路会变成脆弱的“条件依赖”，一处未就绪，全链失效

看结构设计：是否存在无业务含义的中间容器

嵌套应反映真实领域关系，而非技术拼凑。以下模式值得警惕：

• 纯包装层：比如 response.data.payload.content.body.items[0].detail.info.name，其中 payload、content、body 并不对应业务实体，只是 API 网关或序列化工具强加的壳
• 同质化扁平结构被强行分层：例如把一组并列的配置项拆成 config.ui.theme.color.primary、config.ui.theme.font.size、config.ui.layout.margin.top，实际 theme 和 layout 并非继承或组合关系，只是分类标签
• 类型定义与实现脱节：TypeScript 中声明了 interface User { profile: { info: { name: string } } }，但后端返回却是扁平的 { name: "...", email: "..." }，前端靠中间转换函数硬塞进三层结构——此时嵌套是假象，维护负担却是真实的

看协作反馈：团队是否频繁重写/绕过该结构

可维护性崩塌往往先从人开始。留意这些信号：

• 新成员花半天才搞懂某个对象怎么构造、哪些字段必填、哪些可能为 null 或 undefined
• 多人在不同文件里重复写相似的解构逻辑，比如都写 const { a: { b: { c } } } = obj || {};，没人敢动原始结构怕影响他人
• 测试用例大量使用 mock 深层嵌套数据，且每次接口变更都要同步改十几处 fixture
• 有人悄悄新增扁平字段（如直接加 obj.fullName）来规避深层访问，形成“双轨制”数据源

看演进轨迹：历史提交是否显示嵌套在被动累加

翻看 Git 历史，如果发现：

• 近半年内，该对象的类型定义新增了 3 次 .xxx 层级，但每次都是“临时加个字段应付需求”，没有配套的重构或文档更新
• 删除某层的 PR 被驳回理由是“怕影响其他模块”，但没人能说清哪些模块真依赖它
• 有注释写着 // TODO: flatten this in next version，而这条注释已存在 11 个月

说明嵌套已从设计选择退化为路径依赖，继续放任只会让崩塌加速。