本文目录导读：
- 发起阶段（Pre-Discussion）
- 撰写 RFC 文档（Drafting）
- 公开讨论（Discussion）
- 投票阶段（Voting）
- 结果与实现（Implementation）
- PHP 版本发布
- 重要补充：非核心代码的 RFC
- 快速总结流程图
PHP 的 RFC（Request for Comments，请求评论）流程是一个社区驱动的、开放透明的提案机制，用于修改 PHP 语言本身（核心语法、函数、类等），而不是用于修改 PHP 应用程序代码。
如果你是想了解如何提交一个 RFC 来改变 PHP，以下是标准的完整流程（依据 PHP 官方 RFC 规范）：
发起阶段（Pre-Discussion）
- 想法初步验证：在动手写正式 RFC 之前，建议先在 PHP Internals 邮件列表（internals@lists.php.net）发帖讨论你的想法，这一步非常关键，可以让你了解社区是否感兴趣,以及是否存在技术障碍。
- 寻找支持者：RFC 需要至少一名 PHP 核心开发者或活跃的社区成员作为“赞助人”（Sponsor），帮助你将 RFC 文档规范化并推进流程。
撰写 RFC 文档（Drafting）
在 PHP 官方仓库（GitHub 上的 php/php-rfcs 仓库）中创建 Fork 并添加你的提案文件，或直接在本地编写，RFC 文档通常包含以下必填部分：
- 清晰描述改动。
- 状态：
Draft（草稿）、Under Discussion（讨论中）、Voting（投票中）、Accepted（已接受）、Declined（已拒绝）等。 - 目标版本：提议合并到哪个 PHP 版本（如 8.4）。
- 补丁（Patch）：强烈建议提供初步的实现代码（C 语言或 PHP 内部扩展），没有补丁的 RFC 通常不会被认真考虑。
- 说明：为什么要引入这个改动？解决了什么问题？
- 向后兼容性影响：这会影响现有代码吗？如果不兼容,需要明确说明理由。
- 表决（Vote）：需要覆盖的范围（如 PHP 核心库、标准库等）。
公开讨论（Discussion）
- 将 RFC 链接发到 PHP Internals 邮件列表,正式进入讨论期。
- 讨论时长：通常至少要有 2 周 的讨论时间。
- 修订：根据社区反馈修改 RFC 内容和补丁，RFC 必须保持更新,特别是响应反对意见。
投票阶段（Voting）
满足以下条件后进入投票：
- 讨论成熟：没有主要的技术障碍或争议。
- 征求投票：RFC 作者在邮件列表请求开始投票。
投票规则（关键点）：
- 投票者资格：只有 PHP 核心开发者（Core Developers）、活跃的 PHP 内部成员以及经认证的 PHP 项目成员有投票权。
- 投票门槛：通常需要 2/3（67%） 的赞成票才算通过。
- 投票通道：主要使用
viper7或wiki.php.net上的投票系统。 - 时长：通常为 2 到 4 周。
- 投票要求：需要明确列出所有选项（通常是“赞成”和“反对”）。
结果与实现（Implementation）
- 如果通过：RFC 作者或志愿者需要积极地将补丁合并到 PHP 主仓库（通常是下一个发布周期的分支）。
- 如果被拒绝：该提案关闭，作者可以根据反馈修改后重新提交,但通常强调不要重复提交完全相同的提案。
- 不活跃处理：如果投票通过但长期无人实现，RFC 可能会被标记为“Stalled”（停滞）并最终被撤销。
PHP 版本发布
只有合并到主分支的变更才会出现在未来的 PHP 正式版本中，如果你希望在 PHP 8.5 中发布，那么该 RFC 必须在 8.5 的冻结特性日期（通常在 RC 阶段前）之前被接受并合并。
重要补充：非核心代码的 RFC
如果你的想法是修改一个 用户态扩展（如 phpseclib、Guzzle）而不是 PHP 核心本身，那么不需要走 RFC 流程，PHP 的 RFC 流程严格针对：
- PHP 语言语法（如新增
?->运算符、str_contains函数）。 - 核心标准库（SPL）。
- 内置函数行为。
快速总结流程图
想法验证 → 邮件列表讨论 → 撰写 RFC 文档 → 正式发布讨论 → 投票（需67%+） → 合并补丁 → 发布
↑ ↓
└──────────── 根据反馈修改 ────────────────退出（拒绝）实践建议：如果你是新参与者，不要一开始就提交大型语言改动，先尝试提交小型的、高价值的标准库函数（str_contains 这类），学习流程，建立信誉,参与讨论和代码审阅是获得投票支持的基础。
