开发环境给前端工程师开个PHP内置热更新端口

“后端哥，又改接口了？我这边刷新白屏了。”
“哦，等一下，我重启一下 `php -S`，马上好。”
这句话是不是很耳熟？在前后端联调的日子里，前端工程师最害怕的不是接口没写完，而是写完之后，后端同事那个运行在终端里的 PHP 内置服务器突然“啪”一下断了。不是网线问题，是后端改了代码，得手动 Ctrl+C 再敲一遍启动命令。更要命的是，这个服务还不止一个人用，整个前端组都在连它。

于是，前端群里流传着一个传说：要是 PHP 内置服务器也能像 Vite 那样热更新就好了。
怎么说呢，这需求听着离谱，仔细想想，倒也不是不能实现。

先在“伪需求”里找真痛点

PHP 的 `php -S` 是个好东西，一条命令就能起一个开发服务器，不用装 Nginx、不用配 Apache，非常适合快速启动一个项目给同事看效果。但它有个明显的短板：没有内置的文件监听，无法在你修改完 PHP 文件后自动重启或刷新。

对于后端来说，这不算大问题，反正他们习惯改完代码手动刷新浏览器，甚至用 `die()` 一个个打点调试。
可前端不一样。前端只关心接口返回的数据结构，不关心你用没用到 `global`，也不关心 `vendor` 目录里发生了什么爆炸。他们想要的是一个稳定、不抖动的联调环境，最好你改完代码，他们刷新一下页面就能看到新逻辑——哦不，最好连刷新都不用，接口自己“热”起来。

真正的需求不是“热更新”，而是减少因后端重启服务带来的中断感。明白了这一点，后端就可以用很粗暴的方式满足前端的期待。

用 Shell 脚本强行“续命”

既然没有原生的热更新，那就造一个轮子。思路很简单：监听项目目录里的 PHP 文件变化，一旦有改动，就自动杀掉当前 `php -S` 进程，再重新启动。

用 Linux 上的 `inotifywait` 就能轻松实现。假设我们项目的入口是 `public/index.php`，想把端口固定在 `8088`，给前端同事们专用：

#!/bin/bash
PORT=8088
ROOT=./public
while true; do
    php -S 0.0.0.0:$PORT -t $ROOT &
    PID=$!
    # 监听所有 .php 文件的变化（排除依赖目录）
    inotifywait -r -e modify -e create -e delete --exclude '/(vendor|node_modules)/' ./ 2>/dev/null
    kill $PID
    echo "$(date +%H:%M:%S) PHP文件变动，服务已重启"
done

顺手贴一个对应 Node 用户习惯的简化版：用 `fs` 模块写一个 watcher，改动后 `exec('pkill -f php -S')` 再启动。原理一毛一样。

这个脚本跑起来之后，只要项目里的 PHP 文件有任何保存操作，服务就会在几百毫秒内自动重启。前端再也不会看到“连接被重置”的红色错误提示了——至少在刷新页面的时候，服务已经回来了。

一台机器，两个世界

这个“伪热更新端口”最大的意义，不是让后端省事，反而是让前端和别纠结自己人。

通常后端本地也会跑一个自己调试用的端口，比如 `8000`。他可能改改代码、打断点、打印日志，把服务搞得很乱。如果前后端共用同一个服务，前端肯定会连坐遭殃。
现在单独开一个 `8088` 自动重启端口，把它作为给前端的“对外窗口”。后端在自己的 `8000` 上随便折腾，只要把代码提交或同步到项目目录，那份改动就会自动镜像到前端可用的端口上。

甚至可以用两个不同的根目录：一个给后端自己调试，一个用 Git hook 把最新的代码同步过去，然后那个目录由自动重启脚本托管。这样前端拿到的永远是最干净的版本，后端也不会因为不敢重启而留下半截逻辑。看起来就很有“环境隔离”的意思了。

当然了，有些团队会进一步用 Docker 把这个脚本编排进去，配合 `docker-compose` 给前端起的服务里，挂载源码目录，再执行类似 `php watch.php` 的守护进程。本质和轮子没什么区别，只是套了一层更有逼格的“容器”。

但这不是真·热更新

话说回来，这种用“自动重启”模拟出来的“热更新”，还是有点伪科学的味道。因为 PHP 每次请求都会重新编译脚本，所以重启一次之后，下一次请求确实拿到了新代码，哪怕浏览器没刷新，ajax 重新调用时也会命中新逻辑。从这个角度讲，它已经做到了“接口热更新”。

但如果前端谈论的是“页面上的 HMR”，即不刷新页面就自动替换模块、保留状态那种流畅体验，那 PHP 就真不如 Node 生态里的 Vite + React HMR 那么丝滑。好在大多数前后端分离项目中，前端才是页面主体，PHP 只提供 JSON 接口。改动 PHP 后，前端只需要在 DevTools 里触发一次重复请求，然后把返回的新数据渲染出来，不算糟糕。

真正能带来全方位热更新的重方案是 Swoole 或 Workerman 常驻内存模式，但为了一个联调环境，去把整个项目改造成常驻内存，显然是杀鸡用牛刀。与其大动干戈，不如那个终端里的 `while true` 来得直白。

说到底，是让环境更懂人

“开发环境给前端工程师开个PHP内置热更新端口”这句话，听上去像是一句调侃，但其实藏着团队协作里最朴素的价值观：是谁用环境，就让环境适应谁。

前端不懂 PHP 的进程模型，不需要懂。他们只需要知道，你给的那个端口，永远活着，永远拿得到最新代码。这比任何高冷的技术架构都管用。

所以，下次前端兄弟再提这个需求，别急着吐槽，把那个 `inotifywait` 脚本拷过去，改一下端口，然后告诉他：“端口开好了，热得很，随便用。” 从此以后，联调环境安静如鸡，大家又能快乐地写代码了。