SAPI是PHP内核为适配不同运行环境预置的C语言抽象层，非供PHP脚本调用的API；它通过sapi_module_struct结构体封装startup、activate、ub_write等回调函数，实现CLI、FPM、Embed等模块与宿主环境（如Web服务器、命令行）的通信。
PHP 7.3.29 的 SAPI（Server Application Programming Interface）不是“设计出来”的接口供开发者调用，而是 PHP 内核为适配不同运行环境而预置的一组抽象层实现。它本质上是 PHP 与外部宿主环境（如 Web 服务器、命令行、嵌入式系统）之间的桥梁，由 C 语言编写，位于源码的 /sapi/ 目录下。理解它的“设计”，关键在于看清其结构目标、核心组件和典型实现逻辑。
SAPI 是什么：不是 API，而是接入协议
SAPI 不是供你在 PHP 脚本里 use 或 call 的函数库，而是一套约定好的 C 接口规范。每个 SAPI 模块（如 cli、fpm、apache2handler）都必须实现一组固定签名的回调函数，例如：
-
startup()：模块初始化（加载配置、注册扩展等） -
activate()：每次请求开始前准备（如重置全局变量、初始化输出缓冲） -
ub_write()：非缓冲输出（把内容写到响应体或 stdout） -
header_handler()：处理header()函数调用（在 CLI 中为空，在 FPM 中转为 HTTP 响应头） -
read_post()/read_cookies()：统一读取请求数据
这些函数被封装进一个 sapi_module_struct 结构体中，PHP 内核在启动时根据当前模式（如 --enable-fpm 编译选项）选择并注册对应 SAPI 模块，后续所有 I/O 和生命周期管理都通过该结构体调度。
PHP 7.3.29 中 SAPI 的典型实现差异
同一套内核，靠不同 SAPI 行为迥异：
-
Cli SAPI：单进程、无状态、直接输出到终端。
activate()和deactivate()很轻量，ub_write()就是fwrite(STDOUT, $str)；不支持 session、不解析 cookie、不处理 HTTP 头。适合调试、脚本任务、单元测试。 -
FPM SAPI：多进程/多线程模型，有 master-worker 架构。
activate()会初始化 FastCGI 请求上下文，ub_write()将数据打包为 FastCGI 记录发给 Web 服务器（如 Nginx）；支持完整的 HTTP 头、上传文件、session、超时控制。生产环境最常用。 -
Embed SAPI：专为嵌入其他 C/C++ 程序设计（如游戏服务端集成 PHP 脚本），提供
php_embed_startup()等入口，允许宿主程序完全控制 PHP 生命周期和输入输出流。
如何查看和验证 SAPI 实现
在 PHP 7.3.29 源码中，可直接定位：
- 主要结构定义：
main/SAPI.h - Cli 实现：
sapi/cli/php_cli.c（含cli_sapi_module全局实例） - FPM 实现：
sapi/fpm/fpm_main.c（含fpm_sapi_module） - 编译时启用开关：
./configure --enable-cli --enable-fpm --disable-cgi
运行时可通过 php_sapi_name() 函数获知当前 SAPI 名称（如 "cli" 或 "fpm-fcgi"），也可用 php -v 或 phpinfo() 查看。
对 PHP 开发者的实际意义
你通常不需要修改 SAPI 源码，但理解它能帮你：
- 明白为什么
header()在 CLI 下无效，而echo总能输出 - 理解
$_SERVER变量哪些字段来自 SAPI（如REQUEST_METHOD由 FPM 注入，argv由 CLI 注入） - 排查“输出已发送”错误（headers already sent）——本质是
ub_write()被提前触发 - 写兼容性代码：比如检测
php_sapi_name() === 'cli'来跳过 session 启动或重定向逻辑
SAPI 的设计哲学是“隔离变化”：让 PHP 核心专注于语言执行，把环境依赖推给外围模块。这种分层，正是 PHP 能同时跑在网页、终端、甚至路由器固件里的底层原因。
立即学习“PHP免费学习笔记（深入）”；
