Windows下绝对不能出现在文件路径中的字符是:、、/、*、?、"、<、>、|这9个（含补充的<、>），任何位置出现均非法，需对整个路径字符串而非仅文件名扫描校验。
Windows下哪些字符绝对不能出现在文件路径里
Windows对路径字符限制最严格，:、*、?、"、、<code>>、| 这7个字符在任何位置（包括文件名、目录名、盘符后）都非法，哪怕只是出现在字符串里就可能让CreateFileA或std::filesystem::path构造失败。特别注意:——它不只用于盘符（如C:），出现在中间（如log:2024.txt）也会被拒绝。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::string::find_first_of快速扫描：path.find_first_of(R"(:"/|?*)") != std::string::npos - 不要只检查文件名部分——整个路径字符串都要查，因为
dir<name>中<code>在目录名里同样无效 - 注意
/和：虽然是Windows合法分隔符，但/在API层面常被接受（会自动转换），但某些旧工具或命令行参数里仍可能出问题，建议统一用或由std::filesystem::path处理
Linux/macOS路径里真正危险的是什么
POSIX系统理论上允许除 （空字节）和/以外的任意字节，但实际使用中/是唯一硬性禁止的分隔符， 会导致C字符串截断。其他如空格、换行、~、*等不是“非法”，而是shell解析时需转义，属于使用层面风险，不是系统级拒绝。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 检查是否含
/（除了作为路径分隔符的位置）：比如user/name/file.txt合法，但user/name//file.txt虽能创建，却可能被某些工具误判为多级空目录 - 用
std::count(path.begin(), path.end(), ' ')确认无嵌入空字节——这是C++字符串隐式截断的根源 - 避免在路径中直接拼接用户输入的文件名，尤其含控制字符（如
退格）可能干扰终端显示或日志解析
跨平台判断该不该自己写校验逻辑
别重复造轮子。C++17的std::filesystem::path在构造时不会立即报错，但调用.filename()、.parent_path()或std::filesystem::exists()时才暴露问题。更稳妥的做法是：先用std::filesystem::path封装，再尝试std::filesystem::status()或std::filesystem::is_regular_file()——这些函数在底层会触发系统调用，真实反馈路径合法性。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 构造
std::filesystem::path p{input_str}后，立刻检查p.native().empty()——若输入为空或含不可表示字符（如UTF-16代理对损坏），native()可能返回空串 - 对Windows路径，额外调用
std::filesystem::path::has_filename()并检查.filename().string()是否为空或含非法字符，因为\servershare这种UNC路径的filename()可能为空 - 不要依赖
std::filesystem::path::generic_string()来“修正”路径——它只是替换分隔符，不清理非法字符
为什么正则匹配容易漏掉边界情况
用正则R"([:"/\|?*])"查Windows非法字符看似简洁，但忽略两个关键点：一是本身在字符串字面量里要双写（"\\"），二是std::regex在某些编译器（如MSVC 2019）对宽字符支持不稳定，而路径可能含Unicode。更糟的是，正则无法识别CON、AUX这类保留设备名——它们不是非法字符，而是非法名称。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 保留名检测必须单独做：
std::regex_match(p.filename().string(), std::regex(R"(^(CON|PRN|AUX|NUL|COM[1-9]|LPT[1-9])$)", std::regex_constants::icase)) - 优先用
std::string_view+find_first_of替代std::regex，性能高且无编码歧义 - 如果路径来自网络或用户输入，先用
std::filesystem::u8path（C++20）或第三方库（如utf8cpp）验证UTF-8完整性，再进入字符检查流程
真正麻烦的从来不是单个非法字符，而是组合场景：比如路径末尾带空格+点（"file.txt "）、包含BOM头的UTF-8字符串、或NTFS流名（file.txt:zone.identifier）——这些在普通校验里全被放过，却在特定API下调用失败。
