ENTRYPOINT 是 Docker 中最灵活的启动逻辑处理方式，适合封装参数校验、环境预检、配置生成等复杂初始化；需用 exec 格式声明，脚本末尾 exec "$@" 透传参数，配合 CMD 实现默认命令与可覆盖能力。
ENTRYPOINT 是 Docker 中处理启动逻辑最灵活的方式，尤其适合封装需要参数校验、环境预检、配置生成或多步骤初始化的复杂入口脚本。它比单纯用 CMD 更可控，能天然保留命令行参数传递语义，避免 shell 解析歧义。
用 ENTRYPOINT 封装初始化逻辑
把启动前检查、日志准备、配置渲染、依赖服务等待等操作统一写进一个可执行脚本（如 entrypoint.sh），再通过 ENTRYPOINT 调用。这样容器启动时自动执行完整准备流程，无需用户手动干预或额外包装。
- 脚本需具备可执行权限（chmod +x entrypoint.sh）并放在镜像内可访问路径
- Dockerfile 中声明：ENTRYPOINT ["/bin/sh", "/app/entrypoint.sh"]（推荐 exec 形式）
- 脚本末尾通常以 exec "$@" 结尾，将 CMD 或 docker run 后的参数原样传给主进程
支持可覆盖的默认行为
ENTRYPOINT 配合 CMD 可实现“默认命令 + 可覆盖”模式。例如：
- Dockerfile 写：ENTRYPOINT ["/app/entrypoint.sh"] 和 CMD ["app-server", "--port=8080"]
- 运行 docker run myimg → 执行 entrypoint.sh app-server --port=8080
- 运行 docker run myimg nginx -g "daemon off;" → 执行 entrypoint.sh nginx -g "daemon off;"
这种组合让镜像既开箱即用，又保有调试和替换主命令的能力。
避免 shell 形式 ENTRYPOINT 的陷阱
写成 ENTRYPOINT /app/entrypoint.sh（无方括号）会触发 shell 模式，导致 $@ 不生效、信号无法透传、PID 1 不是主进程等问题。
- 务必使用 exec 格式（JSON 数组），确保脚本成为 PID 1 并正确接收 SIGTERM
- 如果脚本本身需解析参数，可用 set -- new-command "$@" 动态重置参数再 exec
- 调试时可临时改 CMD 为 ["ps", "aux"] 或 ["sh"] 进入容器验证 entrypoint 行为
常见实用技巧
在 entrypoint.sh 中加入轻量但关键的健壮性处理：
- 检测必要环境变量是否设置，缺失则 echo "ERROR: ENV VAR XXX required" >&2; exit 1
- 用 wait-for-it.sh 或简单 while 循环等待数据库、Redis 等依赖就绪
- 用 envsubst /app/config.yaml 渲染模板配置
- 创建运行时目录、修正文件权限（尤其挂载卷场景）、加载 secret 文件等
