sync.Map仅适用于读多写少、key分散且无过期淘汰需求的轻量场景，如配置热更新；写频次超10次/秒或需过期机制时，应选用带RWMutex的普通map或专业缓存库。
用 sync.Map 还是自己加锁的 map？
多数轻量级场景下，直接用 sync.Map 是错的。它专为“读多写少 + key 分散”设计，但内部有额外指针跳转和类型断言开销；而你如果只是存几十到几百个配置项、会话或临时状态，一个带 sync.RWMutex 的普通 map[string]interface{} 反而更快、更可控。
常见错误：以为 sync.Map “天然线程安全就一定更好”，结果在小规模写频次稍高的场景（比如每秒几十次 Store）下，性能反而比加锁 map 低 20%～30%。
- 写操作频繁（>10 次/秒）且 key 数量 map +
sync.RWMutex - key 极多（>10w）、写极少、读极多 → 再考虑
sync.Map - 需要支持过期时间 →
sync.Map不行，必须自己维护 timestamp 字段或换库（如github.com/patrickmn/go-cache）
goleveldb.OpenFile 打不开目录就 panic？
goleveldb.OpenFile 不会自动创建父目录，传入路径不存在或权限不足时，返回的 error 可能是 os.ErrNotExist 或 os.ErrPermission，而不是 nil。很多人只判 err != nil 就 panic，却没区分具体原因，导致本地调试正常、部署到容器里就挂。
正确做法是显式处理路径准备：
立即学习“go语言免费学习笔记（深入）”；
- 调用前先
os.MkdirAll(dirPath, 0755)，别依赖 LevelDB 自建目录 - 检查
err是否为leveldb.ErrClosed、os.IsPermission(err)或os.IsNotExist(err)，分别记录日志并提示 - Windows 下路径含空格或中文没问题，但别用
syscall.UTF16FromString转 —— 直接传 Go 原生string即可
Key/Value 必须是 []byte，但别乱用 []byte(s)
goleveldb.Put 和 goleveldb.Get 的 key 和 value 参数类型固定为 []byte。Go 字符串能隐式转切片，但底层共享底层数组 —— 如果你传的是一个长生命周期变量（比如全局 config 字符串），LevelDB 内部可能复用缓冲区，导致该字符串内容被意外覆盖。
这不是 bug，是 LevelDB 的内存复用策略。安全写法只有两种：
- 对每次调用都做显式拷贝：
db.Put([]byte(key), []byte(value), nil) - 高频写场景（如计数器）用
sync.Pool管理[]byte缓冲，但注意重置cap或调用bytes.Buffer.Reset()，否则 Pool 中残留的 slice 长度不可控 - 绝对不要对
value做unsafe.Pointer强转结构体 —— LevelDB 只存字节流，不认 Go 类型系统
迭代器不 Release() 就 leak fd
db.NewIterator 返回的 *leveldb.Iterator 是资源持有者，底层绑定了文件描述符和内存映射。它不实现 io.Closer，但必须手动调用 it.Release()（不是 Close），否则运行几小时后大概率触发 “too many open files”。
典型错误：写个 for it.Next() { ... } 循环完就退出，忘了释放。
- 正确姿势：用
defer it.Release()包裹整个逻辑块 - 如果循环中途
break或return，也要确保it.Release()被执行（可用if it != nil { it.Release() }守卫） -
it.Release()是幂等的，可重复调用；但it.Next()在Release()后会 panic
真正麻烦的不是选哪个库，而是搞清数据要不要落盘、要不要过期、要不要并发写原子性 —— 这些需求一旦模糊，后面所有优化都是白搭。
