go分布式锁需避免锁提前释放与业务未完成失锁，静态ttl无法适配动态负载，须用唯一value+lua脚本原子续期，并由独立看门狗协程保活，推荐redsync/v4或etcd lease。
Go语言处理分布式锁过期挑战，核心在于避免“锁提前释放”和“业务未完成却失锁”导致的并发覆盖。context.WithTimeout不能解决这个问题，因为它只控制单次调用超时，不续租锁本身。
锁过期与业务耗时不匹配是根本矛盾
固定TTL（如10秒）看似简单，但实际中业务耗时波动大：GC停顿、网络抖动、磁盘IO延迟都可能让任务超过预设时间。结果就是锁被自动清除，其他节点趁机加锁，两个goroutine同时操作同一资源——比如重复扣库存、生成重复订单。
- 超时设太短：正常流程被中断，失去互斥性
- 超时设太长：节点崩溃后锁长期滞留，资源无法被抢占
- 动态负载下，静态TTL无法自适应
手动续期必须带所有权校验
续期不是简单调用PEXPIRE，而是要确认“这把锁现在还归我”。Redis里常见错误是直接用SET key value EX seconds续期，忽略了value可能已被别人覆盖。
- 加锁时value必须是全局唯一标识，推荐uuid.NewString() + goroutine ID组合
- 续期用EVAL脚本原子比对value再PEXPIRE，例如：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("PEXPIRE", KEYS[1], ARGV[2]) else return 0 end - 避免用GET+EXPIRE两步操作，中间可能被抢占
独立看门狗协程负责保活
主业务逻辑和续期逻辑不能共享状态变量，否则容易因panic、return或竞态导致续期失效。正确做法是启动一个独立goroutine，在租约到期前反复刷新。
- 续期间隔建议设为TTL的1/3～1/2（如TTL=30s，每10～15s续一次）
- 使用time.Ticker驱动，避免time.Sleep精度误差累积
- 在业务结束前显式通知看门狗退出，防止goroutine泄露
- etcd的Lease.KeepAlive是服务端自动续期，Redis需完全由客户端实现
优先选用成熟封装库降低风险
自己手写易出错，尤其在异常路径（如网络断开、redis返回空响应）下续期失败难察觉。生产环境推荐用经过验证的库：
- redsync/v4：支持自动重试、带唯一value、Lua解锁脚本，可配合自定义续期逻辑
- go-redlock：Redlock算法实现，适用于多Redis实例场景，提升容错
- 若用etcd，直接用官方clientv3的Lease机制，KeepAlive流天然支持心跳续期
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
