你写完一个 .php 文件，上传到服务器就能运行：没有独立构建步骤，也没有常驻进程需要管理，请求结束后内存释放。这条"摩擦最小的上线路径"，源码就在 php/php-src 里；README 自述只有一句：The PHP Interpreter。
它是什么
PHP 语言官方参考实现的仓库，也就是解释器本体的源码，包含运行时、内置函数库、标准扩展和各类 SAPI。仓库标注许可证为 Modified BSD（SPDX：BSD-3-Clause），主页 www.php.net，文档统一指向 php.net/docs。长驻内存、高并发常驻服务并非它的原生强项；Swoole、RoadRunner、FrankenPHP 是同一生态中采用常驻进程路线的替代方案（这属于行业常识，README 未展开）。
四万 star 不能当作热度曲线来看
仓库最近一次推送是 2026 年 10 月 22 日 14:37 UTC，说明当时仍在活跃维护；仓库创建于 2011 年 6 月 16 日（Git 镜像迁移）。元数据显示 40922 stars、8288 forks、2212 个 open issue。有两项统计口径需要分开看：Watchers 也是 40922，与 stars 同值；Contributors 显示 230，可能受 GitHub 接口分页采样影响，不能等同于真实贡献者规模。更关键的是，本次没有任何新闻或事件类信源，因此没有依据说它"突然火了"；这类基础设施仓库靠的是长期积累和周期性曝光。
安装方式：README 只给出了预编译路线
Windows 用户从 windows.php.net 下载压缩包，解压后直接运行其中的 *.exe。若要从 Git 构建最小 PHP，需要 autoconf、bison、re2c；Windows 自建构建指向 wiki.php.net 的 step-by-step 文档。Linux 和 macOS 的完整编译步骤不在本次素材范围内。
两条可核实的工程健康度线索
README 挂了两个徽章：GitHub Actions 工作流 test.yml 的测试状态，以及 OSS-Fuzz 的模糊测试状态，后者指向 issues.oss-fuzz.com 的 project:php 查询。这是目前唯一可见的自动化质量保障信号。
为什么值得知道
一次发版会向下游逐级产生影响：框架的最低 PHP 版本约束、Linux 发行版与托管商的支持矩阵、PECL 扩展的 ABI 兼容、安全团队面对单个 CVE 时的应急范围。"PHP 已死"的预测之所以反复落空，机制也在这里：迁移成本分散在整个托管与框架生态中，没有哪个单一项目能单独承担。
风险与缺口一并说明
风险包括：C 语言实现带来的内存安全类缺陷、单个 CVE 波及全球托管面时的放大效应、RFC 共识流程周期偏长，以及历史积累的向后兼容负担限制新特性推进。此外，本文仅依据 README 与仓库元数据，两份第三方解析（DeepWiki、codewiki）本次均未取到，README 里也没有架构章节和示例代码，因此不写模块划分、不写数据流、不给用法示例。
下次 php-src 发版时，可以关注四件事：框架的最低版本约束怎么跟着变、发行版和托管商的支持矩阵怎么排、常驻运行时路线是被核心吸收还是长期并存、一次 CVE 会牵动多大范围的应急响应。至于 star 数，对这类仓库来说，它读不出热度，只读得出"替换它有多难"。