ENTRYPOINT定义主程序（如/app/server），CMD提供默认参数（如--port 8080）；二者共存时，运行时参数覆盖CMD并追加至ENTRYPOINT；推荐均用exec格式确保PID 1和信号正常传递。
要让镜像既稳定又灵活，关键在于用好 ENTRYPOINT 和 CMD 的分工：ENTRYPOINT 定义不变的执行主体（比如主程序或启动脚本），CMD 提供可变的默认参数。这样既能保证容器行为一致，又支持运行时按需调整。
明确职责：ENTRYPOINT 做“骨架”，CMD 做“血肉”
ENTRYPOINT 应该指向一个确定的可执行文件或启动脚本，它构成容器的核心行为逻辑；CMD 则只负责传参，不参与主流程控制。两者配合，才能实现“镜像即命令”的语义。
- 推荐统一使用 exec 格式（JSON 数组），避免 shell 启动带来的 PID 不为 1、信号转发异常等问题
- 不要在 ENTRYPOINT 中硬编码业务参数——那些应交给 CMD 或运行时 args
- 若 ENTRYPOINT 是 shell 脚本，结尾务必用 exec "$@"，确保 CMD 或 docker run 参数真正成为主进程参数，而非子进程
支持多场景启动：覆盖与追加并存
高可扩展性体现在运行时能适配不同环境，而无需重建镜像。这依赖于对 ENTRYPOINT/CMD 组合的合理设计。
- 直接覆盖 CMD：运行 docker run myimg --port=3000 --debug，会把整个 CMD 替换为这些参数，最终执行 ENTRYPOINT --port=3000 --debug
- 保留 ENTRYPOINT 并追加参数：Kubernetes 中通过 args 字段传递，等效于 docker run 的参数追加，不会影响镜像内置的 CMD
- 彻底替换入口：仅当需要调试或临时绕过启动逻辑时，用 --entrypoint /bin/sh，此时 CMD 完全失效
面向生产：用启动脚本封装初始化逻辑
真实服务常需前置动作（如生成配置、等待依赖就绪、权限检查）。把这些放进 ENTRYPOINT 脚本，再用 exec "$@" 交出控制权给 CMD，就能兼顾健壮性与兼容性。
- 脚本开头做必要校验（例如检查 $PORT 是否合法），失败则 exit 1，让容器快速失败而非挂起
- 配置生成后，用 exec "$@" 启动实际服务，确保该命令获得 PID 1，能正常接收 SIGTERM
- CMD 保持简洁，例如 ["--port=8080", "--env=prod"]，便于 kubectl run 或 Helm values.yaml 直接覆盖
避免常见陷阱：顺序、覆盖与格式
多个 CMD 或 ENTRYPOINT 出现在 Dockerfile 中时，只有最后一个生效；二者不互相覆盖，但组合逻辑必须清晰。
- 不要混用 shell 和 exec 格式：比如 ENTRYPOINT nginx -g "daemon off"（shell） + CMD ["-v"] 会导致 CMD 被忽略——因为 shell 模式下 CMD 不会被解析为参数
- 多阶段构建中，每个 stage 的 ENTRYPOINT/CMD 需显式声明，不会继承上一阶段
- 测试时用 docker inspect myimg | grep -i entry 确认最终生效值，比凭记忆更可靠
