文件操作不能靠“先判断再执行”是因为 os.stat 与 os.create 组合存在竞态，导致重复创建或覆盖；应使用 os.o_create | os.o_excl 原子创建，windows 需降级方案；幂等写入还需基于内容指纹校验。
文件操作为什么不能靠“先判断再执行”
因为 os.Stat + os.Create 或 os.WriteFile 的两步组合，在并发或重试场景下必然出现竞态：两个 goroutine 同时 os.Stat 返回 No such file，接着都创建同名文件，结果就是重复写入、覆盖丢失或权限错乱。这不是小概率事件，而是确定性行为——尤其在批量上传、日志归档、配置热更新等场景中高频发生。
- 别用
if _, err := os.Stat(path); os.IsNotExist(err)做前置判断后写入，这中间存在不可消除的时间窗口 -
os.WriteFile默认是覆盖语义，即使文件已存在也会无条件覆写，无法区分“首次创建”和“重复提交” - 本地文件系统没有原子性的“存在则跳过，不存在则写入”原语，必须靠外部协调或封装逻辑补足
用 syscall.Open + O_EXCL | O_CREAT 实现原子创建
Linux/macOS 下真正可靠的文件幂等创建，得绕过 Go 标准库封装，直接调用底层 open(2) 系统调用，带上 O_EXCL 标志。它能保证“文件不存在才成功创建，存在则立刻失败”，整个过程由内核原子完成，不依赖任何中间状态。
- Go 中需用
syscall.Open（Unix）或os.OpenFile配合os.O_CREATE | os.O_EXCL | os.O_WRONLY，例如：fd, err := os.OpenFile(path, os.O_CREATE|os.O_EXCL|os.O_WRONLY, 0644)
- 如果
err != nil且os.IsExist(err)为 true，说明文件已存在，可直接跳过业务逻辑或返回已存在状态 - Windows 不支持
O_EXCL语义，os.OpenFile在 Windows 上会忽略该 flag，此时必须降级为“创建临时文件 + rename”或引入进程级互斥（如flock文件锁） - 成功获取
*os.File后，务必用defer fd.Close()，否则句柄泄漏会导致后续OpenFile失败
幂等写入需区分“内容不变”和“文件存在”
仅防止文件被重复创建不够——用户可能多次提交相同内容，但期望只保留一份；也可能提交不同内容，却因幂等逻辑误拒。真正的幂等写入，要基于内容指纹做判断，而非仅看文件路径是否存在。
- 对小文件（os.ReadFile），计算 SHA256，再与新内容哈希比对；一致则跳过写入
- 对大文件，避免全量读取，改用分块哈希（如每 1MB 计算一次 SHA256，最后合并）或客户端预传
X-Content-Sha256header，服务端只校验不计算 - 不要用
os.Chtimes更新时间戳来“假装写入”，这会破坏文件变更追踪（如 inotify/watchdog） - 写入前若发现文件存在且内容一致，应返回
200 OK并附带Etag，而不是201 Created，语义才准确
分布式文件操作必须引入外部协调器
单机 O_EXCL 在多实例部署下完全失效：A 实例检查文件不存在并开始写入，B 实例在同一毫秒也做同样判断，结果仍是双写。此时必须把“文件是否已被处理”这个状态外置到共享存储。
- 首选方案是 Redis
SetNX，key 为file:idempotent:{bucket}:{object_key}，value 存客户端传的X-Idempotency-Key，TTL 设为写入超时 + 安全余量（如 300 秒） - Redis 故障时不能 fallback 到“放行”，必须返回
503 Service Unavailable，否则文件一致性彻底失控 - 数据库唯一索引只能兜底：在元数据表（如
file_uploads）上建UNIQUE (bucket, object_key, idempotency_key)，插入失败时查表确认是否真已成功 - 别用 NFS 或 SMB 共享目录做“天然分布式文件系统”——它们不提供跨节点的原子
open(O_EXCL)保证，仍需额外加锁
O_EXCL 只解决第一个，后面两个必须靠哈希或外部状态机。而一旦跨进程，本地文件操作就不再是“本地”问题。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
