容器启动失败主因是运行时覆盖命令后未满足执行前提，需检查CMD/ENTRYPOINT组合逻辑、工作目录、依赖就绪及信号处理，推荐exec格式并验证PID 1和服务优雅退出。
容器启动失败常因运行时覆盖了镜像中预设的启动命令，而新命令又不兼容或缺失必要参数。关键不在“能不能覆盖”，而在“覆盖后是否仍满足执行前提”——比如工作目录、依赖服务就绪、信号接收能力等。
检查 CMD 和 ENTRYPOINT 的组合逻辑
两者共同决定最终执行命令：ENTRYPOINT 是主程序，CMD 是它的默认参数。若只写 CMD，它会被 docker run 后的参数完全替换；若同时定义 ENTRYPOINT 和 CMD，运行时参数会**替换 CMD，但不会绕过 ENTRYPOINT**。
- 推荐用 exec 格式（如 CMD ["node", "app.js"]），避免 shell 模式下 PID 1 不是应用进程，导致无法接收 SIGTERM
- 若 ENTRYPOINT 是脚本（如 ENTRYPOINT ["./entrypoint.sh"]），确保脚本末尾有 exec "$@"，否则参数无法透传给实际服务
- 误删 CMD 且未提供运行时参数时，可能执行空命令，容器立即退出
覆盖命令时必须同步补全上下文
用 docker run -it my-image bash 进入调试很常见，但这会跳过原 CMD/ENTRYPOINT，也意味着丢失原始启动环境。此时需手动还原关键条件：
- 用 -w 指定正确工作目录，例如 docker run -w /app my-image bash
- 用 -e 补齐必需环境变量，如 docker run -e DATABASE_URL=... my-image bash
- 若原镜像依赖健康检查或初始化逻辑，临时覆盖命令前先确认数据库、缓存等已就绪
在 docker-compose.yml 中安全覆盖 command
直接写 command: npm start 很容易丢掉 ENTRYPOINT 或前置检查。更稳妥的做法是保留入口逻辑，仅替换最终动作：
- 若原 ENTRYPOINT 是启动脚本，可写 command: ["start-dev"]，让脚本内部分支处理
- 需要等待依赖时，用 shell 封装：command: sh -c "wait-for db:5432 -- npm start"（需提前安装 wait-for 工具）
- 避免在 command 中写多行复杂逻辑；应提取为独立脚本 COPY 进镜像，再通过 command 调用
验证覆盖后的命令是否可独立运行
别只看容器是否“起来”，要确认进程是否真正承担预期职责：
- 进容器后执行 ps aux | grep -v grep，确认 PID 1 是你的服务进程，不是 sh 或 sleep
- 用 kill -s SIGTERM 1 测试能否优雅退出；若直接 kill -9 才停，说明信号未被正确转发
- 检查日志输出是否包含服务监听地址（如 Listening on :3000），而非卡在某一步初始化
