Linux中查进程配置文件路径需综合cmdline、environ和lsof：cat /proc/PID/cmdline | tr '\0' '\n'找显式配置参数；strings /proc/PID/environ | grep -i 'config|path'挖环境变量；lsof -p PID筛配置后缀文件，辅以pwdx和readlink -f /proc/PID/exe定位上下文目录。
直接看 /proc/PID/cmdline 和 /proc/PID/environ，再辅以 lsof -p PID，基本能覆盖 90% 的真实配置加载路径。硬查“启动时读取的配置文件”没有通用接口，Linux 内核不记录这个元数据，只能靠推断和残留痕迹。
怎么看进程启动命令里带的配置路径
很多程序（比如 Java、Nginx、Redis）通过命令行参数显式指定配置文件，这是最可靠的第一手线索。
-
cat /proc/PID/cmdline | tr '\0' '\n'—— 原始参数，含空字符分隔，必须用tr转换才可读 - 重点关注类似
--config=/etc/myapp.conf、-c /opt/app/config.yaml、-Dspring.config.location=classpath:/custom/这类带等号或空格后跟路径的参数 - 如果看到
java开头，但没明显配置路径，说明可能走默认位置（如application.properties在 classpath）或环境变量驱动，需继续查environ
怎么从环境变量里挖配置路径线索
尤其对 Java、Python 或容器化应用，配置常藏在 JAVA_OPTS、SPRING_CONFIG_LOCATION、CONFIG_PATH 等变量里。
-
strings /proc/PID/environ | grep -i 'config\|opt\|home\|path'——/proc/PID/environ是二进制格式，必须用strings解码 - 注意大小写：常见变量有
JAVA_HOME（影响 classpath）、LD_LIBRARY_PATH（影响 so 加载）、HOME（影响用户级配置查找） - 若输出为空，不代表没环境变量——可能是进程启动后清除了，或由父 shell 注入但未传给子进程（检查是否用了
env -i启动）
为什么 lsof -p PID 有时找不到配置文件
因为配置文件往往只在启动阶段被打开、读取、然后 close()，不会长期持有 fd。所以 lsof 看不到，不代表没读过。
-
lsof -p PID | grep -E '\.(conf|properties|yml|yaml|xml|ini)$'—— 只筛常见后缀，避免噪音 - 若结果为空，别急着放弃：检查
ls -l /proc/PID/fd/是否有指向配置文件的符号链接（哪怕已标(deleted)） - 某些程序（如 systemd 服务）会 fork 多次，PID 可能已变，
lsof查的是当前 PID，不是启动时的原始 PID
pwdx 和 /proc/PID/exe 能帮你缩小搜索范围
这两个命令不直接告诉你配置在哪，但能快速锁定“上下文根目录”，大幅减少手动 guess 的工作量。
-
pwdx PID—— 输出PID: /opt/myapp，那/opt/myapp/conf/、/opt/myapp/etc/就是高概率候选 -
readlink -f /proc/PID/exe—— 如果返回/usr/bin/python3，说明是脚本启动，得配合cat /proc/PID/cmdline看它实际执行的是哪个 .py 文件，再查那个脚本里的硬编码路径或默认逻辑 - 注意：
pwdx显示的是进程当前工作目录，不是启动目录；如果进程启动后执行了chdir()（比如 daemon 化），这个路径就失真了
真正难搞的是那些把配置嵌进 jar、打包进二进制、或运行时从远端拉取的程序——它们根本不落地文件。这种情况下，cmdline 和 environ 是唯一现实入口，其他手段基本失效。
