Windows路径非法字符包括<、>、:、"、/、、|、?、*、ASCII控制字符（0–31）、DEL（127）及结尾空格/点；std::filesystem::path不校验这些，仅字符串处理，实际错误发生在系统调用时。
Windows 路径非法字符有哪些，std::filesystem::path 不会自动检测
Windows 对路径名有明确的保留字符集，比如 <、>、:、"、/、、|、?、*，还有 ASCII 控制字符（0–31）和结尾空格/点。但 std::filesystem::path 构造时完全不校验这些——它只做字符串拆分和拼接，path("a<b") 合法，直到你调用 create_directory() 或 open() 才报错。
所以不能依赖构造成功就认为路径安全。
- 实际错误常出现在
std::filesystem::create_directories()或fopen()时，报错信息类似Permission denied或Invalid argument，但根本原因是非法字符 -
std::filesystem::path::generic_string()返回的是正斜杠风格，但 Windows API 实际仍按反斜杠解析，非法字符检查必须基于最终传给系统调用的原始字节 - 注意：UWP 应用或沙盒环境还额外禁止某些路径前缀（如
\?UNC中的非法组合），但普通桌面程序只需关注字符级限制
用正则表达式快速过滤非法字符（C++11+ std::regex）
正则最直接，但要注意：C++ 标准库的 std::regex 在 Windows 下对宽字符（std::wstring）支持不稳定，且编译器差异大（MSVC 基本可用，GCC libstdc++ 旧版本有 bug）。建议统一用 std::string + UTF-8 编码路径（前提是你的程序全程用 UTF-8 处理路径，且 Windows 版本 ≥1903 并启用了 UTF-8 全局代码页）。
匹配非法字符的正则模式是：[<>:"|?* - ]，加结尾空格/点需额外判断。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 不要写
^[^<>:"|?*\x00-\x1f\x7f]*$—— 这会漏掉结尾空格/点，且\x00在 C++ 字符串字面量里会截断 - 正确做法是先检查末尾：
!path.empty() && (path.back() == ' ' || path.back() == '.')，再用std::regex_search(path, illegal_re) - 示例片段：
std::regex illegal_re(R"([<>:"|?* - ])");<br>bool has_illegal = std::regex_search(path, illegal_re) ||<br> (!path.empty() && (path.back() == ' ' || path.back() == '.'));
更可靠的做法：用 Windows API PathIsRelative 和 GetFullPathNameW 辅助验证
标准库正则容易漏判或误判（比如没考虑 CON、AUX 等保留设备名），而 Windows 自带的 Shlwapi.h 和 FileAPI.h 提供了底层保障。
-
PathIsRelativeW()可快速排除绝对路径格式错误，但它不查非法字符 - 真正管用的是
GetFullPathNameW()：传入路径，它会尝试规范化；若返回 0 或结果含非法字符（比如输出里还剩<），说明不可用 - 关键点：必须用
wchar_t版本，且输入为 UTF-16；如果源路径是 UTF-8，先用std::wstring_convert<std::codecvt_utf8<wchar_t>>>（C++17 已弃用，推荐 <code>MultiByteToWideChar()） - 别忘了检查保留名：
std::wstring name = L"CON";，然后用_wcsicmp()对比路径最后一段（去掉扩展名后）是否匹配L"CON"、L"AUX"等共 10 个设备名
为什么不用 std::filesystem::exists() 或 is_regular_file() 来反向验证
因为它们不解决“非法字符”问题——exists("a<b.txt") 返回 false，但你无法区分这是文件不存在，还是路径本身被系统拒绝解析。尤其当路径含 \? 前缀时，exists() 可能直接抛 std::filesystem::filesystem_error 异常，异常消息里又不包含具体哪个字符违规。
- 这种“试错式验证”延迟高、副作用大（可能触发杀软扫描、审计日志），且掩盖了真实输入问题
- 如果你在接收用户输入（比如 GUI 文本框、命令行参数），必须在 IO 之前就拦截，而不是等
fopen()失败再提示 - 跨平台代码更要小心：Linux 允许
<作为文件名，但 Windows 用户通过 Samba 写入后，Windows 客户端会卡死——所以即使目标是 Linux，只要路径可能被 Windows 消费，就得按 Windows 规则预检
\? 解析略有差异。正则只是第一道筛子，真要稳，得结合 API 规范化 + 保留名查表 + UTF-16 层验证。 
