Go go-pretty 的 AutoMerge 为什么会合并重复单元格

go-pretty 的 AutoMerge 是展示配置：列配置 ColumnConfig.AutoMerge 用于纵向合并相邻重复内容，行配置 RowConfig.AutoMerge 用于横向合并。它不是业务去重，也不认识“部门”“订单”这样的业务分组；开启后看到重复内容减少，首先要查配置作用在行还是列。

官方地址：https://github.com/jedib0t/go-pretty

我会把这个选项理解为“减少视觉重复”，而不是“让数据更正确”。拿库存清单来说，连续三行属于同一库区，库区名只显示一次可能更好读；但是相同件数仍然代表不同货位，把它们也合并就容易误读。下面用原创小例子说明我的配置取舍，示例并非本机执行记录。

先分清重复值出现在哪个方向

我首先看重复值的位置。同一列上下相邻的库区名称，属于纵向展示；同一行左右相邻的标题文字，属于横向展示。虽然两个字段都叫 AutoMerge，配置对象决定了它们的作用范围。

不要因为值在整张表里相同就期待它们跨过其他内容合并。例如“东区、西区、东区”的顺序，前后两个东区并不构成连续的一组。若业务确实要让同组靠在一起，应先决定排序是否合适，而不是先改展示开关。

只给需要分组的列开启合并

我倾向于显式指定列号，只开放库区列。列号从 1 开始；如果按名称配置，需要能匹配首个表头中的名称。使用 Number 时它优先于 Name，因此不要在同一项中给出相互矛盾的定位信息。

package main

import (
    "fmt"
    "github.com/jedib0t/go-pretty/v6/table"
)

func main() {
    t := table.NewWriter()
    t.AppendHeader(table.Row{"库区", "货位", "件数"})
    // 只合并第一列；货位与数量即使重复也保留各自行。
    t.SetColumnConfigs([]table.ColumnConfig{
        {Number: 1, AutoMerge: true},
    })
    t.Style().Options.SeparateRows = true
    t.AppendRows([]table.Row{
        {"东区", "E-11", 4},
        {"东区", "E-12", 4},
        {"西区", "W-03", 7},
    })
    // Render 负责文本展示，不改动业务记录集合。
    fmt.Println(t.Render())
}

这个例子里第一列连续出现两次东区，表达同一个展示分组；第二列 E-11 和 E-12 仍然对应两条记录，第三列两个 4 也各自表示一条库存明细。读者不应因为第一列的合并而推断两条记录已经求和。开启行分隔是为了让明细更容易辨认，不是业务聚合操作。

如果每一行都会被复制到别处，或者将来会脱离整张表单独展示，我会关闭合并，保留每行的完整库区名。少一点视觉重复和单行自解释能力之间，需要根据使用场景取舍。

横向标题单独使用行配置

横向合并适合重复的相邻标题。例如在三列表格上增加一个贯穿表头的说明行，可以给这一个表头传入 RowConfig。不要把这种标题行的配置顺手套到普通明细，恰好相同的两个字段未必表达同一件事。

// 在已有三列 writer 上添加说明性表头，不与上例混为一个独立程序。
t.AppendHeader(
    table.Row{"仓储概览", "仓储概览", "仓储概览"},
    table.RowConfig{AutoMerge: true},
)
// 横向合并只用于这行的展示目的。

我通常先选择一种方向，再考虑另一种。项目配置注释明确提示横纵自动合并组合使用存在限制，不能把它当成电子表格任意合并区域的替代品。复杂多级标题若难以读清，宁可缩减层级，也不要让明细的边界消失。

让读者仍然能辨认每条记录

合并之后最需要保住的是记录边界。我的建议是让货位、单号这类明细标识始终可见，并在表格标题写清楚统计口径。不要依靠颜色差异说明“这里有两行”，因为复制成纯文本、关闭颜色或使用辅助阅读工具时，颜色可能不再有用。

对于需要审阅、逐条复制的清单，完整重复字段往往更实用。对于只想快速扫读分组的汇总视图，适当减少标签重复则有价值。这是输出设计选择，没有必要为了“更漂亮”让所有列都开启 AutoMerge。

性能方面，本文没有提供压测结果，也不把减少屏幕上的重复文本等同于业务处理提速。实际报表的成本可能来自数据获取、格式化和输出；是否优化应根据自身负载测量。

排查不合并和误合并的边界

若看起来相同却未合并，先看原值最终变成的文本是否一致。源码中单元格会转成字符串，列 Transformer 也参与这一过程；类型不同不一定意味着展示文本不同。反过来，业务值不同但被格式化成同一段文字，也可能让展示失去区分度。

因此我会保留一份清晰的业务明细，把用于显示的缩写、单位和转换规则放在展示层。如果合并后的含义不明确，关闭合并通常比给重复值塞入不可见字符更稳妥；后者会让复制和排查更困难。

为什么换成 CSV 或 Markdown 后没有合并？

项目配置文档说明这两种渲染模式不支持该自动合并。导出文件需要独立评估，不要拿文本表格外观作为所有输出模式的承诺。

关闭合并会恢复业务数据吗？

合并是展示行为，不应拿它代替删除或聚合记录。若业务集合已经在上游被去重，需要检查上游处理。

要不要把所有相同数量都合并？

通常不建议仅凭数值相同就这样做。先判断每个值对应的明细是否独立；相同数量不代表同一个业务对象。

参考：go-pretty 配置定义、渲染初始化源码、行数据定义。