Windows路径中绝对禁止的字符是<、>、:、"、/、、|、?、*及ASCII控制字符（U+0000–U+001F）和DEL（U+007F），需按UTF-16逐码元校验；Linux/macOS仅禁止' '和非分隔符'/'，其余字符合法但受shell或应用层限制。
Windows 下哪些字符绝对不能出现在路径里
Windows 文件系统（NTFS、FAT32）明令禁止在文件名或路径组件中使用 <、>、:、"、/、、|、?、* 这 9 个字符，连带 ASCII 控制字符（U+0000–U+001F）和 DEL（U+007F）也不允许。注意： 是路径分隔符，但作为文件名的一部分（比如出现在中间）是非法的；/ 同理——即使 Windows API 有时能容忍它，但 Shell、Explorer 和多数工具会直接拒绝。
实操建议：
- 用
std::any_of遍历字符串每个char，检查是否属于上述 9 字符集合或0x00–0x1F、0x7F - 不要只查
std::string，若路径含宽字符（如std::wstring），需转换为 UTF-16 编码后逐wchar_t判断；Windows API 接口（如CreateFileW）实际校验的是 UTF-16 码元 - 注意：空字符
' '在 C++std::string中合法存在（非结尾），但它会导致c_str()截断，这类字符串传给 WinAPI 会出错
Linux/macOS 路径字符限制其实更简单
POSIX 文件系统（ext4、APFS、ZFS 等）本身**不禁止任何 Unicode 字符**，唯一硬性限制只有 ' '（空字节）和 '/' —— 因为前者是 C 字符串终止符，后者是路径分隔符。也就是说，foo:bar、test*、file|name 在 Linux 下完全合法，能创建、读写、ls 显示。
但要注意真实约束来自上层：
立即学习“C++免费学习笔记（深入）”；
- Shell 解析时，
*、?、[、]、~、$、`、;、&、|、、<code>>、(、)、{、}、TAB、newline等会被 shell 展开或分词，不是文件系统禁用，而是 shell 行为导致“看起来打不开” - 某些 GUI 工具（如 Nautilus、Finder）或备份软件会主动过滤含
?、*的文件名，这是应用层策略，非系统强制 - 如果你用
std::filesystem::path构造路径，它不会报错，但后续调用exists()或create_directories()仍可能失败——失败原因不是字符非法，而是目标文件系统/挂载选项（如noexec、utf8模式）或权限问题
跨平台判断函数怎么写才靠谱
别试图写一个“通用非法字符表”——Windows 和 POSIX 的语义完全不同。正确做法是按目标平台做条件判断，并且区分「路径合法性」和「可操作性」：
- Windows 场景：优先用
GetFullPathNameW+PathIsRelative等 WinAPI 做预检；它会识别CON、AUX、NUL等保留名，以及末尾空格/点等隐式非法形式 - POSIX 场景：真正该检查的是
' '和'/'是否出现在非分隔位置；其余字符交给open()或stat()系统调用去报错更可靠 - C++20
std::filesystem不提供字符合法性校验接口，path::generic_string()返回的字符串仍可能含非法字符；不要依赖path::has_filename()或is_absolute()来代替字符检查 - 如果路径来自用户输入，务必先做 trim（去掉首尾空格/不可见控制符），再检查——Windows Explorer 会静默删掉末尾空格，但命令行不会
容易被忽略的边界情况
真正踩坑的往往不是 * 或 ?，而是这些：
-
\?C:path这类 NTFS 扩展路径前缀下，校验规则不同：允许长路径、允许末尾空格/点，但依然禁止< > : " |等 9 字符 - 网络路径如
\servershare ile，反斜杠是必需分隔符，但file<name仍非法——校验要作用于每个路径组件（split by'\'或'/'后单独检查） - Unicode 中的零宽空格（U+200B）、从右向左标记（U+200F）、替代字符（U+FFFD）等，在文件系统层面虽未明确禁止，但会导致
strcmp失败、Git 无法追踪、IDE 显示异常，建议一并过滤 - Linux 下挂载了 Windows 共享（Samba/CIFS）时，服务端（Windows）仍执行自己的字符校验——此时客户端报
Invalid argument错误，根源在远端，不是本地路径有问题
最稳妥的做法：在目标平台调用最小原子操作（如 CreateFile / open）前，先做平台特化字符筛查，把明显非法的拦在系统调用之前；但永远留一手——捕获 std::filesystem::filesystem_error 或 errno，因为最终解释权在内核和驱动。
