Express 项目里，错误处理中间件为什么总是最后才补
· 阅读需 3 分钟
问一个很现实的问题：为什么很多 Express 项目都有认证中间件、日志中间件、跨域中间件，却偏偏把错误处理中间件留到最后才补？
我的答案是，因为它不像“功能”那样立刻可见，只有出问题时你才会想起它。
2016 年那阵子我自己写 Node.js 服务，刚开始也总想着先把接口打通。路由能返回数据，前端能调用，心里就觉得项目已经像样了。可一旦出现异步异常、参数未处理、数据库报错直接往外冒，才发现没有统一错误出口的项目，其实并不稳。
为什么它经常被拖后
错误处理中间件不像登录、列表、上传那样有明确页面结果。
你不写它，系统多数时候也照样能跑，所以团队天然会把优先级往后放。
但它一旦缺席，代价会在这些地方一起出现：
- 同类错误返回格式不统一
- 堆栈信息直接暴露给客户端
- 日志里没有足够上下文
- 前端拿不到稳定的错误码和提示
这些问题平时不响，到了线上会一起冒头。
真正该处理的不是“报错”，而是“出口”
我后来对 Express 错误处理中间件的理解变了。
它不只是一个“兜底 try-catch”，而是全项目错误出口的收口点。
它至少应该统一几件事：
- 返回体结构
- 错误码映射
- 是否记录堆栈
- 哪些信息可以暴露给客户端
只要这层统一起来，前端联调、日志检索和线上排障都会轻很多。
放在哪一层最合适
我的习惯是：
- 普通中间件先走
- 路由处理业务
- 路由里通过
next(err)或统一包装抛出错误 - 最后交给错误处理中间件收口
也就是说，它不是一个“哪里报错就写哪里”的零散处理方式，而是项目结构上的最后一层守门人。
不要让它承担所有业务判断
错误处理中间件很重要，但也不能什么都往里塞。
参数校验失败、权限不足、资源不存在，这些应该在业务层或校验层尽早明确；错误处理中间件负责把这些结果整理成一致输出，而不是在最后一层重新猜业务意图。
它的价值在于统一，不在于替代业务逻辑。
结语
我后来再看很多小型 Express 项目，稳定性差的根源常常不是路由写得多烂，而是整个系统根本没有一条像样的错误出口。
错误处理中间件总是最后才补，不是因为它不重要，而是因为它的价值只有在系统开始复杂以后才会被真正看见。可越晚补，历史包袱就越重。早点补上，项目会省很多后悔。