go中unlock必须通过锁实例调用且仅能在已加锁后执行，否则panic；因依赖内部状态校验，未持锁或重复解锁均触发fatal error；defer mu.unlock()是保障成对调用的工程底线。
Go 里没有线程，也没有独立的 Unlock 函数；Unlock 是 sync.Mutex 和 sync.RWMutex 类型的方法，必须通过锁实例调用，且只能在已成功 Lock 或 RLock 后调用，否则 panic。
为什么不能直接调用 Unlock？
Go 的 Unlock 不是全局函数，也不是系统级 API。它是结构体方法，依赖锁对象内部状态（如 state 字段）判断是否持有锁。直接调用或在未加锁时调用，会触发运行时 panic：
fatal error: sync: unlock of unlocked mutex
-
sync.Mutex.Unlock()要求该 goroutine 当前已持有写锁（即之前调用了Lock()且未被其他 goroutine 抢占） -
sync.RWMutex.RUnlock()要求当前有活跃读锁（即已调用RLock()且未被配对释放） - 同一个 goroutine 重复调用
Unlock也会 panic —— 锁不绑定 goroutine，但状态校验严格
defer mu.Unlock() 是最安全的释放方式
不是“推荐”，而是事实上的工程底线。因为：
- 函数可能有多个返回路径（正常 return、error early exit、panic recover），
defer覆盖全部 - 避免手写
Unlock被遗漏、被注释掉、或被错误地移到条件分支外 - 即使在
Lock后立即 panic（比如 defer 前发生 panic），defer仍会执行 —— 但注意：如果 panic 发生在Lock之前，defer Unlock就成了未持锁解锁，照样 panic
正确写法：
mu.Lock() defer mu.Unlock() // 紧跟 Lock 后，无空行、无条件包裹
错误写法示例：
if cond {
mu.Lock()
defer mu.Unlock() // ❌ 条件内 defer，cond 为 false 时不执行，cond 为 true 时又可能提前 return 导致锁未释放
}
读写锁的 RUnlock 容易被忽略的细节
sync.RWMutex 的读锁释放比写锁更隐蔽，问题也更难排查：
- 每个
RLock必须配一个RUnlock，少一次就会导致后续写操作永久阻塞（因为读计数不归零） -
RUnlock不检查调用者是否是加锁者，只减计数；所以跨 goroutine 释放读锁合法，但极易漏写 - 不能用
defer rw.RUnlock()在循环里反复加读锁的场景 —— defer 只注册一次，不是每次迭代都 defer
典型陷阱：
for _, item := range items {
rw.RLock() // 每次循环都加读锁
process(item)
// 忘了 rw.RUnlock() → 读计数持续上涨，最终写操作永远等不到机会
}
释放失败的真实表现不是报错，而是卡死
忘记 Unlock 或漏写 RUnlock，程序不会立刻崩溃，而是：
- 后续尝试
Lock的 goroutine 在Lock调用处无限阻塞（表现为 CPU 低、goroutine 数暴涨、无 panic） - 用
go tool trace或pprof/goroutine可看到大量 goroutine 停在sync.runtime_SemacquireMutex - 读写锁下，漏
RUnlock可能只影响写操作，读操作照常 —— 这让问题更隐蔽
真正难调试的，从来不是 panic，而是那个没被释放的锁 —— 它安静得像不存在，却让整个并发流程停摆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
