直接读取 /proc/[pid]/environ 是查看进程初始环境变量最权威的方式，该文件以 \0 分隔、需用 tr '\0' '\n' 或 strings 解析，仅进程所有者或 root 可读，且进程退出后即失效。
直接读取 /proc/[pid]/environ 文件
Linux 内核为每个运行中的进程在 /proc/[pid]/environ 下维护一份原始环境变量快照，这是最真实、最权威的来源——它不经过 shell 解析，也不受当前终端环境干扰。
注意：[pid] 需替换为实际进程 ID，比如 1234；该文件内容是 null-separated（以 \0 分隔）的键值对，直接 cat 会显示为空白或乱码。
- 用
tr '\0' '\n' < /proc/1234/environ换行显示（推荐，简洁可靠） - 或用
strings /proc/1234/environ（strings自动跳过非可打印字符，适合快速浏览） - 如果进程已退出，
/proc/[pid]目录消失，此法失效 - 普通用户只能读取自己启动的进程；读系统进程（如
pid=1）需 root 权限
ps 命令无法显示完整环境变量
ps -E -p 1234 看起来像能查环境变量，但实际只显示部分预设字段（如 USER、PWD），不是真正意义上的环境变量 dump。它不展示 PATH、HOME 以外的自定义变量，更不会包含程序启动时传入的临时变量。
常见误操作：以为 ps e 或 ps -f 能列出全部环境变量——不能。这些选项只影响输出格式或显示父进程信息，和环境变量无关。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
ps的-E选项仅用于显示环境变量列（如果有的话），但默认不启用，且多数发行版 ps 不支持完整 environ 输出 - 依赖
ps查LD_LIBRARY_PATH或自定义配置变量，大概率漏掉
为什么 env 和 printenv 不适用于“具体进程”
这两个命令输出的是**当前 shell 进程**的环境变量，不是目标进程的。即使你用 ps 找到某个进程，再在同一个终端运行 env，得到的仍是你的交互式 shell 的环境，而非那个进程启动时继承或修改过的那一份。
关键区别在于：环境变量在 fork 时被复制，之后父子进程各自独立修改；/proc/[pid]/environ 记录的是 fork 后、exec 前那一刻的副本，而 shell 的 env 是你现在这个 shell 实例的当前状态。
- 若目标进程启动后调用了
putenv()或setenv()，/proc/[pid]/environ仍反映初始值（Linux 内核不实时更新该文件） - 若想确认进程是否在运行中修改了环境，需结合源码或调试器（如
gdb -p [pid]+call getenv("KEY")）
调试时容易忽略的权限与生命周期问题
查看进程环境变量不是“执行一个命令就完事”的操作，它天然受限于进程生命周期和权限模型。
- 进程刚启动就结束（如脚本型命令），
/proc/[pid]可能瞬间消失，需用pgrep -f "xxx" | xargs -I{} sh -c 'tr \"\0\" \"\n\" < /proc/{}/environ 2>/dev/null'批量捕获 -
sudo cat /proc/1234/environ可能失败：某些内核版本（如启用了kernel.yama.ptrace_scope）禁止非子进程读取其他进程的 environ - 容器内进程的 PID 在宿主机命名空间里是另一个数字，
docker inspect [container]查State.Pid才是真实[pid]
真正要还原某个服务的实际启动环境，光看 /proc/[pid]/environ 有时不够——还得查它的 systemd service 文件、启动脚本或容器 entrypoint，因为很多变量是在 exec 之前由 wrapper 注入的。
