ps -p PID -o args 可直接查看进程启动参数，但存在截断、空格丢失和引号还原问题；最可靠方式是 cat /proc/PID/cmdline | tr '\0' ' '。
ps -p PID -o args 能直接看到启动参数，但要注意空格和截断
大多数时候你只需要一条命令就能拿到进程的完整命令行：ps -p 1234 -o args。它会输出类似 /usr/bin/python3 /opt/app/main.py --port 8080 --debug 这样的字符串。
但有三个坑得提前踩明白：
-
args字段在某些旧版 ps 或 busybox 环境下可能被截断（默认只显示前 4096 字节），尤其对带长配置文件路径或大量环境变量注入的进程不友好 - 如果进程启动时参数里含空格或引号，
ps输出里不会还原原始 shell 引用格式，而是按空格分词 —— 比如--config "/etc/my app.conf"会被显示成--config /etc/my app.conf，中间空格丢失语义 -
ps -o args实际读的是/proc/PID/cmdline的解析结果，而内核写入该文件时就已抹去了 shell 层级的引号和转义
/proc/PID/cmdline 是最原始来源，必须用 tr '\0' ' ' 处理
真正未加工的启动参数存在 /proc/1234/cmdline，但它不是普通文本：每个参数之间用 \0（null 字符）隔开，直接 cat 会显示为乱码或只输出第一个参数。
正确做法是：
-
cat /proc/1234/cmdline | tr '\0' ' '—— 把 null 替换成空格，适合快速查看 -
strings /proc/1234/cmdline—— 更健壮，能绕过某些内核版本中 null 结尾缺失的问题 -
xargs -0 echo < /proc/1234/cmdline—— 如果你希望保留参数边界（比如含空格的路径），这个比tr更准，但需要 GNU xargs
注意：/proc/PID/cmdline 只在进程存活时可读；一旦进程退出，目录消失，内容不可恢复。
pgrep -a 和 ps -f 都有用，但适用场景不同
pgrep -a nginx 适合“知道进程名但不确定 PID”的场景，它会直接输出 1234 /usr/sbin/nginx -g daemon off; -c /etc/nginx/nginx.conf。但它的局限在于：
- 匹配基于进程名或命令行子串，
-a选项在部分精简版系统（如 Alpine）里不支持 - 如果多个同名进程参数不同，它会全打出来，没过滤能力
- 对用
exec替换过自身、或argv[0]被篡改的进程（如某些 Go 程序），pgrep可能查不到或匹配错
而 ps -f（全格式）适合看父子关系和完整 CMD 列，但它的 ARGS 列和 ps -o args 一样受截断限制，且默认不显示 PID —— 建议组合使用：ps -f | grep nginx。
dotnet 进程参数容易被混淆，优先查 /proc/PID/cmdline
.NET 应用在 Linux 上启动后，ps aux 里常看到的是 dotnet /path/to/app.dll，后面真正的应用参数（如 --environment Production）可能被吞掉或折叠 —— 这是因为 .NET runtime 启动时会重写 argv，部分版本甚至把用户参数移到环境变量里。
可靠做法只有两个：
- 用
cat /proc/$(pgrep -f 'myapp\.dll')/cmdline | tr '\0' ' '直接读原始数据 - 如果进程已启动且你有权限，进
/proc/PID/目录后执行ls -l exe确认是否为 dotnet 解释器，再结合readlink -f /proc/PID/exe看实际执行路径，避免把 host 进程和 managed 进程参数搞混
别依赖 ps -eo pid,args 查 .NET 参数，它大概率只显示到 dotnet 二进制路径为止。
