另一份值得关注的 rfc 草案：预备字面量字符串匹配与替换（prepared_literal_string_matching）。提案新增 str\matcher、str\replacer、str\matchresult 三个类与 ext/strmatch 扩展，目标是给「在大量文本中反复匹配固定字面量」的场景一个更快的官方实现。参考实现 pr 25122 已包含 c 代码、构建配置与 phpt 测试。
▲ 事件来源页面实时截图：wiki.php.net（官方 RFC）
进展
RFC 创建于 11 月 2 日，讨论已于 11 月 6 日在 php.internals 启动，尚未合入任何发行版。社区争议集中在命名与命名空间。来源：wiki.php.net/rfc/prepared_literal_string_matching
预备字面量匹配是什么
提案把「对固定字面量做匹配与替换」从运行时提前到编译期：模式在编译阶段预编译为匹配结构，运行时只需扫描输入，省去重复解析与编译的开销。对模板渲染、路由匹配这类高频字面量操作有明显收益。
可能的收益与顾虑
收益是常数级的性能提升与更稳定的内存占用；顾虑是编译产物的可缓存性与跨版本兼容——预编译结构一旦进入 opcache 序列化格式，就需要与运行时版本严格对应。讨论仍在推进中。
性能收益从哪来
字面量模式在编译期转成专用匹配结构后，运行时不再重复编译正则或构造状态机，对高频调用（路由表、模板占位符替换）能直接降低 CPU 占用；代价是编译期工作量与缓存体积增加。
为什么不复用现有优化
str_contains / str_replace 已有一定优化，但对「固定字面量 + 高频调用」仍缺少编译期预编译能力。该提案补的正是这一层，把可预测的工作前移到编译阶段。
▲ 官方索引页截图
关键信息
| 项目 | 内容 |
|---|---|
| 类目 | RFC 与需求 |
| 级别 | 中 |
| 日期 | 2026-11-02 |
| 关联编号 | RFC: prepared_literal_string_matching |
| 影响范围 | 下一个合适的次版本 |
| 核验状态 | 已官方确认 |
来源：https://wiki.php.net/rfc/prepared_literal_string_matching
