打开任何一个前端项目，全局搜索 `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，排查要理解完整链路。你会交给谁？还是那个人，因为只有他能从数据库一路追到前端渲染。

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

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

有个场景在金融科技公司几乎每周都会上演:产品经理说"这个需求很简单,就是加个按钮",工程师听到的是"又要改架构"。

会议室里的氛围瞬间凝固。产品经理觉得技术团队在找借口,工程师觉得业务方根本不懂技术。双方都没说错,但都没说对。

这不是沟通技巧的问题,是认知框架的断层。

信息在组织边界丢失

我观察过一个现象:同一个需求,产品经理在需求评审会上讲五分钟,工程师回去讨论要两小时。

不是工程师理解力差,是信息在跨部门传递时发生了质变。

产品经理说"支持用户自定义理财目标",他脑子里是一个完整的业务场景:用户设定目标金额和期限,系统推荐合适产品,定期提醒达成进度。这个场景在产品原型里是完整的,在用户故事里是清晰的。

但工程师听到的是什么?

前端听到的是:新增表单、字段校验、状态管理、埋点上报。后端听到的是:数据库表设计、接口规范、权限校验、数据迁移。全栈工程师听到的更复杂:前后端联调、缓存策略、异常处理、监控告警。

同样五个字,解析出来的工作量相差十倍。

这就是组织边界的代价。产品经理思考的是"用户价值",工程师思考的是"技术实现"。两者的抽象层级不在同一个维度,信息当然会失真。

写在前面

前几天和一个创业公司的 CTO 聊天，他说他们团队 5 个后端开发，已经拆了 12 个微服务。我问他为什么要拆，他说"为了未来的扩展性"。然后我问他现在的 DAU 是多少，他说"几千"。

这让我想起很多年前见过的一个场景：一个刚起步的业务，还在验证商业模式，技术团队已经开始讨论服务网格和分布式追踪了。最后业务没做起来，技术架构倒是挺先进的。

微服务这几年被捧得太高了。很多团队在根本不需要的时候就开始拆服务，结果把自己搞得焦头烂额。今天想聊聊这个话题，不是说微服务不好，而是大部分团队真的不需要它，至少不是现在。

微服务的真实成本

开发成本的指数级增长

很多人以为微服务只是把代码拆开而已。实际上，从单体到微服务，你需要解决的问题是指数级增长的：

服务间通信：HTTP 调用、gRPC、消息队列，你得选一个。然后你会发现，本来一个本地函数调用，现在变成了网络请求。网络不可靠，你得处理超时、重试、熔断。原本简单的代码，现在要考虑各种边界情况。