ZRANGEBYLEX能做前缀补全，因其唯一支持字典序范围扫描，只比较member字符串本身；需统一哨兵前缀、score设为0、member为纯ASCII字符串，并规范min/max参数构造。
为什么 ZRANGEBYLEX 能做前缀补全
因为 ZRANGEBYLEX 是唯一支持字典序范围扫描的 Redis 命令，它不看 score，只比 member 字符串本身——这正好匹配“输入 abc，找 abc* 开头的所有词”的需求。前提是所有 member 必须是纯字符串、且插入时统一加了哨兵字符（比如 + 或 [），否则空字符串、数字开头的词会错位。
- 必须用
ZADD插入时 score 全设为 0（或任意相同值），否则ZRANGEBYLEX不生效 - member 不能含非 ASCII 字符或空格（除非你明确测试过排序行为），Redis 字典序基于字节比较，中文会按 UTF-8 编码排，可能不符合预期
- 如果补全词带特殊符号（如
@、.），得确认它们在 ASCII 表里的位置是否影响范围边界
怎么构造 ZRANGEBYLEX 的 min/max 参数
参数不是简单写 "abc" 和 "abc\xff" 就完事。Redis 字典序范围是左闭右闭，且 \xff 并不总是安全的“最大字节”——尤其当你的词本身以高位字节结尾时。更可靠的是用 + 作为哨兵前缀，再用 [ 开头表示包含边界。
- 插入时统一加前缀：用
ZADD autocomplete 0 "+apple" 0 "+application" 0 "+abc" - 查
"ab"开头：min ="+ab"，max ="+ab\xff"—— 这里\xff是字节 255，确保覆盖所有后续字符 - 更稳妥写法：max =
"+ab\u{ffff}"（实际发命令时还是"+ab\xff"，因为 Redis 只认字节） - 别用
"[ab"和"[ac"，那是老式区间写法，容易漏掉"abz"这类长词
为什么补全结果顺序不对或缺词
常见原因是没控制 member 长度或没做归一化。Redis 对 "a" 和 "aa" 的字典序判断没问题，但如果你存的是 "user:123" 和 "user:456"，而用户输的是 "user:"，那确实能扫出来；可一旦混入 "users"，它就会排在 "user:999" 后面（因为 : ASCII 是 58，s 是 115），导致补全列表跳变。
- 所有待补全词建议转小写 + 去首尾空格后再存，避免
"Apple"和"apple"被当成两个词 - 长度差异大的词（如
"go"和"golang"）天然满足前缀关系，无需额外截断，但要注意ZRANGEBYLEX返回的是完整 member，得自己切掉前缀再返回给前端 - 如果业务需要模糊匹配（比如拼音首字母），
ZRANGEBYLEX无能为力，得换 Trie 或向量索引
性能和线上踩坑提醒
ZRANGEBYLEX 时间复杂度是 O(log N + M)，N 是 zset 总量，M 是返回结果数。看着还行，但真到百万级词+高频请求时，每次扫几百个结果，网络+序列化开销就上来了。更麻烦的是，它不支持 offset/limit 的高效分页——LIMIT 0 10 是从扫描结果里硬切，前面的匹配项越多，越慢。
- 务必对 zset 做
KEYS autocomplete*级别监控，防止单 key 膨胀到千万级 - 别在主从架构里对同一个 zset 频繁
ZADD+ZRANGEBYLEX，从库延迟会导致补全结果短暂不一致 - 生产环境建议加缓存层：把
"ab*"这种高频前缀的结果缓存几秒，哪怕过期也比每次都扫快 - 如果发现
ZRANGEBYLEX返回空但你知道有数据，先ZRANGE autocomplete 0 -1看原始数据格式，八成是哨兵字符或编码对不上
真正难的不是写对那条命令，而是让所有写入路径都遵守同一套编码、前缀、归一化规则——少一个环节，补全就断在某个用户输入上。
