这是一份从可启动服务走到可维护路由的练习笔记。Node.js 和 Express 很容易在几分钟内把一个接口跑起来，但“能返回 JSON”只是开始。真正需要花时间的是把入口、路由、业务逻辑、数据访问和部署边界分开，让下一次修改不必重新猜整个项目。
初始化与启动
先创建目录并初始化 package.json，再安装 Express 和 CORS。入口文件负责创建应用、注册中间件和挂载路由；启动命令写进 scripts，这样本地和部署环境使用的是同一条命令。
mkdir nodeexpress && cd nodeexpress
npm init -y
npm install express cors
健康检查接口应该尽量简单，并返回稳定的 JSON：
import express from 'express'
const app = express()
app.use(express.json())
app.get('/health', (_req, res) => res.json({ ok: true }))
app.listen(process.env.PORT || 3000)
它不仅方便浏览器访问，也能让反向代理、部署平台和监控系统确认进程是否在响应。端口来自环境变量，避免把开发机端口写死在代码里。
路由不要成为垃圾桶
公开接口和管理接口可以放在不同路由模块中。路由函数只处理参数校验、调用服务并返回状态码，业务规则和数据访问不要全部堆进 app.js。对于每个输入，都要明确缺失、格式错误、权限不足和服务异常对应的状态码；只返回一个模糊的 500，会让客户端和日志都很难定位。
中间件的顺序也属于接口契约。解析 JSON 要在使用 req.body 之前，鉴权要在管理路由之前，错误处理中间件放在所有路由之后。每加一层中间件，我都会确认它是否改变了请求对象、响应头或失败方式。
数据和外部依赖
练习阶段可以使用内存数组或文件，但需要明确它们的限制：进程重启会丢数据，并发写入没有事务，多个实例之间也不会共享状态。若服务准备长期运行，应该尽早把数据访问抽成接口，日后替换 PostgreSQL 或其他存储时，路由不必一起重写。
外部 API 需要设置超时、记录请求 ID，并把第三方错误转换成自己的稳定格式。不要把上游响应原样透传给用户，因为对方改字段以后，自己的客户端也会跟着失效。
部署前先留下回滚路径
部署不只是把进程放到服务器上。要确认构建命令、Node 版本、环境变量、反向代理、日志位置和健康检查都能从一台新机器重新解释。更新时保留上一版镜像或提交，发生错误先回滚应用，再判断是否需要处理数据迁移。
这份练习留下的重点不止一条“启动成功”的命令，还包括几组更小的边界：入口知道怎样启动，路由知道怎样回应，服务知道怎样处理用例，数据层知道自己的限制，部署知道如何检查和退回。项目越小，越适合现在就把这些边界写出来。