docker环境变量与entrypoint需分层控制：arg用于构建期、env写入镜像、-e运行时覆盖；entrypoint推荐exec形式（["cmd"]）以支持--entrypoint完全替换和参数追加。
在 Docker 中配置环境变量传递和 Entrypoint 覆盖，核心在于理解 Dockerfile 中的 ENV、ARG、ENTRYPOINT 与容器运行时的 -e、--entrypoint 等机制如何协同工作。关键不是“写死”，而是分层控制：构建时可选、启动时可覆盖、运行时可注入。
环境变量的三层传递机制
Docker 支持三种主要方式注入环境变量，作用时机和优先级不同：
-
构建期变量（ARG）：仅在
docker build过程中有效，用于条件化构建（如选择 Python 版本）。需用ARG key=value声明，并在RUN中通过$key引用；默认不进入镜像，除非显式用ENV赋值保留。 -
镜像固有变量（ENV）：写入镜像层，容器启动时自动生效。例如
ENV NODE_ENV=production，无法被运行时-e覆盖（除非同名重设）。 -
运行时变量（-e / --env-file）：最高优先级。使用
docker run -e KEY=VALUE或-e KEY（从宿主机继承）注入，会覆盖镜像中同名ENV；也可用--env-file=.env批量加载。
Entrypoint 的两种形式与覆盖逻辑
ENTRYPOINT 定义容器启动时执行的“主命令”，分为 shell 形式和 exec 形式，行为差异显著：
-
Shell 形式（不推荐）：
ENTRYPOINT command param1→ 实际执行为/bin/sh -c "command param1"，导致CMD和运行时参数被忽略，且无法用--entrypoint替换整个命令（只替换/bin/sh -c后的部分）。 -
Exec 形式（推荐）：
ENTRYPOINT ["command", "param1"]→ 直接执行，支持参数追加。此时CMD作为默认参数传给 entrypoint；运行时docker run --entrypoint newcmd image arg1可完全替换入口点并传参。
注意：若 ENTRYPOINT 是 exec 形式，且你希望保留原有逻辑但只改参数，可省略 --entrypoint，直接在 run 命令末尾追加参数，它们会自动附加到 ENTRYPOINT 后。
组合实践：安全传递敏感配置 + 动态入口控制
典型场景：应用需要数据库地址和密钥，但密钥不应硬编码进镜像；同时允许调试时临时切换为 bash。
- 在
Dockerfile中声明非敏感默认值：ENV DB_HOST=localhost DB_PORT=5432，不设DB_PASSWORD。 - 使用
ARG控制构建行为（如是否启用 debug 日志），但不用于密钥：ARG LOG_LEVEL=info，再用ENV LOG_LEVEL=$LOG_LEVEL保存。 - 设置 exec 模式 entrypoint：
ENTRYPOINT ["./entrypoint.sh"]，并在脚本中检查$DB_PASSWORD是否为空，为空则报错退出，强制运行时注入。 - 启动时注入密钥并覆盖入口：
docker run -e DB_PASSWORD=xxx -e DB_HOST=prod-db --entrypoint ./debug-shell.sh myapp。
调试与验证技巧
快速确认实际生效的环境变量和入口点：
- 查看镜像元数据：
docker inspect myimage | jq '.[0].Config.Env, .[0].Config.Entrypoint, .[0].Config.Cmd' - 启动交互式容器验证变量：
docker run --rm -it -e TEST=hello myimage env | grep TEST - 绕过 entrypoint 查看原始文件：
docker run --rm -it --entrypoint sh myimage -c 'ls -l /app/entrypoint.sh'
不复杂但容易忽略：shell 形式 entrypoint 会让 --entrypoint 失效预期效果，务必用 JSON 数组格式定义；环境变量覆盖遵循“运行时 > 构建时 > 镜像默认”，但 ARG 不参与运行时传递。
