谈到搜索框中的自动补全功能，Redis 的 ZRANGEBYLEX 命令无疑是一个绕不开的经典选项。它的核心机制是纯前缀字典序扫描，直接基于 member 字符串进行检索，而非像普通 ZSET 那样依赖 score。这一独特优势，也正是它容易被误用的根源——要想发挥其真正威力，技术门槛并不低。
简要来说，ZRANGEBYLEX 是 Redis 中唯一天然支持纯前缀字典序扫描的命令，但如果直接采用 f"[{prefix}" 和 f"[{prefix}xff" 这种写法，极易出现漏词或排序紊乱。问题的根本在于 member 的设计策略以及边界范围的精确构造。
为什么 ZRANGEBYLEX 能胜任前缀补全，却又频频失效？
关键取决于它的比较逻辑——忽略 score，只按字节逐一比对每个 member 字符串本身。从原理出发，这天然适合“找出所有以 abc 开头的词”这类场景。然而，你的数据必须满足以下几个硬性前提：
一是所有 member 必须为纯 ASCII 字符串。如果涉及中文，务必转换为拼音首字母，否则 UTF-8 编码下的排序结果完全不可控。二是所有 member 的 score 必须完全统一，通常建议全部设为 0，否则命令行为未定义。三是数据中不得混入空格、控制字符或类似 \u4f60 的高位字节开头字符串，因为 Redis 按字节比对，而非 Unicode 归一化规则。另一个易被忽略的细节：如果你存储了 "user:123" 和 "users"，当用户输入 "user:" 时，"users" 不会被扫描到，这是由于冒号的 ASCII 码是 58，而字母 s 是 115，"users" > "user:"。
member 存储什么、如何存储才能确保准确？
直接存储原始词是新手常犯的错误。正确的做法是对 member 进行归一化处理：
— 统一转为小写，例如 "Apple" → "apple"
— 去除首尾空格，如 " python " → "python"
— 添加统一的哨兵前缀，推荐使用 "+"，比如 "apple" → "+apple"，这能有效防止空字符串或数字开头的词干扰排序结果
— 注意，只存储完整单词，无需存储所有前缀变体（如 "a", "ap", "app"），而是利用命令的 min/max 边界参数来限定范围
一个标准插入命令示例：ZADD autocomplete 0 "+apple" 0 "+application" 0 "+abc"
min 和 max 参数如何编写才能安全可靠？
这个环节最容易出错。一种常见错误是使用 "[ab" 和 "[ab\xff"。虽然 \xff 被广泛使用，但在某些边界情况下会引发问题，例如当单词本身以 \xff 结尾时，就会越界。
正确的做法是结合哨兵与字典序后继字符来构造：
— min = "+ab"（左闭区间，命令中必须携带方括号 [）
— max 不能简单设为 "+ac"，否则像 "abz" 这样的词会被遗漏
— 目前比较稳妥的方案是使用 "[+ab" 和 "[+ac" 配合哨兵设计，确保所有 "ab*" 都落在 [+ab, +ac) 区间内
— 实际调用方式为：ZRANGEBYLEX autocomplete "[+ab" "[+ac"（注意双引号与方括号必须正确传递）
— 如果未加哨兵前缀，而词中混有数字或符号，排序很可能混乱。例如，"app" 和 "app2" 这两个词，在缺少哨兵时，由于 2 的 ASCII 码是 50，而 a 是 97，结果会是 "app2" 排在 "app" 之前。
线上高频查询时容易被忽视的性能细节
最后，谈谈性能。虽然 ZRANGEBYLEX 的复杂度为 O(log N + M)，看起来不高，但一旦数据量达到百万级别，且每秒有上千次查询时，几个小细节就会在压力下被放大：
— 返回结果数 M 如果过大，会严重拖慢整个链路，包括网络序列化与前端渲染。因此，务必加上 LIMIT 0 10。
— 忘记设置 EXPIRE 是另一个常见问题。我们曾见过有的团队让补全库占满了 16GB 内存。建议设置一个过期时间，例如 EXPIRE autocomplete 86400。
— 中文场景下，如果未做拼音转换，"北京" 和 "保定" 这两个词在 UTF-8 下的字节序为 E58C97E4 和 E4BFB9E5，排序结果从语义上看完全不可理解。
— 另一个性能陷阱是不要先调用 ZLEXCOUNT 来预估词条数量再查询。这等于对同一范围做了两遍扫描，开销直接翻倍。
