真·996 的工作确实是没时间摸鱼的。
之前想的也是聪明如我怎么可能摸不了鱼，但实际结果就是事儿是真的多，电话 ding 是真的烦，出差是真的赶。
代码已经好多好多年了，写的又很恶心，开发工具又没有那么好用，造 10 个账号，有 8 个都会无法开通 xx 宝，然后跑一轮，就脏数据了，人家还不愿意改库，自己又要弄新账号。
到了测试对应的环境，改数据库还要审批，还要用近乎真实的账号覆盖边缘 case，协同的一大堆平台需要一起推进发布，万一推进不了还要临时加个发版开关，这开关一加就没有删的时候了，结果代码里大大小小一大坨开关，谁也不知道现在在用哪套逻辑，几个主要环境的开关还都不一样，除了开发环境，每次变更还要报备来报备去。
一出事故就开会，每次总结下来要做好一二三，结果等到发布的时候还是老样子。

@binbinyouliiii 不不不，switchIfEmpty 应该这么用:
getFromCache(key).switchIfEmpty(
getFromDb(key).flatMap(value -> setCache(key,value))
)
如果设置缓存是纯异步的，也可以：
getFromCache(key).switchIfEmpty(
getFromDb(key).doOnSuccess(value -> setCache(key,value).subscribe())
)

换个姿势解释一下，传统代码是这样子的：
statement1;
statement2;
statement3;

那么对于 Reactor，其根本目标就是在于让 statement1 和 statement2 之间可以执行一些额外的代码，来保证代码是可调度的，进而起到所谓的 IO 优化。

那么首先，就需要改造成：

(statement1 as Mono).then(statement2 as Mono).then(statement3 as Mono)

这样就能在每个 Mono 之间插入一些调度的代码。

另一方面，为了兼容其他的语法，比如 return，比如 null，Mono 就提供了大量的成员方法来简化这个 then，让它写起来更爽。
比如 null 对应了 Mono.empty()，return 对应了 Mono<T>里的 T 。

以上，你需要考虑每个逻辑对应的是 Mono 的哪个方法。
比如 if(x != null) { return x;} <after statement>对应的就是 switchIfEmpty(<after statement> as Mono);
比如 if(x != null) { return x;} else { return y; } 对应的就是 defaultIfEmpty(y)。

其实是一样的。。

People people = getCache(name);
if (people != null) {
return people;
}

=>

getCahe(name).switchIfEmpty(<after logic>)

挺复杂的，从原理上，既要 IDEA 能优雅的把 mapper.xml 更新到对应的位置，又要让解析配置文件的库支持动态加载。
Java 是有 Instrumentation 机制的，其他的软件或者库有没有这个能力就要看看了。

这是一个倒逼的循环。
为了让当前干活更加快速，前置的工作会创造尽可能多的可能性（积极的），但是对于无法预知的未来，技术债是不可避免的（消极的）。在消极因子积聚到一定程度、导致 KPI 无法达成后，就会倒逼产生新的解决方案（中性的），进入新的循环。
从达成目标的角度而言，或者是站在商业模式的立场上，上面的循环反而是良性的，因为消极因此都最终被强行转化为中性的。
而你所说的深度、重复性和潜在的风险，绝大部分时候都会在新的解决方案中处理（但处理的结果不一定是积极的）。如果作为工人，一方面就快速迭代，这是 KPI 导向下工作的本分，另一方面对于快速迭代中产生的问题进行归纳，以迎接下一次的革新，这是晋升的机会。如果作为领导，需要有节奏的对自己负责的工程进行梳理，如果当前的状态仍旧可以快速迭代，那就定期整理问题，如果当前的状态已经寸步难行，那就根据整理的问题直接开新坑。

软件是有生命的，效率优先的情况下，快速的迭代甚至包括了快速的淘汰旧架构，快速的产生新方案。

多种格式支持，还有大量自定义渲染操作，这玩意儿做出来，干嘛还当 Reader 卖啊，再加点文本修改功能，直接把类 Word 软件按在地上锤。。