第 27 章 业务迭代的循环：在已有系统上叠加新需求
副题：增量——迭代 = 一次一次的增量（需求增量/代码增量/债增量）；业务永不停止，系统在约束中演进；每次迭代都是全书地图走一遍
第 26 章拆完了服务：支付、内容、用户，3-4 个服务各自独立演进。业务不会停在"拆完"——新需求来了：老周说"加个二手拍卖"。不是从零开始，而是在这个已经长成的系统上叠加。本章回答：一次迭代，怎么在已有系统上走完第二遍全书地图？
本章要建立的认知
- 迭代是常态，不是例外：业务永不停止，每次迭代都是第 2 章演进循环的一次实例——全书地图（第 1 章）走第二遍；
- 变化从"重来"变成"增量"（第 4 章原话）：三分类让新需求变成"有据可查的增量"，不是"全员恐慌"；
- 迭代有张力与停止点：节奏 vs 质量、功能 vs 还债——什么时候该停下来（重构/还债/再评估），是迭代的边界问题。
27.1 新需求来了：二手拍卖
阶段 5 之后的一个周一，老周说："社区里很多人问能不能卖二手，加个拍卖吧——卖家挂东西，买家出价，价高者得。"
为什么迭代是"考验"（它是"在已有系统上叠加"的难度预告）：从零开发错了可以推倒重来（没用户没数据）；迭代错了要面对真实用户和真实数据——改坏了订单（17 章）、上线挂了一小时（24 章）、迁移丢了数据（14 章）——迭代的每一步都是"在刀尖上做增量"——这也是为什么前 26 章的所有体系（测试/流水线/灰度/监控）在迭代里全部派上用场：迭代不是"重新开始"，是"用全部体系再走一遍"。
这一次与第一次的区别（它是"为什么迭代难"的起点）：第 4 章的"一句话需求"是在空白上（没有系统，从零建）；这一次是在已有的系统上——30 万行代码（26 章）、3-4 个服务、百万级数据（14 章）、线上跑着真实用户和真实交易（17 章）——"加功能"的每一步都在触碰"已有的东西"：改表要迁移、改接口要兼容、改代码要回归、上线要灰度——迭代的难度不在"新功能本身"，在"新功能与旧系统的关系"。
"迭代"与"版本"（它是"一圈"的边界）：迭代的产物是版本（v2.1/v2.2——7 章版本化思想的业务版）——版本的命名与节奏（每圈一个版本号，功能清单跟着版本走——业务方说"2.3 版本有拍卖吗"，需求清单回答）——版本是迭代的"刻度"：发布单（23 章）按版本、回滚按版本（21 章制品）、复盘按版本（24 章）——迭代靠版本记账，版本靠迭代产生（一对互相定义的概念）。
迭代与工程师成长的衔接（它是"为什么写这一章"的提示）：1-3 年工程师每天做的最多的事就是迭代——但多数人的迭代是"按需求改代码"，不是"走循环"——差在哪？按需求改代码（只做开发段）vs 走循环（需求翻译/决策/测试/发布/监控全参与）——本章的全部意义：把"做迭代"升级成"走循环"——同样 2 周，走循环的人积累了完整的方法论，只做开发的人积累了改代码的手感（第 28 章成长路径的伏笔：成长=循环的参与度）。
本章与第 1 章"如何读这本书"的呼应（它是"读书方法"的收官）：第 1 章说"每一章的对应表都试着替你的项目填一遍——填不上的那行就是你的认知缺口"——本章就是"填表"的示范：拿拍卖需求替第 4-25 章各填一行（三分类/决策/表/接口/测试/发布/监控）——"读完本书"的检验：能不能用书里的地图，替自己的项目做一次迭代（第 1 章地图的最终用法：它是你的项目地图）。
"约束不变"的确认也展开（它是"三分类"的第三类详解）：约束为什么也要确认——约束悄悄变化是事故之源（比如"数据不能丢"悄悄变成"尽量别丢"——17 章交易不能错就崩了）——迭代里约束的确认方式：列出来，问一遍（技术栈/数据/安全/合规——4 章清单）——约束的"修订"比"新需求"更敏感（要评审——20 章轨道：改约束=改承诺）。
三分类，老规矩（4 章"打开清单看"）：第 4 章的需求清单还在，老周的话放进三分类——新增功能需求："拍卖：出价、截止、成交"（卖家挂拍卖品、买家出价、时间到价高者得）；影响的非功能需求："交易不能出错"——拍卖的截止时间是并发敏感点（最后一秒的出价和截止判定不能乱——17 章交易正确性的新场景）；约束：不变（技术栈/团队/合规——4 章的约束清单原样适用）——三分类的意义（4 章原话）：把"变化"从"重来"变成"增量"——你知道这次变化要动哪些验收标准、哪些设计、哪些代码——这就是变更的代价清单（没有清单的团队一次变化全员恐慌，有清单的团队一次变化是有据可查的增量——4 章原话）。
拍卖的"非功能"验收细节（它是"翻译"的第三类展开）：非功能需求（"交易不能出错"）在拍卖里拆成可测的验收线——并发正确（最后一秒出价：并发压测（24 章）验证 1000 并发出价+截止，成交唯一）；性能（出价接口 P95 < 500ms——7 章预算风格）；安全（出价要登录（13 章）、不能越权改别人的拍卖（19 章授权）——"老规矩"清单：认证（13）/授权（19）/限流（24，出价防刷——拍卖是攻击目标：恶意抬价）——非功能验收 = 前面所有章节的检查清单（迭代里"非功能"不是新东西，是已有体系的复用）。
"变化管理"的团队侧（它是"业务侧"的沟通）：迭代里业务方和工程师的对话——老周说"拍卖加个功能"，工程师说"这圈排不排得进"——对话靠什么：需求清单（三分类+影响评估——"这圈能做什么"有了依据）；版本（27.2："2.4 版本做"）；优先级（4 章砍需求的标准：不做它不影响核心闭环——"出价提醒"排下圈）——迭代的沟通工具：清单+版本+优先级（不是"尽量快"的模糊承诺——"什么时候好"永远有答案（版本号）——这是业务方信任工程师的基础）。
第一版的范围（"砍需求"的第二次实例——4 章的做法）：老周的完整想象里还有——出价提醒（卖家收到通知）、流拍重挂、信用分……第一版砍掉：出价提醒先不做（通知链路 17 章已有，但拍卖的提醒是锦上添花——4 章砍需求的标准：不做它不影响核心闭环）、信用分不做（第 4 章砍掉的"先不做搜索"同款逻辑：复杂度没到）——第一版拍卖 = 挂拍卖品 + 出价 + 截止成交 + 订单流转（订单复用 17 章的——26.4 说拍卖落交易域，订单链路现成）。
27.2 迭代循环是什么
迭代循环与第 1 章地图（它是"走第二遍"的收官定位）：第 1 章说全书地图是"一张地图放大五次"（技术线）加"一条工程线"——本章的位置：业务迭代是地图的"使用说明书"——第一次走地图是学（4-26 章），本章是"地图在真实业务里怎么转"——读完本章，地图的第二次走法你也拿到了：三分类（业务线入口）→ 决策（方法论）→ 设计（技术线）→ 测试发布监控（工程线）——三条线在一圈里全部经过（第 1 章地图的收官：地图不是知识清单，是操作流程）。
迭代与 26 章的关系（它是"架构之后怎么走"）：26 章拆完服务，迭代在新的架构上继续——架构演进让迭代更快（独立服务独立发布——20 章发布互相踩消失）——迭代又推动架构演进（迭代中触发的演进条件——27.7 停止点三）——架构与迭代是互相喂养的循环（拆→更快迭代→更多功能→更复杂→再拆——第 2 章循环的"结构版"）。
迭代循环的"八段"对照全书（它是"第二遍"的目录级对照）：需求（第 4 章）→ 技术决策（第 5 章）→ 设计（第 6-7 章）→ 开发（第 8-14 章）→ 测试（第 18 章）→ 发布（第 21-23 章）→ 监控（第 24-25 章）→ 下一轮——第二遍走地图 = 八段环的每一段，都有前面章节的现成工具（这是第二遍比第一遍快的根本原因：工具都在）。
迭代（iteration）：一次"需求 → 决策 → 设计 → 开发 → 测试 → 发布 → 监控"的完整循环（图 27-1）——第 4-25 章的全部动作，压缩成一圈——本书前半本是"第一圈"（从零到上线，走了 22 章），从本章开始，每一圈都走一遍但快得多（经验、体系、代码都在——9 章说"框架让迭代更快"，20-25 章的体系让每一环都有现成工具）。
迭代与 20 章"流程是团队的函数"（它是"迭代的规模适配"）：迭代的"严与松"跟着团队走——1 人团队（阶段 1）：一圈=想到就做（最少的流程——20 章）；8 人团队（阶段 4）：一圈=PR+评审+流水线（20/22 章）；30 人团队（阶段 5）：一圈=评审+灰度+监控+复盘（全套）——迭代的流程和架构一样，是团队的函数（20 章思想的收官：流程、架构、迭代，同一个函数）。
"这圈"的实景（它是"八段环"的具象）：拍卖迭代的 2 周——第 1 周：需求三分类（周一）→ 决策（周二）→ 设计表/接口（周三）→ 开发（周四-下周二）——第 2 周：测试（周三-周四）→ 发布（周五）→ 监控（周五下午+下周）——八段环在 2 周里转完一圈——注意：八段不是八周，是八种工作（可以并行/压缩——需求翻译半天、决策半天、设计一天、开发五天、测试两天、发布半天、监控持续——八段的"时长配比"是迭代的经验值）。
迭代与"第 2 章"的关系补一笔（它是"循环"的总收）：第 2 章的演进循环是宏观的（业务复杂度→架构），迭代循环是微观的（需求→功能）——两个循环的接口：微观循环积累业务复杂度（每圈多一点），宏观循环处理它（演进条件触发）——全书的结构就是这两个循环的交替（第 1 章地图：业务线是微观循环的输入，技术线/工程线是微观循环的工具，宏观循环在第 26 章）——第 27 章站在两个循环的交点上。
每次迭代 = 第 2 章演进循环的一次实例（它是"循环"的理论版）：第 2 章说"业务复杂度上升→原方案无法承受→新技术出现"——迭代的每一圈都在检查这件事：这圈跑完，业务复杂了没有？原方案还承受得住吗？（承受不住=26 章那种架构动作）——演进循环是"大循环"（架构），迭代循环是"小循环"（功能）——小循环积累成业务增长，大循环处理小循环攒下的结构性变化（26 章的拆，就是四轮大循环的结果）。
图 27-2 与第 1 章地图的关系（它是"走第二遍"的具象）：第 1 章的全书地图（三条线：业务线/技术线/工程线）——第一次走：第 4-15 章（设计→请求走通）、第 16-20 章（快对稳防久）、第 21-25 章（交付/运行）、第 26 章（架构）——第二次走：本章的八段环，把三条线压缩成一圈——同一个地图，第一次是"学"，第二次是"用"（1 章说地图是拿来用的——本章就是"用"的示范：新需求来了，地图在脑子里自动转起来——"读完全书"的检验标准：遇到新需求，能不能自己在脑子里把八段环走一遍（本章就是这份检验的模拟卷）。
迭代的"复盘"与第 2 章演进循环（它是"圈内的小循环"）：每圈复盘（27.2 说过）里有一个固定问题：这圈跑完，业务复杂了吗？原方案承受得住吗？——承受不住的两个信号（26.1 的协作/数据信号在迭代尺度上出现）→ 触发大循环（26 章架构动作）——小循环（迭代）与大循环（演进）的接口：复盘中的那一问（第 2 章循环在迭代时代的落地：每圈都问，永不忘记）。
演进条件的检查放进迭代（5 章兑现——"把'检查演进条件'放进迭代节奏"）：每个决策记录都写了演进条件（缓存=首页变慢、JWT=多服务、K8s=几十容器……）——迭代时顺带检查：这个条件触发了没有？（触发=重评估该决策）——演进条件检查是迭代的"体检项目"：功能迭代做"功能体检"，演进条件做"架构体检"——体检的频率跟着迭代走（每圈一次，不会忘——5 章原话）。
迭代的"节奏"设计（它是"一圈多久"的实践）：功能迭代 2 周（阶段 5 的节奏——区别于 MVP 的三周和交易功能的两周：体系越成熟，一圈越快）——节奏固定的三个好处：可预测（业务方知道什么时候能用上——22 章发布周期）；可休息（团队知道什么时候发版——冲刺不是常态）；可复盘（每圈结束的复盘（24 章）有固定时点——复盘进迭代：每圈 30 分钟，哪环慢了/哪环出错了/下圈改什么——25 章排障复盘的同款，功能版）。
两种迭代的节奏（20 章兑现——"还债迭代在迭代循环里会有它的位置"）：功能迭代（加新功能——本章主线）和还债迭代（20 章技术债的"定期专门还债"）——节奏建议：三圈功能 + 一圈还债（功能债不还，迭代会越来越慢——20 章"债积累到无法承受就是还债日"——与其被动还，不如主动排期）——"还债迭代"里做什么：重构烂代码（12 章）、补测试（18 章）、补文档（20 章）、升级依赖（21 章）——还债迭代没有新功能，但下一轮功能迭代会快 30%（这是还债的"收益账"）。
27.3 需求：第二次翻译
迭代的第一段：需求分析——第 4 章的"翻译"（业务语言→技术语言）再来一次，但这次要翻译的东西更多（新增+影响+约束）。
拍卖的"状态机"（它是"新功能的老规矩"的第一件）：拍卖品有生命周期——PENDING（待开始）→ ACTIVE（进行中）→ ENDED（已结束）→ 成交/流拍——17 章状态机的原样复用：状态转移表（谁能从 PENDING 到 ACTIVE？开始时间到；ACTIVE 到 ENDED？截止时间到——非法转移被拦住：ENDED 后不能出价）——为什么新功能也配状态机：拍卖和订单一样是"时间敏感+并发"的业务（状态机防乱序——拍卖的出价乱序=成交错误）——状态机不是"交易的专属"，是"有状态业务的通用武器"。
"影响评估"的实景（它是"改动影响评估"的具体）：拍卖的每个需求问"碰到什么"——挂拍：碰商品表（6 章）？不碰——新表 auction；出价：碰用户认证（13 章——出价要登录）、碰限流（24 章——出价防刷）、碰并发（17 章——截止判定）；成交：碰订单链路（17 章——复用）、碰支付（17 章——复用）、碰对账（17 章）——评估的产出：一张"触碰清单"（每个需求点碰哪些已有系统）——清单就是开发计划（按触碰点排开发顺序——25 章排障思路的开发版）。
拍卖的三分类展开（它是"第二次翻译"的实景）：
- 新增功能需求 → 功能清单：挂拍（卖家发布拍卖品：起拍价/截止时间/加价幅度）、出价（买家出价：必须高于当前价+幅度；最后一分钟保护——截止敏感）、成交（时间到，最高价者得——并发点：最后一秒的出价与截止判定的先后）、订单流转（成交后走订单链路：支付/发货/确认——复用）；
- 影响的非功能需求 → 验收标准："交易不能出错"（验收清单）在拍卖场景的具体化——"截止时间到，正好有人出价，结果必须确定且唯一"（这一条就是拍卖的验收标准——能写出来，就可以开始开发（"第一批验收标准可用=停止点"））；
- 约束 → 确认不变：技术栈（5 章）、数据不能丢（4 章）、安全基线（19 章）——约束不变的确认也要做（迭代中"悄悄放宽约束"是事故之源——22 章"约束是承诺"）。
"截止时间"的并发设计（它是"交易不能出错"的拍卖版——必备 2 的机制）：拍卖的"时间到"和出价的先后，是并发问题（17 章的并发思维）：实现要点——截止判定用数据库事务+状态检查（出价时检查 auction 状态仍为 ACTIVE，截止时把状态改为 ENDED——状态机（17 章）原样：PENDING→ACTIVE→ENDED，非法转移（出价发生在 ENDED 后）被状态机拦住——17 章的防线（状态机/事务/幂等）在拍卖里一套不少——"新功能的老规矩"：17 章防线原样照搬。
验收标准与迭代的关系（它是"验收"的两次形态）：第一次（4 章）验收标准是开发前的约定（写下来才开工）；迭代里验收标准是开发后的检验（测试用例（18 章）+监控指标（25 章））——同一个清单，两种用法——迭代的验收清单会变（需求变了/用户反馈了/债还了）——清单是活的（4 章：需求永远不会完整——清单永远在更新）。
需求分析的新动作：改动影响评估（它是"第二次翻译"的新增项）：第一次翻译没有"旧系统"，第二次有——每个需求都要问"它碰到哪些已有的东西"：碰表吗（6 章重审）、碰接口吗（7 章兼容）、碰流程吗（20 章协作）、碰数据吗（14 章迁移）——影响评估 = 变更的代价清单（4 章说的"有据可查的增量"——评估就是那张清单的编制）。
"第一条验收标准"的检验（它是"可以开工"的检查）：写出的验收标准能不能测？——拍卖的三条验收标准全部可测（① 出价成功条件（金额/时间判断）② 成交唯一（并发压测断言）③ 订单流转（E2E）——每条都能写成测试用例（18 章））——"能写成测试"=可以开工（4 章"第一批验收标准可用"的检验方式——迭代版：标准进了测试用例，才叫可用）。
分析瘫痪的防线还在：新需求同样会"分析瘫痪"（拍卖的规则能讨论一个月：悔拍怎么办/出价撤销/异常出价……）——防线同款：写第一条验收标准就开工（4 章原话：需求分析的正确停止点是"可以开始试错"）——拍卖第一版的三条验收标准：① 出价高于当前价且时间未到 → 成功；② 截止时间到 → 最高价者成交且唯一；③ 成交 → 订单进入 17 章订单流程——三条够开发了，剩下的交给迭代（第二圈再加）。
27.4 决策与设计：复用还是新建
迭代的第二、三段：技术决策 + 设计——这一次的决策比第一次小，但一样要九步（第 5 章模型第 20 次应用）。
这次决策与第 5 章的关系（它是"模型越用越轻"的证明）：第 5 章的九步完整走（选技术栈）、第 17 章完整走（交易机制）、第 26 章完整走（拆服务）——本次九步轻量走（3-4 个候选、维度三四个——决策模型不是每次都全量，是每次都有框架：小决策小走，大决策大走（5 章"九步走到极简时就是这样"——原话兑现）——决策记录的又一行：拍卖复用交易域——将来被质疑时有答案（"为什么拍卖不拆独立服务"——记录里写着演进条件）。
决策记录的"第二十行"（它是"决策记录"的收官盘点）：第 5 章那张表，到本章已经填了二十行——语言/数据库/前端框架/CDN/认证/缓存/测试投入/安全投入/工作流/自动化/K8s/可用性目标/告警策略/拆服务/消息队列/拍卖方案……——每一行都是"业务逼出技术"的坐标（26 章说过）——迭代时代决策记录的新用法：每圈可能有新行（小决策也记——"出价提醒用现有通知链"也是一行）——决策记录的完整生命周期：写下→执行→被演进条件触发→重评估→更新（5 章模型的收官：记录是活的）。
★ 拍卖的技术方案——九步决策第 20 次（决策记录又添一行）： ① 目标：拍卖功能上线，不动摇已有系统；② 约束：3-4 个服务（26 章）、订单链路现成（17 章）、迭代周期 2 周；③ 问题：拍卖的代码放哪？④ 候选：A 独立拍卖服务（新服务+新库）；B 并入交易域（复用订单/支付服务，新增拍卖模块+拍卖表）；⑤ 维度：边界匹配（26 章：拍卖属于交易域）、复用收益（订单/支付/对账现成）、独立成本（新服务=新部署/监控/链路——25 章×N）；⑥ 打分：A 的独立服务在"拍卖只是交易的一种形态"面前过度——拍卖的成交就是订单（17 章），拆出去=订单链路跨服务（26.4 的分布式复杂度白付）；B 的复用——拍卖表进订单域（6 章边界：拍卖品是商品的变体——商品表加拍卖字段还是新表？重审（6 章）：拍卖品有独立生命周期（起拍/出价/截止）→ 新表 auction + 出价表 bid，商品表不动——改表贵的账：能不改就不改，必须改趁早（6 章原话））；⑦ 选择：B（复用交易域，新增拍卖/出价表+模块）；⑧ 收益：订单/支付/对账/风控全部复用（17 章防线原样生效），部署/监控/链路不新增（25 章）；⑨ 代价与演进：交易服务变大（拍卖逻辑挤进来）——演进条件：拍卖业务量接近交易主业务时，再拆独立拍卖服务（26.7 的"拆的优先级=变更频率×独立性"——拍卖还小，先不拆）。
接口的"兼容性"检查（它是"在已有系统上叠加"的接口规则）：拍卖的接口是新增（v1 起步——7 章），但拍卖要调用已有接口（成交后调订单接口——17 章）——已有接口能不能加参数？——7 章规则：只加不改不删（加可选参数安全，改语义危险）——迭代的接口纪律：新增随便加，改动走 v2（7 章原话在迭代里的用法）——接口的"依赖清单"（7 章：谁在用这个接口——下线流程）在迭代里也重要：改接口前先查清单（有没有别的服务/前端在用——26 章服务间调用）。
设计的"改动最小化"原则（它是"设计段"的策略）：迭代设计的评判标准不是"最优"，是**"改动最小"**——能加表不加字段，能加字段不改表，能新接口不改接口（三级递减——6/7 章纪律的迭代版）——为什么"改动最小"优先：改动越小，回归面越小（18 章）、回滚越容易（23 章）、影响评估越简单（27.3）——迭代设计的正确姿势：在"够用"和"留余地"之间找最小改动（6 章"够用且留有余地"的迭代用法）。
本次决策与 26 章架构的呼应（它是"决策链"的收官）：26 章拆了服务（大决策），本章的"复用交易域"（小决策）在大决策的框架内做——决策的层级：架构决策（26 章）定框架，迭代决策（本章）在框架内填空——5 章决策记录的完整形态：大决策定方向，小决策填细节，演进条件串起两层（第 5 章模型的收官：决策不是一次性的，是分层的）。
设计：表与接口（它是"设计段"的实景）：
- 表结构重审（6 章兑现——"每次迭代的新需求，都把表结构拿出来重审一遍"）：现有表接得住吗？——商品表（6 章）接不住拍卖（拍卖有独立生命周期）→ 新表 auction（拍卖品：起拍价/截止时间/状态）+ bid（出价：金额/时间/用户）——新表不碰旧表（改表贵的账：这次是加表不是改表——最便宜的一种）——6 章的建模纪律再次生效：够用且留有余地（拍卖状态字段先留：PENDING/ACTIVE/ENDED——17 章状态机的风格）；
- 接口（7 章兑现）：新接口
POST /auctions、POST /auctions/{id}/bids、GET /auctions/{id}——版本化规矩照旧（v1 起步——7 章"只加不改不删"）；出价的幂等键（17 章：连点出价=重复出价——bid_no 幂等键，17 章原样照搬）——"新功能的老规矩"：第 7 章和第 17 章的设计纪律，原样用于新接口（迭代不发明新规矩）。
27.5 开发与测试：在已有系统上改
迭代的第四、五段：开发 + 测试——"改已有系统"的开发，与从零开发完全不同。
开发环境的"迭代"配合（它是"本地开发"的迭代版）：本地开发跑最新代码+测试环境数据（15 章环境分层：本地是自留地）——迭代的开发节奏：功能分支（20 章 Git 工作流）→ 本地自测（18 章）→ PR（20 章轨道）→ 测试环境自动部署（22 章）→ 联调验收（15 章）——每一步都有现成工具，开发段的"快"是体系给的（不是手速）。
拍卖开发与 17 章订单的"交接"（它是"复用"的代码实景）：成交后调订单接口——开发时读订单模块的代码（状态机/事务——代码里的机制），调用方要遵守订单接口的约定（幂等键 order_no——17 章）——"复用"的代码含义：读懂别人的机制，遵守别人的约定（6 章"边界清晰"的代码版）——拍卖开发的第一周 = 读订单代码 + 写拍卖代码（20 章知识传递：读代码也是迭代的日常）。
开发与测试的"并行"（它是"2 周怎么够"的答案）：迭代的开发段和测试段部分并行——测试先写验收标准的测试用例（18 章 TDD 思想：测试先行——验收标准定了就能写测试，不等开发完）；开发完一模块测一模块（模块级验证——27.3 的状态机/并发用例按模块交付）——迭代的"快"来自并行：需求/设计/测试并行准备，开发/测试交错推进（流水线（22 章）把每个合入都自动跑测试——并行的底气是自动化）。
开发的"局部性"（9 章兑现——"框架让迭代更快"）：声明式框架（9 章）让"加拍卖"= 加状态 + 加界面描述（加功能从全链路排查变成局部修改——9 章原话：框架的收益到迭代多了才完全显现——现在就是显现的时候）；后端同理：新增模块+新表+新接口，不动已有逻辑（26.3 边界：拍卖落交易域但模块独立——"加"比"改"安全：新增代码不影响已有行为的概率，远大于改动代码）。
"加"与"改"的比例（它是"迭代开发的策略"）：迭代里能加就不改（新模块/新表/新接口——加）；必须改才改（订单链路的现有逻辑——改）——"加"的风险是新增代码的 bug（可控——测试覆盖新代码），"改"的风险是破坏已有行为（不可控——要回归）——迭代开发的第一策略：新功能用"加"，旧逻辑少"改"（26.3 边界同款思想：加比改安全）。
测试的"并发用例"（它是拍卖测试的独特点）：普通功能的测试用例是"输入→输出"，拍卖的测试有时间维度——截止竞态（出价和截止同时发生：结果必须确定——单元测试写一个"模拟最后一秒"的用例：状态检查和出价在同一事务（27.3 的状态机），测试断言"要么出价成功要么被拒，没有第三种"）；重复出价（连点两次：幂等键（17 章）拦下）；越权（A 不能出 B 的拍卖——19 章授权）——拍卖的测试清单 = 状态机转移表 + 并发用例 + 授权用例（前面章节的测试思路，新场景重排）。
测试：回归是迭代的命门（18 章兑现）：迭代最怕的不是新功能有 bug，是旧功能被改坏——全量回归要 2 天（26 章数字——阶段 5 的真实成本）——测试金字塔（18 章）在这里兑现：单元测试（出价逻辑：高于当前价/截止判定——并发判定是单元测试的黄金用例：最后一秒出价与截止的先后，代码里一个锁/一个状态判断）、集成测试（接口：幂等出价）、E2E（核心链路：挂拍→出价→成交→订单——只跑核心路径）——回归从 2 天降到 2 小时（跑金字塔的核心层，不跑全量——18 章"测试是承诺"：承诺没变的部分，不用全验）——"迭代快"的真相：不是写得快，是回归快。
测试与发布流程的衔接（它是"测试绿了之后"）：测试全绿 → 走流水线（22 章：构建/部署测试环境）→ 发布单（23 章）→ 灰度（23 章）→ 监控（25 章）——迭代的测试不是终点，是流水线的入口（18 章说测试是承诺——22 章让承诺自动化——迭代里测试、流水线、发布、监控是一条链（21-25 章体系的迭代形态）。
契约与联调（7/15 章兑现）：新接口的前后端联调——第 7 章契约（字段/错误码/request_id 原样）、第 15 章三问（断在哪一段/卡在哪一层/数据卡在哪个环节——拍卖的联调问题照样三问定位）——服务间的契约（26 章：拍卖复用订单服务——出价成交调订单接口，契约测试兜底）——"迭代的联调"比第一次轻：契约工具、环境分层（15 章）、测试环境自动部署（22 章）都在——第一次联调是建工具，以后的联调用工具。
开发与"知识传递"（20 章兑现——"知识在不在决定能不能改"）：迭代的开发里，"这段代码为什么这样写"比"怎么写的"更重要——拍卖开发要读懂订单模块（17 章的复杂逻辑）——知识在哪：决策记录（5 章：为什么这么设计）、commit message/PR 描述（20 章）、注释——知识在，迭代就能改；知识不在，迭代靠猜（20 章原话："知识是协作的隐性基础设施"）——迭代也是对知识库的检验：新人能不能独立做一圈，取决于知识传没传到位（20 章评审教学心态）。
轨道与还债：开发走轨道（PR/评审/提交信息——20 章）——"路过就还"（改到哪段代码顺手整理旁边的烂代码——拍卖开发会路过订单模块，顺手还一点订单的债）——债在迭代里还，比专门还便宜（"偿还的节奏"：路过就还+定期还债迭代）。
27.6 发布与监控：迭代的验收
迭代的第六、七段：发布 + 监控——"上线"不是迭代的终点，是验证的开始（22 章"部署完成是运行期的起点"）。
发布前的"发布单"（它是"迭代的发布"清单）：每次迭代的发布都有一张发布单（23 章人工确认清单的迭代版）——新功能清单（这圈发了什么）、回滚方案（拍卖怎么回：关入口+切流量）、监控关注项（这圈上线重点看哪些指标——25 章）、值班确认（24 章 on-call 知道这圈发什么）——发布单是迭代的"交接文档"：开发→运维（或值班人）之间的信息桥（20 章知识传递）。
发布（23 章兑现）：拍卖上线走灰度（23.6/26.6：新版本先 1% 流量——拍卖是高风险发布（涉及钱——17 章），金丝雀是标配）：1% 用户能挂拍 → 观察（25 章指标）→ 逐步放量——回滚路径提前备好（23 章：指回制品——拍卖的发布单里，回滚=切流量+关闭入口——23 章"敢部署的前提是能回滚"）。
迭代发布与 22 章流水线的衔接（它是"发布段"的自动化）：流水线（22 章）是迭代的"传送带"——代码合入（20 章）→ 流水线自动构建/测试/部署测试环境（22 章）→ 人工确认（生产部署）→ 灰度（23 章）——迭代的发布段：人只做两个动作（确认发布单、点灰度按钮）——其余交给流水线（22 章"半自动 CD"的迭代形态：每圈都是半自动）。
"发布日"的团队分工（它是"发布段"的人）：发布日（周五下午）——开发在（出问题能马上定位——25 章）、on-call 在（24 章值班）、老周在（验收业务——27.6）——发布不是一个人的动作，是团队的仪式（22 章发布日求神拜佛的反面：有体系的发布日=确认+观察+庆祝——发布从"怕"变成"节奏"（27.2 说过：发布是节奏的一部分）。
发布的时间窗（它是"发布与迭代节奏"的配合）：迭代 2 周一圈，发布固定在每圈末尾的同一时间（比如周五下午低峰——22 章发布周期的落地）——固定发布窗口的三个好处：可预期（业务方知道周五有新功能）、可准备（on-call 知道周五要盯——24 章值班表）、可回退（发完有问题，周一前都能从容回滚——23 章）——"发布"从事件变成节奏的一部分（22 章说"发布从发布日变成随时"——迭代时代是"随时中的固定节奏"）。
迭代的"验收会议"（它是"监控数据怎么用"）：每圈末的验收——老周看功能（拍卖好用吗）、工程师看数据（指标达标吗——25 章）、一起决定（转正/回滚/下圈改）——验收会议是迭代的"关卡"（18 章测试是关卡、23 章发布单是关卡、验收会议是业务关卡——三道关卡，迭代的质量三道闸）。
监控的"功能开关"配合（它是"发布与配置"的衔接）：拍卖上线用功能开关（23.5 行为类配置：不发布也能开关）——开关的意义：拍卖出问题 → 关开关（不是回滚整个服务——23 章回滚的轻量版）→ 修复 → 开开关——"功能开关"是迭代发布的安全带（灰度（23 章）管流量，开关管功能——两层保险）。
监控：新功能的验收数据（25 章兑现——"监控数据是新功能好不好的证据"）：上线后看什么——功能指标（拍卖转化率：挂拍数/出价数/成交数——业务指标（25.3：业务指标先变））；技术指标（出价接口错误率/延迟——P95 预算：出价 500ms（7 章下单预算同款））；告警（出价接口错误率>1% 告警——25.4 规则：核心链路）——"功能好不好"不再是感觉，是指标（老周说"拍卖好像还行"→ 你给数据：挂拍 500 件/成交率 40%/出价接口 P95 300ms——4 章的验收标准（可测量），在迭代里兑现成监控指标）。
迭代的"度量"（它是"每圈好不好"的答案）：迭代本身也要被度量——圈均缺陷数（每圈漏到生产的 bug 数——18 章承诺兑现率）；圈均还债量（这圈还了多少债——20 章账本）；圈均时间（需求到上线多少天——9 章框架收益的体现）——三个数，三本账（质量/债/速度）——迭代的体检（25 章指标思想的功能版：迭代也要看得见）——度量不是为了考核，是为了"哪环慢了"看得见（27.2 复盘的数据源）。
用户反馈回迭代（它是"循环"的闭环）：监控发现异常 → 反馈进下一圈（修复迭代）；用户提新需求（"拍卖能不能加个提醒"——第一版砍掉的）→ 需求清单更新（4 章：需求永远不完整）→ 下一圈的输入——迭代循环的"环"：上一圈的输出（监控数据/用户反馈/债），是下一圈的输入（需求/决策）（图 27-1 的环闭合——第 2 章循环的业务版）。
上线后的"第一天三看"（15 章兑现——"上线后的第一天"）：15 章说上线后看三样——错误日志（拍卖有没有联调没覆盖的路径报错）、接口延迟（出价接口 P95 是否在预算内）、用户行为（有没有人真的在用拍卖——挂拍数/出价数）——15 章的"第一天"，迭代里每圈都过一遍（发布后的第一天=三看日——25 章监控已经把三看自动化了大半）。
老周的角色（4 章兑现——验收人）：老周是验收人（4 章）——迭代里他的验收从"验收功能"变成"验收业务"：功能验收交给测试（18 章）+监控（25 章），老周验收"拍卖这个业务对不对"（规则/体验/商业）——人和系统的分工：系统验"做得对不对"，老周验"做得对不对路"。
27.7 迭代的张力与停止点
迭代不是无限加速的永动机——它有张力，也有停止点（必备 4 的边界）。
张力管理的"底线清单"（它是"哪些不能松"的明确）：迭代再快，三条底线不松——测试红线（核心链路的测试必须绿——18 章）、评审红线（涉及钱/数据的改动必须评审——19/20 章）、发布红线（发布单必须齐——23 章）——三条底线是迭代的"刹车"：没有刹车的迭代不是快，是失控（24 章事故的教训：快不是目的，稳才是）。
张力：节奏 vs 质量（它是"迭代的代价"）：迭代越快，每一圈留给测试/还债/文档的时间越少——快迭代+零还债=债滚债（20 章：每次"下次再还"都是利息）——张力的管理：固定节奏（2 周一圈——节奏稳定比节奏快重要：团队知道什么时候发版（22 章）、什么时候验收（18 章）、什么时候休息）、质量线不松（测试红线/评审红线——轨道是底线不是装饰）——"快"的正确含义：稳定地快，不是冲刺地快（冲刺=下一圈还）。
迭代的"健康检查"与 24 章的关系（它是"运行期体检"的迭代版）：24 章给系统做体检（演练/容量/告警），迭代给"开发过程"做体检（27.6 的圈均缺陷数/还债量/时间）——两个体检，一个目的：在"变慢/变坏"之前看见（24 章说"出事前有信号"——迭代的圈均指标就是开发过程的"信号"——迭代也要可观测（25 章思想的过程版）。
迭代的"元认知"（它是"迭代迭代"的答案）：迭代本身也要迭代——每圈的复盘（27.2）不只是"这圈怎么样"，还有"迭代流程本身要不要改"（八段环的哪段太慢/哪段总出错——元迭代）——成熟团队的标志：迭代的流程持续被迭代（20 章"流程跟着事故长"——迭代流程跟着复盘长）。
停止点的"信号清单"（它是"什么时候停"的具体信号）：改不动了（加一个小功能要动五处代码——12 章分层被腐蚀→重构）；提心吊胆了（每次改代码都怕碰坏——18 章测试覆盖不足→还债迭代）；演进条件触发了（拍卖做大/流量再涨——5 章决策记录的演进条件→架构再评估）；事故变多了（24 章：防线漏的频次上升——复盘发现同一类事故重复出现→系统性修复）——信号不是感觉，是清单（和 26.1 的三条信号线同款：迭代的停止点也有信号——信号到，停下）。
停止点一：重构（它是"代码层面"的停）：迭代中代码开始"改不动"（加一个小功能要动五处——12 章分层被腐蚀）——停下来重构（行为不变结构变——20 章定义；测试兜底让重构敢做——18 章）——重构不是"停下"，是"让下一轮更快"（重构=迭代的投资）。
停止点二：还债迭代（它是"债层面"的停）：技术债积累到"每次改代码都提心吊胆"——停下来专门还（27.2 的三圈功能+一圈还债）——还债迭代的产出不是功能，是"改动的信心"（"决策记录+技术债=代码病历"——还债=病历清零）。
停止点与 26 章的关系（它是"小循环与大循环"的接口）：迭代中的停止点（重构/还债）解决代码层面的问题，架构再评估解决结构层面的问题——怎么知道是"代码问题"还是"结构问题"：重构还债解决不了（还了债还是慢）→ 结构问题 → 走 26 章（信号三问：协作/故障面/数据——26.1 的清单在迭代尺度上重验）——停止点的分级：先小后大（能重构解决的不用拆服务——23 章"能承受就停"同款逻辑）。
停止与业务的关系（它是"停下"的沟通）：停下来重构/还债，业务方会问"怎么没新功能了"——沟通方式：把"停下"翻译成业务语言（"这圈修地基，下圈功能快 30%"）——技术债的"业务化"（20 章账本的业务版：债=未来功能的速度）——工程师的必修课：用业务语言解释技术决策（第 1 章"翻译"的收官：翻译是双向的——业务翻译成技术（4 章），技术翻译成业务（本章）。
停止点三：架构再评估（它是"结构层面"的停）：迭代中演进条件触发了（拍卖做大→交易服务变胖→26.4 的演进条件；流量再涨→K8s 条件）——停下来走 26 章的大循环（第 2 章：原方案无法承受）——小循环和大循环的配合：小循环发现问题，大循环解决问题（27.2 说过：演进条件检查在迭代里——检查就是为了在正确的时候停下）。
迭代的"终局"不存在（它是"为什么没有终点"的答案）：有人问"系统什么时候做完"——做完不存在：业务在变（新需求）、技术在变（演进条件）、用户在变（反馈）——"完成"是一个阶段的错觉（27.1 说过）——工程师要适应的真相：你维护的不是"做完的系统"，是"永远在长的系统"——这与 1-3 年工程师的直觉相反（学校/教程教的是"做完一个项目"）——接受"没有终点"，是职业化的第一课（第 28 章的伏笔：成长也是没有终点的循环）。
业务永不停止（它是"迭代"的哲学收束）：第 2 章说演进循环是永恒的——迭代循环也一样：业务不会说"功能做完了"，用户不会说"需求提完了"——"完成"是一个阶段的错觉，迭代是常态（4 章"需求永远不会完整"——接受变化，是工程师的日常能力，不是妥协）——边界一句话：系统在迭代中成长，也在迭代中老化——成长靠增量（本章），老化靠还债与再评估（停止点）。
27.8 本章对应表
| 业务诉求 | 技术选择 | 为什么 | 代价/取舍 |
|---|---|---|---|
| 新需求（二手拍卖）来了 | 三分类（4 章兑现） | 变化从"重来"变"增量"；变更的代价清单 | 变更管理成本 |
| 迭代怎么转起来 | 八段循环（图 27-1） | 每次迭代=演进循环实例；演进条件检查在圈内（5 章） | 节奏 vs 质量张力 |
| 拍卖代码放哪 | ★复用交易域（决策第 20 次） | 拍卖落交易域（26 章边界）；订单/支付/对账现成 | 交易服务变胖（演进条件） |
| 表接得住吗 | 表结构重审（6 章） | 改表贵，能不改就不改；新表不碰旧表 | 新表+迁移（如有） |
| 回归 2 天跑不起 | 测试金字塔（18 章） | 承诺没变的部分不用全验 | 测试维护成本 |
| 上线怎么验收 | 灰度 + 功能指标（23/25 章） | 上线=验证开始；业务指标先变 | 指标要定（转化率/错误率） |
| 什么时候停下 | 重构/还债/再评估 | 债是前奏不是失败（20 章）；演进条件触发即停 | 迭代节奏放缓 |
本章对两类读者的收益（与前几章同款）：后端读者——在已有系统上叠加（表/接口/并发/回归）是后端日常的主战场；前端读者——新功能的界面/状态（9 章框架）和接口对接（7 章契约）是前端迭代的日常——两类读者共同的收获：迭代第一次有了完整的方法论（三分类→八段环→停止点——不是"敏捷"的口号，是每一步都有前 26 章的工具）——"迭代"从名词变成流程（第 1 章：名词地图 vs 决策地图——迭代是流程地图）。
第 27 章在地图上的位置
图 27-2 与全书地图（一级图 #1 的复用——它是"第二次走"的图）：第 1 章的全书地图（图 1-1）在本书里出现过两次——第一次在第 1 章（认识地图），第二次在本章（用地图）——图 27-2 把迭代环高亮在全书地图上，标注"第二次走地图"——一张图的两副面孔：学的时候是索引，用的时候是流程（第 1 章"地图是拿来用的"——本章兑现）。
每一行都在本章正文里有完整论证：三分类在 27.1，循环在 27.2，需求在 27.3，决策设计在 27.4，开发测试在 27.5，发布监控在 27.6，边界在 27.7。先看"业务诉求"列——这一章的每一行，都是"在已有系统上叠加"的必然问题。
本章小结
迭代速查（第六部分回指本章时翻回这里）：
- 新需求三分类：新增功能/影响的非功能/约束（4 章）——变化从重来变增量；第一版砍到三条验收标准就开工；
- 八段循环（图 27-1）：需求→决策→设计→开发→测试→发布→监控→下一轮——每次迭代=第 2 章演进循环实例；演进条件检查在圈内（5 章）；三圈功能+一圈还债（20 章）；
- ★决策第 20 次：复用交易域（拍卖落交易域——26 章边界；订单/支付/对账现成；演进条件=拍卖做大再拆）；
- 表与接口：新表 auction/bid 不碰旧表（6 章重审）；接口 v1 版本化（7 章）；出价幂等键（17 章）——迭代不发明新规矩；
- 开发测试：框架让迭代快（9 章）；回归是命门——金字塔让全量回归 2 天降到 2 小时（18 章）；契约与三问照旧（7/15）；路过就还（20）；
- 发布监控：金丝雀（23 章——涉及钱高风险）；监控=新功能的验收数据（25 章：转化率/错误率——上线=验证开始）；老周验收业务（4 章）；
- 停止点：重构（改不动了）/还债迭代（提心吊胆了）/架构再评估（演进条件触发）——小循环发现问题，大循环解决问题。 （七条速查对应本章结构：1 是"需求"，2 是"循环"，3-4 是"决策设计"，5 是"开发测试"，6 是"发布监控"，7 是"边界"——第 28 章成长路径回指时重点翻 2（循环：成长的载体）和 7（停止点：成长的节奏）。）
- 迭代是常态：业务永不停止，每次迭代都是全书地图走一遍（第 2 章循环的业务版）；
- 变化从"重来"变"增量"：三分类+影响评估=变更的代价清单（4 章原话兑现）；
- 新功能的老规矩：接口版本化（7 章）、幂等（17 章）、测试承诺（18 章）、轨道（20 章）——迭代不发明新规矩；
- 迭代有停止点：重构/还债/再评估——小循环发现问题，大循环解决问题；
- "快"的正确含义：稳定地快，不是冲刺地快。
下一章
迭代循环转起来了：新需求进来、功能上线、监控验证、下一轮……但你发现一个更根本的问题——这些技能是怎么长出来的？你从"会写接口"到"会做架构决策"，中间发生了什么？——本书的最后一个问题。
第 28 章，成长路径：1-3 年工程师的技术地图怎么用——把全书的知识变成你自己的成长路线图。