PHP字符串反转唯一标准函数是strrev()，它按字节翻转、不支持UTF-8多字节字符；正确处理中文等需用mb_substr()+array_reverse()等自定义方案，并注意BOM清理与mbstring扩展启用。
PHP 字符串反转用 strrev()，不是 reverse() 或其他名字
PHP 没有叫 reverse()、flip() 或 invert() 的内置函数。唯一标准且安全的字符串反转函数是 strrev()，它只接受一个 string 参数，返回翻转后的新字符串，原字符串不变。
常见错误现象：Call to undefined function reverse() 或 Array to string conversion（误把数组当字符串传进去）。
-
strrev()只处理字节序列，对 UTF-8 多字节字符（如中文、emoji）会乱码 —— 它不是按“字符”翻转，而是按“字节”翻转 - 空字符串
''、null、false传入会触发警告或返回意外结果，建议先用is_string()校验 - 性能上毫无压力，哪怕几 MB 的纯 ASCII 字符串也很快；但 UTF-8 场景下别硬用，后面会说替代方案
UTF-8 字符串要真正“按字符”反转，得自己拆字节再拼
因为 strrev() 不认识 UTF-8 编码规则，直接反转会导致中文变成乱码（比如 "你好" 变成 "好你" 这类）。必须用支持多字节的函数手动切分再反转。
实操建议：用 mb_strlen() + mb_substr() 循环取单个字符，存进数组，再用 array_reverse() 和 implode() 拼回去。
立即学习“PHP免费学习笔记（深入）”；
- 别用
preg_split('//u', $str)—— 在超长字符串下正则开销大，还可能因 PCRE 栈溢出失败 - 确认当前环境已启用
mbstring扩展（php -m | grep mbstring），否则mb_*函数全不可用 - 如果只是偶尔处理短文本（比如昵称、标签），用
preg_match_all('/./u', $str, $matches)更简洁，但注意$matches[0]是匹配结果数组
strrev() 和自定义 UTF-8 反转函数的性能差距在哪儿
纯 ASCII 下 strrev() 是 C 实现，比任何 PHP 层循环快 10 倍以上；但一旦涉及 UTF-8，strrev() 结果错误，再快也没用。真正对比的是「正确但慢」和「快但错」——不能只看 benchmark 数字。
- 1000 个汉字字符串，
strrev()耗时约 0.002ms，但输出乱码；自定义mb_*方案约 0.08ms，可接受 - 超过 10 万字符时，
mb_substr()循环会明显变慢（每次都要重新扫描 UTF-8 起始字节），此时建议改用iconv('UTF-8', 'UCS-4LE', $str)转成定长编码再反转，再转回（更底层，但代码稍重） - 别在循环里反复调用
mb_internal_encoding()—— 它不改变行为，只影响部分旧函数，默认 UTF-8 就够用
别忘了检查输入来源：$_GET、$_POST、JSON 解析后的字符串可能含 BOM 或不可见控制符
用户提交的字符串开头带 UTF-8 BOM（\xEF\xBB\xBF）时，strrev() 会把它翻到末尾，导致后续 json_decode() 或正则匹配失败；而自定义反转若没 trim BOM，也会把 BOM 当作第一个“字符”参与反转。
- 用
ltrim($str, "\xEF\xBB\xBF")清掉开头 BOM（注意：只清开头，BOM 不该出现在中间） - 从数据库读出的字符串一般没问题，但用
file_get_contents()读文件时，尤其 Windows 记事本保存的 UTF-8 文件，极大概率带 BOM - 用
json_encode()输出前做一次反转测试？别。先确保输入干净，反转只是中间步骤，不是兜底手段
