Go标准库无有序map和高性能B-Tree；sort+map仅适用于小数据临时有序遍历，手写B-Tree因并发安全、节点分裂合并、锁序死锁及Less函数严格弱序等复杂性，成本远超预期。
go 标准库没有有序 map，也不存在开箱即用的高性能 b-tree 实现；直接用 sort + map 做有序遍历是临时方案，数据量稍大或需频繁范围查询时就暴露性能短板。
为什么别自己手写 B-Tree 节点结构
从零实现一个正确、可分裂/合并、支持并发、满足严格弱序（Less）的 B-Tree，成本远超预期。比如 google/btree 的 Iterator 在遍历时被其他 goroutine 删除节点会直接 panic；而自己实现节点级锁又极易死锁（父子节点加锁顺序不一致）、漏掉边界 case（如根节点降阶、叶子合并后上溢）。
- 标准库无
BTreeMap，container/tree仅提供简单二叉搜索树，不自平衡 -
github.com/google/btree不处理任何并发，所有方法都是裸操作 - 手写
Less函数必须满足：对任意 a, b, c，若a 且 <code>b ，则必有 <code>a ；否则迭代器行为不可预测
选 tidwall/btree 还是 gods/trees/btree
tidwall/btree 更适合写多、需细粒度控制的场景；gods/trees/btree 更轻量，适合读多、内存紧凑、纯内存索引（如时间序列缓存）。
-
tidwall/btree提供Lock()/Unlock()接口，允许按子树加锁，避免全树阻塞；但 API 略重，需手动管理锁生命周期 -
gods/trees/btree默认线程不安全，但支持Iterator正向/反向遍历，且小数据集下实际比跳表更快（因 cache line 局部性更好） - 两者都不支持 JSON 序列化 —— 若需导出，得自己封装一层
MarshalJSON，把键值对转成[]struct{K, V interface{}}
如何避免 sync.RWMutex 包一层就上线
给 google/btree 外层套 sync.RWMutex 看似简单，实则吞吐归零：所有读写串行化，O(log n) 查找退化为 O(n) 等待锁。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 读多写少？优先考虑
sync.Map+ 预排序切片缓存（仅限无范围查询需求） - 写多？用
tidwall/btree并只在必要路径加锁（例如：仅在Insert和Delete时调用Lock()，Get和Ascend可不加锁） - 注意
AscendRange类方法内部可能修改迭代器状态，多 goroutine 并发调用需额外同步
替代方案：xcontainer/orderedmap 适合什么场景
它不是 B-Tree，而是基于双向链表 + 哈希 map 的插入序保持结构，Set/Get 是 O(1)，但 Iter 是稳定有序，不支持按键范围扫描或前驱/后继查询。
立即学习“go语言免费学习笔记（深入）”；
- 适合配置加载、API 响应字段保序、日志元数据记录等「顺序即插入顺序」场景
- 不适用于需要按字典序查
"user_100"到"user_200"的范围数据 - 它支持泛型和
json.Marshal，但底层仍是两份存储（map + list），内存占用比纯 B-Tree 高约 30%
B-Tree 的真正门槛不在插入逻辑，而在「什么时候不该用它」—— 如果你只需要按键升序遍历一次、数据量 sort.Keys + map 就够了；一旦涉及范围扫描、高并发写入、内存敏感，才值得引入 tidwall/btree 或 gods/trees/btree，并认真对待锁策略和 Less 定义。
