题目重点：用删掉的复杂度、仍保留的要求和失败边界证明“简单”有实际价值。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 本文给回答训练框架，不编造候选人的个人经历、业务数字或面试官评分。
- 选本人能解释决策与执行细节的真实案例；训练例均为虚构情境，实际回答须换为可核验证据。
解题路线
- 先写问题为何复杂：耦合、手工步骤、状态数量或历史约束；不是故意把简单问题讲复杂。列不可删的核心需求。
- 说明看穿复杂度的分析过程，找重复抽象、可取消中间状态或过早设计；至少解释一个曾考虑但放弃的重方案。
- 简单方案也要有明确失败边界：不适用场景如何拒绝、兜底、升级；复杂性若转移给运维或用户，仍需计入总成本。
- 结果可看交付周期、维护点、故障面与用户步骤，但也记录能力减少和新限制。设计行数减少只能作辅证，不能替代业务结果。
- 解释如何让别人能继续维护：短合同、测试关键不变量、删除废弃流程；避免简化只依赖本人经验。
手动走一遍
虚构训练例：多个服务各自解析同一配置，改为一个带版本的声明式规则和验证器。答清哪些规则统一、哪些差异保留，不把全部差异硬塞成大量例外。
规模与取舍
准备一版约2分钟主回答，保留约束、个人动作、反证与结果供追问；这是练习长度，不是题目规定。业务规模用本人实际用户量、周期和指标分母，不能套用训练数字。
易错点与追问
容易失分的边界
- 只报少写几百行代码。
- 复杂度转给用户却不说明。
- 省掉可靠性保障就称简化。
继续深挖
- 哪些要求被删了，谁同意？
- 简单方案何时会失效？
- 别人接手后的维护成本怎样验证？
