对象过度嵌套本身不是错误，但当嵌套层级超出业务语义所需或缺乏明确边界时，会拖慢查找效率、抬高理解与修改成本；识别关键在于观察运行是否卡顿、结构是否反映真实领域关系、协作是否频繁绕过、历史是否被动累加。
对象过度嵌套本身不是错误，但当嵌套层级超出业务语义所需、或缺乏明确边界时，会直接拖慢查找效率、抬高理解与修改成本。识别这类问题，关键不在于数“有多少层”，而在于观察它在运行和协作中是否开始“卡住”。
看运行时：查找路径是否在反复穿透
当一个常用字段需要写成 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 个月
说明嵌套已从设计选择退化为路径依赖，继续放任只会让崩塌加速。
