getfileattributes判断write_only不可靠，因其file_attribute_readonly仅表示文件系统只读属性，windows无原生“只写”概念；posix下需用stat检查st_mode & 0700 == 0200；跨平台应直接尝试以o_wronly/generic_write打开并验证行为。
Windows下用GetFileAttributes判断WRITE_ONLY是否可靠
直接看结论：GetFileAttributes 返回的 FILE_ATTRIBUTE_READONLY 标志**不等于**“只写权限”，它只是表示文件系统层面的只读属性（即不可写），和 POSIX 的 write-only 完全相反。Windows 本身没有“只写”这个访问控制概念，所谓“只写文件”在 Win32 API 中无法原生表达——你设了 FILE_ATTRIBUTE_READONLY，文件就写不了；你不设，它默认可读可写（除非 ACL 显式限制）。所以靠 GetFileAttributes 判断“只写”会得出错误结论。
Linux/macOS 下检查文件权限位是否为0200（仅用户可写）
POSIX 文件权限中，“只写”对应的是权限掩码中 **只有写位（w）被置位、读（r）和执行（x）都未置位**，即用户权限为 0200（八进制）。但要注意：这不代表“只能写”，因为如果组或其它权限里有读位（比如 0240），实际仍可能被读取；真正意义的“只写”需满足 (st_mode & 0777) == 0200（仅用户有写权，其余全无）。
- 用
stat()获取struct stat，检查st_mode & 0700是否等于0200 - 注意：即使权限是
0200，若文件被打开为O_RDONLY，open()仍会失败；反过来，O_WRONLY可能成功，但后续read()必然失败（EBADF或EINVAL） - 不要忽略 umask 影响：创建时指定
0200权限，实际生效可能是0200 & ~umask
跨平台判断“能否以只写方式打开”比查权限更实用
与其纠结“是否只写”，不如直接尝试以最小必要权限打开文件——这是最可靠的运行时判断方式。C++ 没有标准跨平台文件权限检查库，硬编码权限位易出错，而 open()（POSIX）或 CreateFile()（Windows）的行为才是真实约束。
- POSIX：用
open(path.c_str(), O_WRONLY | O_NONBLOCK)，成功且read()立即返回-1+errno == EBADF，说明是只写语义 - Windows：用
CreateFile(path.c_str(), GENERIC_WRITE, FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr)，成功后调ReadFile()必失败（ERROR_ACCESS_DENIED） - 注意：某些文件系统（如 FAT32）不支持细粒度权限，
stat()返回的权限位可能全为 0 或固定值，此时只能靠打开行为判断
std::filesystem::permissions 不能用于检测只写
std::filesystem::status(path).permissions() 返回的是 perms 枚举组合，但它的设计目标是映射 POSIX 权限位，**不提供“只写”的语义判定逻辑**。例如 perms::owner_write 单独存在时，你无法知道 owner_read 是否被清除——因为 permissions() 返回值是按位 or 的结果，不是原始 mode_t。
- 它可能返回
owner_write | group_read，但你无法反推出用户权限位具体是0240还是0200 - Windows 下该函数甚至可能忽略 ACL，只返回简化后的只读/非只读二元状态
- 真要跨平台做权限分析，建议封装一层
stat()/GetFileInformationByHandle()，而不是依赖std::filesystem
O_WRONLY 或 GENERIC_WRITE，并接受失败，比任何静态权限检查都来得实在。权限位容易被挂载选项、ACL、SELinux 等覆盖，而内核对 open 的校验永远是最权威的。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
