上周组里一个产品上线前的合规评审会上，合规专员盯着一段前端代码问了一个问题："这个收益率计算逻辑，用户在购买前看到的结果和购买后持仓页显示的结果，走的是不是同一条计算链路？"

在场的两个前端工程师面面相觑。答案是"不是"。购买前用的是推荐接口的预计算数据，持仓页用的是资产接口的实时结算数据。两条链路，两套精度处理，两组四舍五入规则。在普通业务里这根本不算事——数据来源不同，展示逻辑不同，非常自然。但在金融业务里，这意味着用户可能看到购买前年化3.52%，购买后变成3.51%。

0.01%的偏差，万亿规模下就是上亿的资金差异预期。合规专员当场拍了桌子，上线延期两周。

这个场景在互联网公司几乎不会发生。但在金融科技团队，它是日常。

金融业务的代码有两套读者

大部分工程师写代码时心里只有一个读者：运行时环境。代码能不能跑，跑得快不快，内存占不占得住——所有的优化方向都指向机器。

金融业务的代码不一样。它有两套读者：机器和审计。而且讽刺的是，审计这个读者往往比机器更难伺候。机器只要逻辑正确就行，审计要的是"逻辑正确且可追溯且可解释且可复现"。多出来的这三个"且"，才是金融科技工程真正的成本。

打开任何一个前端项目的代码，搜索 `catch`，你大概率会看到这样的画面：

```javascript
try {
await fetchData();
} catch (e) {
console.error(e);
message.error('操作失败，请稍后重试');
}
```

后端也好不到哪去：

```javascript
try {
await processOrder(orderId);
} catch (err) {
logger.error('订单处理失败', { orderId, error: err.message });
throw new BusinessException('系统异常，请重试');
}
```

这两段代码有一个共同的特质——它们让你觉得错误被"处理"了。日志打了，提示也弹了，异常也抛了，一切看起来都很体面。

但你仔细想想：用户看到"操作失败，请稍后重试"之后能做什么？重试？然后呢——再失败一次？运维看到一条"订单处理失败"的日志，能定位到什么？是库存扣减超时，还是支付回调丢失，还是风控拦截？

很多从前端转 Node.js 的开发者，对这门运行时的理解停留在"写 JavaScript，能跑服务"这个层面。开发环境跑得好好的，上了生产环境，问题一个接一个冒出来，而且每一个都反直觉。

这不是水平问题，是 Node.js 的运行时设计给了你一种安全感——一种在开发环境完全验证不了、只有在流量压上来的那一刻才会破碎的安全感。

我自己在做 BFF 层的这些年，踩过太多这种坑。最深的感触是：Node.js 不会替你兜底，它只是让你以为它会。

事件循环不是安全网

Node.js 的文档里有一句很关键的话：事件循环在单个线程中运行。但很多人对这句话的理解是——"异步代码就不会阻塞"。

这是最大的幻觉。

`async/await` 只是语法糖，它让异步代码看起来像同步代码，但它不会把同步操作变成异步的。当你在一个请求处理函数里做了这些事情，整个事件循环都会停住：

- `JSON.parse` 一个 50MB 的请求体
- 用正则表达式匹配一个精心构造的字符串（回溯攻击）
- 在同步循环里做密集计算，比如加密、排序大数据集
- 调用了某个底层 C++ 扩展的同步接口

过去一年，我接触了不少AI和机器人方向的创业团队。有做具身智能的，有做服务机器人的，有做工业检测的，也有做消费级陪伴机器人的。聊完之后一个很强烈的感受：大量的创业者——尤其是技术背景出身的——正在用软件的思维做硬件的生意，用SaaS的逻辑评估一个物理世界的项目。

这个错位，比大多数人以为的要严重得多。

Demo到产品的距离，在硬件世界里是光年

软件创业的核心叙事是MVP——最小可行产品。两周上线一个版本，收集用户反馈，快速迭代。这套方法论在过去十年被验证了无数次，几乎成了互联网创业的圣经。

但这个叙事在机器人领域完全不成立。

一个做餐厅配送机器人的团队跟我说，他们的软件系统三个月就搭好了，SLAM算法调了两个月效果不错，避障也过得去。但整机跑起来之后，发现轮子打滑导致里程计漂移，激光雷达在不同光照条件下噪点差异巨大，电池在冬天衰减了30%导致续航不达标，餐厅地面的油渍让轮子寿命从设计的一半都不到。每一个都是"小问题"，但要解决任何其中一个，都需要改模具、换供应商、重新做可靠性测试——一个循环下来三个月起步。

软件出bug可以热修复，硬件出问题只能召回。软件改一行代码的成本是几分钟，硬件改一个结构件的成本是几万块起，加上开模周期至少四周。这不是量变，这是质变。