c++oding="utf-8" ?>
首选 std::filesystem::portable_posix_name()，它按字节校验文件名合法性，仅排除 /、\0、ascii 控制字符，长度≤255 字节，支持 utf-8，不误判多字节字符，且不检查路径、保留名或写入可行性。
直接用 std::filesystem::portable_posix_name() —— 它不是“严格 POSIX 标准”的全量校验，而是最贴近实际可用性的、被主流 libc++/libstdc++ 实现采纳的子集。别自己写正则或 isalnum() 遍历，那会误杀 UTF-8 文件名。
为什么 std::filesystem::portable_posix_name() 是首选
它内部按字节处理，符合 POSIX 对“文件名”的真实约束：仅排除 /、<p>它内部按字节处理，符合 POSIX 对“文件名”的真实约束：仅排除 <code>/、\0、ASCII 控制字符（\x00–\x1F 和 \x7F），长度 ≤ 255 字节（注意是字节，不是字符数），且不以 . 或 .. 开头。
\x00–\x1F 和 \x7F），长度 ≤ 255 字节（注意是字节，不是字符数），且不以 . 或 .. 开头。
- 传入
std::string或能隐式转为std::filesystem::path的类型；传const char*会编译失败 - 支持 UTF-8 多字节字符（如中文、emoji），手动用
isalnum()会把一个汉字拆成 3 个非法字节误判 - 不检查 Windows 保留名（
CON、COM1等）、不验证路径是否存在、不关心权限或冲突
std::filesystem::portable_posix_name() 不覆盖的边界情况
它只校验“名字”，不校验“路径”。比如 "a/b/c.txt" 是合法路径，但函数只对 "c.txt" 返回 true；若你传整条路径进去，它会把 / 当作非法字符直接返回 false。
- 空字符串
""→ 返回false（POSIX 不允许空文件名） -
"."或".."→ 返回false（它们是路径解析符号，不是普通文件名） -
"-foo"→ 返回false（portable_posix_name()比 POSIX 原文更严格，禁止以-开头） -
"foo\x00bar"→ 返回false（含嵌入 NUL，C 字符串提前截断，实际写入会失败）
跨平台项目必须补的 Windows 校验
这个函数在 Windows 下完全不拦截 :、*、?、"、、<code>>、| —— 这些字符在 NTFS 上根本无法创建文件。
- 正确做法是组合判断：
std::filesystem::portable_posix_name(s) && std::filesystem::windows_name(s) - 注意：
std::filesystem::windows_name()是 C++17 引入的配套函数，但它不检查保留名（如CON）；需要额外用is_valid_win_filename()类函数过滤 - 如果目标平台明确是 Linux/macOS，就别加
windows_name()—— 它在 POSIX 系统上只是宽松放行，反而可能掩盖问题
真正容易被忽略的是：这个函数只回答“能不能当文件名用”，不回答“能不能成功写入”。比如 "foo\xC0\x80"（非法 UTF-8 序列）会被 portable_posix_name() 放过，但实际 open() 会失败；这种场景得靠系统调用返回的 errno 判断，不是名字校验能覆盖的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
