Node.js中server.listen的(error)=>回调及fallback函数使用时机

(error)=> 的含义 #

这是ES6箭头函数的参数声明部分，你代码里的完整写法是(error)=>{ /* 回调逻辑 */ }，等价于ES5的function(error) { /* 回调逻辑 */ }，是传给server.listen()的回调函数：

• Node.js的server.listen()是异步方法，不会阻塞后续代码执行，当端口监听操作完成（不管成功还是失败），会自动调用你传入的这个回调
• 这是Node.js社区统一遵循的错误优先回调规范：异步操作会把错误对象作为回调的第一个参数传入：
  • 如果监听失败（比如端口被占用、host绑定无权限），error就是对应的错误对象，你代码里的判断分支就会打印错误信息
  • 如果监听成功，error为falsy值（null/undefined），就会走到后面打印监听成功日志的逻辑

Node.js中fallback类回调函数的适用场景判断 #

你提到的这类fallback函数本质是Node.js异步编程模型下的回调函数，核心作用是处理异步操作完成后的结果、做异常兜底，判断是否需要用可以参考这几个规则：

• 先看API签名：所有Node.js原生异步API、以及遵循社区规范的第三方库异步方法，最后一个入参都是回调函数，这种场景必须传。比如文件读写fs.readFile、服务启动server.listen、数据库连接、第三方接口请求这类方法，都要求传回调接收结果。
• 看操作类型：只要是涉及IO、不会立刻返回结果、不会阻塞事件循环的操作，都需要传这类回调处理结果。这类操作你没法用同步的返回值拿结果，也没法用外层的try/catch捕获异步阶段抛出的错误，只能在回调里做两个分支的处理：
  • 异常兜底分支：处理操作失败的场景，比如端口占用、文件不存在、网络超时，避免未捕获错误导致进程退出
  • 成功后续分支：处理操作成功后的逻辑，比如启动成功打印日志、拿到文件内容做后续处理、连接数据库成功后开始执行业务
• 不要滥用：同步执行的逻辑不需要特意加这类回调，只有当你需要等一个耗时异步操作完成后再执行逻辑的时候，才需要传入对应的回调函数。

注：现在Node.js也支持async/await的异步写法，本质是对回调/Promise的封装，适用场景判断逻辑和回调一致：只要是异步IO操作，都需要考虑异常兜底和成功后的逻辑处理，只是写法从嵌套回调变成了线性的try/catch+await写法。

内容的提问来源于stack exchange，提问作者dev595