watch不是锁而是乐观并发控制机制，需配合手动重试才能实现锁语义；直接调用会因未处理redis.txfailederr及未重试导致事务失败或静默错误。
Watch 不是锁，它只是 Redis 提供的乐观并发控制机制。go-redis 的 Watch 方法封装了这一能力，但必须配合手动重试才能真正落地为“锁”语义——不重试就等于没用。
为什么直接调用 Watch 会失败？
Redis 的 WATCH 命令本身不阻塞、不加锁，只在 EXEC 时检查被监控 key 是否被其他客户端修改过。一旦有变更，整个事务返回 (nil)（v8/v9 中表现为 redis.TxFailedErr），而 go-redis 的 Watch 方法默认不重试，直接把错误抛给上层。
- 常见错误现象：
Transaction failed: redis: tx failed或静默失败（没处理 error 导致业务逻辑继续执行旧值） - 根本原因：没捕获
redis.TxFailedErr，也没做重试循环 - 注意：
Watch监控后若 key 被修改，后续所有EXEC都会失败，直到重新WATCH
如何写一个带重试的 Watch 事务函数？
必须显式包裹重试逻辑，且重试次数要有限制，避免无限循环。典型结构是 for i := 0; i + <code>break on success。
- 每次循环都要重新调用
rdb.Watch(ctx, fn, keys...)，不能复用上一轮的tx - 回调函数
fn内部不能依赖外部变量状态（比如缓存的旧值），每次都要从tx.Get重新读取 - 示例关键片段：
const maxRetries = 5 for i := 0; i
Watch 和 SETNX / Lua 锁的本质区别
Watch 是事务级校验，适合「读-改-写」类操作；SETNX 或 Lua 脚本是资源抢占式加锁，适合需要排他执行长流程的场景。
-
Watch不阻塞其他客户端读写，冲突时靠重试解决；SETNX成功即获得独占权，失败需主动等待或放弃 -
Watch无法防止 ABA 问题（key 被改两次又改回原值），Redis 不记录版本号，只看最终值是否变化 - 高并发下，
Watch重试开销可能比 Lua 锁更大，尤其当冲突频繁时；但实现更轻量，无租约管理负担 - 不要混用：
Watch监控的 key 如果同时被SETNX锁住并修改，依然会触发事务失败
真正容易被忽略的是：每次 Watch 失败后，你读到的 key 值已经过期，必须在下一轮重试中重新 GET，而不是沿用上一次缓存的值——这是多数人写出竞态 bug 的根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
