Go slices.Compact 怎样组合到一个小型工具中

把 slices.Compact 放进一个命令行小工具，难点往往是“重复”到底指什么。我倾向于把顺序要求先写成参数：默认压缩连续重复行，只有明确选择 sorted 时才排序并去除全局重复。这样，工具的名字不会掩盖数据顺序的变化。

本文采用 Go 1.22 或以上版本，示例程序为本文独立编写。官方契约可查 https://pkg.go.dev/slices#Compact 和 https://pkg.go.dev/bufio#ScanLines。下面的数量均由固定输入推导，不是实际执行或性能测试记录。

1. 基线数据：七行输入存在两种正确答案

准备一个 items.txt，依次写入 pear、pear、fig、pear、pear、plum、plum，每个词独占一行。中间的 fig 把两组 pear 分开。因此，相邻去重应该保留四行 pear、fig、pear、plum；全局去重并排序则保留三行 fig、pear、plum。

这张表只比较结果规模。sorted 少一行，不能据此推断它运行更快；排序本身有额外工作。如果目标是保留首次出现的原始顺序，同时进行全局去重，需要另行设计集合加输出切片的方案。

2. 假设：先满足语义，再讨论成本

Compact 只处理相邻相等的元素，修改传入切片的底层内容，并返回新的有效切片。它不会替调用者识别相隔较远的重复项。排序让相同字符串相邻，才使 Sort 和 Compact 的组合具备全局去重效果。

我的参数设计让 runs 成为默认值，因为用户没有选择排序时，工具不应擅自重排行。程序始终接住返回值，写成 lines = slices.Compact(lines)。继续遍历旧长度会把已不属于结果的尾部也算进去。所选版本中，压缩后旧有效范围的多余位置会被清零，这不等于底层数组立即释放。

图1：原创说明图，连接线表示组成关系，不是执行日志。

3. 改动点：组装成只有两个模式的小工具

将以下代码保存为 main.go。程序读取标准输入，把正文写到标准输出，把行数统计写到标准错误。所有输入读取成功之后才输出，因此扫描失败不会产生半份去重正文；输出设备失败仍可能留下部分结果，调用端必须检查退出状态。

package main

import (
    "bufio"
    "flag"
    "fmt"
    "io"
    "os"
    "slices"
)

func clean(r io.Reader, w io.Writer, stats io.Writer, mode string) error {
    if mode != "runs" && mode != "sorted" {
        return fmt.Errorf("不支持的模式: %s", mode)
    }
    scanner := bufio.NewScanner(r)
    scanner.Buffer(make([]byte, 64*1024), 1024*1024)
    var lines []string
    total := 0
    for scanner.Scan() {
        line := scanner.Text()
        // 两项限制约束暂存数据，不代表进程总内存上限。
        total += len(line)
        if total > 16*1024*1024 || len(lines) >= 10000 {
            return fmt.Errorf("输入超过行数或正文容量限制")
        }
        lines = append(lines, line)
    }
    if err := scanner.Err(); err != nil {
        return fmt.Errorf("读取输入: %w", err)
    }
    before := len(lines)
    if mode == "sorted" {
        // 排序会改变行序，仅在用户明确选择时执行。
        slices.Sort(lines)
    }
    lines = slices.Compact(lines)
    out := bufio.NewWriter(w)
    for _, line := range lines {
        if _, err := fmt.Fprintln(out, line); err != nil {
            return fmt.Errorf("写入结果: %w", err)
        }
    }
    if err := out.Flush(); err != nil {
        return fmt.Errorf("刷新结果: %w", err)
    }
    _, err := fmt.Fprintf(stats, "mode=%s input=%d output=%d removed=%d\n",
        mode, before, len(lines), before-len(lines))
    return err
}

func main() {
    mode := flag.String("mode", "runs", "runs 或 sorted")
    flag.Parse()
    if flag.NArg() != 0 {
        fmt.Fprintln(os.Stderr, "本工具只从标准输入读取")
        os.Exit(2)
    }
    if err := clean(os.Stdin, os.Stdout, os.Stderr, *mode); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

两种模式共享扫描、限制、输出与错误处理，仅在排序分支上不同。最多接纳 10000 行、行文本合计 16 MiB；Scanner 的扫描缓冲上限另设为 1 MiB，它不是“每行正文恰好可放满 1 MiB”的保证，分隔符也可能占用缓冲空间。

行文本总量不含被 ScanLines 去掉的换行符，也不包含切片、字符串头和缓冲区开销，因此这些阈值不是进程内存配额。这个小工具面向有限文本；超大文件应另做流式相邻去重或外部排序。

4. 压测方法：把可推导结果与待测指标分开

可在本地用 go run main.go -mode runs 和 go run main.go -mode sorted 观察两种结果。本文没有运行这些命令，七行样本的预期结果见前表。标准错误中 input、output、removed 三项用于核对语义，不是耗时测量。

若准备衡量成本，应先固定 Go 版本、机器、输入字节数、平均行长、重复分布和输出设备，再分别记录运行时间与分配指标。比较相邻去重时，基线也必须完成同样的相邻去重；比较排序去重时，对照方案必须给出相同排序结果。不能用“原样输出”和“完成全局去重”的耗时差，证明某个函数更优。

还应区分核心函数和端到端程序。把代码编译为二进制后观察整体耗时，可以避免把 go run 的编译时间算进工具处理成本；对核心算法另做基准时，应明确是否包含输入复制、排序和输出写入。以上是测量设计，并非本文已经执行的测试。

5. 结果对比：能确认的是行数变化

固定样本下，runs 的输出从七行变成四行，sorted 变成三行，这两项都可直接从输入推导。尚未测量的吞吐量、耗时、分配次数和峰值内存，应保持未知。输出更短也不意味着排序模式的总资源消耗更低。

本程序没有保留原切片副本，Sort 和 Compact 可以直接修改暂存数据。如果后续业务还要原始行序，应先用 slices.Clone(lines) 创建独立切片，再处理副本；这里的元素是不可变字符串值，切片复制已能隔离元素位置调整。这个额外副本也必须计入资源测量。

6. 边界条件：文本相等和内存边界都要讲清

图2：原创结构图，展示工具组件及其约束。

ScanLines 去掉行终止符，并处理常见 CRLF 行尾；它不主动去掉正文前后空格，不转换大小写，也不做 Unicode 归一化。pear 和带尾空格的 pear 是不同字符串。实际空白行可作为空字符串参与去重，文件末尾的普通换行不会额外制造一条空记录。

空输入得到零行结果，nil 或空切片对 Compact 都不构成异常。单行输入保持一行。所有行都相同会收敛为一行。相同词被其他行隔开时，runs 仍会分别保留。无效模式在读取前报错，未知命令行选项由 flag 包处理。

Compact 的原地修改需要调用方拥有这段切片的修改权；不要让其他 goroutine 同时读取或改写同一个底层数组。结果长度变小也不能承诺容量同步缩小或内存马上归还。先把输入边界、顺序和输出错误处理明确，再用实际数据决定是否值得引入更复杂的去重实现，这才是这个小工具可继续扩展的基础。