random.choices() 不够用是因为权重频繁更新或采样次数远大于样本数时，每次采样需 O(n) 扫描，总复杂度达 O(k×n)，且无法复用预处理；需支持快速单次采样与动态更新的数据结构，如别名法（静态 O(1) 采样）或基于 SortedList 的前缀和（动态 O(log n) 更新与采样）。
为什么直接用 random.choices() 不够用？
当权重频繁更新（比如在线推荐系统实时调整 item 权重），或采样次数远大于样本数时，random.choices() 每次都需 O(n) 扫描全部权重，总时间复杂度变成 O(k×n)，k 是采样次数。它不维护内部状态，无法复用预处理结果。
真正需要的是支持「快速单次采样 + 动态权重更新」的数据结构，典型解法是别名法（Alias Method）或带权线段树——前者静态构建快、采样 O(1)，后者支持 O(log n) 更新和采样。
用 alias_method 实现静态加权采样（权重不变时首选）
Alias Method 预处理 O(n)，采样 O(1)，空间 O(n)，适合权重固定、采样高频的场景（如游戏掉落表、A/B 测试流量分发）。
- 不要自己手写别名表构造逻辑——容易在小数精度和边界上出错；用成熟实现，比如
numpy.random.Generator.choice()底层已优化，但只支持静态权重；更稳妥的是alias-method第三方包（pip install alias-method） - 构造时传入权重列表，它会自动归一化并建表：
from alias_method import AliasMethod<br>weights = [0.1, 0.3, 0.6]<br>am = AliasMethod(weights)<br>sample_idx = am.sample() # 返回 0/1/2 中的一个整数
- 注意：权重必须全为非负数，且不能全为 0；若含浮点误差导致 sum ≠ 1，该库会自动重归一化，但建议提前检查
sum(weights)
用 sortedcontainers + 前缀和实现动态加权采样
当权重会增删改（比如用户行为实时影响 item 权重），Alias Method 就不适用了。此时用平衡 BST 维护前缀和，每次采样走二分查找，更新则需 O(log n) 插入/删除/修改节点。
立即学习“Python免费学习笔记（深入）”；
Python 没有内置平衡树，但 sortedcontainers.SortedList 可模拟：存 (prefix_sum, index) 对，用 bisect_left 查找。
- 避免手动维护前缀和数组——插入/删除元素时要整体平移，O(n) 太慢
- 用
sortedlist存累积权重，每次更新权重时：先删旧 (old_prefix, idx)，再插新 (new_prefix, idx)，最后调用sl.bisect_left(rand_val) - 更轻量的替代：用
bisect+ 列表，但仅适用于「更新极少、采样极多」场景；一旦有更新就得重建整个前缀和列表，O(n) 重建成本高 - 第三方库
weighted-random封装了类似逻辑，但内部仍是 list + bisect，不支持高效更新
权重更新频繁时，为什么不用 heapq 或 dict？
有人尝试用堆（heapq）按权重排序后采样，或者用字典存权重再遍历——这两者都踩了典型坑：
-
heapq无法按权重随机采样：堆只保证 top-K 最大/最小，不提供按概率分布取样能力；强行用它做加权采样得先转成轮盘赌式累积和，又回到前缀和问题 -
dict存权重 +random.random()后遍历累加判断：最坏 O(n) 每次采样，且无法利用索引加速，纯属退化为暴力扫描 - 真正要支持动态更新，核心是「能快速定位累积和阈值位置」+「能局部修改累积和」，只有基于有序结构（BST / SortedList）或树状数组（Fenwick Tree）才能兼顾二者
Alias Method 的预处理开销和内存占用常被低估；而动态结构里，sortedcontainers.SortedList 的插入/删除实际是 O(n)（因底层是 list），只是均摊常数低——真到万级 item 且每秒百次更新时，得换 C 扩展或 rbtree 类库。
