go中设文件权限须创建时指定而非依赖os.chmod，因后者跨平台失效（windows忽略执行位与组/其他权限），且需预检os.stat、处理符号链接、注意umask影响；细粒度acl需系统调用，web服务权限控制应落于应用层而非文件系统。
Go 项目本身不自动管理文件权限，权限问题全由操作系统和你的代码行为决定。直接用 os.WriteFile 或 os.OpenFile 创建文件时若没显式设权限，会受系统 umask 影响，很可能生成 0666、0777 这类宽泛权限，导致其他用户可读甚至可写——这不是 Go 的错，是你没拦住它。
创建文件时必须一步设好权限，别等写完再 chmod
很多开发者习惯先写文件，再调 os.Chmod 改权限，这中间存在时间窗口：敏感内容（如 token、私钥）可能已被其他用户读取。正确做法是创建即锁定权限。
-
os.WriteFile("token.txt", data, 0600)：推荐用于密钥、凭证类文件，所有者可读写，其余人无权访问 -
os.OpenFile("log.json", os.O_CREATE|os.O_APPEND, 0644)：日志类适用，组和其他人只读 - 权限值必须是八进制字面量：
0644✅，644❌（会被解释为八进制 1204） - Windows 上执行位（x）被忽略，
0755和0644效果可能一样，只认读/写语义
多进程写同一文件？sync.Mutex 完全无效
sync.Mutex 只锁当前进程内的 goroutine，对其他进程、K8s Pod、cron 脚本完全不起作用。两个 ./app 同时跑，各自持有一个互斥锁，但都往 data.json 写，结果就是覆盖、截断、乱码。
- 真正有效的跨进程文件锁：Linux/macOS 用
syscall.Flock（建议性锁），Windows 用windows.LockFileEx - 更省心的方案是用
github.com/gofrs/flock：自动适配平台，API 统一，锁文件路径可独立（如data.json.lock） - 初始化后调
fileLock.TryLock()非阻塞获取，失败时err == nil && !locked，不是 panic - 务必
defer fileLock.Unlock()，否则 panic 会导致锁残留
锁的临界区要窄，别把网络请求、JSON 解析塞进去
文件锁不是万能胶水，它的作用范围应严格限制在“打开→加锁→写入→关闭”这一小段。任何耗时操作（HTTP 请求、数据库查询、sleep、复杂解析）都得挪到锁外。
- 错误示范：打开文件 → 加锁 →
http.Get(...)→ 写入 → 关闭 → 解锁 - 正确顺序：先做所有准备（拉数据、拼内容），再开锁、写、关，全程毫秒级
- 锁持有时间越长，并发吞吐越低；锁范围越大，冲突概率越高
- 重命名文件前必须先解锁，否则新进程按原路径打开的是空文件，旧锁还挂在已重命名的文件上
权限和锁是两件事：前者控制谁能看到内容，后者控制谁能在何时写。最常被忽略的是——你写了 0600，但没加锁，别人虽然读不了，却可能用另一个进程清空它；你加了 flock，但权限是 0666，别人虽不能写，却能直接 cat 出来。两者必须同时到位，且各自独立生效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
