最可靠方法是读取/proc/PID/environ并用tr '\0' '\n'解析，因其保存进程启动时的原始环境快照；直接cat会因空字符分隔显示乱码，且仅进程所有者或root可读，后续setenv修改不更新该文件。
直接读取 /proc/PID/environ 是最可靠的方法
进程启动后，它的原始环境变量就固化在 /proc/PID/environ 里，以 \0 字节分隔——这不是普通文本文件，直接 cat 会显示为乱码或一行挤在一起。必须用 tr 转换分隔符才能看清。
- 先查 PID：
ps aux | grep nginx或pgrep -f "python app.py" - 再读取并解析：
cat /proc/12345/environ | tr '\0' '\n'（把12345换成真实 PID） - 想过滤某变量？加
grep：cat /proc/12345/environ | tr '\0' '\n' | grep ^PATH= - 注意：该文件权限取决于进程权限，普通用户可能无权读取 root 进程的
/proc/PID/environ
penv 命令能省掉手动 tr 步骤
如果你经常要查，penv 就是专为此设计的工具，它自动处理 <p>如果你经常要查，<code>penv 就是专为此设计的工具，它自动处理 \0 分隔、支持高亮和排序，比手写管道链更稳。
- 检查是否已装：
which penv - 没装的话：
apt install psmisc（Debian/Ubuntu）或yum install psmisc（RHEL/CentOS） - 直接运行：
penv 12345，输出就是干净的键值对，无需额外处理 - 它不依赖 shell 环境，也不受当前终端变量干扰，看到的就是进程实际加载的那套
别用 ps auxwwwe 当真——它不可靠
ps auxwwwe 确实会在输出末尾附上环境变量，但只对部分进程生效，且只显示前几 KB，截断严重。很多服务（尤其是 systemd 启动的）根本不会把 env 写进 ps 的 args 区域。
- 现象：
ps auxwwwe | grep myapp可能完全不显示环境变量，或只显示PATH=...开头的一小段 - 原因：内核不保证把完整 environ 放进 ps 可读的字段；
e选项依赖进程是否主动暴露，不是强制行为 - 结论：这招适合快速扫一眼“有没有明显异常”，但不能用于确认某个变量是否存在或取值是否正确
systemd 服务要另查配置，不是看 /proc/PID/environ
systemd 管理的服务，其环境变量往往来自 .service 文件里的 Environment= 或 EnvironmentFile=，而不是父进程继承来的。直接读 /proc/PID/environ 虽然能看到最终结果，但无法追溯来源。
- 查定义位置：
systemctl show --property=Environment myapp.service - 或看完整单元文件：
systemctl cat myapp.service | grep -E '^(Environment|EnvironmentFile)=' - 注意：
/proc/PID/environ显示的是运行时快照，而 systemd 可能在启动时动态注入变量（比如通过%i、%H等替换），这些在源配置里才体现得清
/proc/PID/environ 只反映进程启动那一刻继承的环境，后续进程中自己 setenv() 或 putenv() 修改的变量不会写回这里。如果程序运行中改了 PATH，你在这里看不到。 
