文件队列因部署极简、无外部依赖，适合边缘设备或单机多进程协作；但不支持高并发写入、无原子广播与实时通知，本质是状态轮询+文件锁+序列化协议的组合。
为什么不用 Redis 或 Kafka，而选文件做任务队列
因为部署极简、无外部依赖、适合边缘设备或单机多进程协作场景。但必须接受：不支持高并发写入、无原子广播、无实时通知机制。文件队列本质是「状态轮询 + 文件锁 + 序列化协议」的组合，不是替代专业消息中间件，而是解决“够用且可控”的问题。
典型适用场景：docker-compose 单机多服务协同、IoT 设备本地任务调度、CI/CD 中构建产物分发前的轻量排队。
flock 锁文件时容易忽略的三个细节
Go 标准库不直接暴露 flock，得用 syscall.Flock 或封装好的第三方包（如 github.com/fsnotify/fsnotify 不适用——它监听变更，不保证写入顺序）。常见错误是只对文件句柄加锁，却没考虑多个进程打开同一路径时的句柄隔离问题。
- 必须用
os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0644)打开，不能用os.Create—— 后者默认只写，flock在只写模式下行为不可靠 - 加锁失败时不要立即 panic，应循环重试（带超时），否则一个卡住的消费者会让整个队列停滞
- 解锁必须在
defer之前显式调用syscall.Flock(fd, syscall.LOCK_UN)，Go 的defer在 panic 时可能不执行，导致死锁
任务序列化用 JSON 还是 Protocol Buffers
JSON 可读、调试方便，但字段缺失或类型错位易引发静默失败；Protobuf 体积小、校验强，但需要预定义 schema 且 Go 里需额外 .proto 编译步骤。实际选型取决于运维能力而非性能——单机文件队列吞吐瓶颈从来不在序列化，而在磁盘 I/O 和锁竞争。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
推荐折中方案：用 JSON，但强制校验关键字段：
type Task struct {
ID string `json:"id"`
Name string `json:"name"`
Args map[string]interface{} `json:"args"`
At int64 `json:"at"` // Unix timestamp
}
<p>func (t *Task) Validate() error {
if t.ID == "" {
return fmt.Errorf("missing id")
}
if t.At < time.Now().Unix() - 3600 {
return fmt.Errorf("task expired")
}
return nil
}避免用 interface{} 直接解码，始终走结构体 + Validate() 方法。
消费者如何避免重复消费和漏消费
文件队列没有 ACK 机制，靠「移动文件 + 原子重命名」模拟确认。典型流程：读取 pending/xxx.json → 处理 → 成功后 mv pending/xxx.json done/xxx.json。但 mv 在不同文件系统行为不一（例如 NFS 上非原子），所以必须用 os.Rename，它在同分区下才是原子的。
- 消费者启动时先扫描
done/目录恢复已成功任务的状态，再处理pending/ - 处理中崩溃？靠心跳文件或时间戳判断：若
pending/xxx.json的mtime超过 5 分钟，视为卡死，可迁移至retry/目录 - 绝不允许两个进程同时写同一个
pending/文件——所有写入必须经由单一生产者进程，或用中心化协调（如通过pidfile选举主写入者）
真正麻烦的不是代码，是当磁盘满、权限错、或者 umask 导致新文件不可读时，队列会静默卡住。上线前务必在目标环境跑一次 df -h 和 ls -l 检查目录权限链。
