Linux/macOS用chmod系统调用修改文件权限，必须使用八进制掩码（如0644）并检查返回值；Windows则用SetFileAttributesA设置只读等属性，二者语义不等价，跨平台不可直接映射。
Linux/macOS下用chmod系统调用修改文件权限
在类Unix系统上，C++本身不提供跨平台的权限修改接口，必须调用底层系统API。chmod是最直接的方式，它接受路径和权限掩码（如0644）两个参数。
常见错误是传入十进制数字（比如写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没有“权限”概念（如rwx），只有文件属性（只读、隐藏、系统等）和ACL（访问控制列表）。对普通场景，改FILE_ATTRIBUTE_READONLY最常用，对应C++里的SetFileAttributesA。
注意：这个函数不能设置Linux式的“执行权限”，也无法替代ACL操作；若需精细控制（如限制某用户删除），必须用SetSecurityInfo系列API，复杂度陡增。
立即学习“C++免费学习笔记（深入）”；
- 设为只读：
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确认原始状态，再看调用前后是否真变了，别只信返回值。
