2018年前后，Serverless在国内技术圈火了一阵。各大云厂商轮番布道，"按需付费"、"零运维"、"自动扩缩容"——每个口号都精准戳中了团队的痛点。我当时也投入了不少精力研究，毕竟谁不想不用管服务器？

几年过去了，当初那些All in Serverless的团队，相当一部分已经在往回走。不是Serverless不好，而是很多人慢慢意识到：当初以为消灭的复杂度，其实只是搬了个家。

那些承诺里没写的小字

Serverless的核心承诺有三条，每一条都有对应的现实版本。

"不用管服务器"——开发者只需写业务逻辑，基础设施平台托管。这对前端团队尤其有吸引力，写完函数丢上去就能跑，不用折腾部署和运维。但现实是，你很快会发现自己需要关注函数的内存配置、超时时间、并发限制、冷启动策略、VPC配置、IAM权限……这些不叫"服务器运维"，但本质上还是在管基础设施，只是换了个仪表盘。

"按需付费"——代码不运行就不收钱，空转成本消失。但下一句没人告诉你的是：按需付费的反面是成本不可预测。一个函数死循环触发重试，一个爬虫突然疯爬你的API，一个配置错误导致无限调用——这些异常场景下的账单，会让你深切怀念固定成本的日子。

前端开发有一个有趣的规律：每隔两三年，社区就会宣布一个新的状态管理"最佳实践"。Redux曾是不可撼动的标准，然后MobX说响应式才是正道，Dva试图让Redux更人性化，Zustand说状态管理不该这么啰嗦，Jotai说应该是原子化的，现在Signal又告诉你要从原语层面重新思考这个问题。每一次更迭都伴随着"旧方案已死"的宣言，和一波迁移重构。

但有一个问题始终没人回答：如果每个新方案都比上一个好，为什么我们还是不满意？

经历过Redux到Dva再到Zustand的完整迁移，我发现每一次换库的时候，团队都觉得这次终于对了。每一次，半年后又会发现新的别扭。这种循环让人不得不怀疑——问题可能根本不在库里。

Redux的铁律和代价

Redux的核心思想并不复杂：单一数据源，纯函数更新，不可变数据。这三条铁律在2016年前后确实解决了一个真实痛点——复杂应用中状态变化的不可预测性。组件树里的状态到处飞，回调层层传递，谁能改、谁不能改、改了之后谁是新的，没人说得清。Redux用一套严格的规则堵住了这个口子。

打开任何一个前端项目，全局搜索 `catch`，你会看到什么？一大片空荡荡的 catch 块，偶尔跳出几个 `console.error`，再偶尔冒出一行 `message.error('系统异常')`。后端项目也好不到哪去，try-catch 包着业务逻辑，catch 里面的处理方式跟前端如出一辙——记个日志，打个错误码，然后呢？然后什么都没有。

我把这种写法叫"安慰剂错误处理"。它的作用不是解决问题，而是让写代码的人觉得自己处理了问题。就好像感冒的时候吃维C，你做了点什么，但那点什么跟治愈没有关系。

更残酷的事实是：大部分错误处理非但没用，还在制造新的问题。

try-catch 不是错误处理，是错误藏匿

先说一个很多人不愿意承认的事：try-catch 是所有错误处理手段里最廉价的那一种。它的成本最低，所以它的价值也最低。

我见过太多这种代码：一个函数内部包了三层 try-catch，每一层都把异常吞掉，最外层返回一个 `{ success: false, message: '操作失败' }`。调用方拿到这个返回值，判断 `success` 为 false，然后弹个 toast —— "操作失败"。用户看到这四个字，内心毫无波澜，因为他已经见过一千次了。

团队里总有那么一两个人，什么活都能干，什么锅都能扛。需求来了找他，线上出问题找他，新技术调研找他，代码评审也想拉他。他的日历永远排得最满，他的PR永远是别人等Review最久的那个。

大家都觉得这是"能力强、受重视"的体现。管理者也觉得，把重要的活交给靠谱的人理所当然——毕竟谁能放心把核心模块交给新人？

但我要说一个可能得罪人的判断："能者多劳"不是在重用人才，是在消耗人才。而且这种消耗有一个特别迷惑人的地方——它看起来像是信任，感觉起来像是被需要，唯独结果不是被成全。

看起来是信任，实际上是惩罚

考虑一个很常见的场景。

项目要赶排期，核心功能必须本周上线。你会交给谁？当然是那个靠谱的资深工程师，因为交给别人你不放心，延期了你担不起。

线上出了Bug，排查要理解完整链路。你会交给谁？还是那个人，因为只有他能从数据库一路追到前端渲染。

新人入职需要导师，你会选谁？又是他，因为他技术好、有耐心、能讲清楚。

看起来这个人得到了最大的信任，承担了最重要的工作。但仔细想想，他得到了什么？更多的工作。更满的日历。更少的写代码时间。更晚的下班时间。而那些干得一般的人呢？他们的工作量反而更少，因为没人找他们。