过多层级的条件分支会让表单逻辑难以调试与维护
别名: 条件嵌套 · 表单状态爆炸 · combinatorial reveal · 分支太多
概念解释
一层条件（「需要发票 → 抬头」）人还能在脑子里仿真。三层以上——国家决定税号，税号种类决定附件，附件种类再决定声明——合法组合数按乘法涨，没有人能在改一处时穷举所有路径。难以调试与维护指的是产品、设计和工程都无法再对「某种选择组合下表长什么样、提交什么」给出单一答案。用户侧的可预期、隐藏值交不交、朗读顺序，都会被这团分支拖垮，但那些是症状；这里的对象是分支深度本身。
机制
每个条件是一个布尔，嵌套是笛卡尔积。五层二进制条件有三十二种可见形态，还没算多选。人（含作者）的工作记忆盛不下这张表，回归只能靠碰巧点到的路径。第二层是局部修改的非局部效应：给第三层加一个选项，第一层某个看似无关的国家会突然少一块或多一块，因为共享了同一段显隐函数。没有单一的「当前分支快照」，测试写的是屏幕而不是组合。修复一个隐藏值仍提交的 bug，会在另一组合里把该清的值清掉。分支还与校验、草稿、预填缠在一起：某一组合下必填的字段在另一组合里根本不在 DOM。维护成本在第三层附近开始超过「再加一个条件」的产品收益。
怎么研究
对现有表数最大嵌套深度和可达组合数。用决策表列出每一组合的可见字段与提交字段，看有没有人能填完这张表。比较「展平为多步向导、每步最多一层条件」与「单页深嵌套」。
自变量：最大嵌套深度、组合是否可枚举、是否有分支快照测试。 因变量：漏测组合数、一次改动引发的回归数、作者能否预测某组合的提交载荷、修复时长。
用户测试覆盖不了组合爆炸，容易低估。组合覆盖率（哪怕两两组合）比完成率更能说明这条。不要用「用户没投诉」证明分支可维护——用户只走自己那一条。
边界
税务、医疗、保险的真实世界就是深分支，不能为了好维护而假装规则是平的；应把深规则放进规则引擎和分步，每屏只暴露一层选择，而不是在一屏堆三层下拉。权限不同看到不同字段是授权，不是条件显隐，不要用同一套 if 嵌套实现。AB 实验同时打开多套条件，会把组合数再乘一截，实验期间必须冻结深度。
怎么落地
- 给条件设深度上限：一屏最多一层；更深的规则拆到下一步或规则引擎，不要在同一渲染函数里套三层。
- 为每个合法组合生成可见字段清单和提交字段清单，作为测试快照；改一处条件必须跑快照。
- 新产品需求若要把第 n 层再分叉，先问能不能变成独立任务而不是再套一层。
- 验证：画出当前表的条件树，深度超过两层的节点列出其组合数。随机抽一个组合，让未写过这段代码的人根据文案预测提交载荷，预测失败即不可维护。把第三层折进下一屏后，看回归测试是否从「靠手点」变成「靠快照」。