cmd 和 entrypoint 的真正契合点在于确保启动命令与构建环境、运行时上下文、进程模型及运维需求完全对齐：需匹配基础镜像的可用二进制（如 alpine 用 sh 而非 bash）、以 exec 形式让应用作为 pid 1 正确响应信号、将初始化逻辑封装于 entrypoint.sh 并 exec "$@" 交出控制权、杜绝在 cmd 中补救构建缺陷（如运行时安装依赖），并支持调试覆盖与标准化子命令。
容器启动命令与 dockerfile 设计的真正契合点，在于让 cmd 或 entrypoint 所定义的行为，与镜像构建时的环境、权限、路径和进程模型完全对齐。不是简单“能跑起来”，而是确保启动逻辑在构建上下文、运行时上下文、调试场景和生产约束下都稳定、可预测、可接管。
启动命令必须匹配镜像的执行环境
基础镜像决定了可用的 shell、二进制路径和默认用户。例如：
- 用
alpine镜像却写CMD ["bash", "start.sh"]—— bash 在 Alpine 中默认不存在，应改用sh - 用
distroless镜像时，连sh都没有，CMD 必须是绝对路径的静态二进制，如["/app/server"] - 非 root 用户构建（如
USER node）后，CMD 启动的进程必须有权限读配置、写日志目录，否则启动即失败
ENTRYPOINT + CMD 组合要服务于“主进程即容器生命周期”原则
容器停止 = 主进程退出。因此启动命令必须让应用以 PID 1 运行，并能正确接收和响应 SIGTERM：
- 避免 shell 形式：
CMD node app.js→ 实际 PID 1 是/bin/sh，kill 容器时 node 不会收到信号 - 推荐 exec 形式：
CMD ["node", "app.js"]→ node 是 PID 1，可正常处理终止信号 - 复杂初始化逻辑（如生成配置、等待依赖就绪）应封装进
entrypoint.sh，并以exec "$@"结尾，把控制权完整交给 CMD 参数，不打断进程链
构建阶段与运行阶段的职责必须隔离清楚
Dockerfile 的每一层都该为明确目的服务，启动命令不能“补救”构建缺陷：
- 不要在 CMD 中执行
npm install或python -m pip install—— 依赖应在构建时安装完成，保证镜像可离线运行 - 不要靠 CMD 去
chown或chmod文件 —— 权限问题应在 COPY 或 RUN 阶段解决 - 多阶段构建中，最终 stage 只保留运行时必需的文件和二进制，CMD 应直接调用它们，而不是跨 stage 路径查找或启动构建工具链
启动方式要兼容调试、覆盖与标准化运维
一个设计良好的启动结构，应当允许开发、测试、CI 和 SRE 各取所需：
- 用
ENTRYPOINT ["/entrypoint.sh"]+CMD ["serve"]，既能运行docker run myimg，也能docker run -it myimg sh进入调试 - 暴露清晰的入口点语义，比如支持
CMD ["migrate"]、CMD ["healthcheck"]等子命令，便于 CI 流水线复用同一镜像做不同任务 - 避免硬编码端口、地址或秘钥到 CMD 中，这些应通过环境变量或挂载配置注入，保持镜像通用性
