PHP中ucfirst()仅将字符串首ASCII字母大写，对中文、emoji、数字开头等无效；多单词需ucwords()，但只认空格分隔；UTF-8文本须配合mb_*函数并设mb_internal_encoding('UTF-8')。
PHP里让字符串首字母大写，用 ucfirst() 最直接
它只改第一个字符，不管后面是什么。比如 "hello world" 变成 "Hello world"，"123abc" 还是 "123abc"（数字开头，首字符不是字母，不处理）。
常见错误是以为它能处理多单词或中文——不能。ucfirst() 对中文、emoji、全角字符完全无效，遇到 "你好 world" 会原样返回，因为中文字符在 UTF-8 下占多个字节，ucfirst() 只看第一个字节，根本识别不出“字母”。
- 只作用于 ASCII 字母 A–Z（英文大写范围），对其他语言字母（如 à, ñ, ą）不敏感
- 输入为空字符串或
null时返回空字符串，不会报错但要注意后续逻辑是否依赖非空 - 如果传入的是数字或符号开头的字符串（如
"2nd place"），结果不变，别误以为函数失效
要每个单词首字母都大写，得用 ucwords()
这个函数按空格切分，对每个“单词”调用 ucfirst()。所以 "hello world" → "Hello World"，但 "hello—world" 还是 "Hello—world"（因为中间是短横，不是空格）。
容易踩的坑是默认只认空格为分隔符。如果你的数据来自表单或 CSV，可能混着制表符、全角空格、换行符，ucwords() 就漏掉那些“单词”了。
立即学习“PHP免费学习笔记（深入）”；
- 分隔符仅限 ASCII 空格（U+0020），不识别
\t、\n、全角空格（U+3000） - 对
"foo-bar"或"user_id"无效，需要先替换分隔符再调用，比如：ucwords(str_replace(['-', '_'], ' ', $str)) - 同样不支持 UTF-8 多字节字符，中文词组如
"你好 世界"会变成"你好 世界"（没变化），因为“你好”不被识别为“单词”
处理中文或混合文本，必须自己写逻辑 + mb_* 函数
PHP 原生大小写函数全基于单字节，UTF-8 中文、日文、韩文、带重音的拉丁字母都得靠 mb_strtoupper() / mb_substr() 配合手动切分。
比如实现“中文+英文混合字符串的首字母大写”，得先判断首字符是否为 ASCII 字母，否则跳过；或者统一转成 UTF-8 编码后逐字节/字符扫描——但注意：汉字没有“大小写”概念，所谓“首字母大写”在这种场景下本身语义模糊，实际需求往往是“英文部分首字母大写，中文照旧”。
- 务必设置正确的内部编码：
mb_internal_encoding('UTF-8')，否则mb_*函数行为不可预测 -
mb_substr($str, 0, 1)取第一个字符才安全；用$str[0]会取到 UTF-8 第一个字节，大概率是乱码 - 不要试图用
ucfirst(mb_strtolower($str))来“保险”，mb_strtolower()对中文无影响，但对某些西欧字符（如德语 ß）可能有兼容性问题
性能和兼容性提醒：别在循环里反复调用 ucwords() 处理长文本
它内部做字符串分割和拼接，对超长字符串（比如几万字符的用户评论）会有明显开销。如果只是想格式化用户名或标题，没问题；但要是批量处理日志、导出数据，就得权衡。
PHP 8.0+ 对 mb_* 函数做了不少优化，但老版本（如 7.2）在处理含大量 emoji 的字符串时，mb_strlen() 可能比预期慢 3–5 倍——这不是你代码的问题，是底层 ICU 库的限制。
- 如果只是校验或展示用，优先考虑前端 CSS 的
text-transform: capitalize，服务端少一层转换 - PHP 8.2 开始，
ucfirst()和ucwords()对 ASCII 输入做了 fast-path 优化，但 UTF-8 路径仍走通用逻辑 - 线上环境若用的是 Alpine Linux + musl libc，某些
mb_*函数在极少数 locale 下会返回 false，建议加if (false === $result) { /* fallback */ }
事情说清了就结束。真正麻烦的从来不是函数怎么写，而是你手里的字符串到底是什么编码、从哪来、有没有隐藏控制字符——这些不查清楚，函数再对也没用。
