PHP 进程在 Linux 上既可能是一次性执行的脚本，也可能是长期驻留的服务，比如 PHP-FPM 或队列消费者。不同场景下，管理方式差别很大：有的重在快速排查，有的重在自动恢复，还有的更强调调度和可编排性。
这篇文章把几种常见方法按实际使用问题重新梳理一遍：先看命令行工具适合做什么，再看 Supervisor、Systemd 这类长期运行方案，最后补充脚本自动化和 PHP 自身的进程控制能力，方便你按场景选择。
临时排查与手动干预：先用命令行工具
如果你的目标是快速确认 PHP 进程是否存在、资源是否异常，或者临时结束某个任务，命令行工具通常已经够用。这类方法灵活直接，适合调试、应急处理和日常巡检。
用 ps 查看 PHP 进程
ps 适合快速列出当前运行中的 PHP 进程。原文给出的常用命令如下：
ps aux | grep php执行后可以看到 PID、CPU 占用、内存占用等信息，便于先确认到底有哪些 PHP 进程在运行。
用 top 或 htop 实时观察资源占用
当你怀疑某个 PHP 进程吃掉了过多 CPU 或内存时，top 或 htop 更适合做动态观察。它们可以实时刷新进程状态，帮助你定位异常进程。
如果确认某个进程确实需要结束，可以在 top 或 htop 界面里找到它，按 k 键并输入对应 PID 结束进程。不过这一步最好建立在你已经确认该进程可以被终止的前提上。
用 kill 结束指定进程
对于已经拿到 PID 的 PHP 进程，可以直接使用 kill：
kill 12345如果进程没有正常退出，还可以使用更强制的方式：
kill -9 12345这里的 12345 需要替换为实际 PID。通常的操作顺序仍然是先通过 ps aux | grep php 找到目标进程，再决定是否终止。
用 nice 和 renice 调整优先级
有些时候你并不想直接杀掉 PHP 进程，而是希望它少占一点 CPU 资源。这时可以用 nice 或 renice 调整优先级。
启动脚本时可以这样做：
nice -n 10 php script.php如果进程已经在运行，可以动态调整：
renice -n 10 -p 12345这种做法适合资源竞争比较明显、但进程本身还需要继续运行的情况。
长期运行的 PHP 服务：更适合交给进程管理器
命令行工具的优势是直接，但它们主要解决“看见”和“手动处理”的问题。对于 PHP-FPM 这类需要长期稳定运行的服务，手动管理显然不够可靠。只要进程异常退出，恢复动作就不能再依赖人工盯着。
这时候，更合理的方案是使用专门的进程管理器。
Supervisor：适合持续守护常驻 PHP 进程
Supervisor 是非常常见的进程管理工具，尤其适合 PHP-FPM 一类常驻进程。它的核心价值在于自动守护：当进程意外崩溃时，Supervisor 可以自动重启，减少人工介入。
除了自动拉起之外，它还支持日志记录、状态监控，甚至可以通过 Web 界面查看进程状态。对于希望把多个 PHP 常驻任务统一管理起来的场景，Supervisor 往往比纯命令行更省心。
Systemd：与系统深度集成的服务管理方式
如果你的 Linux 发行版已经默认使用 Systemd，那么直接用它管理 PHP 进程通常是更稳妥的选择。你可以为 PHP 进程编写自定义的 .service 文件，把启动方式、依赖关系、日志策略和重启策略都放进系统级配置里。
例如，在服务单元中写入：
Restart=always这样当进程退出后，系统就会自动重新拉起它。相比临时脚本拼装出来的守护逻辑，Systemd 的优点在于和系统初始化、日志与服务控制体系深度集成，可靠性更高，也更适合生产环境。
想自己控制逻辑：可以用脚本做自动监控
如果现成的进程管理器还不能满足需求，也可以通过脚本做自动化监控。一个典型思路是配合 cron 定时检查目标 PHP 进程是否仍在运行；如果发现已经退出，再自动执行重启。
这类脚本可以用 Bash、Python，甚至 PHP 本身来写。它的优势是自由度高，适合有特殊检查逻辑、额外告警需求，或者要与现有运维流程打通的场景。
不过，自由度越高，通常也意味着后期维护责任越大。脚本方式更像“可定制工具”，适合清楚自己要控制哪些细节的人，而不是默认首选方案。
PHP 自身也能参与进程管理
除了操作系统层面的工具，PHP 本身也提供了一些与进程管理相关的能力。它们更适合写长驻脚本、并发任务处理程序，或者与系统服务管理做更细的配合。
pcntl：在 CLI 中控制子进程
pcntl 是 PHP 的进程控制扩展，支持 fork 子进程、处理信号以及实现进程间通信。借助它，你可以在 PHP 脚本内部直接管理多个子进程，用于并发处理任务。
不过这里有一个很关键的限制：pcntl 只能在 CLI 模式下使用，不能用于 Web 环境。也就是说，它适合命令行脚本、守护进程或 Worker，不适合直接放进 Web 请求处理流程里。
结合 Systemd 与 journalctl 做更细控制
如果你已经在用 Systemd 管理服务，那么 PHP 脚本也可以和这套体系配合。文章中提到，可以通过 systemctl 命令控制服务，再利用 Systemd 的日志系统查看运行状态。
例如，可以为一个 PHP 长驻脚本编写 Systemd 服务单元，再通过：
journalctl来查看日志。这种做法的价值不只在于“能启动”，还在于日志、重启和服务状态都能纳入统一的系统管理接口中。
怎么选：按场景判断最省事
如果只是临时调试、排查异常，或者偶尔手动干预，ps、top/htop、kill、nice 和 renice 这类命令行工具已经足够高效。
如果面对的是 PHP-FPM、长驻脚本、队列消费者这类需要长期运行的进程，Supervisor 或 Systemd 会更合适，因为它们能提供自动重启、日志记录和统一管理能力。
如果业务逻辑特殊，需要自行定义检测条件、重启规则或联动动作，那么脚本自动化和 pcntl 这类 PHP 侧能力更有发挥空间。判断标准其实很简单：你当前更需要的是手动灵活性、系统级稳定性，还是高度定制化。
