std::filesystem::portable_posix_name()不够用，因它仅校验posix侧规则（长度≤255字节、不含/、\0、控制字符、不以.或..开头），不检查windows禁止字符（:、*、?等）和保留名（con、com1），跨平台需组合调用portable_posix_name()与windows_name()。
没有“POSIX跨平台标准”这种东西——POSIX 本身只定义 Unix-like 系统的规则，Windows 完全不遵循。所谓“跨平台安全文件名”，其实是取 POSIX 和 Windows 两套规则的交集，而 std::filesystem::portable_posix_name() 只覆盖 POSIX 侧，不能单独用于跨平台校验。
为什么 std::filesystem::portable_posix_name() 不够用
这个函数只做 POSIX 侧的字节级检查：长度 ≤255 字节、不含 /、\0、ASCII 控制字符（\x00–\x1F、\x7F）、不以 . 或 .. 开头。但它对 Windows 完全无感：
- 不会拒绝
:、*、?、"、、<code>>、|—— 这些在 Windows 上直接导致CreateFile失败 - 不拦截
CON、PRN、COM1等保留名，哪怕你传入"CON.txt"也会返回true - 允许以
-开头（如-file），但某些 shell 工具会把它误认为命令选项
跨平台文件名校验必须组合判断
真正能同时在 Linux/macOS 和 Windows 上安全创建文件的字符串，需同时满足两套约束。推荐写法：
bool is_cross_platform_filename(const std::string& s) {
if (s.empty()) return false;
return std::filesystem::portable_posix_name(s) &&
std::filesystem::windows_name(s);
}
注意两点：
-
std::filesystem::windows_name()是 C++17 起引入的配套函数，它检查是否含 Windows 禁止字符 + 是否为保留名（如CON、LPT9） - 两个函数都要求输入是
std::string；传const char*会编译失败，得显式转成std::string或用std::filesystem::path(s).filename().string()提取纯文件名 - 如果项目还需支持旧编译器（C++14 及以下），就得手写等效逻辑：先过滤 9 个 Windows 禁止字符 +
/+\0，再查保留名表，最后补上 POSIX 的控制字符和长度检查
常见误操作和边界坑
实际工程中最容易栽在这些地方：
- 把路径字符串直接丢给
portable_posix_name()—— 它只接受“文件名”，不含/或\。若原始输入是"dir/file:name.txt"，必须先用std::filesystem::path(str).filename().string()提取最后一段 - 忽略大小写问题：
std::filesystem::windows_name()内部对保留名做不区分大小写的匹配，但你自己实现时若用std::unordered_set<:string></:string>存"CON"，就得确保传入前统一转大写（如用std::transform+std::toupper） - UTF-8 多字节字符完全没问题（比如
"测试.txt"在 Linux/macOS 合法，在 Windows 也合法），但别用isalnum()遍历单字节判断——会把一个汉字拆成 3 次调用，全返回false - 空格和点号（
.）本身合法，但开头/结尾的点或连续点（如".git"合法，".."被portable_posix_name()显式拒绝，"..."却允许）需要业务层额外约束
最终要记住：所谓“跨平台安全”，本质是向最严平台（Windows）看齐。POSIX 允许的宽泛性在这里反而成了干扰项，别试图兼容所有理论可能，只守住两套规则的交集就够了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
