Windows路径中绝对禁止的字符是<、>、:、"、/、、|、?、*，共9个（含/和），其中前7个在任何位置均导致API调用失败；/和虽为路径分隔符别名，但作为文件名字符仍非法。
Windows 下哪些字符绝对不能出现在路径里
Windows 文件系统对路径字符有硬性限制，:、*、?、"、、<code>>、| 这 7 个 ASCII 字符在任何位置（包括文件名、目录名、扩展名）都非法，哪怕只是出现在字符串里就可能让 CreateFileA、std::filesystem::path 构造或 std::ofstream 打开失败。注意：/ 在 Windows 上虽被当作路径分隔符别名（兼容 Unix 风格），但它本身不是非法字符；真正危险的是上面那组“保留字符”。
用 std::filesystem::path 判断是否合法不靠谱
std::filesystem::path 构造函数不会主动校验非法字符——它只是做字符串切分和规范化，比如把 "a/bc" 归一为内部表示。即使你传入含 或 <code>? 的字符串，构造也不会抛异常，后续调用 .string() 或 .generic_string() 仍会原样返回。所以不能靠“没崩溃”来判断合法。
实操建议：
- 手动扫描字符串中是否包含
':', '*', '?', '"', '', '|' - 注意：控制字符（ASCII 0–31）也非法，但实际输入中极少出现，如需严格检查可补充
std::iscntrl - 不要依赖
std::filesystem::exists()或is_regular_file()反向验证——它们只查是否存在，不报字符错误
跨平台判断要区分逻辑和实际约束
Linux/macOS 对路径字符限制极宽松：除 和 / 外基本都允许（/ 是路径分隔符，不能出现在名字里）。但如果你的程序要同时生成 Windows 和 POSIX 路径，就得按更严标准来——即以 Windows 规则为底线。否则一个在 Linux 上能创建的文件名（比如 file:name.txt），到 Windows 就直接失败。
立即学习“C++免费学习笔记（深入）”；
常见误区：
- 以为
std::filesystem::path的has_filename()或has_parent_path()能反映合法性 —— 它们只看结构，不看内容 - 用正则匹配
[\/:*?"|]时忘了转义反斜杠，在 C++ 字符串字面量里得写成"[\\/:*?"|]" - 忽略 Unicode 中的全角符号（如全角冒号
：），它们虽不触发 Windows 系统错误，但易导致用户困惑或工具解析异常
推荐的轻量级校验函数写法
不需要引入第三方库，几行就能搞定核心检查：
bool is_valid_path_chars(const std::string& path) {
static const std::string illegal = ":*?"<>|";
return std::none_of(path.begin(), path.end(),
[&illegal](char c) { return illegal.find(c) != std::string::npos; });
}
说明：
- 这个函数只检查非法字符，不处理空字符串、长度超限（MAX_PATH）、保留设备名（如
"CON"、"PRN"）等深层问题 - 若需完整合规，还得额外查结尾是否为空格或点（Windows 会自动截断）、是否为保留设备名（不区分大小写，且后可跟
.或空格） - 对于网络路径（
\servershare），开头双反斜杠是合法的，无需过滤
真正容易被忽略的是：路径合法性 ≠ 文件可创建性。即使字符全合法，权限不足、磁盘满、父目录不存在等问题仍会导致操作失败——字符检查只是第一道门槛。
