第6章 · 工程落地

第 6 章 · 工程落地

章节摘要：原理需落地为测试、追踪、调优与团队规范。StepVerifier 验证信号序列；Micrometer 暴露流指标；性能调优关注调度器与并发度；反模式清单防止「伪响应式」。

子章节导航

工程落地的三根支柱

响应式系统从「能跑」到「能上线」，需要三件事同时成立：

1. 可测试（6.1）：异步 + 时间敏感，传统「跑一次看结果」的测试方式失效，必须用 StepVerifier + 虚拟时间把「信号序列」变成可断言的契约。
2. 可观测（6.2）：flatMap 十层变换后堆栈只剩抽象类名，没有 checkpoint、指标与追踪，生产事故只能靠猜。
3. 可预防（6.4）：.block()、无界 push、EventLoop 阻塞、错误黑洞——这些反模式把「响应式」变成「更复杂的命令式」，必须有清单防住。

三根支柱指向同一个结论：响应式不是「写出来就行」，而是「测得出、看得见、防得住」。 本章就是这份工程手册。

读完本章应能

1. 用 StepVerifier 写出覆盖正常、错误、背压、取消四类场景的测试
2. 用 checkpoint、log()、Micrometer 指标定位一条流的问题
3. 对照反模式清单评审自己或团队的响应式代码

与前后章衔接

本章是第 5 章设计模式的「验收关」：5.1-5.3 选对的算子，能不能通过 6.1 的信号断言、能不能被 6.2 观测到，最终能不能躲过 6.4 的反模式。建议把第 6 章当作上线前的 checklist 用——每写完一个响应式模块，逐条过一遍本章的内容。

上线检查清单

把三节内容合并成一份可直接使用的上线清单：

九项全过再上线，是响应式系统的最低工程门槛。它把第 6 章「测试、观测、预防」三根支柱落成可执行的动作——这也解释了为什么本章标题叫「工程落地」。

文档化要求

响应式代码比命令式代码更需要文档，因为执行流对读者不可见。建议每个模块的 README 包含：

• 数据流图（用 mermaid 画信号如何流动）
• 调度器使用说明（哪段在哪个线程跑）
• 背压策略与理由（为什么选 buffer/drop/latest）
• 已知反模式规避记录

「不可见的执行流」是响应式系统维护成本高的根源，用文档补足可见性，是团队层面的工程落地。