/proc/[PID]/cmdline 是最可靠、最完整的进程启动命令来源，因其直接反映 execve() 传入的原始 argv，而 ps -f 或 ps aux 的 CMD 列仅显示 argv[0] 或截断摘要，易被修改、省略或受终端宽度限制。
直接看 /proc/[PID]/cmdline，这是最可靠、最完整的来源，其他方法（比如 ps 的 args 或 comm 字段）容易被截断或简化。
为什么 ps -f 或 ps aux 里的 CMD 不够用
因为 ps 默认只显示进程的“命令名”或“参数摘要”，不是原始启动字符串。比如一个带长路径、多层引号、空格和特殊字符的 Java 启动命令：java -Xms2g -Xmx4g -jar /opt/app/xxx.jar --spring.profiles.active=prod，ps aux 可能只显示前几十个字符，或者把参数合并、省略，甚至因终端宽度自动换行截断。
更麻烦的是：ps -f 中的 CMD 列实际是 argv[0]，很多程序（尤其是 daemon 或 systemd 启动的服务）会主动改写它，比如改成 [java] 或 [nginx: master process] —— 这根本不是你当初敲的命令。
-
ps输出受终端列宽限制，超长参数会被砍掉 - 某些 shell 或 exec 调用会重置
argv[0]，导致ps显示失真 -
ps -eo args看似能显示完整参数，但内核对它的填充有长度上限（通常 4KB），且不保证保留原始分隔符
正确做法：读取 /proc/[PID]/cmdline
/proc/[PID]/cmdline 是内核为每个进程维护的原始启动参数数组，以 null 字节（\0）分隔，内容与 execve() 调用时传入的 argv 完全一致。
要可读地查看它，必须用能处理 null 分隔符的工具：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
cat /proc/[PID]/cmdline | tr '\0' ' '—— 把 null 换成空格，最常用 - 用
strings /proc/[PID]/cmdline—— 自动跳过 null 并按 ASCII 打印，适合快速扫一眼 - 用
tr '\0' '\n' —— 每个参数单独一行，清晰易比对
注意：/proc/[PID]/cmdline 只对当前存在且你有权限读取的进程有效；如果进程已退出或权限不足（比如非 root 查看其他用户进程），会报 No such file or directory 或 Permission denied。
怎么快速定位 PID 再查 cmdline
别靠肉眼翻 ps -ef 海量输出。先用精准方式找 PID：
- 查服务名：用
systemctl show -p MainPID | grep MainPID（systemd 管理的服务） - 模糊匹配进程名：用
pgrep -f "关键词"，比如pgrep -f "redis-server" - 查端口反推：用
lsof -i :端口号或ss -tulpn | grep :端口号，然后取 PID 列
拿到 PID 后，立刻执行：tr '\0' '\n' PID/cmdline。如果看到某行是完整路径（如 /usr/bin/python3）+ 后续参数，那就是真实启动命令。
容易忽略的细节
有些进程（特别是容器内或被 systemd 封装过的）的 /proc/[PID]/cmdline 里可能只有解释器路径，真正的脚本路径藏在后续参数里；还有些 Go 或 Rust 程序会把所有参数打平进单个字符串，靠空格分割 —— 这时候 tr '\0' ' ' 仍是最稳的还原方式。
另外，ps -eo pid,lstart,etime 能查启动时间，但它和 cmdline 是两件事：前者告诉你“什么时候启的”，后者告诉你“怎么启的”。两者得配合着看，才能复盘整个启动上下文。
