推荐使用 p{han} 匹配所有汉字（含简繁体、日韩汉字及扩展区），比 u4e00-u9fa5 更全面可靠；提取独立中文块应配合环视断言 (?
怎么用正则匹配中文字符（C#）
直接用 u4e00-u9fa5 范围能覆盖大部分常用汉字，但会漏掉扩展区、生僻字、部首、标点（如「〇」「々」「〆」），也不含繁体字里的「臺」「蘋」等。C# 的 Regex 支持 Unicode 类别，更可靠的方式是用 p{Han} ——它匹配所有汉字字符（含中日韩统一汉字及扩展 A/B/C/D/E/F 区），且无需手动维护码位范围。
常见错误：写成 [\u4e00-\u9fa5] 却忘了 C# 字符串里反斜杠要转义，实际得写成 "[\u4e00-\u9fa5]"；更糟的是误用 "u4e00-u9fa5"（没加方括号），结果匹配的是三个独立字符 一、-、（后者是乱码）。
- 推荐写法：
Regex.IsMatch(text, @"[p{Han}]+") - 若只要纯中文（不含空格、标点、英文字母），用
^[p{Han}]+$配合RegexOptions.None - 想排除全角标点？
p{Han}本身不包含「，。！？」等，它们属于p{P}（标点类别），无需额外过滤
为什么 p{Han} 比 u4e00-u9fa5 更靠谱
u4e00-u9fa5 只覆盖基本汉字区（约 2 万字），而 Unicode 6.0+ 中「汉字」分布在多个区块：U+3400–U+4DBF（扩展 A）、U+20000–U+2A6DF（扩展 B）……这些全在 p{Han} 覆盖范围内。C# 的 Regex 引擎（.NET Core 3.0+ / .NET 5+）默认启用 Unicode 模式，p{Han} 开箱即用；旧版 .NET Framework 4.8 也支持，但需确保未开启 RegexOptions.ECMAScript（它禁用 Unicode 类别）。
性能影响极小——p{Han} 是引擎内置的类别表查表操作，比手写长范围（如 u4e00-u9fffu3400-u4dbfU00020000-U0002A6DF）更简洁、更不易出错。
- 扩展 B 区汉字（如「?」U+20000）用
u4e00-u9fa5完全匹配不到 -
p{Han}同时涵盖简体、繁体、日文汉字、韩文汉字（如「明」在中日韩都是同一码位） - 别混淆
p{Han}和p{IsCJKUnifiedIdeographs}：后者是旧名，已弃用，行为相同但可读性差
提取中文字符串的实际写法（带边界处理）
单纯匹配 p{Han}+ 会把「abc你好123」中的「你好」抽出来，但若想排除夹在英文/数字之间的单字（比如「Windows11」里的「W」不是中文，但「微Win」里的「微」要保留），关键在「词边界」逻辑。C# 中 基于 w（即字母、数字、下划线），对中文无效；应改用环视断言。
示例：提取「独立成块」的中文片段（前后都不是汉字）：
string pattern = @"(?
(? 表示前面不能是汉字（负向先行断言）-
(?!p{Han})表示后面不能是汉字（负向后行断言） - 这样「测试123abc」→ 提取「测试」；「微积分」→ 提取整个「微积分」；「αβγ你好δεζ」→ 提取「你好」
- 注意：如果原文有全角空格、换行、制表符，它们不属于
p{Han}，所以不会阻断匹配，符合日常需求
容易被忽略的编码与选项陷阱
正则本身不关心文件编码，但 C# 字符串是 UTF-16，只要源文本正确解码为 string，p{Han} 就能正常工作。真正易踩的坑在 RegexOptions：
- 千万别加
RegexOptions.IgnoreCase：汉字没有大小写，加了无意义，还可能干扰其他子模式 - 避免
RegexOptions.Compiled用于一次性匹配：编译开销大，短文本反而更慢 - 若处理超长文本（如整本书），考虑用
RegexOptions.Singleline让.匹配换行符——但这和中文提取无关，除非你的模式里用了. - 最隐蔽的问题：正则字符串字面量忘记加 @ 符号，导致
"p{Han}"被 C# 解析成"p{Han}"（p 被当转义），必须写成@ "p{Han}"
Unicode 正则的复杂点不在语法，而在你是否意识到「中文」在 Unicode 里不是一个连续区间，而是一组分散又关联的字符集合；靠硬编码范围迟早漏字，p{Han} 是唯一可持续的选择。
