直接用 strings.Equal 无法发现行级变化，因其仅判断字符串是否完全相等，而实际场景需定位增删改的具体行；需按行切分、统一换行符、预处理空行，并借助 diff 算法或结构化 DiffOp 输出差异。
为什么直接用 strings.Equal 无法发现“行级变化”
字符串相等判断只回答“是否完全一样”，但实际场景中（比如配置文件更新、日志差异、Git patch 分析），你需要知道哪几行被删了、哪几行新增了、哪几行被修改过。Go 标准库不带 diff 工具，strings.Equal 或 == 比较只会返回 false，不告诉你差在哪。
行级比对的前提是把字符串按行切开：strings.Split(text, "\n")，但要注意：
- 最后一行是否含换行符会影响切分结果——
strings.Split不保留空尾行，而strings.SplitN(text, "\n", -1)更可靠 - Windows 和 Unix 换行符混用时（
"\r\n"vs"\n"），需统一预处理，否则同一行可能被切成两行 - 空行和仅含空白字符的行容易被忽略，但它们在某些场景（如 YAML 缩进、代码空行）是有意义的
用 Myers 算法简化版实现最小编辑距离行比对
不必从头手写完整 Myers，Go 生态已有轻量可用的实现，比如 github.com/sergi/go-diff 的 diffmatchpatch 包，它默认做字符级 diff，但传入行切片后可转为行级：
linesA := strings.SplitN(textA, "\n", -1) linesB := strings.SplitN(textB, "\n", -1) dmp := diffmatchpatch.New() diffs := dmp.DiffMain(strings.Join(linesA, "\x00"), strings.Join(linesB, "\x00"), false) // 再按 \x00 拆回行，映射到原始行号
更可控的做法是自己实现一个基于最长公共子序列（LCS）的简化版：遍历两行切片，用二维 DP 表算出编辑路径，然后回溯提取 Diff{Type: "delete", Line: 5} 这类结构。关键点：
立即学习“go语言免费学习笔记（深入）”；
- DP 表空间复杂度是 O(m×n)，对超长文本（>10k 行）要加限制或改用 Hirschberg 算法
- 比较函数不能只用
==，要考虑忽略空格、大小写等业务规则，建议封装成lineEqual(a, b string) bool - 插入/删除/替换三类操作中，“替换”其实可拆为“删+增”，但合并显示更符合人眼阅读习惯
输出格式怎么选：HTML patch 还是结构化数据？
如果你只是打印到终端或记录日志，返回 []struct{Type string; Line int; Content string} 最灵活；如果要嵌入 Web 页面做高亮对比，直接生成 HTML 容易踩坑：
-
html.EscapeString必须对每行内容单独调用，否则<会被当标签解析 - 添加 CSS class（如
diff-del/diff-add）时，别用内联 style，避免 XSS 风险 - 行号对齐依赖
<pre>+white-space: pre，但长行会溢出，需加overflow-x: auto
推荐先产出结构化 diff 结果，再按需渲染：
type DiffOp struct {
Type string // "add", "del", "mod"
LineA int // 原始文本行号（从 1 开始）
LineB int // 新文本行号
Content string
}
真实场景里最容易漏掉的边界情况
上线前至少验证这几种 case：
- 两文本完全相同 → 应返回空 slice，不是 panic 或 nil
- 其中一个是空字符串 →
strings.SplitN("", "\n", -1)返回[]string{""}，不是[]string{} - 只有换行符差异（
"a\nb"vs"a\r\nb"）→ 预处理必须 normalize 换行符，建议用strings.ReplaceAll(text, "\r\n", "\n") - 超长单行（>1MB）→ Split 后导致内存暴涨，应限制单行最大长度，或改用流式逐行读取比对
diff 不是越精确越好，而是要匹配使用场景：CI 中检测配置变更，容忍空白差异；代码 review 工具，则需严格保留所有空白和换行。
