很多人写简历都爱写一句“熟练使用Node”，可真到了线上服务出问题、半夜被叫起来排查的时候，能讲清楚事件循环、能定位内存泄漏的人，十个里面未必有一个。工作里我面试过不少人，问“Node为什么快”，得到的回答多半是“因为异步、非阻塞”——再往下问“那异步到底是怎么实现的”，基本就沉默了。所以这篇东西我不打算讲“Node很厉害”“Node能做什么”这种正确但没用的废话，而是从我用Node做一个真实服务的完整过程讲起，把它背后那些真正影响开发体验和线上稳定性的知识点拆开聊。
这篇内容的定位是给已经写过一点Node、但总觉得停留在“会用”层面的人。你会看到版本管理、模块系统、事件循环、HTTP服务、调试排错这几个使用Node时绕不开的主题。每块我都会给出可以直接抄的步骤，也解释为什么要这么做。最想让你带走的东西很简单：以后再有人问你会不会Node，你不只是说会，而是能说清楚它到底是怎么转起来的。
1. 先把环境装对，再谈“使用node”——版本、运行时与第一行代码
1.1 版本管理：为什么我强烈建议你别直接用官网安装包
很多新手第一次装Node都是去官网下一个当前版本安装包，一路下一步装完，然后node -v能输出版本号就觉得自己搞定了。这个习惯在长期写项目的时候特别坑，原因有两个：第一，Node版本迭代非常快，今天你装的这个版本，可能过半年就进了维护期甚至停止维护，而你的项目依赖的某个老库可能和新版本V8引擎的垃圾回收行为不兼容；第二，不同项目对Node版本的要求经常冲突，我见过最典型的情况是：老项目锁定Node 14，新项目要用Node 20的fetch和test runner，你本地只有一个版本，切项目就得折腾重装。
正确的做法是用版本管理工具。macOS/Linux下建议用nvm，Windows下用nvm-windows或者fnm。这类工具的原理其实不复杂——它们把不同版本的Node二进制放在各自的目录里，然后通过修改PATH环境变量来切换当前生效的版本。装好之后日常操作就这么几条：
nvm install 20.12.2 # 安装指定版本 nvm use 20.12.2 # 切换当前shell使用的版本 nvm alias default 20.12.2 # 设置默认版本这里我想单独提一下Node版本选择策略。如果你不是要尝鲜新特性，老老实实装LTS（长期维护版）。LTS版本的生命周期通常是30个月，意味着你不会因为安全补丁跟不上而被迫升级。我见过太多人图新鲜装了Current版本，结果某天早上来发现依赖装不上了，一查才知道是那个版本里的某个行为变更把兼容性破坏了。生产环境永远用LTS，个人玩可以随意。这是我在实际项目里被折腾过好几回才得出的教训。
1.2 第一行代码背后的隐藏知识点
环境装好后，大部分人做的第一件事就是建个文件写console.log('hello world')，然后node index.js。这一步太顺了，顺到没人会去想一个问题：node xxx.js到底做了什么？
拆开说，Node是一个基于V8 JavaScript引擎的运行时。它做的事情大致是：读取你的JavaScript文件，交给V8编译成字节码，然后执行。但跟浏览器里跑JS不一样的地方在于，Node给你注入了很多浏览器里没有的能力——操作文件系统的fs模块、发起网络请求的http模块、读取操作系统信息的os模块等等。这些模块底层是用C++实现的，通过V8的桥接层暴露给JavaScript调用。这就是为什么Node能做“后端的事情”，而不只是算个逻辑。
再往后，你会接触到npm init，这个命令会生成一个package.json文件。我见过很多项目里的package.json写得乱七八糟，dependencies和devDependencies混用，scripts脚本堆了一堆但没有任何注释。但从实际上说，package.json是整个Node项目的地基，npm靠它来识别项目信息、安装依赖、执行脚本。几个关键字段的用途需要真正理解：
scripts：定义了可以用npm run xxx执行的命令。start、test这类是npm内置的特殊名字，执行时不需要加run。dependencies：生产环境运行时要用的依赖。devDependencies：只在开发阶段用的工具，比如测试框架、构建工具、代码检查工具。
这里有一个非常容易踩的坑：有些同学图省事，所有依赖都npm install xxx一把梭，全都装进dependencies里。这样做的直接后果是生产环境部署时要下载一堆根本不需要的包，拖慢发布速度；间接后果是体积变大、潜在的攻击面变多。正确的做法是：编辑器插件、代码检查、测试框架这类开发期工具，用npm install -D装到devDependencies。
1.3 关于npm镜像配置的一点实操经验
国内开发者用npm大概率会遇到安装慢或者安装失败的问题。解决思路一般是把registry指向镜像源。这个操作本身不复杂：
npm config set registry https://registry.npmmirror.com但我要多说一句：全局改registry有一个隐患——等你以后要发布自己的npm包，或者要用到npm私有仓库里的包时，又得切回来，而且很容易忘记自己改过。所以我现在更推荐的方式是在项目根目录放一个.npmrc文件，只对当前项目生效：
registry=https://registry.npmmirror.com这样项目的镜像配置跟着项目走，换台电脑克隆下来也能保持一致，不影响全局环境。这是个很小的细节，但确实能避免不少麻烦。
2. 模块系统：使用node真正意义上的“组织代码”的开始
2.1 require的加载与缓存机制
Node的模块系统是它区别于浏览器JS的关键设计之一。在浏览器里，你要引入一段JS逻辑，只能用<script>标签，变量全部共享全局作用域，写多了就冲突。Node则实现了CommonJS模块规范，每个文件是一个模块，有自己的作用域，通过require来加载其他模块，通过module.exports导出内容。
require的细节比你想象的多。首先是路径解析：require('./util')会尝试依次加载./util.js、./util.json、./util.node，如果是目录还会去找package.json里的main字段指定的文件。其次是核心模块优先：你写require('fs')，它不会去node_modules里找，而是直接返回Node内置模块。然后是node_modules的向上查找机制：当前目录没有node_modules，就一层层往上级目录找，直到文件系统根目录。这就是为什么项目里的依赖虽然只装在根目录，但深层嵌套的文件也能require得到的原因。
最容易被忽视的是模块缓存。require第一次加载某个模块后，会把模块的exports对象缓存到内存里，后续再require同一个模块，直接返回缓存，不会重新执行模块代码。这个机制正常工作的时候没什么存在感，但一旦踩到就会很痛苦。举个例子：你用require('./config')加载配置，然后在两个文件里修改这个配置对象，第二个文件看到的修改结果会包含第一个文件的改动，因为它们拿到的是同一个对象引用。基于这个原因，我在模块设计上的一个习惯是：不要导出可变对象，尽量导出创建对象的工厂函数，避免模块间的隐式状态共享。
2.2 ESM与CommonJS的边界问题
Node在12版本之后正式支持ES Module（import/export语法），但CommonJS仍然是默认模块系统，这给很多项目带来了一个历史遗留问题：两种模块系统混用时的兼容性判断。
大致记住这几条经验就够用：
- 文件扩展名
.js的模块，默认按CommonJS解析。要让Node按ESM解析，需要把package.json里加"type": "module"，或者把文件扩展名改成.mjs。 - 在ESM里，不能直接用
require。虽然Node提供了createRequire这个函数可以在ESM环境里创建require，但这属于特例场景。 - 在CommonJS里，
import语法是绝对不能用的。 - 如果你在维护一个库要被两种模块系统使用，最简单的方式是package.json里同时配置
main（给CommonJS用）和exports（给ESM用）字段。
从工程上来讲，新建项目建议直接上ESM，毕竟这是语言标准的发展方向，而且现代Node对ESM的支持已经相当成熟。老项目不必强推，能在上面稳定跑着就尽量少折腾模块系统这种底层结构。但我见过不止一次某开发者在一个CommonJS项目里手一抖写了个import，然后报错Cannot use import statement outside a module，一脸懵。知道这个边界在哪，排错也就快了。
2.3 依赖安装的几个安全与一致性细节
Node生态里依赖管理是个大话题，这里只说几个我见过频率最高的实际问题。第一是一定要提交package-lock.json。这个文件锁定了依赖树的确切版本和下载地址。没有它，你同事npm install的时候可能装上依赖里某个小版本更新，导致行为不一致。你可能觉得差一个小版本不至于，但实际上小版本更新也可能引入破坏性变更。把这个文件提交到版本库，是保证“同一次install，不同人装出同一棵树”的基本手段。
第二是不要轻易修改node_modules里的代码来“修bug”。太多次了，某开发者发现某个依赖在特定输入下会报错，图省事直接改了node_modules里的文件，因为当时确实生效了。然后呢？下次npm install，一切回到解放前。正确做法是先用patch-package这类工具把修改持久化，或者向库的作者提issue并提交修复，再或者用overrides字段在package.json里强制指定某个依赖的版本。
第三是注意npm脚本的执行环境。npm run xxx执行时，npm会自动把node_modules/.bin目录加到PATH里，所以你可以在scripts里直接写webpack、jest这些命令，而不用写完整的./node_modules/.bin/webpack路径。这个设计很方便，但也导致一个问题：如果你全局也装了某个工具，某些情况会误用了全局版本而不是项目内版本。遇到这类不确定时，用npx明确指定项目内的工具，比如npx jest --version。
3. 事件循环与异步编程：这是node最容易被误解的核心
3.1 从I/O模型说起：阻塞与非阻塞
要理解Node的异步，得先从最底层的I/O模型谈起。传统后端语言里，一个请求进来，线程去读数据库、读文件，在数据返回之前这个线程就卡在那里等，这叫阻塞I/O。阻塞没问题，问题在于线程是昂贵的资源，一个线程大约占据几MB的内存，同时开的线程数量多了，CPU光做线程上下文切换就要忙死。
Node的思路完全不同。它运行在单线程上（这里说的是JavaScript执行主线程），发现一个I/O操作要执行时，不会停下来等结果，而是把操作交给底层线程池或者操作系统去处理，自己立刻继续执行后面的代码。等I/O结果回来了，再通过事件通知机制，回到主线程上执行回调函数。这种模式叫非阻塞I/O，配合事件循环构成了Node的整个运行模型。
用一个生活化的比方：你在一家餐厅当服务员，如果你是一个“阻塞式服务员”，每桌客人点完菜你都得站在桌子旁边等他把菜吃完，才能服务下一桌。而Node式的服务员，记下点菜单交给厨房后马上转身去服务下一桌，厨房做好了会通过出菜口叫号，你再去上菜。同样数量的服务员，后面这种模式能服务的客流量显然要大得多。
这就是Node适合I/O密集场景的根本原因——大量时间花在网络读写、文件读写、数据库查询上的应用，用Node可以用相对少的资源撑起很高的并发，比如聊天服务、API网关、代理中间层。但如果是CPU密集型的任务，比如图像处理、复杂计算，单线程的Node反而会成为瓶颈，因为计算过程会占住主线程，其他请求只能排队。理解了这一点，你就能判断一个后端服务到底适不适合Node来做。
3.2 事件循环的阶段划分与执行顺序
非阻塞I/O和回调好理解，但事件循环具体是怎么回事，这才是“使用Node”的分水岭。Node的官方文档把事件循环分成几个阶段：timers（定时器回调）、pending callbacks（推迟到下一轮I/O回调）、idle/prepare（内部使用）、poll（I/O回调的核心阶段）、check（setImmediate回调）、close callbacks（socket或文件句柄关闭回调）。每个阶段维护一个先进先出的回调队列，循环会依次经过每个阶段，处理完该阶段队列的回调后进入下一个阶段。
听起来抽象，我用两个经典例子让你直接感受执行顺序。
第一个例子是setTimeout(() => console.log('timeout'), 0)和setImmediate(() => console.log('immediate'))同时出现时，谁先执行？答案是：不固定。因为在主模块里执行时，事件循环才刚刚开始，setTimeout可能先到时间，也可能还没到，而setImmediate是在check阶段执行的。具体顺序取决于执行到poll阶段时，定时器是否已经到期。但你如果把它们放进一个I/O回调里执行（比如在一个fs.readFile的回调里），那setImmediate必然先于setTimeout，因为I/O回调是poll阶段执行的，poll阶段结束直接进check阶段，而定时器要到下一轮循环的timers阶段才可能触发。这类问题面试经常问，实际开发中你用setImmediate来替代setTimeout(fn, 0)这个从浏览器带过来的习惯，性能会更好。
第二个例子是我强烈建议每个Node开发者都亲手跑一遍的测试——验证微任务和宏任务的顺序。看这段代码：
console.log('start'); setTimeout(() => { console.log('timeout'); }, 0); Promise.resolve().then(() => { console.log('promise'); }); process.nextTick(() => { console.log('nextTick'); }); console.log('end');运行结果如下表：
| 输出顺序 | 内容 | 原因 |
|---|---|---|
| 1 | start | 同步代码最先执行 |
| 2 | end | 同步代码按顺序执行完 |
| 3 | nextTick | nextTick队列优先级高于Promise微任务 |
| 4 | promise | 微任务在事件循环每个阶段之间执行 |
| 5 | timeout | 宏任务（定时器回调）在本轮循环的timers阶段执行 |
process.nextTick和Promise.then都属于微任务，会在当前操作结束后立即执行，但nextTick优先于Promise。这里有个很容易被忽略的实际影响：如果在I/O回调里大量使用process.nextTick，会导致I/O回调被饿死，所以官方文档甚至不太推荐你用nextTick，能用setImmediate或Promise就不用它。
我说这些不是为了考试，而是当你调试“为什么这段代码执行顺序跟我预期不一样”的时候，能有一个清晰的排查框架。Node的异步执行顺序不是靠猜的，它有一套严格的阶段规则。
3.3 回调、Promise与async/await的工程选择
早期的Node代码全是回调风格，嵌套多了就成了教科书里常说的“回调地狱”。后来Promise和async/await逐渐成为主流，很多新人在这种环境下开始写Node，根本不会碰到回调地狱，这是好事，但也带来了新的问题——只看过async/await写法的代码，反而对底层Promise机制理解不透。
我的建议是把这三层都理解到位，但写代码时按这个优先级：能用async/await就用async/await，它让异步代码看起来像同步，可读性最好；需要并行请求时用Promise.all，注意它是全失败或全成功的语义，任何一个Promise reject，整体就reject；在封装底层库或者处理一次性事件时，有时候还是需要回调或事件监听器的写法。
这里提一个实战中非常实用的点：async/await里的错误处理。很多人写try { await fetch(...) } catch (err) { console.log(err) }，觉得ok。但对生产代码远远不够。你在catch块里除了记录错误，至少还要考虑：这个错误是临时的还是永久性的？要不要重试？要不要走降级逻辑？要不要上报到监控系统？这些决策才是后端代码真正有工程含量的部分，而不仅仅是语法层面的“会写”。
再补充一个常见误解：async函数里的await只是等待Promise，它并不会让整个事件循环“暂停”。在await等待的这段时间里，事件循环照样在处理其他请求的回调。这也是Node能保持高并发的底层原因——单线程不代表同一时间只能做一件事，它只是代表JavaScript代码的并发是通过事件循环交替执行来实现的，而不是真正的并行计算。
4. 用Node写一个能跑的真实HTTP服务
4.1 从http模块起步：先看最底层的样子
现在很多开发者一上来就用Express或Koa，Node原生http模块反而没碰过。我的建议反着来：先拿原生http模块写一个极简服务，哪怕只跑通一次，你对“HTTP服务到底是什么”的理解都会不一样。原生写法大致长这样：
const http = require('http'); const server = http.createServer((req, res) => { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.end('Hello Node'); }); server.listen(3000, () => { console.log('server running at http://localhost:3000'); });这段代码虽然短，但涉及了几个基本概念：req是请求对象，里面包含了请求方法、URL、请求头等信息；res是响应对象，你通过它来设置状态码、响应头和响应体；server.listen指定端口启动服务。在此基础上，你自然会发现两个问题：一是原生写法处理路由很笨拙，得自己解析req.url再做if判断；二是请求体的读取是流式的，要用data事件累加数据，处理完再根据Content-Type解析成JSON或表单格式。
我建议你亲手把这几个场景写一遍：GET请求返回一段JSON、POST请求接收JSON体并回显、404兜底路由。做完这些，你可能才会真正体会框架的价值——框架不是帮你省了代码量，而是把请求解析、路由分发、中间件机制、错误处理这些“每个服务都必须做的事”标准化了。
4.2 引入Express后路由与中间件的组织方式
绝大多数项目里，Express仍然是最稳妥的选择。它的核心模型是中间件（middleware）——一个洋葱模型：请求从最外层中间件进去，一层层向内，最后到达路由处理器，响应再从内层一层层传出来。理解了这个模型，你就理解了Express的骨架。
用Express重写上面的服务：
const express = require('express'); const app = express(); app.use(express.json()); app.get('/health', (req, res) => { res.json({ status: 'ok', time: Date.now() }); }); app.post('/users', (req, res) => { res.status(201).json({ id: 1, ...req.body }); }); app.use((req, res) => { res.status(404).json({ message: 'not found' }); }); app.listen(3000);注意代码里app.use(express.json())这一句。这是Express 4内置的JSON解析中间件，没有它，req.body会是undefined，你拿不到POST传上来的JSON数据。这是新手踩过无数次的坑。当然除了JSON解析，Express的中间件世界里你还会用到：日志中间件、CORS处理中间件、静态文件服务中间件等。写之前想清楚“这个能力是全链路都需要，还是只对某些路由需要”，然后决定是app.use全局挂载还是指定路由挂载，这会影响性能和执行顺序。
4.3 工程化配置：日志、错误处理与优雅退出
写一个能跑的HTTP服务不难，难的是写一个能稳定跑在线上、出问题时能快速定位的服务。我觉得有三件事你需要在一开始就做好。
第一件是日志规范。console.log只是开发阶段的调试手段，线上服务你需要结构化日志——每次请求至少记录时间、方法、路径、状态码、耗时，建议用pino或winston这样的日志库，输出JSON格式。为什么是JSON？因为机器解析方便，可以接入各种日志采集分析平台，按字段筛选、聚合。
第二件是错误处理。Express里有一个老问题：如果异步路由处理器里抛出的错误没有被捕获，请求就会挂起，连接不关闭，而且Express默认只会处理同步代码里抛出的错误。解决方法是把异步处理函数包一层，把Promise reject转给next(err)，或者用Express 5（它原生支持Promise错误处理）。在错误处理中间件里，你需要区分客户端错误（4xx）和服务器内部错误（5xx），不要把所有错误都返回500，也不要让错误堆栈直接暴露给客户端——这既是安全问题也是体验问题。
第三件是优雅退出。部署一个node server.js，然后要重启时直接kill进程，正在处理的请求会被粗暴打断。规范做法是监听SIGTERM和SIGINT信号，先停止接收新请求，等待正在处理的请求完成，再关闭数据库连接，最后退出进程。这个模式在Kubernetes等容器环境里尤其重要，因为平台重启Pod不会等你慢慢收拾。兼容这套逻辑的服务，才能算得上“生产可用”。
5. 调试与排错：使用node过程中最常见的几个大坑
5.1 内存泄漏的初级排查思路
Node服务跑着跑着内存越来越高，最后OOM（Out Of Memory）被系统杀掉，这是线上最头疼的问题之一。内存泄漏的原因通常有几类：全局变量缓存了不该缓存的数据、事件监听器不断增加但没有移除、闭包持有大对象、定时器/Interval未被清理。
排查第一步是重现。你需要在测试环境压测或者跑负载脚本，观察内存是否持续增长不回落。Node提供了一个很好的诊断入口：node --inspect启动后，可以在Chrome开发者工具的Memory标签页里抓取堆快照（Heap Snapshot），对比两次快照之间哪些对象实例数量明显增多、被什么变量引用，从而推断泄漏点。
这里我要给一个实用的经验：别一上来就分析堆快照，先检查最明显的两个东西。第一，有没有全局数组或对象在无界增长？比如把请求日志缓存在内存里；第二，有没有往EventEmitter实例上重复addListener？特别是用了第三方库时，如果它在内部主动监听你的对象事件，而你没有相应清理，每来一个请求就多一个监听器，内存就多一份引用。诊断这类问题用process.memoryUsage()打印rss和heapUsed，配合一个简单的定时检查脚本，看趋势是否直线上升。定位到具体代码之后，修复往往只差一两行，难的是找到那一两行。
5.2 unhandled promise rejection为什么不能忽略
Node 15之后，unhandledRejection的默认行为从警告升级为直接终止进程。这意味着你代码里任何一处Promise被reject但没有catch的地方，都可能让整个服务崩溃。听起来很无情，但我支持这个变更——因为被忽略的rejection往往意味着某条业务路径发生了错误，而它没有进入错误处理流程，等于线上事故被悄悄吞掉了。
实际项目里，我见过最离谱的一次：某个定时任务的异步函数里，数据库查询偶尔因为连接超时而失败，但那时项目用的Node版本还没有把unhandledRejection升级成抛错，这个错误只是在控制台打了一行警告。结果就是，某些数据缺失了足足两个星期才被人发现。如果当时进程直接崩掉，反而会立刻触发告警和人肉介入。
所以我的建议是：第一，开发阶段，打开--unhandled-rejections=strict模式，让每个未处理的rejection都直接暴露；第二，代码审查时，严格把关每一个async函数调用链是否有兜底catch；第三，在应用外层加一个process.on('unhandledRejection', ...)全局兜底，记录日志，但不要指望它能治好根本问题，它只是让崩溃发生得更体面一点。
5.3 端口占用与进程管理的实操
我在带新人做Node实战时，几乎每个人都遇到过同一个报错：Error: listen EADDRINUSE: Address already in use :::3000。这个错误的意思是端口被别的进程占用了。新手的第一反应往往是改一个端口继续跑，其实这样反而掩盖了问题——说明有一个旧服务进程可能还活着，它可能占用着旧代码、旧配置。正确做法是找到占用进程并处理干净。
操作系统层面的事件，Linux和macOS上用lsof -i:3000查看进程PID和名字，然后用kill <PID>结束它。Windows上用netstat -ano | findstr :3000查PID，再用taskkill /PID <PID> /F结束。不过这些都是被动处理，我更建议用进程管理工具来托管你的Node服务——比如pm2。它的价值不只是守护进程崩溃后自动重启，还有人看板、日志聚合、集群模式等特性。部署一个Node API服务，最省心的方式之一就是pm2 start app.js --name api-server -i max，用集群模式把服务跑满机器上所有CPU核心。
当然像Docker、Kubernetes这种容器化部署方案是目前更主流的做法，它们本身具备进程重启和资源隔离能力，pm2在容器里的角色就弱化了。但不论怎么部署，理解“服务是怎么被进程管理的”这一点是通用的——这决定了你排障的时候先看哪里、拿到日志去哪里找、进程被杀掉后由谁来拉起。很多人线上服务挂了半天不知道，就是因为跑了前台进程，终端一关程序就没了。用pm2或者容器平台至少能保证：程序死了，它会重新拉起来；重启的时候，你的服务是优雅退出且日志可查的。
补充几条我个人在实际操作中的体会
写到这里，“使用node”这个话题其实还有很多延伸，模块打包、测试策略、性能剖析、安全加固，每个方向都能再写一长篇。我最后挑几条这两年做Node项目最有体感的经验分享给你。
第一，遇到诡异的线上问题时，先确认版本，再怀疑代码。Node版本升级、依赖小版本更新、系统库变动，都可能改变运行行为。排查链路的第一环永远是核对环境和可复现条件，而不是盯着代码干瞪眼。第二，日志要打在关键节点。很多团队日志只在错误时打，结果正常路径发生了什么完全不可见。我的习惯是每个外部请求、每个外部依赖调用、每个关键数据处理分支，都要有结构化的info日志，请求级别用请求ID串起来。排查问题时，你顺着请求ID就能把一次完整操作从头看到尾。第三，善用Node 18+内置的测试运行器和fetch。以前写接口测试要用jest、要装supertest，现在Node原生就能跑基础单元测试和集成测试，脚手架搭建成本低非常多。
“使用node”不是一句简历上的话，它是一整套思维方式和工程习惯。把这篇文章里提到的东西都跑一遍、想一遍、拆一遍，你再去写Node项目，心里会踏实很多。踩坑是难免的，但知道自己为什么踩坑，下一次就能绕过去。
