PHP是分工明确的协作系统：Zend引擎编译执行opcode并管理内存，SAPI层（如CLI/FPM）负责请求接入，扩展模块（如PDO、mbstring）提供具体函数功能，三者协同构成可拆解、可替换的运行时系统。
PHP不是点一下就跑起来的黑盒子，它是一套分工明确、可拆解、可替换的协作系统。拒绝一键安装包，本质是拒绝模糊认知——只有看清Zend引擎怎么编译opcode、SAPI如何把HTTP请求送进去、扩展怎么注册函数、操作系统如何调度进程，你才能真正掌控环境，而不是被环境牵着走。
Zend引擎：不写C也能看懂的执行核心
Zend引擎是PHP的“大脑”，但它不实现strlen()、file_get_contents()这些函数。它的职责非常聚焦：
- 把.php文件切分成token（比如
echo、$name、;），再拼成抽象语法树（AST） - 把AST编译成轻量级的中间指令（opcode），类似汇编但跨平台
- 用虚拟机逐条执行opcode，同时管理变量符号表、引用计数和垃圾回收
- 提供函数调用机制——查函数名、找对应实现、传参、返回值，但不管实现逻辑
你可以用php -d vld.active=1 -d vld.execute=0 test.php直接看到某段代码生成的opcode，这就是引擎工作的第一现场。
SAPI层：Web请求进来的“门禁系统”
SAPI（Server API）决定PHP怎么跟外界打交道。它不是可选组件，而是必经通道：
立即学习“PHP免费学习笔记（深入）”；
-
CLI：命令行模式，
php script.php走的就是它，没有HTTP头，适合脚本和调试 - PHP-FPM：生产环境主流选择，以FastCGI协议与Nginx通信，进程管理独立、内存隔离好、支持平滑重启
- Apache mod_php：已逐步淘汰，PHP嵌入Apache进程，一个请求崩溃可能拖垮整个Apache
关键点在于：同一个PHP二进制文件，换不同SAPI，行为完全不同。FPM有worker进程池、慢日志、动态子进程管理；CLI没有请求上下文、不自动清空全局变量。理解SAPI，才能解释为什么$_SERVER在CLI里为空、为什么FPM要配pm.max_children。
扩展模块：能力边界的真正定义者
你写的new PDO()、curl_init()、mb_strlen()，全由扩展提供。它们不是“插件”，而是PHP启动时加载的C动态库：
- 标准扩展（如
ext/standard、ext/json）随PHP源码一起编译，默认启用 - 可选扩展（如
redis、imagick）需单独编译或通过包管理器安装，并在php.ini中显式启用（extension=redis.so） - 每个扩展有生命周期钩子：MINIT（模块初始化）、RINIT（请求初始化）、RSHUTDOWN（请求结束）等，决定资源何时分配、何时释放
报错Call to undefined function mb_detect_encoding()？不是PHP坏了，是mbstring扩展没加载。用php -m | grep mbstring和php --ri mbstring就能定位到具体缺失环节。
手动搭建环境：从源码到服务的四步闭环
不依赖XAMPP或phpstudy，自己搭一套最小可用环境，能立刻建立真实感知：
-
装依赖：在Ubuntu上运行
sudo apt install build-essential autoconf libxml2-dev libssl-dev libcurl4-openssl-dev libpng-dev libjpeg-dev，缺哪个头文件，编译时就会报错，逼你搞清每个扩展背后依赖什么C库 -
编译PHP：下载PHP源码，执行
./configure --enable-fpm --with-openssl --with-curl --enable-mbstring，开关即决策——开什么，就链接什么；关什么，就精简什么 -
配FPM：编辑
php-fpm.conf设监听端口（如127.0.0.1:9000），改www.conf设用户、进程数、慢日志路径，所有配置都直连操作系统资源 -
连Nginx：在server块里加
location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; include fastcgi_params; }，此时Nginx只是反向代理，PHP处理完全交由FPM进程池
这四步做完，你手里的PHP不再是个神秘程序，而是一个可观察、可调优、可替换组件的运行时系统。
