直接用list.sort()不适合频繁插入，因其每次O(n log n)且破坏稳定性；bisect.insort()更优，查找O(log n)、插入O(n)，语义清晰；insort_right()插在相等元素右侧，insort_left()插在左侧；手动定位再insert易出错，除非需索引本身；性能瓶颈在list插入而非二分查找。
为什么直接用 list.sort() 不适合频繁插入场景
每次插入新元素后调用 list.sort()，时间复杂度是 O(n log n)，而实际只需要 O(n) 的插入位置查找 + O(n) 的内存搬移。更糟的是，排序会破坏原有相等元素的相对顺序（稳定排序虽可配置，但没必要绕路）。bisect 模块专为“维持有序”设计，所有操作都基于二分查找，查找部分是 O(log n)，插入仍是 O(n)（由底层 list 决定），但常数项更低、语义更清晰。
bisect.insort() 和 bisect.insort_left() 的区别在哪
两者都把值插入到有序列表中并保持有序，关键差异在**相等元素的插入位置**：insort()（即 insort_right()）把新值插在所有相等元素的右侧；insort_left() 插在左侧。这对后续用 bisect_left()/bisort_right() 查找边界很重要。
- 如果列表里已有
[2, 4, 4, 6]，插入4： -
bisect.insort_right(a, 4)→[2, 4, 4, 4, 6]（新4在末尾两个4右边） -
bisect.insort_left(a, 4)→[2, 4, 4, 4, 6]（新4在开头两个4左边）
多数场景用 insort() 就够了；只有你需要严格控制相等元素的相对顺序（比如实现优先队列中“先来先服务”的同优先级逻辑），才需选 insort_left()。
插入前用 bisect.bisect_left() 手动定位再 list.insert() 有必要吗
没必要。除非你同时需要插入位置索引做其他事（比如记录插入点、触发回调、或批量插入时预计算所有位置），否则直接用 insort() 更安全。手动组合容易出错：比如忘记传对列表引用、索引越界、或在多线程下被并发修改——而 insort() 是原子操作（单线程语义下）。
立即学习“Python免费学习笔记（深入）”；
一个典型误用：
pos = bisect.bisect_left(a, x) a.insert(pos, x) # 看似等价，但中间若 a 被改写就崩了
真正需要手动定位的场景极少，比如你要统计某个值插入后左边有多少个严格更小的元素，这时才取 pos 值本身。
性能瓶颈其实在 list 插入本身，不是 bisect 查找
bisect 查找快得几乎可以忽略（log₂(10⁶) ≈ 20 次比较），真正的开销来自 list.insert() —— 它要移动插入点之后的所有元素。如果你频繁插入且数据量大（>10⁴），考虑换数据结构：
- 插入极少、查询极多？用
sortedcontainers.SortedList（Cython 加速，均摊O(log n)插入） - 需要范围查询或按秩访问？
blist.sortedlist或手写平衡树（不推荐） - 只是偶尔维护有序，且能接受 O(n) 插入？坚持用
bisect.insort()最简单可靠
别为了省下那几十纳秒的查找时间，去自己实现二分逻辑——标准库已足够好，出错成本远高于收益。
