wiki.php.net 上新增了一份 rfc 草案：grapheme_str_pad。它为 ext-intl 扩展新增一个按字素簇（grapheme cluster）填充字符串的函数，解决「按显示宽度填充多字节字符串」这一类问题。0.1 初稿于 11 月 3 日提交，0.2 版在 11 月 4 日澄清了错误条件与填充片段合并规则，投票尚未开始。
▲ 事件来源页面实时截图：wiki.php.net（官方 RFC）
与 mb_str_pad 的区别
mb_str_pad 按显示宽度处理，而这份 RFC 按字素簇处理——对 emoji、组合字符这类「多个码点算一个字符」的场景，两者结果不同。建议跟踪投票状态，并区分两个函数的适用场景。来源：wiki.php.net/rfc/grapheme_str_pad
按字形簇填充的意义
str_pad() 以字节或码位为单位，遇到组合字符（基字符 + 变音符号）或 emoji（多码位序列）会在字形中间截断，产生视觉上的乱码或孤立符号。grapheme_str_pad() 以字形簇为边界填充，保证显示完整性，对多语言界面与用户名补位这类场景尤其有用。
当前的讨论焦点
提案讨论集中在 API 命名与参数顺序是否与 str_pad 保持一致、填充宽度的语义（字形簇数还是显示宽度）、以及与 mbstring/intl 现有函数的关系。若通过，目标版本为 PHP 8.7。
与现有多字节函数的差异
mb_str_pad 按码位计数，遇到组合字符仍可能截断字形；grapheme_str_pad 按字形簇计数，视觉长度与填充结果一致。对含 emoji 或阿拉伯文等复杂文字的用户名、标签做对齐时应优先考虑后者。
命名与边界行为的争议
与 str_pad 保持一致的参数顺序是社区主要诉求，但字形簇计数与字节计数在边界上差异明显（空字符串、负长度、非法 UTF-8），提案需要逐条明确，否则容易埋下兼容性争议。
▲ 官方索引页截图
关键信息
| 项目 | 内容 |
|---|---|
| 类目 | RFC 与需求 |
| 级别 | 中 |
| 日期 | 2026-11-03 |
| 关联编号 | RFC: grapheme_str_pad |
| 影响范围 | 未来 PHP 版本 / ext-intl |
| 核验状态 | 已官方确认 |
来源：https://wiki.php.net/rfc/grapheme_str_pad
