Path.GetInvalidFileNameChars() 返回 Windows 禁止用于文件名或路径段的字符数组（如 ''、':'、'*' 等），仅适用于单个文件名/目录名校验，不包含空格、点等合法字符，也不覆盖保留名、末尾空格/点、长度限制等问题。
Path.GetInvalidFileNameChars() 返回哪些字符
它返回一个 char[]，包含 windows 系统禁止用于文件名或路径段的所有字符，比如 ''、'/'、':'、'*'、'?'、'"'、'、<code>'>'、'|'。注意：这个数组不包含空格、点（'.'）、下划线等合法字符，也不检查长度或保留名（如 "con"、"prn"）。
常见错误现象：
– 直接用 Contains 检查整个路径字符串是否含非法字符，却忘了路径中允许出现 '' 和 '/' 作为分隔符（尤其在 Path.Combine 后的完整路径里）；
– 把 Path.GetInvalidFileNameChars() 当成“所有非法字符全集”，漏掉保留设备名、末尾空格/点、长路径限制等问题。
- 只对**单个文件名或目录名**（即路径的最后一段）做此检查才合理
- 不要对完整路径（如
"C: ooar.txt"）直接遍历检查，否则会误报'' - 该方法返回的字符集是静态的，不随 .NET 版本变化，但不覆盖 NTFS 元数据限制（如流名
:Zone.Identifier）
用 Path.GetInvalidPathChars() 判断路径字符串结构是否合法
Path.GetInvalidPathChars() 返回的字符比文件名更宽泛，包含 ' '、控制字符等，但它依然**不等于路径合法性判断的全部**。它的作用只是辅助识别明显非法字符，不能替代实际验证。
使用场景：
– 在接收用户输入的路径前做快速预筛（比如 UI 文本框 on-change 校验）；
– 配合 Path.GetDirectoryName() 和 Path.GetFileName() 分离后，分别检查各段。
-
Path.GetInvalidPathChars()包含' '和 ASCII 控制符（– - 它不包含
'.'或空格，但末尾带空格或点的文件名在 Windows 上会被系统自动截断（如"test.txt "→"test.txt"），属于隐式不合法 - 跨平台代码要注意：Linux/macOS 不限制
':'，但 .NET 的这个 API 始终返回 Windows 规则
真正可靠的路径合法性验证必须调用 Path.GetFullPath()
仅靠字符检查远远不够。Path.GetFullPath() 是最接近“操作系统级校验”的托管方法：它会解析相对路径、展开 ".."、检查盘符是否存在（部分情况下）、拒绝空字符串和纯空白，并抛出 ArgumentException 或 IOException。
示例：try { Path.GetFullPath("C:\temp\..\..\"); } → 成功返回 "C:\"；Path.GetFullPath("CON") → 抛出 ArgumentException（因为 "CON" 是保留名）；Path.GetFullPath("a?.txt") → 抛出 ArgumentException（含通配符）。
- 它能捕获
Path.GetInvalidFileNameChars()漏掉的关键问题：保留设备名（"AUX"、"NUL"等）、以空格或点结尾、包含".."越界（如"...."超出根目录） - 性能影响极小，纯内存计算，不访问磁盘（除非启用了某些 UNC 或网络路径解析策略）
- 注意：它不会检查目标目录是否可写、是否存在父目录，也不保证后续
File.Create()一定成功
生产环境建议组合使用三步校验
单独依赖任一方法都容易翻车。真实项目里，尤其处理用户上传的文件名或配置路径时，得把三者串起来用。
- 先用
string.IsNullOrWhiteSpace()排除空值 - 再用
Path.GetFullPath()做结构合法性兜底（捕获保留名、通配符、越界".."） - 最后拆解为
Path.GetFileName()，用Path.GetInvalidFileNameChars()检查是否含非法字符（确认不是"COM1.txt"这种看似合法实则受限的命名）
容易被忽略的点：Windows 对路径总长度限制为 260 字符（MAX_PATH），但启用长路径支持后，.NET 6+ 默认绕过该限制——而 Path.GetFullPath() 在长路径开启前仍可能因内部缓冲区截断导致行为异常。所以，如果目标环境不确定是否启用 LongPathsEnabled，最好额外加一层 path.Length 提醒或日志记录。
