sync.mutex 无法用于分布式锁，因其仅限单进程内生效，跨实例时各服务持有独立锁，无法保证全局互斥；分布式锁需满足唯一持有、自动续期与异常释放三大要求。
为什么不能直接用 sync.Mutex 做分布式锁
因为 sync.Mutex 只在单进程内有效，跨机器、跨进程完全不感知。你起 10 个服务实例，每个都拿到自己的 sync.Mutex，锁根本没意义——多个实例仍可同时写入 DB 或触发重复任务。
分布式锁的核心约束是：**同一时刻，只有一个客户端能持有锁，且锁必须具备自动续期和异常释放能力**。否则容易出现死锁、脑裂或任务重复执行。
常见错误现象：
– 服务崩溃后锁未释放，后续所有请求卡住
– 锁过期时间设太短，业务还没做完锁就丢了，导致并发写入
– 多个客户端误判自己“成功加锁”，实际只有一个是真持有者（缺乏原子性校验）
用 Redis + SET key value EX seconds NX 实现加锁
Redis 的 SET 命令支持原子性设置带过期时间的 key，且 NX 保证只在 key 不存在时才设置——这是实现分布式锁最轻量、最可靠的基础原语。
关键细节：
-
value必须是唯一标识（如 UUID），不能写死字符串，否则无法安全解锁（防止 A 加锁、B 误删） -
EX时间不是越长越好：建议 30–60 秒，太长容错差，太短需配合自动续期 - 不要用
GET + DEL解锁：非原子操作，可能删掉别人刚续上的锁 - 解锁必须用 Lua 脚本，校验
value相等再删，例如：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end
如何避免锁被意外提前释放（续期与看门狗）
业务处理时间不确定，硬设一个固定过期时间风险高。正确做法是启动一个后台 goroutine，在锁过期前定期续期（renew），也就是“看门狗”机制。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
续期条件：
- 仅当当前 goroutine 仍是锁持有者（比对本地
value和 Redis 中值） - 续期频率建议为过期时间的 1/3（如锁 30s，每 10s 续一次）
- 续期失败（如 Redis 不可用）应主动释放锁并报错，避免悬挂
- 业务函数结束前必须显式调用
Unlock()，不能依赖超时自动释放
注意：续期本身也要防重入——同一个锁实例只能有一个续期 goroutine 运行，可用 sync.Once 或状态字段控制。
Golang 客户端封装要点（基于 github.com/go-redis/redis/v9）
别手写一堆 Do() 调用，封装成结构体更可控。核心字段至少包括：client（Redis 客户端）、key、value（随机 token）、expiry、stopRenew（chan 控制续期退出）。
实操建议：
- 加锁方法返回
bool, error，false表示抢锁失败（不阻塞，由上层决定是否重试） - 提供
TryLock(ctx, timeout)支持超时等待，内部用time.Ticker轮询，但轮询间隔 ≥ 50ms，避免打爆 Redis - 解锁方法必须检查
value是否匹配，不匹配直接返回 error，不静默失败 - 所有 Redis 命令调用必须传入
ctx，以便网络超时或取消时及时中断
复杂点往往藏在边界：服务重启时旧锁还在 Redis 里、网络分区导致部分节点认为自己持锁、Lua 脚本执行失败却没被 client 捕获——这些都得靠日志 + value 追踪 + 运维清理脚本来兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
