应使用 defaultdict(set) 而非 dict 或 defaultdict(list)；文档 ID 统一转为 int 以节省内存、加速运算；需预过滤停用词并设频次阈值防内存爆炸；多词交集查询应按集合大小升序排列后用 & 运算符。
倒排索引该用 dict 还是 defaultdict？
直接用 dict 手动检查键存在性（if term not in index: index[term] = set()）性能差，尤其在高频插入场景下。改用 defaultdict(set) 是更优解——它避免了每次查找开销，且 set 支持 O(1) 去重与合并。但注意：不要用 defaultdict(list) 替代，除非你明确需要保留重复 doc_id 或顺序；多数检索场景中重复和顺序无意义，反而拖慢后续交集运算。
文档 ID 该存 int 还是 str？
统一用 int 存储文档 ID。原因很实际：
- 内存占用小：一个
int（如 32 位 ID）比等长字符串节省 50%+ 内存
- 集合运算快：
set.intersection() 在整数集合上比字符串集合快 2–3 倍（CPython 底层哈希更轻量）
- 序列化友好：转成
array.array('I') 或写入二进制文件时更直接
如果原始 ID 是 UUID 或路径字符串，务必在构建索引前映射为单调递增整数（例如用 dict 维护 str → int 映射表），别把字符串塞进倒排表。
如何避免内存爆炸？
倒排索引最容易在“高频通用词”（如 "the"、"a"、"的"）上吃光内存。必须做两项硬控制：
- 预过滤停用词：加载索引前先用固定
set 过滤掉已知停用词，别依赖运行时判断
- 设置词频/文档频阈值：丢弃只在 1 个文档中出现、或总词频 if len(posting_list) ）
- 对超长 posting list 启用压缩：若某词命中 > 10000 个文档，考虑改用
array.array('I') + 差分编码（delta encoding），而非裸 set
不设阈值的全量索引，在百万级文档下极易突破 10GB 内存。
查询时怎么快速求多个词的交集？
别写循环嵌套求交：result = a & b & c 比 a.intersection(b).intersection(c) 快，因为前者由 C 层优化。更关键的是顺序：把最小的 posting set 放最左，例如 small_set & medium_set & large_set，能显著减少中间结果大小。可以用 sorted(posting_lists, key=len) 预排序，但仅当列表数量 ≤ 5 时值得做——排序开销会抵消收益。超过 5 个词 AND 查询，建议改用堆合并（heapq.merge）配合游标遍历，避免构造巨型临时集合。
倒排索引的性能瓶颈往往不在算法多炫，而在数据表示是否“贴近机器”：整数 ID、紧凑容器、提前裁剪、操作符优先级——这些细节漏掉一个，吞掉几 GB 内存或慢上十倍，都悄无声息。
int 存储文档 ID。原因很实际：
- 内存占用小：一个
int（如 32 位 ID）比等长字符串节省 50%+ 内存 - 集合运算快：
set.intersection()在整数集合上比字符串集合快 2–3 倍（CPython 底层哈希更轻量） - 序列化友好：转成
array.array('I')或写入二进制文件时更直接
dict 维护 str → int 映射表），别把字符串塞进倒排表。
如何避免内存爆炸？
倒排索引最容易在“高频通用词”（如 "the"、"a"、"的"）上吃光内存。必须做两项硬控制：
- 预过滤停用词：加载索引前先用固定
set 过滤掉已知停用词，别依赖运行时判断
- 设置词频/文档频阈值：丢弃只在 1 个文档中出现、或总词频 if len(posting_list) ）
- 对超长 posting list 启用压缩：若某词命中 > 10000 个文档，考虑改用
array.array('I') + 差分编码（delta encoding），而非裸 set
不设阈值的全量索引，在百万级文档下极易突破 10GB 内存。
查询时怎么快速求多个词的交集？
别写循环嵌套求交：result = a & b & c 比 a.intersection(b).intersection(c) 快，因为前者由 C 层优化。更关键的是顺序：把最小的 posting set 放最左，例如 small_set & medium_set & large_set，能显著减少中间结果大小。可以用 sorted(posting_lists, key=len) 预排序，但仅当列表数量 ≤ 5 时值得做——排序开销会抵消收益。超过 5 个词 AND 查询，建议改用堆合并（heapq.merge）配合游标遍历，避免构造巨型临时集合。
倒排索引的性能瓶颈往往不在算法多炫，而在数据表示是否“贴近机器”：整数 ID、紧凑容器、提前裁剪、操作符优先级——这些细节漏掉一个，吞掉几 GB 内存或慢上十倍，都悄无声息。
set 过滤掉已知停用词，别依赖运行时判断array.array('I') + 差分编码（delta encoding），而非裸 set
result = a & b & c 比 a.intersection(b).intersection(c) 快，因为前者由 C 层优化。更关键的是顺序：把最小的 posting set 放最左，例如 small_set & medium_set & large_set，能显著减少中间结果大小。可以用 sorted(posting_lists, key=len) 预排序，但仅当列表数量 ≤ 5 时值得做——排序开销会抵消收益。超过 5 个词 AND 查询，建议改用堆合并（heapq.merge）配合游标遍历，避免构造巨型临时集合。
倒排索引的性能瓶颈往往不在算法多炫，而在数据表示是否“贴近机器”：整数 ID、紧凑容器、提前裁剪、操作符优先级——这些细节漏掉一个，吞掉几 GB 内存或慢上十倍，都悄无声息。
