node.js项目docker化需选合适基础镜像、分层优化构建、非root用户运行及配置端口健康检查；alpine轻量但兼容性差，含原生模块宜用slim；npm依赖应前置copy并用npm ci；须addgroup/adduser并chown文件，最后user切换；expose、healthcheck、cmd数组格式不可少。
Node.js 项目用 Docker 搭建，核心是写好一个靠谱的 Dockerfile，再配好运行时环境。不靠玄学，靠顺序、分层和权限控制——这几个地方配错，轻则镜像臃肿、构建慢，重则启动失败或安全告警。
基础镜像选 Alpine，但得看兼容性
生产环境优先用 node:18-alpine 或 node:20-alpine。体积小（约 39MB）、攻击面少、启动快。但它用的是 musl libc，不是 glibc。如果你用了依赖 C++ 原生模块的包（比如 sharp、bcrypt、某些数据库驱动），可能直接报错“cannot find module”或“symbol not found”。这时降级用 node:20-slim（约 200MB）更稳妥，它基于 Debian，兼容性更好，也比完整版 node:20（900MB+）干净得多。
- 纯 JavaScript 项目（Express、Nest、Fastify 等）→ 直接上 Alpine
- 含原生模块或 CI/CD 中频繁编译 → 用 slim 更省心
- 开发阶段调试需要 devtool、bash、curl 等 → 可单独用完整镜像做 builder 阶段
Dockerfile 分层要“静动分离”
关键不是“复制代码 + 装依赖”，而是让 Docker 的层缓存真正生效。npm 安装最耗时，必须让它只在 package.json 或 package-lock.json 改变时才重跑，而不是每次改一行代码就重装整个 node_modules。
- 先
COPY package*.json ./，再RUN npm ci --only=production（CI 场景推荐npm ci，比npm install更确定、更快） - 再
COPY . .—— 把源码放最后，避免缓存失效 - 如果是 TypeScript 项目，
npm run build放构建阶段，不要塞进运行镜像里
运行用户不能是 root
Docker 默认以 root 运行容器，但 Node.js 应用完全没必要。不设非 root 用户，Kubernetes 会拒绝部署（PodSecurityPolicy 或 Pod Security Admission 拦截），本地扫描也会标高危。
- 加两行：
RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001 -G appgroup - 复制文件后加
COPY --chown=appuser:appgroup，确保文件属主正确 - 最后
USER appuser切换身份，后续所有命令都以该用户执行
端口、健康检查、启动命令别漏掉
这些不是可选项，是生产就绪（production-ready）的基本信号：
-
EXPOSE 3000（或你实际监听的端口）——虽不影响功能，但明确语义、方便工具识别 -
HEALTHCHECK：比如curl -f http://localhost:3000/health || exit 1，让编排系统知道服务是否真活 -
CMD ["node", "dist/index.js"]—— 用数组格式，避免 shell 封装带来的 PID 1 问题（否则 SIGTERM 杀不死进程）
配完跑一次 docker build -t my-node-app .，再 docker run -p 3000:3000 my-node-app 测试通不通。不复杂，但容易忽略细节。
