PHP处理Unicode字符串的本质是避免字节级误操作，必须用mb_*函数（如mb_strlen、mb_substr）并显式传'UTF-8'参数，正则需加u修饰符，否则易致乱码、偏移或匹配失败。
PHP处理Unicode字符串操作，本质是避免把多字节字符当单字节切分或计数。直接用strlen、substr、strpos这类函数操作中文、emoji或带重音的拉丁字符，大概率出错——不是截断乱码，就是位置偏移。
为什么 strlen("你好") 返回 6 而不是 2
因为strlen只数字节：UTF-8中每个汉字占3个字节，所以"你好"共6字节。这不是bug，是设计使然——PHP原生字符串函数全按字节操作，不感知编码。
- 误用
substr($str, 0, 4)可能切在汉字中间，输出乱码字节序列（如"你"） -
strpos($str, "好")返回的偏移量是字节位置，不是字符位置，后续用它做substr会错位 - 数据库字段长度限制（如
VARCHAR(10)）按字符算，但strlen结果不能直接拿来比对
必须用 mb_* 函数替代原生函数
所有涉及长度、截取、查找、大小写、分割的操作，只要字符串含非ASCII字符，就得换mb_*系列函数，并显式传入'UTF-8'编码参数。
-
mb_strlen($str, 'UTF-8')→ 正确返回字符数（"你好" = 2） -
mb_substr($str, 0, 2, 'UTF-8')→ 安全截前两个字符，不会劈开汉字 -
mb_strpos($str, "好", 0, 'UTF-8')→ 返回字符偏移（不是字节），可用于后续mb_substr -
mb_strtolower($str, 'UTF-8')→ 支持土耳其语、希腊语等特殊小写规则，strtolower会失效
漏传'UTF-8'参数很危险：mb_strlen($str)会 fallback 到mb_internal_encoding()值，而这个值未必是UTF-8，尤其在老项目里容易被忽略。
立即学习“PHP免费学习笔记（深入）”；
正则匹配 Unicode 字符要加 u 修饰符
不用/u，preg_match就把字符串当字节流处理，.不匹配汉字，\w不包含中文，\p{L}直接报错。
- 匹配任意Unicode字母：
preg_match('/\p{L}/u', $str) - 匹配中文、日文、韩文字符：
preg_match('/[\x{4e00}-\x{9fff}]/u', $str) - 替换所有非ASCII空白（含不间断空格{00a0}）：
preg_replace('/\s+/u', ' ', $str)
注意：\s在/u模式下才包含U+00A0等Unicode空白；不用/u，它只认ASCII空格、制表符。
过滤不间断空格 u00a0 的坑与解法
trim($str)清不掉U+00A0，$str === " "也判不等——因为它根本不是空格（U+0020），而是独立的Unicode字符。
- 错误写法：
str_replace(chr(160), '', $str)→chr(160)生成单字节\xA0，在UTF-8里不等于U+00A0（实际是\xC2\xA0） - 正确写法：
str_replace("\u{00a0}", '', $str)→ PHP 7.0+支持Unicode转义，精准匹配 - 更通用：
preg_replace('/[\x{00a0}\x{2000}-\x{200f}\x{2028}\x{2029}]/u', '', $str)→ 一并清理常见Unicode空白
最易被忽略的是：前端粘贴内容常带U+00A0，后端不做清理就存库，后续用==或IN查询会静默失败——看着相等，实则字节不同。
