Go go-diff 的语义清理与效率清理有什么区别

go-diff 中，DiffCleanupSemantic 关注差异对人的可读性，整理语义上过于琐碎的相等片段；DiffCleanupEfficiency 关注编辑操作的组织成本，清除操作意义较小的相等片段，并受 DiffEditCost 影响。两者都处理已经得到的差异列表，但优化目标不同，不能把“效率清理”直接理解为让 DiffMain 的运行时间更短。

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

例如同一个文本比较服务，网页要让编辑人员看清改动，另一个调用方只想处理一组编辑操作。这两个出口不必共用同一套清理结果。下面从调用方式、参数和旧代码改造说明选择方法；这不是新版本发布公告，示例也是原创演示，未在本机执行。

按差异结果的使用者选择清理目标

差异算法可能找到一些很短的相等段。对读者来说，把一个替换拆成好几处小改动未必更清楚；对操作处理程序来说，保留一个很短的相等段也可能不值得额外分段。清理改变的是差异表达的组织，不是允许修改源文或目标文本。

“语义”也不能理解为自然语言模型知道句子含义。这里是文本差异算法的启发式清理，不会理解业务规则或判断两个句子的事实是否一致。

给同一份差异建立独立比较分支

先用 DiffMain 得到原始列表，再分别复制给两个清理函数。若在同一变量上连续执行两种清理，第二次处理的是已经清理过的列表，就不能把结果当成两种策略对同一输入的公平比较。

package main

import (
    "fmt"
    "github.com/sergi/go-diff/diffmatchpatch"
)

func main() {
    dmp := diffmatchpatch.New()
    before := "Warehouse A: pack 12 green cartons."
    after := "Warehouse B: pack 15 blue cartons."
    raw := dmp.DiffMain(before, after, false)

    // 为两种清理复制切片，避免共享底层数组影响对比。
    semantic := dmp.DiffCleanupSemantic(
        append([]diffmatchpatch.Diff(nil), raw...),
    )
    dmp.DiffEditCost = 4 // 编辑成本参数，不是超时或并发数。
    efficient := dmp.DiffCleanupEfficiency(
        append([]diffmatchpatch.Diff(nil), raw...),
    )

    // 打印各段操作与文本，保留空白和标点便于观察。
    for _, item := range []struct {
        name string
        diffs []diffmatchpatch.Diff
    }{
        {"raw", raw},
        {"semantic", semantic},
        {"efficiency", efficient},
    } {
        fmt.Println(item.name)
        for _, part := range item.diffs {
            fmt.Printf("%v %q\n", part.Type, part.Text)
        }
        // 两端文本仍应能重建，具体切段结果以实际运行结果为准。
        fmt.Println("source:", dmp.DiffText1(item.diffs) == before)
        fmt.Println("target:", dmp.DiffText2(item.diffs) == after)
    }
}

这里使用相同原文和目标文本，让两个分支只在清理策略上不同。示例没有附上猜测的差异输出，因为具体切段需要以实际版本和输入运行结果为准。输出时用带引号的文本形式，是为了让空格和标点更容易辨认，避免展示时看漏短相等段。

不必期待每个输入都会让两种策略产生不同结果。如果文本本来只有一处简单替换，或者没有可整理的碎片，两个列表可能一致。相同结果不表示某个函数失效。

把效率参数与业务耗时分开理解

DiffEditCost 表达编辑操作的成本尺度。示例显式设为 4，是为了让比较条件可见，不是给所有项目推荐唯一最佳值。它不表示毫秒、线程数或请求额度。调整时应结合下游如何处理差异段，而不是凭字段名把它当作加速开关。

如果服务慢，先分别测量计算差异、清理、序列化和展示所花的时间，再定位成本。即使清理后操作段减少，也不能在没有测量时宣称整条业务链路一定更快；若大部分时间花在读取文档，展示策略并不能直接消除这部分成本。

调整旧实现时保留原文与结果契约

若旧代码一直把语义清理结果交给所有调用方，不建议只把函数名全局替换成效率清理。先盘点用途：审阅界面在意阅读体验，下游操作处理在意自己的成本模型，存档可能还需要保存原始差异。把策略作为明确的应用配置，比让不同入口偷偷使用不同默认值更易维护。

还要避免把切段后的列表长度当成文本改动字符数。一个差异段可能包含多个字符，同一个替换也可能由删除和插入组成。若已有指标、定位信息或缓存依赖差异列表结构，换策略前应明确它们是否允许变化。

DiffCleanupSemanticLossless 是另一接口，关注把单处编辑边界移向更自然的词边界；它不等同于本文的 Semantic，也不能仅凭名称包含 Semantic 就当成同一操作。

用源文本重建检查清理结果

示例里同时调用 DiffText1 和 DiffText2，分别重建源文本与目标文本，再与 before、after 比较。两项均为 true 是一个明确的正确性检查点，但它不证明展示效果最好，也不证明成本配置最合适。

实际项目可以把简单替换、短相等段、空白变化和中文标点变化作为不同样例，记录策略、参数和依赖版本。这里检查的是文本比较功能的契约，不需要为得到一张配图运行这些样例。

两种清理可以连续调用吗？

接口允许把列表传给另一种清理，但那是组合策略。要比较各自效果，应使用同一原始列表的独立副本。

语义清理会理解业务语义吗？

不会替代业务判断；它处理文本差异结构，不判断事实含义或领域规则。

效率清理保证结果更短吗？

不能对所有输入作这种承诺。有些输入没有可整理的细碎相等段，结果可能不变。

参考：go-diff 官方包文档与接口说明。