§1 摘要与结论TL;DR · 一句话结论 在不改变可观察行为的前提下重组软件内部结构，使其更易理解、更易修改；判定重构 是否成立的硬标准是行为不变，治理要点是把小步变换持续进行而非安排一次性大改。
别名：refactoring discipline、behavior-preserving、重构纪律、行为保持、小步重构 | 英文：Behavior-Preserving Refactoring | 类型：方法 / practice
§2 局部关系图行为保持重构 的 1-2 跳邻域关系图 组合（combination）：单一知识源与高内聚同向协同 前置依赖（prerequisite）：演化不可逆使技术债必然累积 细化（refines）：架构侵蚀与漂移是技术债的架构层形态 前置依赖（prerequisite）：持续演化推动复杂度与变更成本上升 依赖关联（dependency）：侵蚀与漂移使系统抗拒变更、抬高变更成本 依赖关联（dependency）：变更成本是技术债利息的可观测落点 依据推导（derives_from）：行为保持重构是偿还技术债的核心手段 依据推导（derives_from）：坏味道是变更成本上升的可观察信号 依据推导（derives_from）：债务象限与偿还策略依据技术债本质 依据推导（derives_from）：演进式架构以演化不可逆为前提 依据推导（derives_from）：遗留治理以降低变更成本为目标 依据推导（derives_from）：弃用策略是演化不可逆下的有序退场 前置依赖（prerequisite）：坏味道作为启发式信号触发重构 依赖关联（dependency）：债务偿还依靠行为保持重构 前置依赖（prerequisite）：改动遗留代码前先建立行为安全网 前置依赖（prerequisite）：遗留治理与弃用共享迁移路径设计 依赖关联（dependency）：债务治理与演进式架构协同 前置依赖（prerequisite）：演化定律的复杂度递增是技术债的理论根据 依赖关联（dependency）：架构腐化是演化定律在架构层的表现 跨体系对照（cross_reference）：行为保持纪律与重构手法族分工互补 依据推导（derives_from）：演进式架构承接软件必须持续演化的定律 依据推导（derives_from）：评审以高内聚低耦合作为结构判据 组合（combination）：持续设计投入与代码评审共同对抗结构腐化 组合（combination）：持续设计以重构为日常改进手段 组合（combination）：评审发现的坏味道交由重构手法处理 案例印证（case_instance）：印证：以行为保持为前提重组内部结构 案例印证（case_instance）：印证：单一契约源消除接口知识的多份副本 案例印证（case_instance）：印证：拒绝静态类型/契约优先是以类型安全换取低部署成本 实现（implements）：静态分析平台为代码评审提供自动化检查信号 实现（implements）：规则引擎自动化识别代码坏味道 实现（implements）：SQALE 为技术债量化与偿还提供方法基础 实现（implements）：债务量化支撑按偿还优先级治理技术债 促成（enables）：SQALE 方法使技术债量化指标得以落地 组合（combination）：SonarQube 采用 SQALE 指标命名实现债务度量 组合（combination）：平台提供技术债量化指标的计算与展示 对照（contrasts）：度量指标是工具估算，不等于代码质量真值 实现（implements）：绞杀者渐进替换实现遗留系统渐进治理方法论 实现（implements）：绞杀者增量迁移体现有引导的增量演进 案例印证（case_instance）：印证：单一契约源与能力注册中心防止涟漪效应 依据推导（derives_from）：重构以改善内聚耦合、降低变更成本 组合（combination）：重构手法族用于达成信息隐藏分解边界 促成（enables）：重构手法使信息隐藏在既有代码上可逐步落地 行为保持重构行为保持重构（MTH-L-01） 网申 v2 深度重构网申 v2 深度重构（CAS-X-04） 技术债本质技术债本质（ESS-L-02） 重构手法族重构手法族（MTH-H-01） 代码坏味道启发式代码坏味道启发式（MTH-L-02） 技术债象限与偿还策略技术债象限与偿还策略（MTH-L-03） 遗留系统渐进治理遗留系统渐进治理（MTH-L-06） 内聚与耦合内聚与耦合（ESS-H-02） 权衡的不可消除性权衡的不可消除性（ESS-O-03） SonarQube 静态…SonarQube 静态分析平台（TEC-H-01） 代码复审与可读性治理代码复审与可读性治理（MTH-H-04） 演进式架构演进式架构（MTH-L-04） 技术债量化度量指标技术债量化度量指标（TEC-H-03） 可修改性战术实现可修改性战术实现（TEC-M-03） 变更成本随复杂度增长变更成本随复杂度增长（ESS-L-05） SQALE 技术债评估方…SQALE 技术债评估方法（TEC-H-02） DRY 单一知识来源DRY 单一知识来源（ESS-H-03） 软件演化定律软件演化定律（ESS-L-01） 架构侵蚀与漂移架构侵蚀与漂移（ESS-L-03） 演化的不可逆性演化的不可逆性（ESS-L-04） 战略式编程与持续设计投入战略式编程与持续设计投入（MTH-H-03） 信息隐藏模块化分解信息隐藏模块化分解（MTH-H-02） 绞杀者渐进式替换绞杀者渐进式替换（TEC-L-02） 弃用与日落策略弃用与日落策略（MTH-L-07）
以本节点为中心，静态内联 1–2 跳邻域：内环 6 个直接邻接、外环 17 个二跳节点，共 24 个节点；连线按边类型着色（六类配色见下）。构建期计算，无运行期脚本。 §3 原理 · 为什么重构之所以能安全地偿还结构债，靠的正是「不改变可观察行为」这一约束：它把「改结构」与「改功能 」两种意图分开，使每一步都能被测试验证，从而把高风险的改造拆解为一系列低风险的小步。 若允许行为变化，所谓重构就与重写无异，失去了安全网与可回退性。与大改相比，小步重构的收益不在单次效率，而在可持续性：它使代码随时保持在可修改状态，避免债务积累到只能推倒重来的程度。把行为保持写成硬标准还有一层组织价值：它提供了可争议、可验证的共同判据，使关于「这次改动算不算重构」的分歧落在可检验的事实上，而不是各自对「重构」的理解。这也解释了为何重构常与测试驱动紧密结合——没有可自动验证的行为边界，行为保持就只能依赖人工判断。因此重构是一种纪律与习惯，而非危机时刻才启动的专项运动。
§4 机制 · 如何运作小步变换序列是核心机制：每一次变换只做一件结构上明确的事，若测试通过则保留、失败则回退，风险被限制在单步之内。 安全网是前提，没有测试时重构等同于赌博。实践上遵循「先让代码可测，再动结构」的次序：对缺乏测试的代码，先用覆盖既有行为的方式建立保护，再进行重构。重构往往在改动功能前后进行——先做预备性重构使新功能更易加入，或在完成后清理过程中的妥协。识别重构的边界同样重要：一次变换若既改结构又改行为，就无法用「行为不变」来验证，应拆成先后两步——先以行为保持的方式调整结构，再在干净的结构上实现功能变化，把两种意图分离，是让每次改动都保持可回退、可定位的关键所在。关键是识别何时停止：当结构已足够支撑当前需求时，继续抽象 会引入过度设计，反而制造新的维护负担。 把变换拆到可命名、可验证的粒度，既是操作要点，也是团队协作的基础——每一步都清晰到可以被他人审阅与接手。
§5 工程 · 怎么落地以行为保持为验收标准：每次变换后运行 测试，确保可观察行为不变。 把重构嵌入日常开发 而非单列阶段 ，在改动代码时顺手清理，使代码始终比接手时更干净。 对可测性差的旧代码，先建立覆盖既有行为的保护再动结构。用评审与自动化门控防止「借重构之名改行为」。工程上还可把重构与提交/评审节奏对齐：让纯结构改动与功能改动在提交历史上可区分，便于审阅与回溯；对高风险区域先补充测试再动结构，并把重构范围限制在当前任务相关的小片区域，避免借机扩散成全文件重写。为重构设置范围与退出条件：当发现结构问题超出当前任务范围时，记录债务并克制扩张，而非顺势展开大体量改造，把一次日常改动演变成高风险的重写。
§6 权衡卡代价 · 风险
其四，重构可能滑向过度抽象，制造比重复更难维护的结构。
行为保持约束本身也有成本：对既有行为有缺陷的代码，执着于「行为不变」会延迟必要的修正，此时应把行为修正与结构重构明确分开、分别验证，而不是混在一次改动里，让风险与意图都变得难以追踪。
更根本的是，行为保持重构依赖对「可观察行为」边界的界定：若团队对哪些行为算对外承诺缺乏共识，重构的验证范围就会模糊，风险随之上升。
原文要点
其一，无测试直接重构会引入回归缺陷，此时应先补安全网。 其二，行为保持约束假设既有行为正确：若既有行为本身是缺陷，重构会将其固化，这类改动应归为功能修正而非重构。 其三，小步重构在短期内看似低效，容易在交付压力下被牺牲，而债务恰在此时累积。 其五，把「重构」当作重写或改行为的借口会破坏安全网与团队信任。 因此应以测试绿灯与明确范围为前提，并把偿还节奏制度化。 因此，判断一次重构是否成功，不看它消除了多少坏味道，而看它是否让后续同类变更变得更小、更安全、更可预期。 权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7 学习路径条MTH-L-02 代码坏味道启发式 → MTH-L-06 遗留系统渐进治理 → MTH-L-01 行为保持重构
§8 案例带CAS-X-04 · 经 direct 网申 v2 深度重构 一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。
CAS-X-02 · 2 跳派生：当前节点 → CAS-X-04 → TEC-M-03 网申填写扩展逆向架构 对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
CAS-X-03 · 2 跳派生：当前节点 → CAS-X-04 → ESS-H-03 网申 v3 多模块解耦 一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
CAS-X-05 · 2 跳派生：当前节点 → MTH-H-01 → ESS-H-02 preset 通道耦合分析 对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
CAS-X-15 · 2 跳派生：当前节点 → MTH-H-01 → MTH-H-04 Open Code Review 图谱 对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
§9 信源与核验核验状态 True（verified）
置信度 high
复核日期 2026-10-12
生命周期 active
规范信源 BK-021、WEB-040、WEB-014、BK-022
书证核验 BK-021 Ch4（direct），ChDefining Refactoring（direct），ChFormat of the Refactorings（direct），ChThe Two Hats（direct），ChWhen Shouldn't You Refactor?（direct）；BK-022 ChImproving Design（direct），ChLegacy Code Change Algorithm（partial）
勘误 常见误解：重构约等于重写或清理代码 [BK-021]
勘误 常见误解：可以在没有测试的代码上直接重构 [BK-022]
§10 原始关系清单展开：本节点的全部原始关系边（6 条，含边 ID 与方向） 关系 方向 对端节点 说明 案例印证 ← CAS-X-04 网申 v2 深度重构E-947 印证：以行为保持为前提重组内部结构 跨体系对照 → MTH-H-01 重构手法族E-621 行为保持纪律与重构手法族分工互补 依赖关联 ← MTH-L-03 技术债象限与偿还策略E-614 债务偿还依靠行为保持重构 依据推导 → ESS-L-02 技术债本质E-606 行为保持重构是偿还技术债的核心手段 前置依赖 ← MTH-L-02 代码坏味道启发式E-613 坏味道作为启发式信号触发重构 前置依赖 ← MTH-L-06 遗留系统渐进治理E-615 改动遗留代码前先建立行为安全网
软件工程 / 架构设计方法论知识图谱 · 节点页由 16-checkpoint/gen-nodes.py 生成 · 数据源 10-dag-data/methodology-dag.json