Go中修改文件权限需先确保文件关闭，再用os.Chmod；Windows仅支持ModeReadOnly等有限标志，跨平台应使用os.ModeReadOnly按位操作，临时文件重命名可避免句柄占用问题。
Go 中写入文件后如何修改权限（chmod）
Go 语言里，文件写入完成后修改访问属性，本质是调用操作系统级别的 chmod 操作。关键点不是“写入后才改”，而是“确保文件已关闭且句柄释放”，否则在 Windows 上可能报 The process cannot access the file because it is being used by another process。
最稳妥的做法是：先用 os.WriteFile 或 *os.File.Write 写完并显式调用 Close()，再用 os.Chmod 修改权限。
-
os.WriteFile是原子写入，内部自动处理打开/关闭，适合小文件，写完即可直接os.Chmod - 用
os.OpenFile手动控制时，必须确认Close()已执行 —— 常见疏漏是 defer 放在函数开头但写入中途 panic，导致没真正关闭 - 权限值用八进制整数表示（如
0644），不是字符串"644"；Go 会按os.FileMode解析，写错成644（十进制）会导致权限异常
Windows 下修改权限的注意事项
Windows 不支持类 Unix 的读/写/执行三位权限模型，os.Chmod 在 Windows 上只影响两个标志：os.ModeTemporary 和 os.ModeReadOnly。其他位（如用户/组/其他执行位）会被忽略。
典型表现：
立即学习“go语言免费学习笔记（深入）”；
- 对普通文件设
os.Chmod(path, 0755)，实际只生效只读位（即去掉只读属性），其余数字被丢弃 - 若想设为只读，用
os.Chmod(path, 0444)或更明确地os.Chmod(path, os.ModeReadOnly) - 不要依赖
0755在 Windows 上“启用执行”，那没有意义；可执行性由文件扩展名（.exe、.bat）和系统策略决定
跨平台一致设置只读/可写的安全写法
如果目标只是控制“能否编辑”，而非模拟 Unix 权限，应避免硬编码八进制模式，改用 os.ModeReadOnly 与按位操作组合：
// 设为只读（Windows 和 Unix 都生效） os.Chmod(path, 0644|os.ModeReadOnly) // 实际等价于 0444 // 清除只读（恢复可写） info, _ := os.Stat(path) os.Chmod(path, info.Mode()&^os.ModeReadOnly)
这样写的好处是：不假设底层权限位布局，兼容 os.Stat 返回的实际模式，也绕过 Windows 对非只读位的静默忽略。
注意：os.ModeReadOnly 在 Unix 上对应的是用户位的读标志（即 0400），但它在不同系统上语义一致 —— 表示“禁止修改内容”。
为什么 os.WriteFile 后立刻 os.Chmod 有时失败？
常见于 Windows + 病毒查杀软件或 OneDrive/Google Drive 同步进程正在扫描新文件。此时 os.Chmod 报错 Access is denied，不是 Go 的 bug，而是文件仍被其他进程句柄占用。
- 加短暂重试（100ms × 3 次）比盲目 sleep 更可靠
- 不要用
time.Sleep固定等待，尤其在 CI 环境中 I/O 延迟不可控 - 若必须强一致性，改用
os.Rename原子替换：先写入临时文件（xxx.tmp），Chmod完再Rename覆盖原文件 —— 此时原文件句柄已无关联，干扰最小
临时文件方案看似多一步，但在生产环境尤其是 Windows 上，反而更少出问题。权限变更和文件可见性这两个动作，物理上分离比挤在同一个路径上更健壮。
