直接用LCS算法做文本差分效果差，因为其仅追求最长字符级匹配，不保留行/词边界、不建模编辑操作上下文，无法生成可读的增删改标记；实际diff需以行为单位切分、结合编辑距离与块对齐，LCS仅作为子模块而非完整解。
为什么直接用 LCS 算法做文本差分效果差？
因为标准 LCS 只找最长公共子序列，不保留行/词边界、不处理插入/删除的上下文，输出结果无法直接映射到可读的「增删改」标记。比如两段文本仅换行位置不同，LCS 可能返回一个跨行的字符序列，完全丢失结构信息。
实际文本差分（如 git diff 或 diff-match-patch）核心不是最大化匹配长度，而是最小化编辑距离（Levenshtein 扩展），并按行或按 token 切分后对齐。LCS 是其中一环，但必须配合回溯路径与块划分才能生成 human-readable 的差异。
用 github.com/yudai/gojsondiff 这类库前先看清它的适用边界
很多 Go 差分库（如 gojsondiff、textdiff）底层确实用了 LCS，但它们默认以「行」为单位切分，而非字符。这意味着：
- 两段文本若只有空格或缩进差异，会被当作整行不同 → 产生大量假阳性
- 大文件（>10MB）时，纯二维 DP 的
LCS会吃掉 O(n×m) 内存，Go runtime 可能触发 GC 频繁或直接panic: runtime: out of memory - 它们通常不暴露中间的
lcsMatrix或编辑脚本（edit script），无法定制高亮逻辑或合并冲突
手写轻量级行级差分：避开二维 DP，用 map[string]int 做预处理
如果只是比对配置文件、日志片段或小规模 Markdown，没必要硬上完整 Myers 算法。可以这样平衡效率与可读性：
立即学习“go语言免费学习笔记（深入）”；
先对两文本按行分割，用哈希加速匹配：
// linesA, linesB []string
lineToIndexA := make(map[string]int)
for i, line := range linesA {
if _, exists := lineToIndexA[line]; !exists {
lineToIndexA[line] = i
}
}
// 构造「候选匹配数组」：对 linesB 每行，查它在 linesA 中最早出现位置
matches := make([]int, len(linesB))
for i, line := range linesB {
if idx, ok := lineToIndexA[line]; ok {
matches[i] = idx
} else {
matches[i] = -1
}
}
再基于 matches 数组跑一次简化版最长递增子序列（LIS），得到最长公共子序列的行号映射 —— 时间复杂度 O(m log m)，空间 O(m)，比二维 DP（O(n×m)）友好得多。
注意点：
- 重复行会导致误匹配，可在
lineToIndexA中改用map[string][]int存所有位置，回溯时贪心选最靠右的未用索引 - 空行和纯空白行建议提前标准化（
strings.TrimSpace），否则"\n"和" \n"被视为不同 - 不建议对每行再做字符级 LCS：既慢又破坏语义，除非明确需要「行内加粗变化」这类粒度
真正要上线的差分服务，绕不开 myers.Diff + 自定义 Chunker
生产环境推荐直接用 github.com/sergi/go-diff，它实现了 Myers 差分算法（本质是优化过的编辑图最短路径），比朴素 LCS 更贴近真实 diff 行为。关键是要控制输入粒度：
不要传原始大字符串，而是自己实现 Chunker：
func SplitByBlankLine(text string) []string {
return strings.FieldsFunc(text, func(r rune) bool {
return r == '\n' && len(strings.TrimSpace(line)) == 0
})
}
然后对每个 chunk 调用 diff.NewTextDiff().Compare。这样既避免单次计算爆炸，又能保证「空行分隔的段落」整体移动被识别为 move 而非 delete+insert。
容易被忽略的细节：
-
go-diff默认区分大小写且不忽略空白，Compare前需统一strings.ToLower和strings.ReplaceAll制表符 - 它返回的
diffmatchpatch.Diff结构里，DiffEqual/DiffInsert/DiffDelete类型必须严格按顺序消费，跳过或重排会破坏上下文 - HTML 渲染时，
DiffInsert和DiffDelete的相邻块要合并（比如连续 3 行 insert 应包在一个<ins>里），否则 DOM 节点过多拖慢渲染
差分不是比谁匹配字符多，而是比谁更懂文本的「块意图」。LCS 是数学解，diff 是工程解 —— 选哪个，取决于你手里的文本长什么样、用户到底想看出什么变化。
