Redis LCS 怎样读取两个字符串的公共子序列位置

Redis LCS key1 key2 IDX 返回最长公共子序列的匹配位置。每个匹配段包含第一字符串和第二字符串各自的起止索引，索引从 0 开始，终点包含在区间内；WITHMATCHLEN 可附带各段长度，MINMATCHLEN 可过滤短段。公共子序列允许中间有间隔，不能把这些区间理解为一段连续公共子串。

官方地址：https://redis.io/docs/latest/commands/lcs/

先确定需要的是子序列位置

考虑比较两份短文本并高亮共同部分的场景。普通 LCS 返回匹配内容，LEN 返回总长度，IDX 才给出两份原文中的位置。如果只拿匹配字符串再次搜索原文，重复文本可能让高亮落在错误位置；位置模式更适合表达具体对应关系。

这里的匹配保持相对顺序，但不要求相邻。例如本例第一串 AXBYC 与第二串 ABC 的公共子序列是 ABC，第一串中的三个匹配字节中间夹着 X、Y。它不会因为两处有间隔，就只选其中一个字节。

用 IDX 取得两边的匹配区间

以下命令供读者在支持 LCS 的测试实例使用，键值都为本次原创短示例。本文没有启动 Redis，也没有把推导结果包装成执行回执。当前独立 LCS 命令从 Redis Open Source 7.0.0 提供。

# 独立演示键设置短期过期时间，不与业务正文混用。
redis-cli SET 'demo:{lcs175}:left' 'AXBYC' EX 300
redis-cli SET 'demo:{lcs175}:right' 'ABC' EX 300

# 默认得到子序列，LEN 只取长度，IDX 读取位置与总长度。
redis-cli LCS 'demo:{lcs175}:left' 'demo:{lcs175}:right'
redis-cli LCS 'demo:{lcs175}:left' 'demo:{lcs175}:right' LEN
redis-cli LCS 'demo:{lcs175}:left' 'demo:{lcs175}:right' IDX WITHMATCHLEN

按给定 ASCII 数据推导，三对单字节匹配位置分别为左侧 [0,0] 对右侧 [0,0]、左侧 [2,2] 对右侧 [1,1]、左侧 [4,4] 对右侧 [2,2]，总长度为 3。这是在解释区间含义，不是实际运行输出。

IDX 结果包含 matches 与 len。匹配段按从后向前的顺序产生，因此渲染高亮时通常需要按起始位置整理顺序；不要直接假设返回列表已经从文首排到文尾。对闭区间 [start,end]，长度是 end-start+1；转换为程序常用的半开切片时，结束位置应为 end+1。

LEN 与 IDX 不应同时请求：IDX 已提供总长度。客户端应按使用的 RESP 协议和驱动返回对象解析字段，避免依赖 redis-cli 多行打印的布局。

过滤短匹配时怎样解释总长度

# 只展示至少两个字节的连续匹配段，并附带每段长度。
redis-cli LCS 'demo:{lcs175}:left' 'demo:{lcs175}:right' IDX MINMATCHLEN 2 WITHMATCHLEN

上例各段都只有一个字节，过滤后 matches 可以为空，但 len 仍描述整个 LCS 的长度，不能把空匹配段列表当成“没有公共子序列”。MINMATCHLEN 用于过滤展示的段，不会重新定义最长公共子序列算法，让它改求某个更长的连续子串。

有多种同长度最优解时，不宜把某个重复片段的具体选中位置当成跨实现的唯一业务标准。需要可复现的展示策略时，应把原文版本、参数与服务实现约定一并纳入结果上下文。

把字节索引映射回文本显示

Redis 的字符串匹配按字节进行。ASCII 示例中一个字节恰好对应一个显示字符，中文、表情和其他多字节编码则不满足这个条件。不能把 IDX 的偏移直接当作 JavaScript 字符串的字符索引，也不能随意在 UTF-8 字节中间截断再解码。

需要面向人的文本差异显示时，应保留原始编码字节与显示位置之间的映射，并确认匹配段落在完整编码边界上。对于按字素簇、单词或语义单位对比的需求，可能更适合在独立文本处理层实现，不应假设一个字节 LCS 自动具备这些语言规则。字节级比较行为可从 Redis 官方字符串命令实现看到。

对原文做 Unicode 正规化、换行统一或其他预处理后，偏移属于处理后的版本。若页面展示的还是未处理原文，必须维护映射；不能简单复用处理后索引。保存一个版本标识或内容指纹，也有助于防止旧位置被应用到新正文。

控制大输入的计算与结果生命周期

LCS 的时间复杂度为 O(N×M)，N、M 为两份字符串长度。两边同时增长会迅速放大计算量，返回很少的区间也不意味着计算便宜。官方文档建议限制到很小的字符串，或使用独立实例承载这类工作。

调用入口应限制单串字节数、两串长度乘积和并发量。MINMATCHLEN 减少展示内容，不能被当作消除了整个动态规划成本。对于文档级差异、大批量比较或交互式高频编辑，可以把计算移到独立工作服务，Redis 仅保存短文本版本或结果缓存；这是架构取舍，不是经过本次压测得出的性能结论。

结果缓存应绑定两份原文的版本和全部匹配参数。输入过期或更新后，旧 matches 不能继续用于新文本。缺失键、空文本、错误类型和命令执行失败应由业务接口分别表达，避免把没有数据误报成内容完全不同。

IDX 的 end 是否包含最后一个字节？包含，所以半开切片的结束位置需要加 1。

过滤后 matches 为空但 len 不为 0，是错误吗？不一定。总子序列可能由多个短段组成，而这些短段都被阈值隐藏了。

只需要共同字符数量，可以用 LEN 吗？可以用它获取 LCS 长度，但应记住它是顺序相关的字节子序列长度，不能当成语义相似度或字符集合交集数量。

选项及返回格式参考 Redis LCS 官方文档。