entrypoint 是 docker 中实现容器启动前环境预检最可靠的方式，通过 shell 脚本执行检查后用 exec "$@" 交还控制权；必须用 exec 数组格式声明，配合健康检查与可重试逻辑确保服务就绪。
在 docker 中，entrypoint 本身不是“钩子函数”，但它是最常用、最可靠的方式实现容器启动前的环境预检——核心思路是用一个 shell 脚本作为入口，先完成检查逻辑（如等待数据库就绪、校验配置、生成 runtime 文件等），再用 exec "$@" 交还控制权给原始命令。
为什么必须用 ENTRYPOINT 而非 CMD？
CMD 容易被 docker run 后面的命令覆盖，无法保证预检一定执行；而 ENTRYPOINT 指令不会被覆盖，它把后续参数当作自身脚本的输入，天然适合做前置封装。关键前提是：必须使用 exec 形式（数组写法），否则会多一层 shell 进程，导致容器主进程不是业务程序，退出后容器立即终止。
标准 entrypoint.sh 编写要点
- 脚本开头加
#!/bin/sh -e，让任意命令失败时脚本直接退出（避免静默跳过错误） - 预检逻辑要可重试、有超时，比如用
nc -z db 5432或curl -f http://api/health配合 while 循环 - 检查通过后，务必用
exec "$@"启动原 CMD，而不是"$@"或sh -c "$@"——只有exec才能替换当前进程，使业务命令成为 PID 1 - 脚本需设为可执行：
RUN chmod +x /entrypoint.sh
Dockerfile 中的正确声明方式
必须统一使用 exec 模式，避免混用 shell 和 exec 语法：
FROM node:18 COPY entrypoint.sh /entrypoint.sh COPY app.js /app.js ENTRYPOINT ["/entrypoint.sh"] CMD ["node", "app.js"]
这样，运行 docker run myapp --port 3001 时，实际执行的是 /entrypoint.sh --port 3001，脚本内部再以 exec node app.js --port 3001 启动应用。
配合 Docker Compose 做服务依赖协调
单独靠 depends_on 不够（它只等容器启动，不等服务就绪）。推荐组合使用：
- 在 db 服务中启用
healthcheck，定义真正的就绪判断 - 在 app 的 entrypoint.sh 中主动等待该健康端点返回
healthy，或调用wait-for-it.sh等轻量工具 - Compose 文件里仍保留
depends_on: { db: { condition: service_healthy } }，形成双重保障
