os.chmod批量修改权限未生效的根本原因是目标文件非当前用户所有、路径为符号链接、权限值非完整模式，且windows忽略执行位；跨平台批量改属主需规避os.chown在windows的panic及uid/gid映射限制。
os.Chmod 批量改权限为什么没生效
直接循环调用 os.Chmod 却发现文件权限没变，大概率不是代码写错，而是权限模型本身不满足条件。常见现象包括：返回 nil 但 ls -l 看权限未更新，或报 operation not permitted。
- 目标文件必须由当前进程用户拥有（owner）——非 root 用户无法给他人文件改权限
- 路径不能是符号链接；
os.Chmod默认操作的是链接指向的目标文件（follow symlink），若想改链接本身权限，得用os.Lchmod（仅 Unix-like 系统支持） - 传入的权限值必须是完整模式，例如
0644，不是掩码；Go 不会自动应用 umask，你给什么就设什么 - Windows 下执行位（如
0755中的 x）会被静默忽略，不报错也不生效
跨平台批量改属主（os.Chown）要避开哪些坑
os.Chown 是最不稳定的批量操作之一，Windows 直接 panic，macOS 和 Linux 也受 UID/GID 映射限制，几乎不能无脑用。
- Windows 上调用
os.Chown会立即 panic，必须用runtime.GOOS != "windows"显式包裹 - Linux/macOS 需以 root 或文件当前 owner 身份运行才能改 owner；改 group 则需是 owner 或 root
- macOS 要求 UID/GID 必须真实存在于系统数据库（如
/etc/passwd），填个不存在的数字会失败 - Docker 容器内若以非 root 启动，
os.Chown几乎必然失败，除非启用了 user namespace remapping - 多数场景下，与其事后硬改属主，不如在创建文件时就控制：用
syscall.Umask(0)+os.OpenFile(..., 0644)确保初始权限和上下文一致
批量读取并修改属性推荐用 filepath.WalkDir 而非 filepath.Walk
filepath.Walk 已被标记为 legacy，官方推荐用 filepath.WalkDir ——它更轻量、不递归进入不可读目录、且回调函数接收 fs.DirEntry，避免额外 os.Stat 调用。
-
fs.DirEntry自带IsDir()和Info()，可先过滤再决定是否深入，减少系统调用 - 对每个匹配文件调用
entry.Info()获取权限/属主信息，比反复os.Stat更高效 - 若需跳过特定目录（如
node_modules、.git），在回调中直接返回filepath.SkipDir - 注意：遍历中不要做耗时操作（如网络请求、大文件读取），只收集路径或元数据，后续再并发处理
批量修改前务必检查设备号，否则 os.Rename 跨分区必失败
用 os.Rename 批量重命名或移动文件时，如果源和目标路径不在同一挂载点（比如从 /home 移到 /mnt/usb），会返回 invalid cross-device link 错误——这不是 bug，是 Unix 文件系统限制。
- 必须提前用
os.Stat获取源与目标路径的Stat.Sys().(*syscall.Stat_t).Dev，比较设备号是否一致 - 设备号不同时，改用
io.Copy+os.Remove组合：先完整复制内容，再校验字节数是否与源文件大小一致，最后删除原文件 - 复制后建议调用
dstFile.Chmod和dstFile.Chown显式同步属性，因为io.Copy不继承权限和属主 - 这个检查步骤极易被跳过，尤其在脚本化批量任务中——一旦出错，原文件已删、新文件不全，数据就丢了
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
