关键不是“找全”，而是“找准路径、分清层级、验证生效”：systemd服务变量在.service文件[Service]段用Environment=或EnvironmentFile=设置；Shell脚本直接export或source；Docker看-e、ENV或env_file；Nginx+PHP-FPM通过fastcgi_param传递；验证需查systemctl cat、/etc/default/、docker inspect或/proc/PID/environ，注意覆盖顺序。
新手排查服务配置文件里的环境变量，关键不是“找全”，而是“找准路径、分清层级、验证生效”。很多服务（比如 systemd 服务、Nginx 的 fastcgi_param、Docker 容器启动脚本）会从特定位置读取环境变量，但这些变量不会出现在 env 或 printenv 的输出里——因为它们还没被加载进当前 Shell 环境，只对目标服务进程有效。
先确认服务用的是哪种启动机制
不同机制加载环境变量的方式完全不同：
-
systemd 服务：变量通常写在
.service文件的[Service]段里，用Environment=或EnvironmentFile=指定；
例如：Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk"或EnvironmentFile=/etc/default/myapp -
Shell 启动脚本（如
/etc/init.d/下的老式脚本）：直接在脚本开头用export VAR=value设置，或source /path/to/env.sh -
Docker 容器：看
docker run -e参数、Dockerfile中的ENV指令，或docker-compose.yml的environment:或env_file:字段 -
Web 服务器代理层（如 Nginx + PHP-FPM）：PHP 的环境变量可能来自
fastcgi_param指令，不经过系统 env，需查php-fpm.conf或站点配置中的env[VAR_NAME] = value
定位配置文件的常用路径
别盲目搜索，按优先级检查这些位置：
- systemd 服务：运行
systemctl cat 服务名（如systemctl cat nginx），直接显示完整 unit 文件内容，含所有Environment*行 - 全局服务默认值：
/etc/default/服务名（Debian/Ubuntu 常见，如/etc/default/mysql） - systemd 全局环境：
/etc/systemd/system.conf或/etc/systemd/user.conf中的DefaultEnvironment= - Docker：
docker inspect 容器ID | grep -A 10 Env查运行时环境；cat docker-compose.yml | grep -A 5 environment - 用户级服务脚本：
~/.bashrc、~/.profile或服务专属的~/.myapp/env.sh（如果服务文档明确说明）
验证变量是否真被服务读到
光看到配置写了不等于服务用了。最可靠的方法是让服务自己“说出来”：
- 对支持调试的服务（如 Node.js、Python Flask），加一行日志打印
os.environ.get('VAR_NAME')或process.env.VAR_NAME - systemd 服务可临时加调试命令：
sudo systemctl edit 服务名→ 添加：[Service]ExecStartPre=/bin/sh -c 'echo JAVA_HOME=$JAVA_HOME >> /tmp/service-env.log' - 进入服务容器内部查：
docker exec -it 容器名 sh -c 'env | grep VAR_NAME' - 查看服务进程实际继承的环境：
cat /proc/$(pgrep -f "服务关键词")/environ | tr '\0' '\n' | grep VAR_NAME（需 root 权限）
注意变量作用域和覆盖顺序
同一个变量可能在多个地方定义，最终生效的是“离服务最近、加载最晚”的那个：
- systemd 的
Environment=会覆盖EnvironmentFile=里的同名变量 -
/etc/environment是系统级早期加载，但仅影响 PAM 登录会话，不影响大多数 systemd 服务 - 服务脚本里
export的变量，只对该脚本及其子进程有效，不会反向污染你的终端 - 如果服务是通过
sudo -u user cmd启动的，它读的是该用户的 shell 配置，不是 root 的
