std::filesystem::portable_posix_name() 是 c++17 中校验单个文件名是否符合 posix 兼容子集的函数，仅检查长度≤255字节、不含/ /控制符/以.或..开头等，不处理 windows 保留名或路径，也不保证文件可创建。
没有“严格符合POSIX跨平台标准”这回事——POSIX本身不定义跨平台，只定义类Unix系统行为；Windows根本不遵循POSIX文件名规则。所谓“跨平台安全”，本质是取 POSIX 和 Windows 两套规则的交集，而非某个单一标准。
std::filesystem::portable_posix_name() 是什么，不是什么
它不是 POSIX 标准的完整实现，而是 C++17 标准库中一个**偏向 POSIX 兼容性子集**的检查函数。它校验的是：长度 ≤ 255 字节（注意是字节，不是字符）、不含 、/、ASCII 控制字符（ – 和 ）、不以 . 或 .. 开头。
- 它允许 UTF-8 多字节字符（如中文、emoji），因为 POSIX 允许任意可打印字节序列，只要不碰禁用字符
- 它不检查 Windows 保留名（
CON、COM1等），也不拒绝:、*、?—— 这些在 Linux 上合法，但在 Windows 上直接失败 - 传入
const char*会编译失败，必须是std::string或能隐式转为std::filesystem::path的类型
跨平台文件名校验必须组合判断
单靠 std::filesystem::portable_posix_name() 无法保证 Windows 下可用。真正安全的做法是同时满足 POSIX 和 Windows 的约束：
- 先调用
std::filesystem::portable_posix_name(s)（过滤掉 /、NUL、控制符、超长、以 . 开头等） - 再调用
std::filesystem::windows_name(s)（拦截:、*、?、"、、<code>>、|及保留名） - 两者都返回
true才算跨平台安全 —— 注意：portable_posix_name()比windows_name()更严格（例如禁止以-开头），所以顺序不能颠倒
示例逻辑：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
bool is_cross_platform_filename(const std::string& s) {
return std::filesystem::portable_posix_name(s) &&
std::filesystem::windows_name(s);
}
手动校验容易踩的坑
手写字符白名单（比如只允许 a-z、0-9、_、-、.）看似简单，实际问题很多：
- 误判 UTF-8：一个汉字占 3 字节，但
isalnum()对每个字节单独调用会返回 false，导致“中文.txt”被当成非法 - 漏掉
（DEL 控制符），它不属于–，但 POSIX 明确禁止 - 忽略长度是按字节计，不是字符数 —— 一个 emoji 可能占 4 字节，255 字符远超 255 字节限制
- 把
.和..当成“允许含点”，其实规则是“不能以.或..开头”，.config合法，..hidden不合法
路径 vs 文件名，别混为一谈
std::filesystem::portable_posix_name() 只校验**单个名字组件**（即不含 / 的纯文件名），不处理路径。如果你传入 "dir/file.txt"，它会因含 / 直接返回 false。
- 要判断整个路径是否为合法相对路径，得用
std::filesystem::path(s).is_relative() - 要判断路径字符串是否含非法字符（比如 Windows 下的
:），需单独遍历黑名单："\/:*?"|" - 空字符串
""、单个"."、".."都被portable_posix_name()接受，但它们不是普通文件名，而是路径解析符号
最易被忽略的一点：这个函数不保证你能成功创建文件——它只管名字合规，不管目录是否存在、权限是否足够、磁盘是否满。真正落地前，仍需 std::filesystem::exists() 和实际 I/O 尝试兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
