Windows路径中绝对禁用的字符是:、<、>、|、?、*共6个；Linux/macOS仅禁止空字节 ，/为唯一分隔符，其余字符均合法；跨平台检测需按系统分支分别检查。
Windows 下哪些字符绝对不能出现在路径里
Windows 文件系统对路径字符有硬性限制，:、<、>、|、?、* 这 6 个是保留字符，任何位置（包括文件名、目录名、完整路径字符串）出现即非法。注意：/ 和 是路径分隔符，本身合法，但混用或结尾多余会导致语义错误，不属于“禁用字符”范畴。
常见误判点：有人用 std::filesystem::path 构造后检查 .empty() 或捕获异常来判断，但这是错的——构造函数对含 ? 或 * 的路径不会抛异常，它只是把它们当普通字符存着；直到真正调用 create_directories() 或 exists() 才可能失败，且错误码不直接对应字符问题。
- 最稳妥方式是手动扫描字符串，检查是否包含上述 6 个字符
-
std::string::find_first_of("?:<>|*") != std::string::npos就能快速命中 - 注意：只检查路径字符串本身，不需提前 normalize 或 replace 分隔符
Linux/macOS 路径中真正危险的是什么
POSIX 系统没有全局“禁用字符表”，但有两个事实约束： （空字节）必然截断路径，/ 是唯一合法分隔符，其他所有字符（包括 :、?、*）在文件名里都合法。所以 C++ 里判断“是否含禁用符”在 Linux 上实际只需检查 。
容易踩坑的是跨平台代码：有人直接复用 Windows 的字符黑名单，在 Linux 上误报 my:file.txt 为非法——其实完全合法。
立即学习“C++免费学习笔记（深入）”；
- 用
strnlen(path.c_str(), path.size()) != path.size()检查隐式 - 或者更直白：
std::count(path.begin(), path.end(), ' ') > 0 - 别忘了：路径开头或中间出现
../、./不是“非法字符”，只是相对路径语义，std::filesystem::weakly_canonical()可处理，但不属于本问题范畴
跨平台统一检测该怎么做
没有银弹，必须区分系统。C++ 标准库不提供 is_valid_path_character() 这种函数，std::filesystem 也刻意回避了字符级校验。正确做法是封装一个函数，内部根据 defined(_WIN32) 分支处理。
示例逻辑：
#ifdef _WIN32
return path.find_first_of("?:<>|*") != std::string::npos;
#else
return std::find(path.begin(), path.end(), ' ') != path.end();
#endif
- 不要用
sizeof(void*) == 8判断平台，用编译宏更可靠 - 如果项目已用 CMake，可在
target_compile_definitions中统一定义PLATFORM_WINDOWS，避免散落_WIN32 - 注意：Windows 的
GetFullPathNameWAPI 会自动过滤某些非法组合（如AUX、CON），但那是设备名规则，和路径字符无关，不在本检测范围内
为什么不能依赖 std::filesystem::path::has_filename() 之类的方法
这些成员函数只做结构解析，不验证字符合法性。std::filesystem::path("foo<bar") 构造成功，.has_filename() 返回 true，.filename().string() 仍返回 "foo<bar"——但你在资源管理器里根本无法创建这个文件。
- Windows Explorer 创建文件时遇到
<直接弹窗报错，错误码是ERROR_INVALID_NAME（123） - 而
std::filesystem::create_directories()对同样路径抛出std::filesystem::filesystem_error，但 what() 字符串不保证包含具体非法字符信息 - 所以运行前静态检查比运行时报错更可控，尤其对用户输入的路径
真正麻烦的是 UNC 路径或长路径前缀（\?），它们放宽了部分限制，但普通应用极少需要主动构造——除非你明确在做备份工具或磁盘扫描，否则按常规路径规则检测就够了。
