应先用SHA-256哈希预检再diff，支持流式读取、超时控制与换行标准化，go-diff仅适用于文本行级比对，大文件需限行并发需节制。
直接用 SHA-256 预检再 diff，别一上来就逐行比
两文件是否变更，99% 的场景下根本不用进 diff 逻辑。先算哈希，一致就跳过；不一致再走精细比对——这是性能分水岭。
-
fileSHA256必须支持流式读取，不能把整个大文件 load 到内存里；io.Copy+sha256.New()是标准做法 - 哈希碰撞概率低于
2^-256，生产环境可视为“完全一致”，无需额外校验 - 若文件超 100MB，建议加
context.WithTimeout防止哈希卡死，尤其在 NFS 或慢盘上 - 注意：Windows 上路径大小写不敏感，但哈希值严格依赖字节内容，不要用路径名代替内容校验
go-diff 库只处理文本行级差异，别指望它比二进制
go-diff（如 github.com/sergi/go-diff）本质是 Myers 算法实现，输入必须是 []string，即按行切分的文本。它不支持字节级、JSON 结构级或二进制 diff。
- 读文件时用
strings.Split(strings.TrimSpace(string(buf)), "\n")，别漏掉TrimSpace，否则末尾空行会干扰 diff 结果 - 若原始文件含 Windows 换行符
\r\n，要统一转成\n再传入，否则每行多一个\r就全错位 - 大文件（>10 万行）慎用：Myers 时间复杂度最坏 O(N×M)，建议先做哈希过滤，再限制最大行数（如截取前 5000 行做快速预览）
- 输出格式默认是 unified diff（
@@ -1,3 +1,4 @@），解析时注意Diff结构体字段名是Added/Removed，不是Insert/Delete
并发比对多个文件对时，别让 goroutine 泛滥
批量比对（比如监控 100 个配置文件）时，并发开太多反而拖慢整体速度——IO 和哈希计算都是瓶颈，不是 CPU 密集型任务。
- 用带缓冲的 channel 控制并发数，例如
sem := make(chan struct{}, 5)，每启动一个 goroutine 前sem ，结束时 <code><-sem - 避免在 goroutine 里重复打开同一文件多次；提前
os.Stat获取Size()，小文件（ - 结果聚合别用全局 map + mutex，改用
sync.WaitGroup+ slice append（每个 goroutine 写独立 slot），最后合并 - 注意：
os.Open返回的*os.File不是线程安全的，不同 goroutine 不能共用同一个 file 句柄
diff 结果要落地，得自己补 context 行和格式化
go-diff 默认只返回变更块（Diff slice），没有前后几行上下文，也没颜色或 HTML 渲染——这些得你补。
立即学习“go语言免费学习笔记（深入）”；
- 用
diffmatchpatch（同源库）能拿到更细粒度的字符级差异，但性能差；go-diff更适合“哪几行变了”这种语义 - 生成 human-readable 输出时，手动从原文件读取变更行前后各 2 行，拼成带行号的片段；别依赖 diff 输出里的行号偏移，它可能因删/增错位
- 写日志或 API 返回时，用
encoding/json序列化结构体，字段命名用OldLines/NewLines而非Removed/Added，避免前端误解 - 如果要存历史 diff 记录，别存原始 diff 字符串，存
{FileName, HashBefore, HashAfter, ChangedLines: []int}更省空间且可检索
哈希预检和 diff 分离是核心，但最容易被忽略的是：文件编码不一致时，哪怕内容一样，哈希也不同。UTF-8 BOM、空格缩进风格、换行符类型，都会导致哈希不等——比对前统一 normalize 才是真正可靠的起点。
