密码哈希 api 正在经历一次并行讨论：add password_bcrypt_wrap 与 add password_bcrypt_sha256 两份内容相近的 bcrypt 预哈希 rfc 同时在进行，提案者自己担心分别投票会产生不理想的结果。
▲ 事件来源页面实时截图：PHP Foundation Discourse（官方论坛）
争议点
讨论集中在 prehash 的命名（sha512 还是 hmacsha512）以及 PHC 字符串格式。bcrypt 的固定 72 字节限制是预哈希方案的动机——长密码先过一次 SHA 再交给 bcrypt。
跟进价值
这是 PHP 基金会 Discourse 上的一手讨论记录，适合跟踪社区在密码哈希 API 上的真实分歧。来源：discourse.thephp.foundation/t/php-dev-rfc-discussion-add-password-bcrypt-wrap/6331
预哈希为什么要单独提 RFC
bcrypt 有 72 字节输入上限，超过部分会被静默截断；同时它不适合直接接收任意长度的口令材料。两份并行讨论的 RFC 试图规范「先对输入做预哈希、再交给 bcrypt」的流程，让长口令与二进制材料得到明确处理。
分歧在哪
主要分歧是预哈希的算法与编码方式是否应写入语言层（涉及向后兼容与互操作性），还是留给用户空间自行约定。无论结果如何，迁移时都要考虑已有哈希的可验证性，避免存量用户无法登录。
迁移时的兼容性
若采用预哈希流程，必须保证存量哈希仍可验证：常见做法是记录哈希版本或前缀标识，登录时按标识选择校验路径，验证成功后按新流程重新哈希，实现平滑迁移。
▲ 官方公告页配图
关键信息
| 项目 | 内容 |
|---|---|
| 类目 | RFC 与需求 |
| 级别 | 中 |
| 日期 | 2026-11-02 |
| 关联编号 | PASSWORD_BCRYPT_WRAP / BCRYPT_SHA256 |
| 影响范围 | 密码哈希 API |
| 核验状态 | 已官方确认 |
来源：https://discourse.thephp.foundation/t/php-dev-rfc-discussion-add-password-bcrypt-wrap/6331
