1.1 核心定义与哲学

1.1 核心定义与哲学

本节摘要：响应式编程将**变化（change）升格为一等公民，用传播（propagation）**描述数据随时间的因果链，而非一次性赋值。本节对照命令式与流式心智，并给出 Netflix、Uber 等工业场景的语义锚点。

学习目标

1. 用一句话区分「响应式」与「异步编程」
2. 解释 x$ = y$.combineLatest(z$).map(...) 与 x = y + z 的本体差异
3. 列举响应式在认知、架构、工程三个维度的价值

一、问题与直觉

命令式代码回答「此刻变量是什么」；响应式回答「当上游变化时，下游如何自动更新」。电商大促页面同时聚合库存缓存、推荐画像、物流 IoT、风控规则——数据源异构且节奏不同，用同步调用链只能不断 Thread.sleep 或堆线程。

响应式把程序建模为事件流上的声明式依赖图：map、filter、flatMap 定义的是流之间的函数关系，而不是执行步骤序号。

用一个更具体的例子说明。命令式写法里，界面上的「可见库存」取决于库存量与是否开启限购：

# 命令式：手动跟踪依赖
stock = 0
limit_flag = False
visible = stock if limit_flag else min(stock, 10)

def on_stock_change(new_val):
    global stock, visible
    stock = new_val
    visible = recompute()   # 每次都要手动重算
    render(visible)
​

而响应式写法把「visible 是 stock 与 limit_flag 的函数」这句话直接声明出来，之后任何上游变化都会自动传播：

// 响应式：声明依赖，变化自动传播
const stock$ = new BehaviorSubject(0);
const limitFlag$ = new BehaviorSubject(false);
const visible$ = combineLatest([stock$, limitFlag$])
    .pipe(map(([stock, flag]) => flag ? stock : Math.min(stock, 10)));
visible$.subscribe(render);   // 依赖永远同步
​

响应式要求你把「当 A 变化时 B 应该怎样」写成 B = f(A) 的依赖声明；异步编程只要求「B 的结果不在当前时刻」。前者是关系建模，后者是执行时机。两者可叠加但不等价——你可以同步地、关系式地建模，也可以异步地、命令式地编程。

二、核心定义

四维编程观（SOURCE 第一章）：空间上数据分布于节点与队列；时间上操作有 creation→emission→consumption→termination；因果上算子构成依赖图；韧性上背压与降级是免疫机制。

命令式：x = y + z 是瞬时快照。响应式：x$ = y$.combineLatest(z$, (y,z) -> y + z) 是只要 y 或 z 有新值，x$ 必然发射的因果河。

关于「传播即运算」需要再深入一步：命令式的赋值在时间上是一次性的，第二次赋值靠程序员记得去执行；响应式的 combineLatest 不是「算一次」，而是注册了一条永不失效的推导规则。这意味着：

• 新增数据源时，命令式要找到所有依赖它的赋值点逐个补算，响应式只需在规则里加一个上游；
• 删除依赖时，命令式漏删会留下过期值，响应式的 GC 会回收不再被引用路径关注的流；
• 测试时，命令式断言「此刻的值」，响应式断言「一组时间上排列的发射序列」。

这条差异解释了为什么响应式系统的 bug 往往不是「算错了」而是「忘了让它传播」——因为你不再手动控制传播时机，传播规则本身就变成需要设计的产品。

三、哲学与工程含义

Netflix 工程团队报告：核心推荐 API 从 Servlet 迁到 Reactor 后，同等硬件吞吐约 3.2 倍、P99 延迟降约 67%、堆占用降约 41%——差异来自线程不再绑定请求，等待变成零成本订阅。

Spring WebFlux 中一条 Mono<User> 可能贯穿 JWT 校验、缓存、DB、外部 API；层边界从调用栈变成流的汇入与分流。retry(3)、timeout(5s) 是流定义的一部分，错误是流图中可监控的合法分支。

// 声明式组合：错误与降级写在流上
webClient.get().uri("/user/{id}", id)
    .retrieve().bodyToMono(User.class)
    .flatMap(u -> ratingService.rate(u.id))
    .onErrorResume(e -> Mono.just(defaultRating));
​

这段代码值得拆开看三个点。第一，flatMap 让两个异步步骤组合而不嵌套——评级调用失败不会让外层调用栈崩溃；第二，onErrorResume 是流定义的一部分，编译器、测试工具、监控都能看到这条降级规则，而命令式的 catch 只能靠运行时报错被偶然发现；第三，整条链是惰性的——在 subscribe() 之前它只是一张「计划图」，这是第二章 Publisher/Subscriber 契约的直接后果。

从工程视角看，响应式的价值是系统级的：

1. 资源：同样 10 万并发连接，阻塞模型需要 10 万线程（约 8GB 栈内存起步），Reactor 单 EventLoop 加少量 worker 即可承载；
2. 契约：request(n) 让内存水位可预测，而非依赖「运气好队列没满」；
3. 运维：重试、超时、降级作为流的一部分可见、可测、可监控，不再是散落在 catch 块里的秘密。

一节小结

• 响应式是范式，不是某个库
• 核心是变化 + 传播 + 背压 + 组合
• 价值在系统级资源与契约，不在单次请求微优化

用一句话收束：响应式编程 = 把「当 A 变化时，B 按规则推导」这条因果链，建模为可组合、可背压、可取消的流。

下一节用 Reactive Manifesto 四支柱把上述哲学写成可评审的系统原则。