题目重点：低延迟候选索引与个性化排序分离，冷前缀也要有回退。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练给用户输入prefix返回TopK完整query，实际语言、规模、个性化与规则未给。
- query日志可能含敏感信息，候选不能直接把所有用户输入公开复用。
解题路线
- 事件聚合query规范化/频次/时效，清理机器人与异常刷量，保留语言和地区；敏感/不适合公开建议的query按定义过滤。规范化不丢地区/语言意义。
- 候选用trie/FST或prefix→TopK缓存，热门prefix预计算，长尾从索引获取。频次随窗口衰减，实时trend独立流汇入，避免一次异常爆发占满建议。
- 排序结合prefix匹配、频次、时效和上下文，可选择是否个性化；候选及排序需明确延迟预算，不能在线遍历所有queries。去重与多样性避免同义改写占满列表。
- 用户每键输入都可能请求，client debounce/取消加request sequence，旧prefix结果不覆盖新输入。server缓存按语言/地区/version及公开/个人scope，个人历史不进共享cache。
- 评价keystrokes saved、成功搜索、建议接受与误建议/延迟，按prefix长度、语言及冷启动切片。点击率高可能诱导错误query，需要最终任务成功与安全护栏。
手动走一遍
用户从ca输入cat，ca的慢响应晚到不能覆盖cat建议。prefix只有1字母频繁热点，用公开TopKcache，但包含个人历史时需个人隔离。
规模与取舍
候选检索约O(prefix length+候选数)，rank O(Kfeatures)，索引空间依query数/共享前缀。按键请求放大与热门prefix峰值需单算。
易错点与追问
容易失分的边界
- 整库每次startswith扫描。
- 把个人query日志直接变成所有人建议。
继续深挖
- 实时热点如何快速出现又防刷量？
- 拼写纠错和中文拼音多路候选怎样保持低延迟？
