Linux PHP开发环境搭建：18年经验实战指南

　　去年8月，我蹲在测试机房第三排右数第二个工位上重装第十七遍 PHP 7.4 的 FPM 模块，显示器右下角校样还挂着上个月给市场部改的 Banner 图——青灰渐变底，三行字，第二行“极速响应”四个字被设计喊回三次，说“不够呼吸感”。我盯着那个没关掉的 PS 窗口，顺手把 php-fpm.conf 里 pm.max_children 从 50 改成 32，保存，reload，然后听见隔壁工位老张对着电话吼：“不是我改的 ini，你查 /etc/php/7.4/fpm/pool.d/www.conf 顶层 include，它 include 了 /usr/local/etc/php-fpm.d/override.conf，而 override.conf 里那行 user = www-data 是上周保洁阿姨擦桌子时手滑碰歪键盘打出来的。”

　　我原以为用 Docker 封一版干净镜像就能收工。结果 build 到 RUN pecl install xdebug-3.1.5 时卡住，日志里飘着一行 warning：‘xdebug: cannot load because its version does not match the version of PHP’——可我明明用的是 php -v 输出的版本号粘贴的。查了四十分钟，发现是 alpine:3.16 基础镜像里预装的 php-cli 版本和 pecl 仓库默认拉的 xdebug 源码包编译目标不一致，而这个差异只在 phpinfo() 第二十七行的 “Compiler” 字段后括号里闪了一下，还是灰色小字。我敢打包票：你在任何文档里都找不到这行字跟 pecl 安装失败的关系，但它就在那儿，淡得像水印。

文章配图，仅供参考

　　凉掉的外卖盒盖子没扣严，咖喱汁洇到键盘 F6 键右边半厘米。我边扒拉饭边看 Jenkins 构建日志：build #487 成功，#488 失败，#489 又成功。点开失败那次的控制台输出，最后一行是 ‘Failed to fetch https://packages.sury.org/php/dists/buster/main/binary-amd64/Packages.gz’——但我们的宿主机明明跑的是 Ubuntu 22.04。翻 git blame，发现是新来的实习生改了 apt-sources.list 模板，他复制了公司内网文档里一段过期链接，文档标题是《PHP 环境标准化模板（v2.3）》，而 v2.4 压根没同步进 Confluence，只有 QA 老李在 Slack 频道里发过一条“别用 v2.3 的源，挂了”，没加粗，没 pin，发完立刻切去处理另一个线上告警。

　　领导发来六十秒语音，开头就问：“PHP 开发环境这块，是不是又靠个人经验硬扛？”我没回。语音放完我切到 tmux，ctrl-b 后按 3，跳到第三个窗格——那里开着一个两年前的 screen 会话，还挂着 nginx -t 的输出，最后一行写着 ‘syntax is ok’，后面跟着个时间戳：2022年04月11日16:23:07。我手指悬空两秒，没 ctrl-c。其实那天是我调通 Laravel Mix 与 Webpack Dev Server 热更新共存的节点，用的方案是改 nginx 的 upstream timeout + 把 webpack 的 port 指向 127.0.0.1:8081 而非 localhost:8081，因为后者在某些 systemd-resolved 为启用的机器上会多走一圈 loopback 查 hosts——这点连官方 Issue 都没提，只在 Debian 邮件列表某个四年前的回复末尾带了一句“may behave differently if nsswitch.conf lists ‘resolve’ before ‘files’”。我说不准这是不是唯一解法，但我删过三次 /etc/resolv.conf 后才摸到门。

　　前天下午两点零七分，审稿间的灯突然熄了三十秒。整层楼只有我们组留着人，空调还在转，嗡嗡声比平时响一点。小陈跑去配电箱，出来时说跳闸了，但没查出原因；后来发现是隔壁部门换了个大功率饮水机，线路老化，电压波动触发了 UPS 的瞬间保护。这事跟我手上的 PHP-FPM 进程崩溃率没关系。但它让我想起来——去年8月那阵子，监控平台每天凌晨三点十五分准时报一次 FPM worker crash，我们追了三天日志、coredump、strace，最后定位到是 systemd 重启了 php-fpm.service 之后，/run/php/php7.4-fpm.sock 文件权限继承错了一级：父目录是 root:www-data，socket 却被创建成了 root:root，导致 nginx 工作进程无法连接。修复方式是改 systemctl 的 tmpfiles.d 目录配置，加一行 ‘z /run/php 0755 root www-data -’。没人教过这句 z 是啥意思。手册里写‘create and set permissions’，没说 z 是‘if exists, fix it; if not, make it with this mode’。我试过 w 和 f，全崩。

　　印刷对接的电话又来了，这次是印厂问“封面封底的出血线你们确认是三毫米吗”，我说确认。挂了以后盯着 terminal 里 tail -f /var/log/php7.4-fpm.log，看着新进来的 request 记录一行行刷——其中一行夹着 Warning: session_start(): Failed to read session data: files，我顺手 grep /etc/php/7.4/fpm/php.ini -A 10 -B 2 | grep session.save_path，看到路径是 /var/lib/php/sessions，再 ls -ld /var/lib/php/sessions，发现 owner 是 root，不是 www-data。修了。但其实这不是重点。重点是：我三年前在另一家公司的生产环境也遇到完全一样的路径权限问题，解决方式一样，路径也一样，连那台服务器的 Dell R720 序列号我都还记得前六位是 CN123456——只是那时候还没迁到 Kubernetes，所有事都在物理机上摊开晾着，谁都能看见 socket 权限、session 路径、ulimit -n，看得太清，反而容易漏掉真正堵住的缝。

　　“Linux PHP开发环境搭建：18年经验实战指南”？站得住。不是因为它有多完整，而是它活下来了。优胜劣汰——不是技术淘汰人，是那些今天还在你 config 里裸奔的、没加 chmod、没设 selinux context、没检查 umask、甚至没进 CI 的二十行 bash 初始化脚本，在十八年里被线上雪崩、凌晨三点的 pagerduty、运维锁屏时顺手 kill -9 掉的进程、以及新来的实习生抄错的一行注释，一遍遍打碎、重组、再打碎。你信不信，我现在敢直接 rm -rf /etc/php//fpm/pool.d/.conf，十秒内重建一套能跑 PHPUnit 且不爆 open_basedir 的池配置，靠的不是记忆，是肌肉知道哪里该补 chown，哪里该 touch 一个空文件让 systemd-tmpfiles 先过一遍……算了，我先回个微信，市场部刚催定稿图，说“青灰不行，要低饱和莫兰迪蓝”，还得改。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!