最可靠方式是用preg_match('/[\x{4e00}-\x{9fff}\x{3400}-\x{4dbf}]/u', $str) === 1，必须加u修饰符，覆盖基本汉字与扩展a区，避免误判emoji、全角ascii等非中文字符。
用 preg_match 判断字符串是否含中文最可靠
直接用正则匹配 Unicode 中文范围，是 PHP 里最通用、最不容易漏判的方式。中文字符在 Unicode 中主要落在 \u4e00-\u9fff（基本汉字）和 \u3400-\u4dbf（扩展 A）、\u20000-\u2a6df（扩展 B）等区间，但实际项目中，覆盖前两个区通常就够用了。
实操建议：
- 写法：
preg_match('/[\x{4e00}-\x{9fff}\x{3400}-\x{4dbf}]/u', $str)，注意末尾的u修饰符必须加，否则 UTF-8 字节流会匹配失败 - 返回值是
1（匹配到）或0（没匹配到），不是布尔值，别直接用于if ($result)这种松散判断，建议显式写成if (preg_match(...) === 1) - 如果字符串可能为空或非字符串类型，先用
is_string($str) && $str !== ''做前置校验，避免警告
mb_ereg 能用但不推荐
mb_ereg 看起来更“多字节友好”，但它依赖系统级的正则引擎（如 libmbfl），在不同 PHP 版本或编译选项下行为不一致，PHP 8.0+ 已标记为废弃，部分 Docker 镜像甚至默认不启用 mbstring 扩展的正则支持。
常见错误现象：
- 本地开发能跑，线上报
Warning: mb_ereg(): mbregex compile err - 匹配结果忽有忽无，尤其遇到 emoji 或生僻字时
- 升级 PHP 后直接报
Call to undefined function mb_ereg()
结论：别用 mb_ereg，哪怕文档里写着“支持多字节”，现实兼容性太差。
别用 strlen 和 mb_strlen 差值判断
有人想“中文占多字节，所以如果 strlen($s) > mb_strlen($s) 就说明有中文”，这逻辑在纯 ASCII + GBK 场景下偶然成立，但在 UTF-8 下完全不可靠。
原因：
- UTF-8 中，中文确实是 3 字节，但 emoji（如 ?）是 4 字节，某些符号（如 ①）也是 3 字节但不是中文
- 全角 ASCII 字符（如 ＡＢＣ）也占 3 字节，会被误判
- 空格、换行、BOM 头等都影响字节长度，导致假阳性
这种写法看似省事，实则埋了隐性 bug，上线后可能把日文、韩文、甚至带 emoji 的用户昵称当成“含中文”来拦截。
性能与边界场景提醒
对单次判断来说，preg_match 开销几乎可以忽略；但如果在循环里高频调用（比如处理上万条日志），可考虑提前编译正则：$re = '/[\x{4e00}-\x{9fff}]/u'; 然后复用。
容易被忽略的点：
- 半宽/全宽数字、字母、标点（如 １２３、ＡＢＣ、，。！）不属于中文 Unicode 区，不会被上面正则捕获——这是对的，它们不是中文字符
- 繁体字、异体字（如「為」「爲」）都在
\u4e00-\u9fff内，无需额外处理 - 如果业务明确要包含日文平假名/片假名，得手动加区间，比如
\x{3040}-\x{309f}，但这就不再是“判断是否含中文”了
真正要拦的，是用户输入里混入中文的场景，比如邮箱用户名、数据库字段名、API 参数名——这时候只认汉字区间，反而更准确。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
