文件任务分发仅适用于单机多进程、离线批处理、边缘设备或降级兜底等特定场景，因文件系统无分布式一致性保障，易致重复消费、任务丢失或竞态冲突；必须满足共享文件系统、原子操作（如os.rename）、可校验回退等硬约束，否则应优先选用redis或etcd。
为什么不用 Redis 或 ETCD，而选文件做任务分发
文件系统本身不具备分布式一致性保障，直接用文件做任务分发容易出现重复消费、任务丢失或竞态冲突。只有在特定场景下才合理：单机多进程协作、离线批量处理、无中心依赖的边缘设备、或作为降级兜底方案。如果你的部署环境连轻量级服务（如 Redis）都跑不了，又必须让多个 Go 进程协同处理一批任务，文件才是折中选择。
核心约束得先立住：所有进程共享同一份文件系统（如 NFS 或本地磁盘），且文件操作需原子、可校验、可回退。否则不如直接改架构。
os.Rename 是唯一靠谱的“原子提交”方式
Linux 下重命名文件是原子操作（只要源和目标在同一文件系统），这是实现“任务领取”最可靠手段。别用 os.WriteFile 直接覆盖，也别用 os.Create + Write，这些都会导致中间态可见，引发多个进程读到不完整任务。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 任务定义存为 JSON 文件，命名形如
task_123.json - 待领取目录：
pending/；已领取目录：claimed/；完成目录：done/ - 领取逻辑就是：
os.Rename("pending/task_123.json", "claimed/task_123.json")，成功即视为抢到任务 - 失败时捕获
syscall.EBUSY或os.ErrNotExist，说明已被抢走，直接跳过
如何避免任务卡在 claimed/ 目录不挪走
进程崩溃、OOM 或 panic 会导致任务文件滞留在 claimed/，后续无人处理。不能靠心跳或超时清理——文件系统没状态反馈。必须靠“执行前写标记 + 执行后双步提交”：
- 领取后，立即在
claimed/task_123.json同目录生成临时标记：claimed/task_123.json.lock - 执行完任务，先写结果到
done/task_123.result.json，再删掉.lock文件，最后os.Rename把原任务文件移进done/ - 启动时扫描
claimed/，对每个*.json.lock检查对应任务是否已在done/存在结果；若不存在，且锁文件距今超 5 分钟，就把它挪回pending/（视为失败重试）
并发轮询的节奏和资源消耗怎么控
轮询不是越快越好。time.Sleep(100 * time.Millisecond) 在多数场景已足够，频繁 stat 会打满 NFS inode cache 或触发 ext4 日志刷盘压力。更稳的做法是结合 fsnotify 监听 pending/ 目录事件，但要注意：
-
fsnotify不保证事件顺序，也不保证一次创建只触发一次事件，需自己 dedup（比如用 map[string]struct{} 缓存最近 10 秒内的文件名） - NFS 上
fsnotify可能失效或延迟高，此时 fallback 到固定间隔轮询 - 每个 worker 进程应限制最大并发领取数（如最多同时处理 3 个任务），用带缓冲 channel 控制：
sem := make(chan struct{}, 3)
文件路径权限、NFS 的 noac 挂载选项、以及 claimed/ 目录的 sticky bit 设置（防止非 owner 删除他人任务），这些细节漏掉一个，上线后就会出 silent failure。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
