std::filesystem::permissions 默认不修改文件权限，因未指定操作类型（如 perm_options::add）且默认为 replace 会清空未设权限位；Windows 仅支持基础读写映射，且需目录可写才能修改。
std::filesystem::permissions 为什么改不了文件权限
直接调用 std::filesystem::permissions() 却发现文件权限没变，大概率是没传对参数或忽略了底层限制。它默认只修改权限位（如 user_write），不触碰所有权或特殊位（setuid/setgid），更不会自动递归——这点和 shell 的 chmod 行为不同。
常见错误现象：std::filesystem::permissions("a.txt", perms::owner_write) 执行后，a.txt 依然不可写；或者在 Windows 上完全无反应。
- 必须显式指定操作类型：用
perm_options::add、perm_options::remove或perm_options::replace，否则默认是perm_options::replace，会把未指定的权限全清掉（比如只传perms::owner_write，结果 group/other 权限全没了） - Windows 支持有限：仅映射 basic 权限（read/write/execute），且不区分 user/group/other；
perms::group_read这类在 Windows 上被忽略 - 需要写权限才能改权限：目标文件所在目录必须可写（尤其 macOS/Linux），否则抛
std::filesystem::filesystem_error
怎么安全地给文件加写权限（跨平台）
目标是“让当前用户能写”，不是“精确还原 chmod 644”。这时候别硬套 Unix 模式，用组合权限语义更稳。
推荐写法：
立即学习“C++免费学习笔记（深入）”；
namespace fs = std::filesystem;
fs::permissions("config.json",
fs::perms::owner_write | fs::perms::group_write | fs::perms::owner_read | fs::perms::group_read,
fs::perm_options::add);
- 用
perm_options::add最安全：只加权限，不碰原有 read/execute 位 - 避免单独写
perms::owner_write：它不含 read，加完可能导致文件不可读（尤其文本配置文件） - macOS/Linux 下，
owner_read和owner_write对应传统 r/w；Windows 下它们映射到 FILE_GENERIC_WRITE / FILE_GENERIC_READ
递归修改目录权限时容易崩在哪
std::filesystem::permissions() 本身不递归。想改整个目录树？得自己遍历，但顺序错了会出问题。
典型翻车点：
- 从上往下遍历（先改 dir，再改其子项）：如果父目录去掉了 write 权限，后续子项可能无法访问，抛
filesystem_error - 没过滤符号链接：默认会跟随 symlink，可能意外改到系统关键路径（比如
/usr/bin被软链到某处） - 没检查权限是否已存在：重复加同一权限位，虽不报错，但某些旧版 libc++ 有竞态行为
实操建议：用 fs::recursive_directory_iterator + fs::perm_options::add，并设 fs::directory_options::skip_permission_denied 防中断；对每个 entry 先 fs::is_regular_file() 再操作，跳过 symlink。
权限改了但程序还是打不开文件
权限只是门槛之一。改完 perms 后仍 open 失败，八成是其他层卡住了。
- 进程没重读文件：Linux/macOS 下，已打开的 fd 不受新权限影响；改权限后需重新
fopen()或open() - SELinux/AppArmor 限制：即使
ls -l显示 rw，策略可能禁止特定进程访问（常见于容器或发行版加固环境） - Windows ACL 覆盖：
std::filesystem::permissions()只动 DACL 基础位，若文件有显式 ACL（比如管理员加了 deny 条目），基础权限无效 - 文件被占用：Windows 下若另一进程以独占方式打开，
open()仍失败，和权限无关
验证是否真生效：用 fs::status("path").permissions() 读回当前值，别信 ls -l 的缓存输出；在目标平台本地跑测试，别只在开发机上验证。
