Linux/macOS 上改文件权限，得老老实实走 chmod 系统调用，传八进制掩码（比如 0644），还得检查返回值。Windows 那边呢，用 SetFileAttributesA 控制只读这类属性就行。两边的语义根本不对等，跨平台时千万别直接硬映射。
Linux/macOS 下用 chmod 系统调用修改文件权限
在类 Unix 系统上，C++ 本身没有跨平台的权限修改接口，所以得直接调底层系统 API。chmod 是最直接的方式，接受路径和权限掩码两个参数。很多人容易犯的一个错误是直接传十进制数字，比如写 644 而不是 0644。结果权限被解释成八进制以外的值，行为完全出乎意料——chmod("file.txt", 644) 实际等价于 chmod("file.txt", 01204)（八进制），根本不是预期的 rw-r--r--。
- 权限掩码必须用前缀
0表示八进制：读写执行对应4/2/1，用户/组/其他三段组合，比如0600（仅所有者可读写）、0755（所有者全权，组和其他可读+执行） - 路径必须是绝对路径或相对于当前工作目录的有效路径；相对路径容易因为程序启动位置不同而失败
- 调用后一定要检查返回值：
chmod成功返回0，失败返回-1，这时可以查errno（比如EACCES表示无权修改、ENOENT表示文件不存在）
Windows 下用 SetFileAttributesA 控制基础属性
Windows 没有 Linux 那样的“权限”概念（rwx），只有文件属性（只读、隐藏、系统等）和 ACL（访问控制列表）。对于普通场景，改 FILE_ATTRIBUTE_READONLY 最常用，对应 C++ 里的 SetFileAttributesA。注意：这个函数不能设置 Linux 式的“执行权限”，也无法替代 ACL 操作；如果需要精细控制（比如限制某用户删除），必须用 SetSecurityInfo 系列 API，复杂度会陡增。
- 设为只读：
SetFileAttributesA("file.txt", FILE_ATTRIBUTE_READONLY) - 清除只读：
SetFileAttributesA("file.txt", FILE_ATTRIBUTE_NORMAL) - 失败时返回
0，调用GetLastError()获取错误码（比如ERROR_ACCESS_DENIED） - 路径支持正斜杠
/或反斜杠\，但建议统一用\\或/避免转义问题
跨平台封装时别硬套 POSIX 语义
试图用同一套代码在 Windows 上模拟 chmod 0755 的效果，往往适得其反。比如把 0755 直接传给 SetFileAttributesA，会把高位字节当属性掩码，触发未定义行为。
真正可行的做法是分层处理：先判断平台，再映射语义。比如，把 0755 解释为“允许执行”，在 Linux 下调 chmod，在 Windows 则仅移除只读属性（因为 Windows 默认允许执行）；而 0600 这类纯读写控制，在 Windows 只能靠 ACL 实现，不该假装能完成。
- 检测平台推荐用预处理器：
#ifdef _WIN32/#ifdef __linux__ - 不要依赖第三方库（如 Boost.Filesystem）的
permissions接口来“统一”行为——它在 Windows 上实际调用的仍是 ACL，而且默认不抛异常，失败时静默处理 - 如果项目必须跨平台且需要 ACL 级控制，优先考虑用
icacls（Windows）或setfacl（Linux）走子进程调用，比手撸 API 更稳
权限修改失败的三个高频原因
权限改不动，90% 不是代码写错，而是环境卡住。
- 当前进程没权限：普通用户无法用
chmod提升文件属主权限（比如加suid位），也不能修改不属于自己的文件（除非是 root）；Windows 下需要管理员提权才能修改系统文件属性 - 文件被占用：Windows 上如果文件正被其他进程打开（尤其记事本、IDE），
SetFileAttributesA会失败；Linux 下虽然允许改权限，但已打开的 fd 仍按旧权限运行 - 文件系统不支持：NTFS 支持 ACL，FAT32 不支持；Linux 挂载的
vfat或ntfs-3g可能忽略chmod调用——这时chmod返回 0 但实际无效，需要额外验证
调试时先手动用 ls -l 或 attrib 确认原始状态，再看调用前后是否真变了，别只信返回值。
