docker镜像构建中配置环境变量需区分构建时与运行时：用env设运行时变量，arg+env组合实现构建期传入并保留至运行时，多阶段构建须显式传递，避免run export或依赖宿主机变量。
在 Docker 镜像构建阶段配置环境变量，核心目标是让最终容器启动后，应用进程（如 Node.js 的 process.env、Python 的 os.environ）能直接读取到这些变量。关键在于区分“构建时用”和“运行时用”，并确保变量真正进入容器环境。
用 ENV 指令设置运行时环境变量
这是最常用、最直接的方式。ENV 定义的变量会写入镜像元数据，在容器启动时自动注入到 PID 1 进程环境中，所有子进程都能继承。
- 语法简单：例如
ENV NODE_ENV=production或ENV APP_PORT=8080 - 变量值固化在镜像中，适合默认配置（如日志级别、监听端口、基础路径）
- 注意：不要放敏感信息（密码、密钥），因为
docker inspect或docker history可轻易查看 - 若后续运行容器时用
-e指定同名变量，会自动覆盖 ENV 的值
用 ARG + ENV 组合实现构建期灵活注入
当某些变量需要在构建时动态传入（比如公司内部代理地址、版本号、Git 分支），又希望它们也出现在运行时环境中，就用 ARG 声明参数，再用 ENV 赋值。
- Dockerfile 示例：
ARG HTTP_PROXY<br>ENV http_proxy=$HTTP_PROXY
- 构建命令：
docker build --build-arg HTTP_PROXY=http://proxy:8080 -t myapp . - 这样既避免硬编码，又保证容器运行时也能访问代理（对 apt、npm、curl 等生效）
- 注意：ARG 本身只在构建阶段存在，不进镜像；只有被 ENV 接收后，才成为运行时变量
多阶段构建中注意环境变量的传递
在 builder 阶段设置的 ENV，默认不会自动带到 final 阶段。如果 final 阶段需要（比如运行时要连数据库），必须显式再次声明或复制。
- 错误写法：builder 阶段设了
ENV DB_HOST=xxx，final 阶段没重设 → 应用读不到 - 正确做法：
– 在 final 阶段重新ENV DB_HOST=xxx（适合固定值）
– 或通过构建参数传入：ARG DB_HOST+ENV DB_HOST=$DB_HOST - 也可在 COPY 后的 entrypoint 脚本里动态生成环境文件，但不如直接 ENV 清晰可靠
避免常见陷阱
有些写法看似合理，实际无效或有隐患：
-
不要在 RUN 中用 export：比如
RUN export FOO=bar && echo $FOO—— 变量只在当前 shell 生命周期有效，不会保留到镜像或后续层 -
不要依赖宿主机环境变量：Docker 构建过程默认不继承宿主机的
$HOME、$PATH等（除非显式用 ARG 传入） -
慎用 shell 形式 CMD/ENTRYPOINT：如
CMD node server.js会启动 /bin/sh -c，可能影响变量解析；推荐 exec 格式CMD ["node", "server.js"]，更干净可控
