bisect模块不直接返回查找结果，仅返回插入位置索引；判断存在性需用bisect_left获取索引后，检查索引是否越界且arr[i]等于目标值。
bisect 模块不能直接返回查找结果，它只返回插入位置索引；想查是否存在某个值，得自己拿索引去比对。
为什么 bisect_left 和 bisect_right 返回的索引可能不同？
这两个函数处理重复元素的方式不同：bisect_left 返回最左侧可插入位置（即该值首次出现的位置），bisect_right 返回最右侧可插入位置（即该值最后一次出现之后的位置）。
比如列表 [1, 2, 2, 2, 3] 中查找 2：
-
bisect_left(..., 2)返回1 -
bisect_right(..., 2)返回4
差值 4 - 1 就是 2 出现的次数。这个特性常被用来统计频次，而不是单纯判断存在性。
立即学习“Python免费学习笔记（深入）”；
如何用 bisect 正确判断某个值是否在有序列表中？
不能只调用 bisect_left 就完事——它返回的是“应该插入的位置”，不是“是否找到”。必须额外做一次索引边界检查和值比对。
正确写法示例：
import bisect <p>def contains(arr, x): i = bisect.bisect_left(arr, x) return i < len(arr) and arr[i] == x</p><h1>测试</h1><p>nums = [1, 3, 5, 7, 9] print(contains(nums, 5)) # True print(contains(nums, 4)) # False
注意三点：
- 必须检查
i ，否则访问 <code>arr[i]可能越界（比如查一个比所有元素都大的数） - 不能用
arr[i] == x代替i ，因为后者可能先触发 IndexError - 不要用
bisect.insort或bisect_right替代，逻辑不等价
bisect 的性能优势在哪？什么时候别用它？
它底层是二分查找，时间复杂度 O(log n)，比 x in list 的 O(n) 快得多——但前提是列表已经有序。
容易踩的坑：
- 传入无序列表时，结果完全不可靠（不会报错，但返回的索引没意义）
- 如果只是偶尔查一次，而列表本身还要频繁修改，维护有序成本可能高于线性扫描
- 浮点数比较时要注意精度问题，
bisect_left依赖运算符行为，某些自定义对象需实现 <code>__lt__
真正适合它的场景：静态或低频更新的有序数据，且查询密集——比如预加载的时间戳索引、离散配置区间映射表。
