dockerfile中应使用entrypoint封装初始化检查（如环境校验、依赖等待、配置生成），并以exec "$@"结尾透传cmd参数；cmd仅负责运行主程序，保持无副作用、支持参数覆盖，二者协同实现可复用、可调试、符合docker原生命令语义的启动逻辑。
用 Dockerfile 简化容器启动脚本的复杂逻辑，核心是把“该不该做”和“怎么做”拆开：初始化检查、环境校验、配置生成这些事交给 ENTRYPOINT 脚本，而真正要跑的应用命令留给 CMD。这样既保持可复用性，又支持参数覆盖，还不破坏 Docker 的原生命令语义。
用 ENTRYPOINT 封装启动前检查
把参数校验、依赖服务等待（如数据库连通性）、配置文件渲染、日志目录准备等逻辑统一写进一个 shell 脚本（比如 entrypoint.sh），再通过 ENTRYPOINT ["./entrypoint.sh"] 声明。这个脚本必须用 exec "$@" 结尾，才能把 CMD 传来的参数正确透传给最终程序。
- 脚本开头加
#!/bin/sh，优先用 sh 而非 bash，减小镜像体积 - 所有检查失败应直接
exit 1，避免容器假启动 - 不要在脚本里启动后台服务（如 & 启动 redis-server），它会脱离 PID 1，导致信号无法接收
让 CMD 只负责运行主程序
CMD 应该是纯粹的、无副作用的执行命令，例如 ["java", "-jar", "/app.jar"] 或 ["node", "server.js"]。它不参与初始化，只响应 ENTRYPOINT 的最终调用。
- 避免写成
CMD ["sh", "-c", "java -jar ..."]，shell 解析会绕过 exec 模式，丢失信号转发能力 - 如果想提供默认参数，写成
CMD ["--port=8080"]，它会被 ENTRYPOINT 的exec "$@"接收并追加到主命令后 - 用户运行容器时加参数（如
docker run myimg --port=9000），会自动替换或补充 CMD 的内容
精简镜像 + 加快脚本执行
启动慢常源于镜像臃肿或脚本冗余。优化方向很明确：
- 基础镜像选
alpine或distroless，去掉包管理器和 shell 多余组件 - 启动脚本里少用
curl、jq、sed -i这类重量级命令；能静态配置就别动态生成 - 把耗时操作（如下载远程配置、预热缓存）移到构建阶段，或改用健康检查异步完成
- 用
.dockerignore排除node_modules/、.git/、tests/等无关文件，减少上下文传输开销
验证脚本是否生效
别靠猜，用几条命令快速确认行为是否符合预期：
-
docker build -t testimg . && docker run --rm testimg echo hello—— 看是否输出 “hello”，验证 ENTRYPOINT + CMD 组合是否透传成功 -
docker run --rm -it testimg sh—— 进入容器，手动执行./entrypoint.sh true，检查脚本本身是否语法正确、权限可执行 - 在脚本里加
set -x（调试模式）和echo "[INFO] ..." >&2，把关键路径输出到 stderr，便于排查卡点
