Windows无“只写”属性，仅有FILE_ATTRIBUTE_READONLY标志；Linux无“只写”概念，仅靠r/w/x权限位组合，且w需配合r才可靠，跨平台不应抽象“只写”，应按系统语义分别处理权限检查与控制。
只写属性在Windows和Linux上根本不是一回事
Windows里“只写”（即FILE_ATTRIBUTE_READONLY）是文件系统级属性，而Linux没有“只写”概念——只有读、写、执行权限位，且w权限必须配合r才有意义（否则连stat()都可能失败）。所以先确认你跑在哪种系统上，别拿Linux的chmod 200 file去当Windows的“只写”用。
Windows下用GetFileAttributes判断只读标志
Windows中所谓“只写”，实际是误称；系统只有FILE_ATTRIBUTE_READONLY（只读），没有独立的“只写”属性。用户常把“不能读、只能写”的行为理解为“只写”，但NTFS本身不支持这种状态：一个文件若不可读，CreateFile打开时就会失败（除非用GENERIC_WRITE + FILE_FLAG_NO_BUFFERING等特殊方式，但那是另一回事）。真正能检查的只有是否设了只读标志：
DWORD attr = GetFileAttributes(L"myfile.txt");- 若
attr == INVALID_FILE_ATTRIBUTES，说明路径不存在或无访问权，别急着判属性 - 若
(attr & FILE_ATTRIBUTE_READONLY) != 0，表示系统标记为只读——注意：这不等于“当前进程无法写”，只是提示可能需要SetFileAttributes清除后才能修改
Linux下检查权限位要分清“可写”和“不可读”
Linux没有“只写文件”的概念，但你可以组合检查权限位是否异常（比如w有、r无）。不过得小心：stat()返回的st_mode包含所有权限和类型位，直接用access(path, W_OK)更可靠：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
if (access("myfile.txt", W_OK) == 0 && access("myfile.txt", R_OK) != 0)—— 表示可写但不可读 - 但这种情况极少见：多数情况下，如果
R_OK失败，open(..., O_WRONLY)也可能失败（取决于父目录权限、SELinux策略等） - 不要用
(st_mode & S_IWUSR) && !(st_mode & S_IRUSR)做判断，因为stat()成功不代表你能open()写——内核最终裁定权在VFS层，不是mode位说了算
跨平台代码别硬凑“只写”抽象
试图封装一个is_write_only(const std::string&)函数是危险的。它在Windows上无对应语义，在Linux上行为依赖上下文（如umask、ACL、挂载选项）。更务实的做法是：
立即学习“C++免费学习笔记（深入）”；
- 明确你要解决的实际问题：是防止误删？还是限制日志文件被cat？还是调试权限配置？
- Windows下关注
GetFileAttributes+SetFileAttributes控制只读位 - Linux下用
access(path, W_OK)确认可写性，再按需检查R_OK——但结果仅作参考，关键操作前仍要open()并处理errno - 永远记得：文件权限只是第一道门，DAC、MAC（如SELinux）、capabilities都可能覆盖它
真正的“只写”行为往往靠运行时逻辑控制（比如只提供std::ofstream接口、不暴露std::ifstream），而不是靠文件系统属性兜底。
