生产级docker镜像必须可复现、最小化、安全可控：禁用latest标签，显式指定如node:18.19.0-alpine3.20；优先选用-alpine/-slim变体；禁止保留构建工具；合并run指令并清理缓存；合理使用user与.dockeringore。
为什么直接用 FROM node:latest 或 FROM ubuntu 就算不上生产级
因为 latest 标签不锁定版本，下次构建可能拉到完全不同行为的镜像；而 ubuntu 这类通用基础镜像体积大、预装包多、攻击面广。生产环境要求可复现、最小化、权限收敛、安全可审计——这些都得靠显式控制来实现。
- 必须写死基础镜像 tag，比如
FROM node:18.19.0-alpine3.20，而非node:alpine或node:latest - 优先选
-alpine或-slim变体，避免带完整包管理器和调试工具的基础镜像 - 禁止在镜像中保留构建时才需要的工具（如
git、gcc），除非你明确需要它们在运行时存在
RUN 指令合并与缓存失效的实操边界
Docker 构建缓存按层生效，但只要某一层指令变了，它之后所有层都会重建。所以把频繁变动的操作（如复制源码）放在后面，把稳定操作（如装依赖）放在前面，是提速关键。
- 把
apt-get update && apt-get install和apt-get clean && rm -rf /var/lib/apt/lists/*写在同一行RUN里，否则中间层会残留缓存目录 - Node.js 项目中，先
COPY package.json .，再RUN pnpm install，最后才COPY . .—— 这样改代码不会触发重装依赖 - 不要写成两行
RUN apt-get update和RUN apt-get install，第二行无法复用第一行的 apt 缓存索引
非 root 用户 + USER 指令为什么不是“加了就行”
只写 USER nobody 很容易导致容器启动失败：nobody 用户可能没权限访问工作目录、日志路径，或绑定端口（EXPOSE 不等于能 bind，USER 后普通用户默认不能 bind 1024 以下端口）。
- 先
WORKDIR /app，再RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001创建专用用户 - 用
RUN chown -R appuser:appgroup /app确保目录归属正确 - 最后
USER appuser:appgroup，且确保应用监听端口 ≥ 1024（如3000而非80） - 如果必须暴露 80 端口，别硬 bind，改用反向代理（如 Nginx 容器前置）或
--cap-add=NET_BIND_SERVICE启动容器（不推荐）
.dockerignore 被忽略的三个高危文件类型
没配 .dockerignore 的后果不只是镜像变大：它可能把 .env 里的数据库密码、node_modules 里的本地二进制模块、甚至 .git 历史记录一起打进镜像，造成敏感泄露或构建失败。
- 必须包含：
.git、.gitignore、node_modules、*.log、.env、.venv、__pycache__ - 特别注意：
dist/或build/如果是构建产物，也要加进去——否则 COPY . . 会覆盖掉前面RUN pnpm build的结果 - 不要用通配符过度屏蔽，比如
*会误删Dockerfile本身；逐条列比模糊匹配更安全
USER 切换后权限断层、.dockerignore 漏了一行导致 package-lock.json 被跳过、或者 FROM 镜像里 glibc 版本和你编译的二进制不兼容——这些都没法靠 docker build --no-cache 解决，得从 Dockerfile 第一行开始推演执行流。
