ps -ef | grep nginx 基本是判断 Nginx 是否已经启动时最常用的命令之一，执行后通常可以看到主进程和工作进程；不过为了避免把 grep 自己也匹配出来，更推荐使用 ps -ef | grep '[n]ginx'；此外，最好再结合 ps -eo pid,args 一起查看，确认拿到的是完整的启动命令和参数。
ps 的 -f 或 -eo 并配合 args 字段，而不是默认的 ps aux —— 因为后者经常会截断过长命令，无法完整显示启动参数。
ps -ef 能查看完整启动参数，但要注意字段顺序和命令截断问题
ps -ef 是 Linux 查看进程信息时最常用、也相对稳妥的起点，它采用 SysV 风格输出，CMD 列默认会显示完整命令行（包含全部参数），前提是终端宽度足够，且没有受到 shell 自动换行的干扰。
- 字段顺序固定：
UID、PID、PPID、C、STIME、TTY、TIME、CMD - 如果某条命令特别长（例如包含大量环境变量、长路径或复杂参数），
ps仍然可能发生截断 —— 这时不能只靠拉宽终端，而应改用-eo自定义输出字段 ps -ef | grep nginx会把 grep 自身那一行也匹配出来，建议使用ps -ef | grep '[n]ginx'来规避这个问题
ps -eo pid,cmd --sort=-pid 可精准控制输出列，减少截断风险
如果想确保看到每个进程完整的启动命令，最好显式指定 cmd 或 args 字段，并尽量避免默认输出宽度带来的限制：
ps -eo pid,cmd：只输出 PID 和完整命令行，列更简洁，适合后续管道处理或脚本分析ps -eo pid,args的效果与cmd基本一致，但语义更清晰（args更强调命令行参数）- 加上
--sort=-pid可以按 PID 降序排列，便于快速定位最近启动的新进程 - 注意：
ps -eo pid,comm只显示二进制名称（如ja va），不会包含启动参数，使用时不要混淆
遇到 systemd 服务时，ps 看不到原始参数？可结合 systemctl show
像 docker.service 这类由 systemd 管理的服务，在 ps 中通常只能看到类似 /usr/bin/dockerd 这样的进程名；不过不要被这个表象误导，真正的启动参数通常定义在 unit 文件里，ps 并不会把这些配置内容完整还原出来。
- 查看真实启动参数：执行
systemctl show --property=ExecStart docker.service - 查看完整环境与参数配置：使用
systemctl cat docker.service查看 unit 文件内容 - 如果服务已经启动但参数被覆盖（例如通过
systemctl set-environment），还需要结合systemctl show --property=Environment ps显示的是进程当前实际执行的命令，而不是 systemd 解析后的最终配置结果 —— 两者在某些场景下可能并不完全一致
procfs 是最权威的来源，但不要直接 cat /proc/*/cmdline
每个进程的完整命令行参数实际保存在 /proc/ 中，以 null 字节分隔，可读取但不适合直接 cat —— 否则容易出现乱码，甚至影响终端显示。
- 更安全的读取方式：
tr ' ' ' ' < /proc/1234/cmdline | sed 's/ $//' - 批量查看所有进程参数：
for pid in /proc/[0-9]*; do echo "$(basename $pid): $(tr ' ' ' ' < $pid/cmdline 2>/dev/null)"; done | head -20 - 注意：
/proc/可能为空（例如内核线程），也可能因权限不足而无法读取（非 root 用户通常看不到其他用户的进程详情）/cmdline - 这是查看进程参数最权威的来源，但日常排查时优先使用
ps -eo pid,args会更高效，因为它底层就是读取该文件并进行了格式化展示
args 究竟来自镜像默认定义，还是在 docker run 时被覆盖；再比如 Ja va 进程里的 -D 参数是否在启动后通过 JMX 被动态修改。这种情况下，仅查看 ps 输出通常还不够，还需要结合 /proc//environ 以及应用自身的状态接口综合分析。
