用 preg_match 判断字符串含中文最可靠
正则匹配是 php 里判断中文最通用、最可控的方式，mb_detect_encoding 不靠谱，iconv 转码易误判，而 preg_match 直接锚定 Unicode 中文区间，不依赖编码猜测。
常见错误是写成 /[x4e00-x9fa5]/u —— 这只覆盖了基本汉字块，漏掉扩展 A/B 区（比如“?”、“?”）、标点（如「」『』）、平假名片假名等广义“中文环境常用字符”。
- 推荐用
/[p{Han}p{Common}p{InCJK_Symbols_and_Punctuation}]/u，但需确保 PCRE 启用了 UTF-8 和 Unicode 属性支持（PHP 7.3+ 默认开启） - 更轻量且兼容性更强的写法是：
/[x{4e00}-x{9fff}x{3400}-x{4dbf}x{20000}-x{2a6df}}x{2a700}-x{2b73f}}x{2b740}-x{2b81f}}]/u（覆盖常用汉字+扩展A+B+C区） - 如果只要判断“是否含任意汉字”，单条
preg_match('/[x{4e00}-x{9fff}]/u', $str)已够用，别过度追求全覆盖
mb_strlen 和 strlen 差值不等于中文个数
有人用 mb_strlen($str, 'UTF-8') != strlen($str) 推断含中文，这是错的——它只能说明字符串含多字节字符，可能是中文，也可能是 emoji（?）、日文（こんにちは）、甚至某些拉丁扩展字符（ç、ñ）。
这个技巧在纯 ASCII + 中文混合场景下偶然有效，但一旦引入 emoji 或其他 UTF-8 多字节符号，就会误报。
立即学习“PHP免费学习笔记（深入）”；
- emoji 占 4 字节，
strlen比mb_strlen大 3，也会触发“疑似中文”逻辑 - 日文假名同样多字节，
mb_strlen($str, 'UTF-8')返回正确字符数，但和中文无关 - 真正想统计中文字符数？必须用
preg_match_all('/[x{4e00}-x{9fff}]/u', $str, $matches)，再取count($matches[0])
注意 mb_ 函数的编码参数默认不是 UTF-8
很多 PHP 环境默认内部编码是 ISO-8859-1 或空，mb_detect_encoding 不指定候选编码列表时可能返回错误结果，mb_substr 不传第三个参数会按默认编码截断，导致乱码或崩溃。
哪怕你确定输入是 UTF-8，也要显式写全：mb_internal_encoding('UTF-8')，否则 mb_regex_encoding()、mb_strlen() 行为不可控。
-
mb_detect_encoding($str, ['UTF-8', 'GB2312', 'GBK'], true)的第三个参数true很关键：强制只返回能完整识别的编码，避免模糊匹配 - 不设
mb_internal_encoding，mb_ereg类函数可能直接报Warning: mbregex compile Error - CLI 模式下该设置尤其容易被忽略，Web 环境有时靠 php.ini，但脚本内显式声明更稳妥
简单场景用 ctype_print 反向排除也行
如果你只是想“过滤掉纯英文数字空格的字符串”，可以反过来：先剔除所有可打印 ASCII 字符，再看剩下啥。比正则更快，适合高频短字符串判断。
但注意，ctype_print 只认 ASCII 可打印范围（32–126），对中文、制表符、换行符都返回 false，所以不能直接用它“检测中文”，而是用来辅助判断“非纯 ASCII”。
-
$clean = preg_replace('/[x20-x7E]/', '', $str);清掉所有 ASCII 可打印字符后，若!empty($clean)，说明含非 ASCII 内容（可能是中文，也可能不是） - 配合
mb_strlen($clean, 'UTF-8') > 0可确认它是有效 UTF-8 字符，而非乱码 - 这招在日志清洗、表单预检等低精度需求里省 CPU，但别拿它做内容审核依据
真正难的不是写对一行正则，而是想清楚你要拦截的是“所有中文字符”，还是“影响排版的 CJK 字符”，或是“用户输入里混入了非拉丁文字”——边界没定义清，代码越写越像补丁。