C++标准库无跨平台文件权限接口，SetFileAttributes与chmod语义不同：前者仅处理Windows属性位（如只读、隐藏），后者操作POSIX rwx权限模型，混用将导致权限失控或静默失败。
Windows下SetFileAttributes不能替代chmod
直接说结论：C++标准库不提供跨平台文件权限设置接口，SetFileAttributes和chmod语义不同，强行混用会导致权限失控或静默失败。
Windows的SetFileAttributes只处理只读、隐藏、系统、存档等“属性位”，不对应Unix的rwx三组权限位；而chmod修改的是POSIX权限模型（user/group/other + rwx），Linux/macOS上还涉及ACL、sticky bit等扩展。两者不是同一维度的概念。
-
SetFileAttributes("file.txt", FILE_ATTRIBUTE_READONLY)在Windows上会设只读，但在Linux上对chmod无任何影响 - 在Linux上调用
chmod("file.txt", 0644)，Windows下完全无效，且不会报错（除非你手动做了平台判断） - macOS虽然支持
chmod，但对某些挂载卷（如exFAT、FAT32）会忽略权限位，行为与Linux不一致
用boost::filesystem::permissions做最小兼容封装
Boost 1.70+ 的 boost::filesystem::permissions 是目前最稳妥的跨平台抽象——它内部对Windows调用SetFileAttributes模拟只读，对POSIX系统调用chmod，并屏蔽了大部分底层差异。
但它只覆盖常用子集：只读（owner_read等）、可执行（owner_exe）、写入（owner_write），不支持setuid/setgid、sticky bit或ACL。
立即学习“C++免费学习笔记（深入）”；
- 设置只读：
boost::filesystem::permissions("file.txt", boost::filesystem::perms::owner_read | boost::filesystem::perms::group_read | boost::filesystem::perms::others_read, boost::filesystem::perm_options::replace) - 取消写入（即设为只读）：
boost::filesystem::permissions("file.txt", boost::filesystem::perms::owner_write | boost::filesystem::perms::group_write | boost::filesystem::perms::others_write, boost::filesystem::perm_options::remove) - 注意：Windows下
owner_exe会被忽略，others_write在NTFS上实际映射为“删除权限是否允许”，不是严格等价
自己封装时必须检查stat/GetFileInformationByHandle返回值
跨平台权限逻辑若不用Boost，就得手写条件编译，但容易漏掉关键检查点：权限是否真正可读写，而不是仅看函数返回成功。
比如Linux下chmod成功，不代表进程后续能open(O_WRONLY)——可能受SELinux、mount选项（noexec、nosuid）或umask影响；Windows下SetFileAttributes成功，也不代表CreateFile能以GENERIC_WRITE打开——可能被父目录ACL拒绝。
- 务必在设置后尝试最小IO验证：
std::ofstream f("file.txt", std::ios::out | std::ios::app)是否能打开 - Windows下不要只依赖
GetLastError()，要结合GetFileInformationByHandle查dwFileAttributes中FILE_ATTRIBUTE_READONLY位 - Linux/macOS下建议用
stat()比对st_mode & S_IWUSR，而不是只信chmod()返回值
CI/CD里最容易被忽略的权限继承问题
本地测试通过的权限设置，在CI（尤其是Docker容器或GitHub Actions runner）里常失效，根本原因是文件系统挂载方式或用户上下文不同。
例如：GitHub Actions默认用runner用户运行，但挂载的workspace卷可能是root-owned且noexec；Docker容器内/tmp常是tmpfs，不保存chmod结果；WSL2里Windows挂载的NTFS分区默认忽略POSIX权限位。
- CI脚本中别假设
chmod 755 script.sh之后就能./script.sh，显式用sh script.sh绕过可执行位检查 - 在Dockerfile里设置权限，优先用
COPY --chmod=755而非RUN chmod（后者在overlayfs上可能不持久） - Windows CI中，如果目标是让脚本“双平台可用”，与其折腾
SetFileAttributes，不如统一用sh -c "..."或cmd /c包装器启动
跨平台权限不是设一次就完事的事，它永远绑定在具体的文件系统、用户上下文和运行时环境中。没验证过的chmod或SetFileAttributes调用，大概率只在你本地开发机上有效。
