在 Docker 容器内配置“系统级”环境变量最可靠方式是使用 Dockerfile 中的 ENV 指令预设，变量写入镜像元数据并在启动时注入 PID 1 环境供所有子进程继承；次选方案为通过 entrypoint 脚本动态 export，适用于运行时计算场景；挂载 /etc/profile.d/*.sh 仅影响交互式 shell，不作用于服务进程；直接修改 /etc/environment 不被 Docker 官方推荐且多数镜像不支持。
在 Docker 容器内配置“系统级”环境变量，本质是让所有进程（包括 shell、子命令、应用服务）都能自动继承该变量。Docker 本身不提供传统 Linux 中 /etc/environment 或 /etc/profile 那类全局持久化机制，但可通过以下方式实现等效效果。
用 ENV 指令在镜像构建时预设
这是最常用、最可靠的方式，适用于非敏感的默认配置（如 PATH、TZ、LANG）：
- 在 Dockerfile 中使用 ENV 设置，变量会写入镜像元数据，并在容器启动时注入到 PID 1 进程环境，所有子进程自动继承
- 示例：
FROM ubuntu:22.04<br>ENV TZ=Asia/Shanghai<br>ENV LANG=C.UTF-8<br>ENV PATH="/app/bin:$PATH"
- 注意：ENV 值会固化在镜像层中，不可被运行时覆盖（除非用 -e 显式指定同名变量）
通过 entrypoint 脚本动态注入
适合需要运行时计算或条件判断的场景（如根据主机名设置 NODE_ENV）：
- 编写一个 entrypoint.sh，在 exec 主程序前用 export 设置变量
- 确保脚本有执行权限，并在 Dockerfile 中声明：
COPY entrypoint.sh /entrypoint.sh<br>RUN chmod +x /entrypoint.sh<br>ENTRYPOINT ["/entrypoint.sh"]
- entrypoint.sh 示例：
#!/bin/sh<br>export HOSTNAME=$(hostname)<br>export APP_ENV=${APP_ENV:-production}<br>exec "$@"
挂载自定义 profile 文件（仅限交互式 shell）
对需登录容器调试的用户有用，但不影响后台服务进程：
- 准备一个 /etc/profile.d/myenv.sh 文件，内容为
export VAR=value - 启动容器时用 -v 挂载：
docker run -v $(pwd)/myenv.sh:/etc/profile.d/myenv.sh myimage - 该方式只影响新启动的 bash/zsh 会话，不改变容器初始环境，也不影响 CMD 启动的服务进程
避免直接修改 /etc/environment
虽然某些基础镜像支持该文件，但 Docker 官方不推荐：
- 它依赖 init 系统（如 systemd）读取，而多数精简镜像无此机制
- Docker 启动容器时并不解析该文件，变量不会自动加载到 PID 1 环境中
- 强行写入可能导致镜像臃肿、行为不可预测，且与 Docker 的环境注入模型冲突
