很多人问过我同一个问题Node.js 学到什么程度才能叫“学完了”我通常先反问一句你写 Express 接口已经非常熟练了但被问到“为什么 setTimeout 的定时器不准”“接口偶尔超时怎么排查”“两个服务之间如何保证数据一致”这类问题时还能不能聊出东西这一问往往就把差距聊出来了。Node.js 这门技术本身并不复杂复杂的是围绕它铺开的整套能力链从语法、异步、模块到工程化、测试、部署再到事件循环、V8 内存、流式处理最后落到系统架构、服务治理和技术取舍。市面上单点教程很多但把这条链路串成一条有阶段、有标准、有产出物的学习路线反而少见。所以我想把自己的实际经验整理出来分成四个阶段入门期、工程期、原理期、架构期。每个阶段学什么、做什么、用什么标准检验自己都会讲清楚。这份路线适合刚接触 Node.js 的新人也适合写过一阵子业务但感觉一直在“会用框架”层面打转的同学。下面直接进入正题。1. 学习路线为什么要分阶段以及大多数人卡在哪1.1 最常见的三种学习弯路我带过不少新人也看过很多自学者的学习记录发现 Node.js 学习最容易走偏的方向有三个。第一种语法驱动学完就忘。今天看一遍回调函数明天背一遍fs模块后天搜一下express.static怎么用。知识全是碎片没有一条主线把它们串起来写出来的代码还是“Java 思维搬进 JavaScript”充斥着大量同步式写法。第二种框架驱动只会搭接口。这类同学能找到工作但天花板很低。会用 Express 写 CRUD会用 Mongoose 连数据库但遇到线上问题就卡住内存为什么会涨并发一高为什么延迟飙升进程为什么无缘无故退出因为这些问题的答案都不在框架层。第三种原理驱动脱离实战。一上来就啃 libuv 源码、研究 V8 隐藏类谈起事件循环头头是道但代码写得一塌糊涂连个像样的服务都搭不起来。原理是很好但脱离实践的原理只是谈资。分阶段学习的本质是让每个阶段都有明确且可迁移的产出。你学的不是“知识列表”而是一层层叠加的“系统能力”。1.2 四个阶段的目标和能力模型我先给一个总览表后文逐个展开。阶段核心目标典型产出检验标准第一阶段入门期掌握语言基础与异步模型不依赖框架的 HTTP 服务、命令行工具能解释回调、Promise、async/await 的关系第二阶段工程期具备独立交付业务能力可维护的业务系统、测试与部署流水线能独立上线一个带数据库、鉴权、日志的服务第三阶段原理期理解运行时底层机制性能分析报告、内存问题排查案例能定位并解释线上故障根因第四阶段架构期具备系统设计与取舍能力架构方案、技术选型文档、容错设计能在多个候选方案中给出有依据的选择这四个阶段不是严格串行。实际成长中会有重叠比如你写业务的同时也可以研究原理但主次必须分明。我强烈建议按顺序走原因是每个阶段的知识对下一阶段都有支撑作用不懂异步模型就谈不了事件循环没写过完整业务就看不清架构要解决什么问题。1.3 这份路线的适用范围先说清楚这份路线主要面向 Web 后端方向的开发者。如果你是用 Node.js 做工具脚本、爬虫、集成测试到第二阶段基本就够了后面两个阶段属于“增值项”。但如果你的目标就是从 Node.js 开发者走向系统架构师那四个阶段缺一不可。另外学习周期我给一个参考值第一阶段 3 到 6 周第二阶段 3 到 6 个月第三阶段 6 个月以上持续迭代第四阶段更是需要项目机遇和个人悟性。别指望速成但按这个顺序走每一步都会觉得“值”。2. 第一阶段把 Node.js 用起来先跨过异步这道分水岭2.1 最小启动包语法、模块与内置模块入门阶段不需要碰任何框架。先把三块地基打牢第一块是 JavaScript 语言本身。不是所有 JS 语法都要背熟但几个重点必须过关闭包、this指向、原型链、解构赋值、展开运算符。闭包尤其重要因为它和异步回调、事件监听器的内存泄漏直接相关。this的指向问题不搞清楚后面写类、写事件处理器会非常痛苦。第二块是模块系统。CommonJS 和 ESM 都要认识。现在新项目普遍用 ESM但大量存量代码和工具链仍是 CommonJS。至少要知道require与import的区别、模块缓存的含义、循环依赖会发生什么。这里我不建议死记结论可以自己写两个互相引用的文件跑一遍观察 Node.js 给出的警告信息印象会深很多。第三块是内置模块。重点学fs、path、http、events、stream、child_process这几个。不需要每个 API 都背但要知道“Node 提供了什么能力”。比如遇到文件处理先想到fs遇到进程管理先想到child_process。真正写代码时翻官方文档就行关键是要建立“内置模块够用”的直觉而不是遇到什么都先npm i装个包。一个版本题外话装 Node.js 时优先选择官网的 LTS 版本不要为了尝鲜去追最新版。我自己踩到过测试版号还没正式发布、安装器直接报错的尴尬。生产项目老老实实锁 LTS能省掉一堆兼容性麻烦。2.2 异步三件套回调、Promise 与 async/await 的递进逻辑Node.js 最大的特点就是异步 I/O。入门节点上异步编程是第一个分水岭。我建议按“回调 → Promise → async/await”的顺序学不要直接跳到 async/await。为什么因为 async/await 只是语法糖它背后包装的仍然是 Promise 和微任务队列。如果没经历过回调时代你很难理解为什么会有 Promise 这种东西也不容易理解await之后的代码到底在哪个时机执行。事件循环的原理放到第三阶段细讲入门阶段你只需要建立一个核心认知异步任务不会像同步代码那样从上到下依次执行它会在某个将来的时间点被回调。为了验证这个认知你可以写这样一段代码console.log(a); setTimeout(() console.log(b), 0); Promise.resolve().then(() console.log(c)); console.log(d);先猜输出顺序再实际运行。如果你的预期是a d c b说明你对“同步代码先跑完、微任务先于宏任务”已经有了基本感觉如果你猜的是a b c d那就回头把事件循环的基础概念再读一遍这一步值得慢一点。学完三个版本之后再给自己立一条规矩新代码统一用 async/await 编写只有在需要兼容旧接口或做特殊并发控制时才手动操作 Promise。这不是偷懒而是让代码可读性更高、错误处理更明确。2.3 实战检验写一个不依赖第三方框架的 HTTP 服务理论学完不动手等于白学。入门阶段的收官项目我建议是用原生http模块写一个“迷你接口服务”。这个项目要包含路由分发、请求体解析、简单文件读写、统一错误响应。不需要数据库不需要框架所有数据可以放在内存里甚至用 JSON 文件模拟存储。示范一个最小骨架const http require(node:http); const server http.createServer((req, res) { if (req.url /health req.method GET) { res.writeHead(200, { Content-Type: application/json }); res.end(JSON.stringify({ status: ok })); return; } res.writeHead(404, { Content-Type: application/json }); res.end(JSON.stringify({ message: Not Found })); }); server.listen(3000, () console.log(server running at 3000));这个练习的意义在于你能亲眼看到 Node.js 是怎么处理网络请求的请求对象是一个Readable流响应对象是一个Writable流它们背后都是事件机制在驱动。这些感受是用框架时感知不到的。2.4 入门期最容易踩的三个坑我把自己带新人时常纠的问题列出来。坑一用同步方法处理正经业务。初学文件操作时因为同步写法简单有人就全用fs.readFileSync。但同步方法会阻塞事件循环并发一高整个服务就卡死。正确的做法是默认使用异步 API只有脚本启动加载配置这种一次性场景才考虑同步。坑二回调地狱的代码还拿来上线。在项目里见到三层以上嵌套回调时我的反馈永远是同一个重构成Promise或async/await。这不是风格偏好而是可维护性问题。嵌套回调里的错误处理极易漏掉一旦漏掉就是线上事故。坑三npm install装包不假思索。刚入门时很容易看到一个包装一个依赖越来越多版本还经常冲突。我的建议是装包前先问自己一句“内置模块真做不到吗”装完后把依赖锁定在配置文件里提交到仓库避免别人拉下来跑不通。完成这些内容第一阶段就算通关了。此时你应该能独立写一个简单的 HTTP 服务也能看懂别人项目里基础的异步代码。接下来可以进入工程化训练。3. 第二阶段从“能跑”到“能干活”工程化能力决定职业下限3.1 框架学习深挖一个而不是收集一堆进入第二阶段会有个绕不开的选择学 Express 还是 Koa还是直接上 NestJS我的建议非常明确入门框架选 Express。理由有三点Express 生态最成熟中间件数量最多遇到问题最容易找到答案。Express 的设计足够简单你能看清楚“中间件机制”是怎么回事这为后面理解 Koa 的洋葱模型和 NestJS 的依赖注入都打好了底。真实存量项目中 Express 占比仍然很高你出去大概率会碰到它。Koa 可以在熟悉 Express 之后再体验。Koa 的洋葱模型在进阶场景里更优雅但这也是它最大的学习负担——如果没搞懂中间件执行顺序调试起来会懵。NestJS 则属于工程化更强的一档。如果你确定要走企业级后端方向第二阶段后期了解 NestJS 是有价值的但我不建议一上来就学。它把很多东西都“替你做完了”比如依赖注入、模块化组织你反而看不到底层逻辑。选定框架后别急着写业务。先做一件事手写一个中间件的执行链理解next()调用前后的执行顺序。哪怕只是十来行的函数组合也能帮你建立对中间件机制的直观认识。3.2 基本功三件套调试、测试与错误处理这个阶段最容易忽视的不是新框架而是“让代码可维护”的基本功。调试。别再全靠console.log了。学会用 Node.js 自带的node --inspect和浏览器 DevTools 配合断点调试。在关键入口打上断点观察调用栈、变量值、异步回调的时序排查问题的效率翻几倍。这个过程会让你真正理解异步代码的执行顺序而不是靠猜。测试。业务代码越来越复杂时没有测试就是裸奔。测试框架用 Vitest 或 Jest 都可以我建议新手从 Vitest 上手因为它的 API 更简洁、TypeScript 支持更自然。不要一上来追求覆盖率数字先把“核心业务逻辑的关键链路”覆盖住。比如一个下单接口至少要有成功下单、余额不足失败、重复提交幂等失败三个用例。错误处理。在我看来这是第二阶段最重要的内容。Node.js 的错误类型很多同步异常、异步回调错误、Promise rejection、未被捕获的事件异常。你要形成一套自己的处理规范例如所有 async 函数必须try/catch或使用统一包装中间件捕获EventEmitter的error事件必须监听否则进程直接崩溃进程级别要挂uncaughtException和unhandledRejection钩子至少做到记录日志后优雅退出而不是默默死掉。3.3 真实业务的三个必修课数据库、鉴权与日志第二阶段的核心是“能独立交付一个业务系统”所以这三块绕不开。数据库。关系型与非关系型建议都碰一碰。关系型用 PostgreSQL 或 MySQL 选一个另一个可以后补非关系型优先 MongoDB 或 Redis。重点不是会写 SQL 或 CRUD而是理解连接池怎么配置、事务怎么用、慢查询怎么定位。很多新手项目跑得慢不是 Node.js 的问题而是 SQL 里缺索引、连接没复用。鉴权。最常用的方案是 JWT。你要自己能写出完整的登录流程密码哈希推荐bcrypt或argon2、签名与校验、过期处理、刷新令牌的取舍。我特别提醒一点JWT 一旦签发就很难主动吊销所以短期令牌 刷新令牌的双 token 设计在多数业务里是标配。日志。不要用console.log打天下。至少引入结构化日志方案把请求 ID、用户 ID、耗时、状态码统一输出成 JSON 格式方便检索和分析。日志分级debug、info、warn、error也要建立起来线上定位问题时能救命。3.4 部署与交付PM2、Docker 与 CI/CD 的入门闭环代码写完了部署不上去等于零。第二阶段最后一块拼图是部署。最简单的起点是PM2。它解决几个核心问题进程守护挂了自动重启、多实例cluster 模式、日志收集。哪怕你暂时不写配置文件也要记住三个命令pm2 start、pm2 logs、pm2 reload。紧接着上Docker。写一个干净的多阶段Dockerfile把构建、依赖安装、运行分开。一个基础示例FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . FROM node:20-alpine WORKDIR /app COPY --frombuilder /app/node_modules ./node_modules COPY --frombuilder /app ./ EXPOSE 3000 CMD [node, src/index.js]这个文件不复杂但它能逼你思考镜像分层怎么设计、哪些文件不该进镜像、生产依赖如何瘦身。CI/CD可以从一个最小的 GitHub Actions 或 GitLab CI 开始提交代码后自动跑测试、构建镜像、推送到镜像仓库再触发部署。不用追求全自动先把“自动测试 手动部署”跑通就已经超过很多小团队的交付水平了。到这个阶段结束时你应该能独立把一个带数据库、鉴权、日志的业务服务上线并且别人可以接手维护你的代码。接下来第三阶段会开始触及 Node.js 的“灵魂”。4. 第三阶段一头扎进原理把“会用”升级为“懂它为什么”4.1 事件循环与 libuv重新审视异步时序很多人在第二阶段已经能用 async/await 写得很溜但碰上“为什么这段代码先输出、那段后输出”就答不上来。第三阶段首先把这块彻底补上。Node.js 的异步能力底层是libuv提供的事件循环。简单理解libuv 是一个用 C 编写的异步 I/O 库它管理线程池、文件系统操作、网络 I/O、定时器。JavaScript 代码本身是单线程的但事件循环在底层调度着大量异步任务。事件循环的“几个阶段”记忆起来不难timers定时器回调、pending callbacks上一轮遗留的 I/O 回调、idle/prepare内部使用、poll轮询等待 I/O、checksetImmediate、close callbacks关闭回调。每个阶段都有对应的任务队列一个阶段执行完再进入下一个阶段。你真正需要建立的不是背诵顺序而是三个判断process.nextTick和Promise的回调会在“当前阶段结束后、进入下一阶段前”执行所以它们的优先级精细调度中比定时器更高。setTimeout的延迟时间只是“最早可执行时间”不是精确计时器。事件循环被同步任务阻塞时定时器会相应延后。setImmediate与setTimeout(0)的执行顺序不是固定的取决于外层代码处于事件循环的哪个阶段。这个阶段我给一个直观的练习用setImmediate、setTimeout、process.nextTick、fs.readFile组合不同的打印顺序然后逐行解释原因。做过三轮这种实验后你对异步时序的掌控会有一个肉眼可见的提升。4.2 V8 与内存管理服务为什么越跑越慢线上 Node.js 服务最常见的故障之一就是内存持续增长、GC 越来越频繁、响应越来越慢。要排查这类问题必须理解 V8 的内存结构。V8 把内存分为新生代和老生代新生代存放短生命周期对象用 Semi-Space 设计配合 Scavenger 算法快速回收老生代存放生命周期较长或晋升下来的对象用标记-清除和标记-整理。Node.js 进程的heapUsed指标就是看这些区域的使用量。内存泄漏的常见原因我归纳为四类全局缓存无脑生长把所有东西都塞进global或模块级Map一直没有清理条件。事件监听器堆积每次请求都往某个EventEmitter上on但从不off。闭包持有大对象异步回调引用了外层大变量导致它一直无法回收。流与连接未关闭数据库连接、HTTP 请求、文件流用完了没有释放。排查思路也相对固定。先用node --inspect打开 DevTools 的 Memory 面板连续做几次堆快照heap snapshot比较对象数量变化重点看挂载在全局和环境上的大的闭包容器然后结合业务逻辑锁定“什么操作会增加这些对象”。这里提一句别迷信“内存泄漏就加内存”。遇到内存问题先做快照对比找到真实累积源头才是根治。4.3 Stream 与背压处理大流量的正确姿势fs.readFile一把梭会把整个文件读进内存这是很多人的习惯写法。文件小无所谓文件一旦上 GB内存直接爆。而这个问题的标准解法是流。流是一种“边读取边处理”的机制。Node.js 中有四种流可读Readable、可写Writable、双向Duplex和转换Transform。用流处理大文件的核心优势是内存占用恒定不随文件体积增长。但流里最容易被忽视的是背压Backpressure。简单说可读流的产出速度可能远大于可写流的消费速度如果不加控制数据会堆积在缓冲区导致内存暴涨。Node 的pipe方法会自动帮你处理背压——只要消费方反馈写不下了生产方就暂停流动。我自己写流处理时坚持一个原则能pipe就不手动read能链式转换就不要逐条push让框架的流控机制发挥作用。典型场景示范读取一个大日志文件逐行过滤后写入新文件。用Transform实现行级处理内存占用始终在几十 MB 以内。这个能力在处理数据迁移、报表导出任务时特别有用。4.4 进程模型cluster、worker_threads 与应用场景Node.js 是单线程的但一个 Node.js 进程只能用一个 CPU 核心。要利用多核 CPU必须启动多个进程。两个主要工具需要分清cluster 模块用于多进程共享端口。主进程负责监听端口和负载均衡子进程各自运行事件循环。它解决的是“并发吞吐量”问题。即使是小服务我也建议用 PM2 的cluster模式启动多实例默认就能享受多核红利。要注意的是多进程之间不共享内存session 这类数据必须外置到 Redis。worker_threads则用于“计算密集任务”。比如图像处理、加密解密、大数据序列化这类同步计算会阻塞事件循环放到 worker 线程里才能不拖垮主进程。worker 之间通过postMessage通信数据是拷贝传递所以传送大数据时要谨慎。选型逻辑很简单I/O 密集用 cluster 加多进程就够CPU 密集型碎活用 worker两者结合的场景则要考虑混合架构。常见反例是有人把 cluster 当成线程池把所有逻辑全塞进 worker反而带来通信成本和数据拷贝开销。4.5 性能分析三板斧基准、火焰图、堆快照第三阶段的实战检验是解决一个真实的性能问题。我日常排查性能问题时按照下面三板斧来。第一板斧基准对比。先用autocannon或wrk压测确认“到底慢多少”。没有数据支撑的优化都是猜。建议压测之前先明确压测场景和参数压测结果记录成文件方便对比改动前后差异。第二板斧CPU 火焰图。如果 CPU 占用高、请求延迟大用clinicjs或0x生成火焰图。火焰图一眼能看出热点函数在哪里到底是业务代码的问题还是第三方模块里某个低效操作占了大量 CPU。我见过很多“V8 优化不生效”的现场最后发现都是正则表达式灾难性回溯导致 CPU 打满火焰图几秒钟就能暴露。第三板斧堆快照。内存相关的问题用前面 4.2 的方法做连续堆快照对比定位泄漏源。配合heapdump类工具把快照拉到 DevTools 里分析。这三板斧不是并列关系而是按“现象 → CPU → 内存”的排查路径依次使用。原理期的学习方式以“排查真实问题”为主不要贪多半年里深入解决两三个线上问题比读十本书都管用。5. 第四阶段越过代码站在系统边界上做架构决策5.1 架构师不是“更高级的程序员”而是技术取舍者到了第四阶段身份开始转变。你可能已经被叫“架构师”或者正准备往这个方向走。但我要先泼一盆冷水架构师的核心职责不是画出一张漂亮的架构图也不是代码写得比别人好而是在各种约束条件下做出可执行的技术取舍。约束包括团队规模、交付时间、成本预算、现有技术栈、数据一致性要求、合规要求、团队学习曲线。同一个业务问题在大厂高并发场景和创业公司快速验证场景下最优解完全不同。架构能力的第一表现是“能说清楚为什么选这个方案代价是什么”。比如团队核心系统应该用 NestJS 这类框架性强、约束多的技术还是用 Express 这类自由度高的轻框架没有标准答案。前者结构统一、适合多人协作但学习成本和约束感强后者上手快、灵活但对团队成员自律性要求极高。架构师要能分析这两个方案在你们团队的落地差异而不是拿社区热度当决策依据。5.2 从单体到分布式拆分的时机与代价很多开发者一上来就想着微服务觉得服务拆得越多越“架构”。我的建议是先做强单体拆分必须由真实痛点驱动。单体阶段怎么设计模块边界清晰、数据库 schema 规范、接口版本化、团队拥有明确代码所有权这些做到了单体可以支撑很长时间。真正出现痛点时拆分的信号也各不相同某个模块发布频率远高于其他模块、团队协作互相阻塞、某个模块的资源需求与其他模块差异巨大。拆分时的“前三个服务”我通常会建议挑边界最清晰的拆比如独立的定时任务服务、独立的推送服务、独立的对外接口层。避免一上来就拆订单和用户这种强关联核心。拆完之后你必须直面一个单体时代没那么痛的问题数据一致性和网络不可靠。两个服务之间不能再用本地事务要考虑消息队列、最终一致性、幂等重试、分布式事务方案。我的习惯是能靠业务设计的幂等解决就绝不引入分布式事务框架因为后者会带来极大的复杂度。消息队列如 RabbitMQ、Kafka在架构中的定位不是“解耦神器”而是“异步削峰和故障缓冲”。引入它意味着你要额外运维、处理消息重复和顺序问题。我在自己的架构方案里有个原则如果只是为了让两个服务异步通信先考虑 HTTP 回调或定时任务只有流量峰值明显、需要削峰填谷或需要保证最终一致性的复杂场景才考虑 MQ。5.3 架构的非功能需求高可用、可观测与容量规划业务功能是架构的一部分但架构师和普通开发明显拉开差距的地方往往在“非功能需求”。高可用。核心词是“消除单点”。服务要多实例部署数据库要主从或高可用方案消息队列要有副本。再往上走还要考虑故障自动转移、优雅停机、流量摘除。我强烈建议团队每个季度做一次故障演练主动 kill 掉一个实例观察流量切换是否正常、日志和告警是否到位。演练完你会发现比平时读多少文章都管用。可观测性。三个维度缺一不可日志分布式追踪 ID 串联、指标QPS、延迟、错误率、CPU、内存、链路追踪请求在多个服务间的完整路径。先别追求上全链路系统从一套能回答“当前系统健康吗”的指标体系开始RED 方法Rate、Errors、Duration就足够覆盖大多数团队的需求。我通常建议“日志先行”——没有统一访问日志和错误日志时任何监控都等于空中楼阁。容量规划。不是算一次容量就完事而是持续地在发布新功能前回答三个问题这个功能带来的额外 QPS 是多少现有实例的冗余量够吗如果翻倍增长哪个资源会先成为瓶颈我见过不少系统不是流量打挂的而是突增的慢查询把数据库连接池占满拖垮的这类问题在设计阶段就应该通过预估评估并预防。5.4 技术选型与边界意识让决策有据可查技术选型是我在架构评审中被问到最多的话题也是最容易出现“口水战”的环节。我的经验是建立一套“选型对照表”把候选方案放在同一标准下比较。对照表至少包含这些维度业务匹配度能否覆盖核心需求团队熟悉度学习成本、招聘难度运维复杂度部署、监控、升级负担可扩展性未来三年是否够用社区与生态活跃度、关键问题是否有解风险与替代方案如果这个方案挂了怎么办几条实践经验不要因为某个方案“高级”而选择它除非它能直接解决当前的痛点不要因为某个方案“大家都在用”而无脑选择先确认它的约束是否和你们团队匹配决策后一定要输出一份简短的技术选型文档写明背景、选项对比、结论、潜在风险这样以后质疑和复盘都有迹可循。5.5 一条可参考的检验路径考纲、评审与复盘第四阶段没有终点但需要有检验手段。我自己的做法有三条。第一条把系统架构设计师考试大纲当成一张知识地图。这不是让你一定去考试而是它把架构师需要覆盖的知识面梳理得非常系统计算机系统、信息化、软件工程、系统架构设计、项目管理等。你可以用它逐项对照自己的盲区查缺补漏。第二条主动参加架构评审包括给别人评审和让别人评审你的方案。评审中最有价值的不是通过而是“为什么这么设计”的追问。被挑战得多了你自然会把“边界条件”和“权衡理由”提前想清楚。第三条坚持做问题复盘。每次线上故障、每次架构决策失败都要沉淀成一篇复盘文档。不用写得很长但要覆盖问题现象、根本原因、修复过程、为什么当时没发现一根线、以后如何预防。见过上百份复盘之后你再看系统时会自然带着一种“这里会出什么问题”的警觉。最后说点我自己的体会这条四阶段路线是我带团队时推荐给多数人的成长框架也是我自己走过来的复盘总结。我见过不少聪明人想直接跳到第三、第四阶段结果在第一阶段的异步模型上摔了跟头也见过在第一阶段停留太久、迟迟不开始做真实项目的人。四阶段的顺序不是教条是为了让你在每个深度上都有“够得着的产出”。如果让我给一条最实在的建议我会说每个阶段都留一个“长期观察项目”。它不需要多复杂但必须贯穿你的成长全程。比如一个个人博客后端从原生 HTTP 版迭代到 Express 数据库版再到部署上线、性能优化、甚至拆成几个服务。这样一个项目会反复逼迫你做工程决策边界意识和架构取舍的直觉就是在一次次“改不动了该重构了”的体验中长出来的。Node.js 本身只是一门技术但走向架构师需要的东西恰恰都藏在“把技术用出边界感”的过程里。希望这份路线能让你少走一些我走过的弯路。
