rlocker不能直接传给函数作“只读锁”用，因其仅为*sync.rwmutex的代理视图，生命周期依赖原mutex；一旦原mutex被回收、重置或提前解锁，rlocker调用lock/unlock即panic。
为什么 RLocker 不能直接传给函数做“只读锁”用？
因为 RLocker() 返回的是一个实现了 sync.Locker 接口的匿名结构体，它把 RLock() 和 RUnlock() 封装成 Lock()/Unlock()，但底层仍依赖原 *sync.RWMutex 实例。一旦原 RWMutex 被回收或生命周期结束，RLocker 就会 panic —— 常见于闭包捕获、goroutine 携带或返回后继续使用。
典型错误现象：fatal error: sync: RUnlock of unlocked RWMutex 或 panic: sync: RLock/RLocker called on uninitialized RWMutex，尤其在函数返回 RLocker 后，调用方误以为可长期持有。
-
RLocker不是独立锁，只是原RWMutex的视图代理 - 不能跨 goroutine 长期持有，也不能脱离原 mutex 生命周期存在
- 函数参数接收
sync.Locker时，传入mu.RLocker()是合法的，但必须确保调用期间mu有效且未被重置
重构只读场景：用 RLocker 替换 RLock/RUnlock 的安全模式
目标不是“收窄粒度”，而是让只读逻辑更清晰、避免忘记 RUnlock；真正收窄锁粒度靠的是拆分数据结构或用更细粒度的 mutex，RLocker 只是辅助手段。
正确做法是：在确定只读、且作用域明确（如单次函数调用）的前提下，把 RLocker() 作为参数传入，由被调函数统一管理读锁生命周期。
- 被调函数内部调用
locker.Lock()和locker.Unlock()，语义上仍是读操作 - 调用方无需显式
RLock/RUnlock，减少出错可能 - 必须保证被调函数执行完前，原
RWMutex不被Write操作重置或重新分配
示例：
func readWithLocker(data *MyData, locker sync.Locker, fn func()) {
locker.Lock()
defer locker.Unlock()
fn()
}
// 安全调用
mu.RLock() // ← 这里其实多余，但常见误写
readWithLocker(d, mu.RLocker(), func() {
fmt.Println(d.field)
})
// mu.RUnlock() ← 绝对不能在这里补，否则 panic
RLocker 在 closure 和 goroutine 中的典型陷阱
最常踩的坑是把它塞进闭包或启动 goroutine 后异步使用——此时原 RWMutex 可能早已解锁甚至被回收。
- 闭包中捕获
mu.RLocker()并延迟执行？危险。应改为在闭包内即时调用mu.RLock()+defer mu.RUnlock() - goroutine 中传入
mu.RLocker()？除非你能 100% 确保 goroutine 结束前mu一直有效且未被写操作干扰，否则改用mu.RLock()+ 显式defer - struct 字段存
sync.Locker？不要。字段应存*sync.RWMutex，需要只读时现场调RLocker()
错误示例：
locker := mu.RLocker()
go func() {
locker.Lock() // mu 可能已 RUnlock 或被 Write 锁覆盖
defer locker.Unlock()
use(data)
}()
替代方案：什么时候该放弃 RLocker，直接用 RLock？
当只读逻辑跨多个函数、或涉及条件分支、或需与写操作协调时，RLocker 的封装反而增加理解成本和风险。
- 分支逻辑中部分路径要读、部分要写？别传
RLocker，直接用mu.RLock()/mu.Lock()显式区分 - 需要在 defer 前判断是否真要读？
RLocker强制你先取再用，不如按需RLock - 性能敏感场景？
RLocker有极小开销（接口动态 dispatch），但通常可忽略；真正瓶颈在锁竞争本身
说到底，RLocker 是个便利工具，不是锁粒度优化器。想收窄粒度，得从数据结构拆分、分片、或用 sync.Map 等无锁/低锁方案入手。
最容易被忽略的一点：很多人以为 RLocker 能“自动升级为写锁”，它完全不能。读写锁升级在 Go 里不支持，强行混用会死锁或 panic。
