Linux中通过ls -l /proc/{PID}/exe和ls -l /proc/{PID}/cwd可直接获取进程可执行文件路径及启动工作目录，二者共同定位程序主文件夹位置。
直接看 /proc/{pid}/cwd，它就是服务进程启动时所在的工作目录，通常就是程序主文件夹位置。
Windows 下通过服务 PID 找程序文件夹
Windows 服务本身不等于独立进程，很多由 svchost.exe 或其他宿主承载，所以不能只看 PID 对应的进程路径。需分两步：
- 先确认该 PID 对应的服务名：打开任务管理器 → “服务”选项卡 → 找到服务 → 右键“转到详细信息”，记住高亮进程的 PID；或在命令行运行
tasklist /svc | findstr "1234"（1234 是 PID） - 再查服务配置中的实际路径：用
sc qc "服务名"，找到 BINARY_PATH_NAME 行，引号内是可执行文件路径；若路径是svchost.exe -k netsvcs，则需结合注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{服务名}\Parameters\ServiceDll查真正的 DLL 路径，其所在目录即核心程序位置 - 若服务是独立 .exe（如 nginx.exe、redis-server.exe），BINARY_PATH_NAME 的目录就是程序文件夹；注意去掉参数部分（如
-Service），只取引号内的路径
Linux 下通过服务 PID 找程序文件夹
Linux 中进程与服务关系更直接，PID 对应的 cwd 和 exe 链接能快速定位：
- 运行
pwdx PID—— 一行命令直接输出工作目录，多数服务（如 Nginx、Redis）就部署在此目录下 - 运行
ls -l /proc/PID/cwd—— 输出类似cwd -> /opt/myapp，这个/opt/myapp就是程序主文件夹 - 运行
ls -l /proc/PID/exe—— 显示可执行文件全路径，例如exe -> /opt/myapp/bin/app，其父目录/opt/myapp通常就是完整程序包所在位置 - 对 Java 服务，
exe可能指向java或dotnet，此时要看/proc/PID/cmdline（用cat /proc/PID/cmdline | tr '\0' '\n'查看），从中识别 JAR 或 DLL 路径，再取其所在目录
通用技巧：避开常见误区
不是所有“程序文件夹”都等于安装目录，尤其在容器或非标部署中：
- systemd 服务可能设了
WorkingDirectory=，优先以该值为准，可通过systemctl show -p WorkingDirectory 服务名查 - 某些服务（如 Docker 容器内进程）的
/proc/PID/cwd指向容器内部路径，需结合docker inspect查宿主机映射关系 - PID 文件（如
/run/nginx.pid）只是记录 PID 的文本文件，不反映程序位置，别把它和程序文件夹混淆 - 权限不足时，
/proc/PID/exe和cwd可能显示为 “(deleted)” 或拒绝访问，建议用 root 或服务所属用户执行
