std::filesystem::path 不校验 Windows 非法字符（如 : " / | ? *），仅作字符串封装；需手动检查，否则 create_directories() 等调用时才报 ERROR_INVALID_NAME（123）等系统错误。
Windows 下 std::filesystem::path 无法自动过滤非法字符
Windows 路径中存在一组系统级禁止使用的字符（如 、<code>>、:、"、/、、|、?、*），std::filesystem::path 构造时不会报错，也不会拒绝这些字符——它只做字符串封装，不校验合法性。直接传给 create_directories() 或 open() 时才会在系统调用层失败，错误码通常是 ERROR_INVALID_NAME（123）或 ERROR_BAD_PATHNAME（161）。
所以不能依赖 path 对象本身判断是否“可用”，必须手动检查。
- 常见错误现象：
std::filesystem::create_directories(path)返回false，但没打印具体错误；或抛出std::filesystem::filesystem_error，异常信息里含The filename, directory name, or volume label syntax is incorrect - 使用场景：用户输入路径、配置文件读取、URL 解析后拼接路径等不可信来源
- 注意：
std::filesystem::path::has_filename()、is_absolute()等函数完全不涉及非法字符检测
用 std::regex 校验前先明确匹配目标
正则不是万能解法，尤其在 Windows 路径中，“非法”分两类：一是绝对禁止的控制字符（如 ），二是保留设备名（如 <code>CON、AUX、NUL 等，不区分大小写，后面可跟点或空格）。只靠正则扫一遍 :"/|?* 是不够的。
- 必须同时检查：
[:"/\|?*]+ 设备名前缀（CON、PRN、AUX、NUL、COM[1-9]、LPT[1-9]） - 设备名匹配需忽略大小写，且允许后跟
.或空格（如CON.、aux都非法） - 正则性能影响小，但频繁调用建议编译一次复用：
static const std::regex illegal_pattern(R"(^[:"/\|?*]|^CON|^PRN|^AUX|^NUL|^COMd|^LPTd)", std::regex_constants::icase) - 注意：
在 C++ 原始字符串中要写成，不是\b；std::regex_search检查的是整个路径字符串任意位置，别漏掉文件名部分
更稳妥的做法：用 PathCchValidateString（Windows API）
标准库 regex 只能覆盖一部分规则，而 Windows 实际路径验证逻辑更复杂（比如结尾空格、点、设备名+扩展名组合等）。Win10+ 推荐用系统原生函数 PathCchValidateString，它由 PathCch.h 提供，行为与 Explorer 和 CreateFile 一致。
立即学习“C++免费学习笔记（深入）”；
- 需要链接
Pathcch.lib，头文件加#include <pathcch.h></pathcch.h> - 调用示例：
HRESULT hr = PathCchValidateString(path_str.c_str(), PATHCCH_ALLOW_LONG_PATHS);，返回S_OK表示合法，否则非法 - 相比 regex，它自动处理：
CON.txt、com1、file.、name（末尾空格）、..（相对路径中的非法上溯）等边界情况 - 跨平台项目慎用：该 API 仅 Windows，Linux/macOS 下需 fallback 到简单 regex 或跳过校验（因为它们对文件名字符限制宽松得多）
实际校验逻辑建议分层处理
别指望一个正则或一个函数包打天下。真实路径校验应分三步走，每步成本递增但精度也递增：
- 第一层（轻量）：用
std::regex_search快速筛掉明显含[:"/\|?*]的字符串，95% 的恶意输入在这里拦截 - 第二层（准系统级）：对剩余路径调用
PathCchValidateString（Windows）或简单检查长度/结尾空格（其他平台） - 第三层（最终确认）：真正执行
std::filesystem::status(path)或尝试open()，捕获异常并解析std::system_error::code().value()—— 这才是唯一权威答案 - 容易踩的坑：把校验结果缓存太久；对同一路径反复调用
PathCchValidateString却没考虑线程安全（它是线程安全的，但别误以为能省掉锁）；在路径拼接后才校验，而不是对每个组件单独校验（比如用户传入的dirname本身含CON，拼进C: mp后仍是非法）
路径合法性永远是动态的：取决于当前 OS、当前权限、当前文件系统（NTFS vs FAT32）、甚至当前进程是否以管理员运行。最保险的“判断”，其实是让它试一次。
