php中字符串大小写转换需区分ASCII与utf-8：strtolower/strtoupper仅支持ascii，处理中文或重音字符会出错；应使用mb_strtolower($str, ‘utf-8’)和mb_strtoupper($str, ‘utf-8’)确保正确性。
PHP 字符串转小写用 strtolower，但中文、UTF-8 会出错
直接调用 strtolower 处理中文或带重音符号的西欧字符（如 é, ñ），结果不变甚至乱码——它只认 ASCII 字节，对多字节 UTF-8 字符完全失效。
常见错误现象：strtolower('你好') 返回原字符串；strtolower('café') 变成 caf。
- 必须确认当前字符串编码是 UTF-8，且 PHP 内部默认编码未被修改（
mb_internal_encoding()应为UTF-8） - 改用
mb_strtolower($str, 'UTF-8')，这是唯一可靠方案 - 如果项目已全局设好
mb_internal_encoding('UTF-8')，可省略第二个参数，但显式传入更稳妥 -
strtolower比mb_strtolower快约 3–5 倍，纯英文场景可继续用，但一旦混入非 ASCII 字符，就别碰
PHP 字符串转大写用 strtoupper，同样不支持 UTF-8
和 strtolower 是一对“ASCII 限定兄弟”，strtoupper('İstanbul') 会把带点大写 I（İ）变成错误的 I，丢失土耳其语大小写规则。
使用场景：处理用户输入的英文表单字段、生成全大写标识符（如数据库字段名）时，若输入来源不可控（比如含粘贴文本），必须防这坑。
立即学习“PHP免费学习笔记（深入）”；
- 优先用
mb_strtoupper($str, 'UTF-8') - 注意：某些语言有特殊大小写映射（如德语 ß 没有对应大写，希腊语 ΐ 有复杂变体），
mb_*函数按 Unicode 标准处理，比strtoupper更准 - 不要依赖
setlocale(LC_CTYPE, ...)配合strtoupper——PHP 的 locale 支持不稳定，跨平台尤其容易失效
大小写转换失败的典型报错和调试方法
没有直接报错，但你会看到输出和预期不符，比如表单提交后搜索不到数据、缓存 key 不命中。本质是字符串比较失败（== 或 in_array 判定失准）。
- 先用
bin2hex($str)看原始字节：如果中文显示为e4bda0e5a5bd（UTF-8 编码），却用strtolower处理，说明肯定出问题 - 检查
mb_detect_encoding($str)，返回FALSE或ASCII而你明明传了中文？那字符串可能已被截断或损坏 - 确认文件保存编码是 UTF-8 无 bom——BOM 会导致
mb_*函数误判首字节，引发奇怪偏移
性能与兼容性取舍：什么时候还能用 strtolower
如果你 100% 确保输入只有 a–z、A–Z、0–9 和基本符号（比如做 API 的 Token 格式化、http header 名标准化），strtolower 安全、快、无需额外扩展。
- 服务器没开
mbstring扩展？strtolower是唯一选择，但此时必须过滤掉所有非 ASCII 输入（例如用正则/^[a-zA-Z0-9_-.]+$/校验） - PHP 8.2+ 开始，
mbstring已是默认启用扩展，没理由回避 - 别为了“省一个函数调用”在核心逻辑里硬上
strtolower——一次隐式编码错误引发的线上问题，远比多几微秒执行时间代价高
真正麻烦的不是函数选哪个，而是你根本没意识到字符串有编码这回事。只要涉及用户输入、文件读取、数据库字段，先问一句：这个字符串的编码到底是什么？