直接用 list.append() 再 list.sort() 效率低，因每次全量排序达 o(n log n)；bisect.insort() 用二分查找定位再插入，省去重复排序开销，实测千级元素以上优势明显。
为什么直接用 list.append() 再 list.sort() 不行
因为每次插入后都全量排序，时间复杂度是 O(n log n)，而维护一个已排序列表的典型需求（比如实时插入日志时间戳、维护优先级队列的轻量变体）往往要求单次插入控制在 O(log n) 查找 + O(n) 位移——bisect.insort() 正是为此设计：它先用二分法定位插入点，再调用 list.insert() 完成偏移，整体仍是 O(n)（受限于插入本身），但省去了重复排序的开销，实测在千级元素以上就能明显感知差异。
常见错误现象：my_list.append(x); my_list.sort() 在循环中使用，结果 CPU 占用高、响应变慢；或者插入后顺序错乱，其实是没注意 sort() 默认升序，而原始列表可能含 float('inf') 或自定义对象导致排序异常。
bisect.insort() 和 bisect.insort_left() 有什么区别
核心在于相等元素的插入位置：当目标值 x 已存在于列表中，insort() 等价于 insort_right()，会把新元素插到所有相同元素的右侧；insort_left() 则插到最左侧。这对实现稳定排序或处理带时间戳的重复键很重要。
- 若列表是
[1, 2, 2, 3]，执行bisect.insort(my_list, 2)→[1, 2, 2, 2, 3]（新2在末尾两个2之后） - 执行
bisect.insort_left(my_list, 2)→[1, 2, 2, 2, 3]（新2在开头两个2之前） - 两者性能无差异，选哪个取决于业务语义：比如按“首次出现优先”就用
insort_left，按“最新写入靠后”就用默认insort
插入自定义对象时必须重载 __lt__ 而不是 __eq__
bisect 模块内部只做小于比较（），不调用 <code>== 或 __eq__。如果类没定义 __lt__，会抛 TypeError: '。
示例：
class Event:
def __init__(self, time, msg):
self.time = time
self.msg = msg
def __lt__(self, other):
return self.time events = []
bisect.insort(events, Event(3.5, "start"))
bisect.insort(events, Event(1.2, "init")) # 自动按 time 排序
容易踩的坑：__le__、__gt__ 不起作用；用 functools.total_ordering 可以减少样板代码，但底层仍依赖 __lt__。
别忽略 insort 的原地修改特性与并发风险
bisect.insort() 直接修改原列表，不返回新列表。这和 sorted() 的行为相反，误写成 new_list = bisect.insort(old_list, x) 会导致 new_list 是 None。
更隐蔽的问题是并发：如果多个线程共享同一列表并调用 insort，会出现竞态——二分查找位置和实际 insert 之间列表可能已被其他线程修改。此时不能靠 bisect 自身解决，必须外加锁：
import threading lock = threading.Lock() <p>with lock: bisect.insort(shared_sorted_list, new_item) </p>
另外，insort 对 array.array 或 deque 无效，只支持普通 list；如果数据量极大（>10⁵），应考虑 sortedcontainers.SortedList 这类专为频繁插入优化的结构，而非硬撑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
