bisect模块设计初衷是为插入服务而非查询，故bisect_left和bisect_right返回插入位置而非布尔值；判断存在需先获取pos = bisect.bisect_left(a, x)，再检查pos < len(a) and a[pos] == x。
bisect 模块不能直接返回查找目标的索引或布尔结果，它只返回插入位置 —— 所以想“查找是否存在”，必须手动比对。
为什么 bisect_left 和 bisect_right 返回的不是 True/False？
bisect 的设计初衷是为插入服务，不是查询。它假设你已知列表有序，只负责告诉你“如果要插，该插哪儿”。所以：
- bisect_left(a, x) 返回第一个 ≥ x 的位置
- bisect_right(a, x) 返回第一个 > x 的位置
两者相等时，说明 x 不在列表中；不等时，中间那段索引全对应 x 的出现位置。
判断元素是否存在的正确写法
别用 bisect_left 返回值直接当“找到”的标志（比如 if bisect_left(a, x) != -1 是错的 —— 它从不返回 -1）。正确做法：
- 先调用
pos = bisect.bisect_left(a, x) - 检查
pos是否越界：pos - 再检查
a[pos] == x
完整一行可写成：pos 。例如：
import bisect a = [1, 3, 5, 7, 9] x = 5 pos = bisect.bisect_left(a, x) found = pos < len(a) and a[pos] == x # True
用 bisect.insort 维护有序列表时的陷阱
很多人以为 bisect.insort_left(a, x) 就是“安全插入”，但要注意：
立即学习“Python免费学习笔记（深入）”；
- 它不检查
x类型是否与a元素兼容 —— 插入字符串到数字列表会直接报TypeError - 它不检测列表是否真有序 —— 如果
a已乱序，插入后仍乱序，后续所有bisect调用结果不可靠 - 插入操作时间复杂度仍是 O(n)，因为 Python 列表底层是数组，挪动元素开销大
如果你频繁插入+查找，考虑改用 sortedcontainers.SortedList（第三方），而非硬撑 bisect + list。
替代方案：什么时候不该用 bisect？
不是所有“有序查找”场景都适合 bisect：
- 列表长度 x in a 更快（C 层优化，且避免函数调用开销）
- 需要同时支持增删查，且数据量大 →
set或dict的 O(1) 查找更合适（即使你要的是“有序”，也可额外维护一个排序键） - 列表是
array.array或 NumPyndarray→ 用对应库的搜索函数（如np.searchsorted），bisect对它们无效
真正发挥 bisect 价值的场景很窄：你有一份静态或低频更新的纯 Python list，又必须保持插入后有序，并高频做位置定位 —— 这时它的语义清晰、无依赖、零安装成本才是优势。
