sync.RWMutex对文件操作无效，因其仅同步内存变量访问，无法控制多goroutine对同一文件描述符的并发I/O；真正防护需用syscall.Flock等内核级文件锁或路径隔离设计。
读写锁（sync.RWMutex）本身不解决文件资源竞争——它只保护内存变量，对文件 I/O 无作用；真正要防的是多个 goroutine 同时读写同一个文件句柄或路径，这得靠文件系统级锁（如 syscall.Flock）或设计隔离。
为什么 sync.RWMutex 对文件操作无效
很多人误以为给一个 *os.File 或文件路径加 RWMutex 就能防止并发冲突，其实不是：
-
sync.RWMutex只同步 goroutine 对「内存中某个变量」的访问，比如map、结构体字段、缓存指针等 - 文件是操作系统资源，
*os.File是个封装了 fd 的句柄，多个 goroutine 拿到同一*os.File并发Write，底层会竞争同一 fd，RWMutex完全拦不住 - 即使你用
RWMutex锁住一个file *os.File变量，也只是阻止其他 goroutine 修改这个指针值，而非阻止它们调用file.Write()
真正有效的文件并发控制：用 syscall.Flock
Unix/Linux/macOS 下，syscall.Flock 是最轻量、内核级的文件锁方案，支持共享锁（读）和独占锁（写）：
- 获取共享锁：
syscall.Flock(int(file.Fd()), syscall.LOCK_SH)→ 多个 goroutine 可同时持有，但阻塞任何独占锁请求 - 获取独占锁：
syscall.Flock(int(file.Fd()), syscall.LOCK_EX)→ 仅允许一个持有，阻塞所有其他锁 - 锁与文件描述符绑定，进程退出或
Close()后自动释放，无需手动 unlock - 注意：Windows 不支持
Flock，需改用syscall.LockFileEx或跨平台库如github.com/gofrs/flock
高频多文件场景别锁文件，改用路径隔离 + 并发控制
如果你要并发处理成百上千个不同路径的文件（如日志轮转、批量上传），硬上文件锁反而拖慢吞吐。更合理的做法是：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 按文件路径哈希分片，每个 shard 独立 channel + worker，避免争抢同一文件
- 用带缓冲的
semaphore（例如golang.org/x/sync/semaphore）限制总并发数，防 open 文件数超限或磁盘 IO 打满 - 复用
*os.File：打开一次，供多个 goroutine 顺序读写（配合io.Copy或bufio.Reader），比反复 open/close 更高效 - 写临时文件 +
os.Rename原子提交，避免直接覆写导致读取中断
容易被忽略的坑：syscall.Flock 的 fd 生命周期
常见错误是把文件锁加在已关闭的 fd 上，或跨 goroutine 复用 fd 导致锁失效：
-
file.Fd()返回的 fd 在file.Close()后即失效，后续Flock调用返回EBADF - 不要把
*os.File存在全局变量里长期复用——文件可能被外部程序删/重命名，fd 会变成 dangling - 若需长时间持锁，建议在
OpenFile后立刻加锁，并在整个业务逻辑结束前保持 file 打开状态 - Go 1.22+ 中
os.File默认启用O_CLOEXEC，不影响Flock，但旧版本需确认是否被 fork 继承
文件锁不是加个 RWMutex 就完事的事；关键在区分「内存同步」和「系统资源协调」——前者用 Go 原语，后者必须交还给 OS。真正在意性能，就别让 goroutine 在 Flock 上排队，而是提前规划路径、限制并发、原子提交。
