PHP发展记事
2010-09-20 09:28:28 
阿炯
PHP是一种开源的通用计算机脚本语言，尤其适用于网络开发并可嵌入HTML中使用。其语法借鉴吸收了C语言、Java和Perl等流行计算机语言的特点，易于一般程序员学习。主要目标是允许网络开发人员快速编写动态页面，但PHP也被用于其他很多领域。本文收录了一些重要的发展轶事。短短两年使用率下滑 40% 曾经风靡全球的 PHP 为何逐渐失去优势
短短两年使用率下滑 40% 曾经风靡全球的 PHP 为何逐渐失去优势
2024年4月下旬消息，根据 WordPress 联合创始人 Matt Mullenweg 的说法，PHP 的受众比例急剧下降，疑似受到 WordPress“JavaScript 优先”主张的影响。TIOBE 编程语言人气指数发布更新并提出“PHP 的魔力是否正在消散？”的灵魂拷问。2024年4月，PHP 在 TIOBE 编程语言指数榜上仅位列第 17，“成为其有史以来的最低排位”。
暴露 PHP 人气急剧下滑的还不只是 TIOBE 榜单。在年度 Stack Overflow 开发者调查报告中其市场占比也从 2018 年的 30.7%（即受访者当中使用 PHP 的百分比）下降至 2023 年的 18.58%。JetBrains 开发者生态系统调查同样观察到类似的趋势，PHP 占比从 2017 年的 30%下降至 2023 年的 18%。而且最后一项数据尤其值得关注，因为 JetBrains（以及 WordPress 托管厂商 Automattic）正是 PHP 的最大赞助方之一。
JetBrains 公布的开发者调查结果
这种下滑趋势在 BuiltWith 上体现得尤其明显，自 2020 年底以来 PHP 的流行度增长线开始断崖式跌落。
BuiltWith 公布的 PHP 趋势图
截至 2021 年 11 月的一项调查显示，PHP 在互联网前百万个网站中的占比仍在 3 万以上。但如今两年多过去，其占比已经下滑至 1.5 万左右。而且截至202年4月，BuiltWith Quotes 公布的实际占比数字为 18.19%。18%这个比例与 Stack Overflow 及 JetBrains 的调查发现高度吻合，因此可以基本确定，PHP 在开发者中的受欢迎程度已经从之前的约 30%萎缩至现在的 18%。换言之，在短短两年之间下降了 40%。所以结论是什么？在过去几年里到底发生了什么样的变化，才导致 PHP 在 Web 编程语言的竞争当中迅速落败？
WordPress 高调宣布“JavaScript 优化”
可以说，PHP 衰落的最大原因就是 WordPress（迄今为止最具人气的 Web 内容管理系统）正在从 PHP 转向 JavaScript。WordPress 联合创始人兼 Automattic 公司 CEO Matt Mullenweg 在上月于中国台湾召开的 WordCamp Asia 2024 大会上也就此做出论述。
他在回答观众提问时表示，“我觉得 WordPress 中的大部分新代码现在都是由 JavaScript 编写而成，而且这种趋势已经持续了一段时间。因此从方方面面来讲，如今的 Gutenberg 已经转化成了一个 JavaScript 优先的项目。”
大家绝没看错：Matt Mullenweg 直言现在的 WordPress 就是个“JavaScript 优先的项目”。而他所提到的 Gutenberg，其实是该公司备受争议的全新用户界面，同时也是推动 JavaScript 全面替代 PHP 的主要原因。当然他也承认从 PHP 转向 JavaScript“并不容易”。
这倒不是说 WordPress 不再依赖于 PHP。毕竟在撰写本文时，恰好就是在 WordPress 中以“/wp-admin/post-new.php”结尾的 URL 输入这篇文章；但只能说目前如此，未来的 WordPress 已经确定要走向另一条道路。
Mullenweg 还谈到，他希望能在 WordPress 中看到进一步改进——令人惊讶的是，他已经开始从 JavaScript 的视角出发看待这些变化。比如说PHP是一种服务器端脚本语言（意味着代码通常在 Web 服务器上处理），而 Mullenweg 希望 WordPress 能使用 JavaScript 把更多操作交由客户端执行。他意味深长地表示，“我真心觉得我们应该把更多处理任务留在客户端。比如对于正在编辑的内容，这部分处理就可以交给客户端。这种在浏览器运行 JavaScript 的速度可能会更快，因为现在虚拟机和性能极强的处理器已经相当普遍。”
在演讲即将结束之时，有观众向 Mullenweg 询问他对 Gutenberg 项目的感受，以及开发人员为其做出贡献时遭遇到哪些困难。提出这个问题的开发者还希望“降低 Gutenberg 的抽象级别”。Mullenweg 回应称，“说实施，我觉得大家必须适应这种发展态势。我认为 Gutenberg 的开发方式和 JavaScript 优先理念才是大部分 Web 开发工作的未来方向。顺带一提，其实我也得重新学习，这些东西跟我当初熟悉的方式也有区别。也许我们可以把某些抽象调整得更简单一点，但总体而言，我会选择深入研究一下。”
他还补充称，Gutenberg 项目、包括向 JavaScript 语言的转变，目前还远未完成。“在启动 Gutenberg 项目时，我们就知道这可能是个为期 10 年的项目。目前我们才刚刚完成 60%到 70%的工作。”
与此同时，在 PHP 基金会这边……
不得不承认，WordPress 项目（也是 PHP 能够在 Web 领域保持流行的最大动因）正坚定向着 JavaScript 世界迈进。这几乎必然会阻止更多年轻开发者选择 PHP，同时迫使其他开发人员（例如那些致力于服务 WordPress 客户的开发人员）从 PHP 转向 JavaScript。但好消息是，仍然有相当一部分开发者群体会继续使用 PHP——毕竟两轮大规模开发者调查中的这 18%对应着相当体量的从业受众。而 PHP 基金会将继续为他们提供支持。
PHP 基金会于 2021 年 11 月正式成立，希望以非营利组织的身份承担起 PHP 项目的管理职责。PHP 基金会是由 JetBrains 领导的企业联盟所建立，其中包括 Automattic、Zend、Laravel 以及 Acquia（Drupal 的托管商）等。JetBrains 工程师 Roman Pronskiy 则出任项目负责人，目前在基金会网站上的头衔为“运营主管”。
在2024年 2 月的 Laravel 会议上，Pronskiy 主要探讨了技术问题，同时也承认“PHP 基金会目前最艰巨的任务，就是扭转 PHP 在公众心目中的形象。”虽然他没有具体说明是哪些原因导致 PHP 的公众形象下降，但 Matt Mullenweg 在解释 WordPress 转向“JavaScript 优先”的理由时已经基本给出了答案。无论如何，Pronskiy 正快速投身于 PHP 项目的后续开发，并为其组织起由 10 名有偿开发者组成的全职团队。
PHP 基金会团队
总而言之，2024 年的 PHP 几乎成了 Web 开发领域爹不疼、娘不爱的“孤儿”，而 JavaScript 则是在家、在校都备受关注的宠儿。对 PHP 来说更加可悲的是，目前的这种人气下滑趋势短时间内恐怕无法停止——毕竟 WordPress 那边的开发团队还在积极适应新的 JavaScript 规范。但至少 PHP 基金会还在为此而努力，也许这股颓势能够逐渐迎来转机。
协程提案 Fiber 引发激辩
PHP 社区于2021年3月8日发起了将 Fiber RFC 添加到 PHP 的投票。根据 Fiber RFC 中的描述，Fiber 主要用于为异步 I/O 实现协程，提供了独立栈分配、函数调用的暂停和恢复功能，它将作为扩展集成到 PHP 中。按照计划，投票将于3月22日截止，最新数据为 38 票赞同、11 票反对。从目前的结果来看，Fiber RFC 很大可能会通过投票从而被添加到 PHP(获得 2/3 的赞成票即可通过)。当前公开的投票结果显示，两位创始人——PHP 创始人 Rasmus Lerdorf 和 Swoole 创始人韩天峰均投了反对票。
Swoole 是一个 PHP 协程框架，为 PHP 提供协程、高性能网络编程支持，并提供了多种通信协议的网络服务器和客户端模块，可以方便快速地实现 TCP/UDP 服务、高性能 Web、WebSocket 服务、物联网、实时通讯、游戏、微服务等，使 PHP 不再局限于传统的 Web 领域(来自 Swoole 官网介绍)。
Reddit 上的一篇帖子引起了不少讨论，有人认为 Fiber 是 generator 的升级版本，它是协程的最小化核心实现，并且不会对 PHP 产生不利影响，将它集成到 PHP 有利于发展和探索未来的异步生态。也有人质疑其投反对票是因为担心此提案会对 Swoole 的商业化 (Swoole Plus) 造成影响。对于 Fiber RFC 的观点是，建议先作为一个 PECL 扩展，PHP 内核开发者能够思考清楚 PHP 未来协程的整体技术体系和实现方式后再做决定。实际上异步编程颠覆了 PHP 一直以来的设计哲学和编程模式。如果 PHP 语言官方决定要支持像 Node.js、Golang、Swoole 这样的异步/协程并发编程模式，那么就需要系统性思考一下整体的架构，以及完整的实现。
韩继续发表文章(关于 PHP 8.1 的 Fiber RFC)从技术细节详细地解释了自己反对 Fiber RFC 的原因。他认为用户真正需要的是一种完整的、系统性、成体系、简单易用、可靠的一整套技术方案，并根据自己的经验提出可从 7 个方面进行考虑：
EventLoop API
协程(对应 ext-fiber)
IO 调度器(Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)
CPU 调度器
现有同步阻塞 IO 扩展(redis、curl、php_stream、sockets、mysqli、pdo_mysql 等)和内置函数(sleep、shell_exec、sleep、gethostbyname 等)如何实现支持协程，变成异步非阻塞模式
协程通信(channel)
服务器：实现 PHP-FPM 协程版，或者提供一个新的协程 HttpServer
虽然他给出了充分的理由投反对票，但从目前看来，许多人并不认可他的做法。他们认为，即便实现 PHP 的协程化难度很大也不需要等到有成熟方案之后才合并，也不能因为 Fiber 不够完善，就猜测它不能满足大多数人的要求。反而因为 Fiber 是最小化实现，集成到 PHP 不会对使用者造成很大的维护负担，却又能满足很多人的项目需求，他们可以在此基础上进行更多实现，为用户开放了探索各种协程方案的可能。因此，这一部分开发者认为没有理由反对将 Fiber RFC 添加到 PHP。双方思考角度不同，所以给出了截然相反的投票结果，而且他们都有各自的立场——虽然初衷都是希望 PHP 变得更好，但无论如何，最后还是以投票结果为准。
关于轻量级高性能的 API 和 MVC 应用服务框架-Swoolefy
Swoolefy是一个基于swoole扩展实现的轻量级高性能的常驻内存型的API和Web应用服务框架，高度封装了http，websocket，udp服务器，以及基于tcp实现可扩展的rpc服务，同时支持composer包方式安装部署项目。swoolefy抽象Event事件处理类，实现与底层的回调的解耦，支持同步|异步调用，内置view、Log、session、mysql、redis、memcached、mongodb等常用组件等。
核心特性
1、轻量级的框架，实现路由与调度，MVC三层，当然也可以配置多层
2、支持composer的PSR-4规范和实现自定义注册命名空间
3、支持多协议，目前支持http，websocket，tcp，udp，以及基于tcp实现的rpc，开放式的系统接口，可自定义协议数据格式
4、抽象Event的事件处理与底层的事件监听解耦，屏蔽不同协议之间的应用差异，大部分代码实现共用
5、实现超全局变量，IOC，静态延迟绑定，组件服务常驻内存化，trait的多路复用，钩子事件，单例，工厂模式等
6、简单易用的异步务管理TaskManager， 定时器管理TickManager， 内存表管理TableManager， 进程管理ProcessManager，超全局管理
7、灵活多层的配置,配置参数即可实现底层已封装的复杂功能
8、应用对象的深度复制，实现对象的常驻内存，每个请求只需要从内存中复制应用对象，不需要再重新创建，减少IO消耗
9、封装View，Log，Mysql，Redis，Mongodb，Swiftmail，Session等常用组件，其他组件根据业务按照约定即可封装成组件
10、实现异步半阻塞与全异步非阻塞，EventHander与底层解耦
11、基于inotify实现自动监控swoole服务的文件变动，实现worker自动reload，智能邮件通知
12、命令行形式高度封装启动|停止控制的脚本，简单命令即可管理整个框架
两个 RCE 漏洞被提前泄露
PHP团队发出了紧急警告：2026年10月下旬将发布安全更新，修复两个严重漏洞。这不是常规的月度补丁，而是「信息提前泄露了，我们等不了原定的披露时间」——PHP 安全团队原计划周四披露，但消息泄露后把补丁提前到了周三（10 月 21 日 14:00 UTC）。两个漏洞编号 CVE-2026-109618 和 CVE-2026-109619，都是远程代码执行（RCE）漏洞。PHP 官方给的严重度是 CVSS v4.0 9.2，而泄露的消息里说 10.0（满分）—— 无论按哪个算，都是「尽快修复」级别。安全公司 watchTowr 确认了漏洞真实性，还说自己已经成功复现了 CVE-2026-109618，但在补丁发布前不会公开技术细节。
影响面是这次最让人紧张的部分。据 watchTowr 和安全研究者的分析，这两个 RCE 影响 PHP 5、6、7、8 全系版本。安全研究员 Florian Roth 特别提醒了一个残酷的现实：只有 PHP 8 会收到官方补丁，PHP 5 和 PHP 7 多年前就已停止支持（EOL），还在跑它们的服务器将没有官方修复。考虑到互联网上仍有大量跑着 PHP 5/7 的老系统，这意味着很多服务器会「裸奔」—— 没有补丁可打。
泄露的路径很有意思。源头是 Hacker News 上一条「Tell HN」帖子（用户 petecooper，10 月 20 日 15:20 UTC），自称「可靠消息源」称两个 CVSS 10.0 的 PHP RCE 即将披露、影响 PHP 5 及以后所有版本。发帖人承认没有证据，帖子后来被标记，但截图已经传遍了 X 和 Mastodon。watchTowr 随即确认泄露属实：「我们本来都要等到周四 11am ET。信息泄露了，关于 PHP 的 embargo 零日 RCE 漏洞，我们可以确认是真的。」
这里有个值得注意的细节：泄露本身缩短了补丁的窗口。Embargo（保密期）是厂商和发行版、托管商、安全公司协调的时间窗，让补丁和公告同时发布。一旦严重度和日期泄露，手里已经有漏洞情报的人就知道了自己还有多少时间。PHP 团队也明确表示：「如果任一漏洞细节公开，或出现野外利用证据，我们保留提前发布的权利。」目前还没有观察到野外利用，漏洞也不在 CISA 的已知被利用漏洞目录里。
对管理员来说，动作很明确：明天 14:00 UTC 补丁发布后立即升级 PHP 8；还在跑 PHP 5/7 的，要么尽快迁移到受支持版本，要么做好长期暴露的准备。这次没有可用的临时缓解措施（workaround），补丁就是唯一的防线。这不是一次普通的 0Day 漏洞，而是一个拖了两年的老问题 —— 最终以「内存管理 + 错误处理」两个核心漏洞的形式在 AI 时代爆发。
完整时间线：
2024 年：PHP 做了多年来第一次外部安全审计（Sovereign Tech Agency 资助、OSTIF 组织、Quarkslab 执行）。修复 Quarkslab 报告的问题时，核心开发者发现了 OOM（内存耗尽）问题的最初迹象 —— 这正是后来 CVE-2026-109618 的根源。但修复卡住了：安全团队开发了多个方案，各有取舍 —— 破坏向后兼容、引入新 DoS 风险、或需改动大量无法协调的第三方扩展。共识制团队难以抉择，一拖就是两年。
2026 年 7 月 30 日：安全公司 Calif 开始对 PHP 审计（通过 Patch the Planet 项目）。
8 月 11 日：Calif 研究员 Ryan A 报告无条件远程代码执行（RCE），与 2024 年的 OOM 问题同根因；OpenAI 同日独立报告同一根因。此后还有更多报告跟进。这也解释了为什么最近 PHP 收到的安全报告暴增 ——7 月以来发布了 15 个 CVE，处理了 100 多个无效 / 重复 / 不可复现的报告。AI 在其中扮演了双重角色：一方面 OpenAI Daybreak Red、Claude Mythos 这类工具帮团队验证报告；另一方面，AI 辅助研究也让报告的「数量」爆炸式增长。
10 月 20 日：两个 CVE ID（CVE-2026-109618、CVE-2026-109619）在论坛和社交平台流传，带着错误的时间和错误的 CVSS 分数（流传 10.0，实际 9.2）。PHP 项目被迫提前预公告。随后安全公司 Calif 误发了一段 PoC 视频（展示漏洞对多个目标有效），视频虽删但副本已传开。
PHP 基金会事后发文复盘，解释了为什么这个漏洞这么难修：两个漏洞都藏在 PHP 几乎每个请求都会碰到的部分 —— 内存管理和错误处理。修复难在不能破坏兼容性、不伤性能、不强迫大量第三方扩展改变。