ENTRYPOINT 本身不解析环境变量，需通过 shell 形式或自定义 entrypoint.sh 主动读取、校验并应用；配合 ARG/ENV 分层配置、运行时覆盖及健康检查协同，实现配置平滑覆盖与服务鲁棒启动。
ENTRYPOINT 本身不解析环境变量，但配合 shell 形式或 exec 形式脚本，能实现配置的平滑覆盖——关键在于让启动逻辑主动读取、校验并应用环境变量，而不是依赖静态写死值。
用 shell 形式 ENTRYPOINT 承载变量解析逻辑
镜像中定义 ENTRYPOINT ["sh", "-c", "exec \"$1\" \"$@\""] 这类通用入口，实际执行前由 shell 展开环境变量。更常见的是自定义 entrypoint.sh：
- 脚本开头用
#!/bin/sh，确保可执行权限 - 用
set -u检查未设置变量，避免静默失败 - 用
${VAR:-default}提供默认值，如PORT=${PORT:-8080} - 用
export VAR=value动态重设变量，影响后续命令 - 最后必须以
exec "$@"启动主进程，保证 PID 1 正确且信号可传递
ENV + ARG 分层预留配置入口
构建阶段就为运行时留出扩展空间：
- Dockerfile 中用
ARG DEFAULT_DB_HOST+ENV DB_HOST=${DEFAULT_DB_HOST:-localhost}，构建时可传参定制，不传则 fallback - 避免直接写
ENV DB_HOST=prod-db，否则运行时-e DB_HOST=dev-db虽能覆盖，但语义上已失去“默认值”含义 - 对敏感或动态值（如 token、密钥），只声明 ENV 占位符，运行时通过
-e或--env-file注入，不进镜像层
运行时覆盖需匹配 ENTRYPOINT 的接收方式
ENTRYPOINT 是 exec 形式（["python", "app.py"]）时，CMD 或 docker run myapp arg1 arg2 会作为参数追加；但环境变量仍需在脚本或应用内读取：
- 若主程序是 Python，靠
os.getenv("DEBUG")获取，而非硬编码DEBUG = True - 若 ENTRYPOINT 是 shell 脚本，可在脚本里用
if [ "$DEBUG" = "1" ]; then echo "debug mode"; fi - 用
docker run --entrypoint /bin/sh -it -e DEBUG=1 myapp -c 'echo $DEBUG'快速验证变量是否注入成功
与健康检查、依赖等待协同增强鲁棒性
平滑覆盖不只是改变量，更要让服务按新配置稳住：
- entrypoint.sh 中根据
$DATABASE_URL自动选择连接池大小、超时等参数 - healthcheck 使用
curl -f http://localhost:$PORT/health，而$PORT来自环境变量，不是写死 8080 - compose 文件中
depends_on: { db: { condition: service_healthy } }和 entrypoint 内部探测解耦：前者保底，后者精细控制启动时机
