Go go-diff 应用补丁后为什么还要看每块匹配结果

我第一次把 go-diff 接到“把旧文本更新成新文本”的流程里时，最容易犯的错是只保存 PatchApply 的第一个返回值。文本看起来已经变化，并不等于每一块补丁都成功匹配。官方接口明确返回两个结果：更新后的文本，以及与补丁对应的 []bool。

官方文档：https://pkg.go.dev/github.com/sergi/go-diff@v1.4.0/diffmatchpatch

所以可靠的处理方式是：把 patchedText 当作内容结果，把 results 当作完整性信号。只有所有布尔值都为 true，当前输入才适合按“整批应用成功”继续向下游提交；出现 false 时，要保留补丁索引和上下文信息。

先理解 PatchApply 的双返回值

这个接口的职责不是抛出一个“成功/失败”异常，而是尽量把能匹配的补丁应用到文本上，再逐块报告结果。补丁匹配依赖补丁中携带的上下文，原文在生成补丁后如果发生了额外编辑，某些块可能找不到足够接近的位置。

这两个返回值最好不要被压缩成一个字符串判断：

• patchedText：当前调用结束后的文本。
• results：每个补丁是否应用成功，顺序对应传入的补丁列表；如果库内部拆分了过大的补丁，结果数组也应按实际返回结果处理。

生成并序列化补丁

生产流程中经常需要把补丁放入消息、数据库或文件。PatchMake 可以从旧文本和新文本生成补丁，PatchToText 再把补丁转成文本格式。下面的示例只展示对象关系和错误边界，注释保留了每个关键参数的含义。

package main

import (
    "fmt"

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

func buildPatch(oldText, newText string) string {
    dmp := diffmatchpatch.New()

    // PatchMake 根据旧文本与新文本计算可应用的补丁集合。
    patches := dmp.PatchMake(oldText, newText)
    // PatchToText 使用可传输的文本格式，便于写入队列或持久化。
    return dmp.PatchToText(patches)
}

func main() {
    patchText := buildPatch("服务启动，端口为 8080", "服务启动，端口为 9090")
    // 这里只打印补丁文本；真实系统还应记录原文版本或业务对象版本。
    fmt.Println(patchText)
}

这里要记录“补丁对应的原文版本”。仅保存补丁文本而不保存版本号，后续很难解释为什么同一份补丁在不同文本上得到不同的匹配结果。

重新解析后应用补丁

收到补丁文本后，用 PatchFromText 解析；解析错误和应用失败是两层不同的问题。前者通常意味着传输内容不完整或格式不对，后者表示补丁结构能读懂，但当前文本没有满足匹配条件。

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

    // 先解析文本格式；解析失败时不能把空补丁当作成功。
    patches, err := dmp.PatchFromText(patchText)
    if err != nil {
        return "", fmt.Errorf("解析补丁失败: %w", err)
    }

    // PatchApply 同时返回修改后文本和逐块匹配结果。
    patchedText, results := dmp.PatchApply(patches, baseText)
    for index, applied := range results {
        if !applied {
            // 保留索引，方便关联原补丁和上下文日志；不要静默吞掉部分失败。
            return patchedText, fmt.Errorf("第 %d 个补丁未匹配", index)
        }
    }
    return patchedText, nil
}

这个写法保留了已经成功应用的内容，同时把部分失败显式交给调用方。若业务要求“全有或全无”，调用方还需要在外层决定是否丢弃这次结果、重新基于最新文本生成补丁，或进入人工处理。

为什么最终文本看起来正常仍不够

补丁是按上下文寻找匹配位置的。假设一份补丁原本针对配置文件中的一个端口和一段相邻注释；在补丁生成后，另一个进程先改了注释，库仍可能应用部分可匹配的块。此时最终文本可能“像是改过了”，但并不能证明整个变更集都落地。

处理部分成功与上下文漂移

我在服务配置和文档同步场景里，通常会把每个结果索引写入结构化日志，并把原文版本、补丁文本摘要和失败索引绑定起来。这样重试时可以先判断目标文本是否已经被其他流程更新，而不是无条件重复应用同一份补丁。

重试策略可以按场景区分：

• 配置或代码生成：先重新读取最新基线，再重新计算补丁。
• 协作编辑：把失败块交给冲突合并流程，不覆盖新内容。
• 低风险文本：允许成功块保留，但要明确记录未应用的索引。

不要把 results 当成“可以忽略的调试字段”。它正是这类模糊匹配算法把不确定性交给调用方的接口边界。

落地时我会保留的清单

1. 保存补丁对应的原文版本或业务版本号。
2. 区分 PatchFromText 的解析错误与 PatchApply 的部分匹配失败。
3. 逐项遍历 []bool，记录失败索引，不只比较最终字符串。
4. 明确部分成功后的策略：回滚、重新生成、冲突合并或人工处理。
5. 把 go-diff 版本和关键匹配参数纳入可追踪配置，避免同一补丁在不同默认值下难以复现。

常见问题

PatchApply 返回的布尔数组和补丁数量一定相同吗？

通常按传入补丁逐块对应；但库会对超过匹配上限的补丁进行拆分，因此调用方应以返回的结果数组为准，不要写死为原始切片长度。

只想要最终文本，可以忽略 results 吗？

只有在明确接受部分应用并且下游还有独立完整性保障时才可以。配置、迁移、同步这类需要完整变更的场景不建议忽略。

PatchFromText 失败后能直接调用 PatchApply 吗？

不能。解析错误说明没有得到可靠的补丁集合，应先修复传输或序列化问题。

对我来说，go-diff 的关键不在于“能不能把字符串改掉”，而在于能否把每个补丁的应用状态交给业务判断。把文本结果和逐块结果一起保存，后续的重试、冲突处理和审计才有依据。