Go go-diff 怎样为两段文本生成可应用的补丁

如果接口只返回“旧文本”和“新文本”，接收方往往还需要知道哪些字符被删除、哪些内容被插入，并把这组变化保存到消息或数据库里。Go 的 go-diff 可以把这件事拆成“生成补丁、序列化补丁、解析补丁、应用补丁”四个环节。

官方地址：https://pkg.go.dev/github.com/sergi/go-diff/diffmatchpatch

本文使用 github.com/sergi/go-diff/diffmatchpatch，示例从两段 plain text 生成补丁文本，再在接收端应用。它不是 Git patch 文件，也不是二进制差分和自动冲突合并器。

先分清 diff、patch 和最终文本

DiffMain 适合查看两段文本的差异；真正要跨进程保存和传输时，使用 PatchMake 生成补丁集合，再用 PatchToText 得到字符串。接收方拿到字符串后，先调用 PatchFromText 恢复补丁对象，最后交给 PatchApply。

这个分层很重要：生成补丁时需要同时拥有旧文本和新文本；应用补丁时需要一份与生成端一致的基线文本。补丁本身并不携带“可以无条件覆盖任何内容”的权限。

从两份文本得到可传输的补丁

最小写法是把旧版本放在第一个参数，把新版本放在第二个参数。补丁文本可以直接放入 JSON 字段、消息体或文本文件；如果两份文本相同，补丁集合通常为空，业务层可以把它当成没有变更。

package main

import (
	"fmt"

	"github.com/sergi/go-diff/diffmatchpatch"
)

func main() {
	oldText := "name: app\nport: 8080\n"
	newText := "name: api\nport: 8080\n"

	// 创建 diffmatchpatch 实例，用旧文本和新文本计算补丁。
	dmp := diffmatchpatch.New()
	patches := dmp.PatchMake(oldText, newText)

	// 将补丁集合编码成可保存、可传输的文本。
	patchText := dmp.PatchToText(patches)
	fmt.Println(patchText)
}

这里的 PatchToText 解决的是表示和传输问题，不负责把补丁写回文件。若要审阅差异，可另外用 DiffPrettyText 或自定义展示；不要把适合人读的展示文本直接当作应用输入。

接收端先解析，再应用到正确基线

接收方不必重新计算新文本，只要拿到补丁字符串和当前基线即可。解析阶段可能因为截断、转义错误或内容不是合法补丁而失败；应用阶段则可能出现某一项找不到匹配上下文的情况，这两个错误应分开处理。

package main

import (
	"fmt"

	"github.com/sergi/go-diff/diffmatchpatch"
)

func applyPatch(baseText, patchText string) (string, error) {
	dmp := diffmatchpatch.New()

	// 先恢复补丁对象；格式错误要在应用前返回，避免继续处理坏数据。
	patches, err := dmp.PatchFromText(patchText)
	if err != nil {
		return "", fmt.Errorf("解析补丁失败: %w", err)
	}

	// 应用接口同时返回新文本和每个补丁是否成功匹配的结果。
	updatedText, applied := dmp.PatchApply(patches, baseText)
	for i, ok := range applied {
		if !ok {
			return "", fmt.Errorf("第 %d 个补丁未应用", i+1)
		}
	}
	return updatedText, nil
}

func main() {
	baseText := "name: app\nport: 8080\n"
	patchText := ""

	// 生产代码应从消息或存储中读取 patchText，并记录失败上下文。
	updatedText, err := applyPatch(baseText, patchText)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(updatedText)
}

示例中的空字符串只是占位，实际调用应传入上一个示例生成的 patchText。PatchApply 返回的布尔切片要逐项读取：全部为 true 才能把结果当成完整应用；出现 false 时，应保留基线版本并让业务层选择重新拉取、人工合并或重新生成补丁。

按负载和边界选择保存方式

小型配置、模板和协同编辑消息可以直接保存 PatchToText 的结果；如果补丁要跨队列或跨服务传递，建议给它附带基线版本号、内容哈希和生成时间，避免把针对旧版本的补丁误用到新文本上。

三个容易踩到的边界

基线变了，补丁不一定还能完整应用

补丁包含上下文，目标文本即使只是被别人改了一小段，也可能让某个补丁找不到足够匹配内容。收到部分失败结果后不要直接覆盖原文，否则容易把未应用的变化伪装成成功。

它处理的是文本，不是 Git 提交

go-diff 的定位是 plain text 的 diff、match 和 patch。Git 的提交、索引、文件权限、重命名和三方合并规则不在这个 API 的职责内；需要这些语义时，应使用版本控制工具或专门的合并库。

把补丁当作不可信输入

来自网络的补丁文本先限制大小，再调用 PatchFromText，同时记录解析错误和应用失败的版本信息。不要把补丁内容直接拼接进 HTML 或命令行；它应该像普通输入一样经过转义、权限和审计处理。

常见问题

PatchMake 生成的是字符串吗？

不是。PatchMake 返回补丁集合，PatchToText 才把它转换成文本表示。保存或传输时使用后者，应用前再用 PatchFromText 解析。

PatchApply 返回 false 应该怎么办？

把它当作应用不完整处理：保留原基线，记录对应的补丁序号和版本信息，然后重新获取最新文本并重新生成补丁，或交给人工合并流程。不要只检查最终字符串非空就认为成功。

小结

可落地的调用链是：旧文本与新文本交给 PatchMake，用 PatchToText 形成传输内容；接收端用 PatchFromText 恢复，再把补丁和正确基线交给 PatchApply，最后逐项读取布尔结果。只要把基线版本、解析错误和部分应用纳入协议，go-diff 就能成为轻量的文本更新组件。