最稳判断路径含中文的方式是用正则匹配Unicode中文范围：bool hasChinese = Regex.IsMatch(path, @"[u4e00-u9fffu3400-u4dbfuf900-ufaff]");覆盖常用汉字、扩展A区及兼容汉字区，精准且跨平台兼容。
用 Regex.IsMatch 判断路径里有没有中文字符
直接上最稳的判断方式：用正则匹配 Unicode 中文范围。Windows 路径本身允许中文，但业务常需拦截（比如日志归档、文件同步服务不支持非 ASCII 路径）。别用 Encoding.UTF8.GetByteCount(path) != path.Length 这种旁门左道——它会把 emoji、日文、韩文全误判成“中文”，而且对带 BOM 的路径也不可靠。
正确写法：
bool hasChinese = Regex.IsMatch(path, @"[u4e00-u9fffu3400-u4dbfuf900-ufaff]");
-
u4e00-u9fff覆盖常用汉字（基本汉字区） -
u3400-u4dbf补充扩展 A 区（生僻字、古籍用字） -
uf900-ufaff补充兼容汉字区（如全角 ASCII 对应的汉字形变） - 不加
RegexOptions.Compiled——单次调用反而更慢；高频调用才考虑缓存Regex实例
为什么不用 char.IsLetter 或 char.IsSurrogate
这两个方法看起来“语义清晰”，但实际踩坑率极高。中文字符在 .NET 中属于 UnicodeCategory.OtherLetter，而 char.IsLetter('中') 返回 true，看似可用——但问题在于：IsLetter 同时也会返回 true 给日文平假名、俄文字母、阿拉伯数字（某些字体下）、甚至部分数学符号。它不是“是否中文”的判断依据，而是“是否字母类字符”。
-
char.IsSurrogate只能识别代理对（surrogate pair），用于处理超出 BMP 的 Unicode 字符（如某些 emoji），和中文无关 - 用
path.Any(char.IsLetter)会把"C: estファイル.txt"（含日文）也当“有中文”误拦 - 中文路径里混着英文目录名很常见，必须精确到汉字块，不能靠字符分类泛泛而论
验证路径合法性时，中文检查要放在哪一步
路径字符串可能根本就不是合法路径——比如含 <、|、控制字符，或者长度超 260（未启用长路径支持时）。中文检查只是其中一环，顺序错了会导致逻辑漏洞或异常抛出。
- 先用
Path.GetInvalidPathChars()扫描非法字符（如<>|?*） - 再检查长度：
path.Length > 260 && !AppContext.TryGetSwitch("System.IO.UseLegacyPathHandling", out bool useLegacy) - 最后做中文检测——否则前面一步就抛
ArgumentException，中文逻辑根本没机会执行 - 注意：网络路径
\servershare开头的 UNC 路径，Path.GetFullPath会失败，别盲目调用
正则性能和跨平台差异要注意什么
在 .NET 5+ 上，Regex 默认使用基于 Span 的引擎，速度够用；但在 .NET Framework 4.8 或旧版 Mono 上，Regex 编译开销明显，尤其短路径高频调用时。另外，Linux/macOS 文件系统原生支持 UTF-8 路径，但 .NET 的 Regex 在不同运行时对 Unicode 类别的解析行为一致，无需额外适配。
- 避免每次调用都 new
Regex(@"[u4e00-u9fff...]", RegexOptions.Compiled)——静态只读字段缓存一个实例即可 - 如果路径来自用户输入且长度不可控（比如拖拽进来的超长路径），加个
path.Length < 1024快速拒绝，防正则回溯攻击 - 别用
p{Han}——虽然语义更准，但 .NET Framework 不支持该 Unicode 类别，跨版本不兼容
真正难的不是写对正则，是想清楚“中文”在这里到底指什么：是禁止所有 CJK 字符，还是仅限简体中文？要不要放过全角数字和标点？这些边界一旦定错，后面补救成本远高于写一行正则。
