sync.mutex不能解决分布式一致性问题，因其仅作用于单进程内存，跨节点时其他实例完全无法感知，导致并发操作同一资源；它不满足分布式锁必需的互斥性和容错性要求。
为什么直接用 sync.Mutex 不能解决分布式一致性问题
单机锁在多进程或跨节点场景下完全失效——sync.Mutex 只作用于当前进程内存，其他服务实例根本感知不到这个锁。你看到的“加锁成功”，只是本机 goroutine 拿到了本地互斥权，对集群里另一台机器上的同名订单处理逻辑毫无约束力。
- 现象：两个服务实例同时处理同一笔订单，库存扣减两次、状态被覆盖
- 本质：锁的粒度没脱离单机边界，不满足分布式锁的「互斥性」和「容错性」要求
- 误区：试图用
context.WithTimeout包裹本地锁，以为能防死锁——超时只影响本机调用链，不影响其他节点是否已上锁
RedisLock.Lock() 的原子性陷阱在哪
看似简单的 SETNX + EXPIRE 两步操作，在网络分区或 Redis 主从切换时会破坏原子性：第一步成功、第二步失败，导致锁永久存在（即“死锁”）。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 正确做法必须用 Lua 脚本封装
SET命令的EX和NX参数，例如：SET key value EX 30 NX - 值必须是全局唯一标识（如 UUID），不能是固定字符串，否则
Unlock时可能误删他人持有的锁 - 超时时间（TTL）要远大于业务执行最大耗时，但也不能过长——建议设为预估耗时 × 2 ~ 3 倍，避免故障节点长期霸占锁
etcd 实现分布式锁比 Redis 更可靠吗
是，尤其在强一致性场景下。etcd 基于 Raft 协议，写入需多数节点确认，天然支持线性一致性读；而 Redis 默认异步复制，主从切换期间可能丢失已 set 的锁。
- 关键差异：
etcd的lease机制自动续期，配合CompareAndSwap（CAS）实现锁抢占，比 Redis 的 TTL 被动过期更可控 - 代价：etcd 写延迟通常比 Redis 高 2~5ms，高并发抢锁场景下吞吐略低
- 适用场景：金融交易、库存扣减等不允许任何数据错乱的流程；Redis 更适合日志去重、缓存更新等容忍短暂不一致的场景
用 go.etcd.io/etcd/client/v3 实现可重入锁要注意什么
etcd 官方 client 不提供开箱即用的可重入锁（即同一线程多次加锁不阻塞），必须自己维护持有者标识和计数器——这很容易引入竞态。
- 不要在内存里存
lockCount：goroutine 切换或 panic 可能导致计数错乱 - 安全做法是把持有者 ID（如 goroutine ID + 时间戳）和计数一起序列化进 etcd value，每次
Unlock前先Get校验 - 更稳妥的替代方案：放弃可重入，改用业务层拆分——比如把“创建订单+扣库存”拆成两个独立锁，用不同 key，避免嵌套加锁
defer 捕获，网络超时或 SIGKILL 会导致锁滞留。必须搭配看门狗机制（如定期扫描过期锁并清理）或选用支持自动 lease 回收的后端（如 etcd）。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
