跨平台文件名校验必须同时使用std::filesystem::portable_posix_name()和windows_name()：前者过滤字节级非法字符与长度，后者覆盖Windows特有约束（如保留名、非法符号），缺一不可。
没有“严格的POSIX跨平台规范”这回事——POSIX和Windows的文件名规则根本冲突，强行统一只会误判或漏判。真正可行的做法是分层校验：先用 std::filesystem::portable_posix_name() 做基础字节级过滤，再叠加 std::filesystem::windows_name() 覆盖 Windows 特有约束，二者缺一不可。
为什么 std::filesystem::portable_posix_name() 不能单独用于跨平台
它只针对 POSIX 系统设计，对 Windows 完全无效：portable_posix_name("a:b.txt") 返回 true（因为冒号在 Linux 合法），但 Windows 下 CreateFile 会直接失败；同样，portable_posix_name("CON") 也返回 true（POSIX 不管设备名），而 Windows 会拒绝创建。
它还比 Windows 更严：禁止以 - 开头（如 -config.json），但 Windows 允许；也禁止单个 . 或 ..，而 Windows 对这两者有特殊语义处理。
- 它检查的是「字节长度 ≤ 255」，不是字符数——UTF-8 中文名可能占 3 字节/字符，容易超限
- 它不拒绝
~、$、`等 shell 元字符，这些在命令行中极易引发意外展开 - 传入
const char*会编译失败，必须是std::string或能隐式转为std::filesystem::path的类型
为什么必须同时调用 std::filesystem::windows_name()
windows_name() 是 C++17 在 Windows 平台提供的原生校验函数，它识别全部 9 个非法字符（:、*、?、"、<、>、|、\、/），以及 ASCII 控制符（\x00–\x1F）和结尾空格/点号。
立即学习“C++免费学习笔记（深入）”；
但它不检查 POSIX 层面的问题：比如 name\x00suffix（含嵌入 NUL）在 Windows 下构造 std::filesystem::path 就会抛异常，而 windows_name() 可能返回 true——因为它只扫字符串内容，不检测底层截断风险。
- 保留名（如
CON、COM1）只在校验无扩展名时触发，CON.txt会被windows_name()放行 - 大小写不敏感：传入
"con.TXT"，函数内部会转大写后比对 - 该函数在非 Windows 平台可能未实现或返回
false，不能单独依赖
跨平台组合校验的正确写法
必须两者都为 true 才算通过，且顺序不能颠倒：先做 portable_posix_name() 快速筛掉含 /、\0、超长或控制符的字符串，再进 windows_name() 检查 Windows 特有禁忌。
bool is_cross_platform_filename(const std::string& s) {
if (s.empty()) return false;
// 先过 POSIX 字节关
if (!std::filesystem::portable_posix_name(s)) return false;
// 再过 Windows 语义关（仅 Windows 平台有效）
#ifdef _WIN32
if (!std::filesystem::windows_name(s)) return false;
#endif
return true;
}
- 不要用
std::all_of+ 字符白名单——会把 UTF-8 多字节字符拆开误判（如中文“文”被当成 3 个非法字节） - 不要跳过空字符串检查：
portable_posix_name("")返回false，但有人会忽略这点直接传空串导致后续逻辑崩 - Linux/macOS 下仍建议启用
windows_name()（如果可用），因为路径若要同步到 Windows 存储，提前拦截比事后报错更稳妥
最容易被忽略的底层陷阱
所有这些函数都只校验名字字符串本身，不碰路径结构——"dir/sub/../file.txt" 是合法相对路径，但 "dir/sub/./../file.txt" 里那个 ./ 段本身仍是合法文件名，不会被任何函数拦住。
真正危险的是嵌入 NUL："hello\x00world.txt" 在 C 字符串中会被截断为 "hello"，portable_posix_name() 和 windows_name() 都只看到前 5 字节，完全无法发现后面被吃掉的部分。
- 如果你接收的是用户输入或网络数据，必须先确认原始字节流不含
\0，不能只信std::string::size() -
std::filesystem::path构造失败才是最终防线，但异常开销大，不适合作为主校验手段 - 跨平台项目中，哪怕只跑 Linux，也要按 Windows 规则清洗——否则某天导出到 Windows 设备就静默失败
