Go bufio.Scanner 资源没有释放为什么

我排查过几次“文件句柄一直涨”的 Go 服务，最后发现问题常常不在 Scanner.Scan()，而在于把 Scanner 误认为资源拥有者。bufio.Scanner 只是从传入的 io.Reader 读取并切分 token，它本身没有 Close 方法。真正需要关闭的是创建出来的文件、网络连接、管道或其他实现了 io.Closer 的底层对象。

如果 Scanner 读取的是 *os.File，就在成功拿到文件后立即 defer file.Close()；循环结束后再检查 scanner.Err()。Scanner 不会替你释放底层资源。

为什么 Scanner 看起来像资源，却没有 Close

NewScanner 接收的是 io.Reader，保存的是“从哪里读”的接口引用，不负责判断这个 Reader 是文件、连接、内存字符串还是自定义流。关闭动作必须由创建资源的一方决定，否则 Scanner 也无法知道关闭底层对象是否会影响其他使用者。

例如 strings.NewReader 没有需要释放的操作系统句柄；而 os.Open 返回的文件必须由调用方关闭。两者都能传给 Scanner，所以释放责任不能放在 Scanner 类型上。

正确的释放位置：拿到资源后立即 defer

最稳妥的写法是让“打开资源”和“登记释放”紧挨着出现。这样正常读完、扫描中途返回、业务校验失败，都能走到同一个关闭动作。

package main

import (
    "bufio"
    "fmt"
    "os"
)

func readLines(path string) error {
    // 打开文件的函数拥有关闭责任，成功后马上登记释放动作。
    file, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("打开文件失败: %w", err)
    }
    defer func() {
        // Close 的错误通常发生在底层 I/O 收尾阶段，这里保留记录位置。
        _ = file.Close()
    }()

    scanner := bufio.NewScanner(file)
    for scanner.Scan() {
        // Text 返回当前 token；下一次 Scan 继续推进输入。
        fmt.Println(scanner.Text())
    }
    // Scan 返回 false 既可能是 EOF，也可能是读取错误。
    if err := scanner.Err(); err != nil {
        return fmt.Errorf("扫描文件失败: %w", err)
    }
    return nil
}

这里的 defer 绑定的是 file，不是 Scanner。若函数体里有多处 return，只要文件已经成功打开，释放动作就不会因为某个分支漏写而消失。

不要把 Scan 结束直接当成成功

Scan() 返回 false 时，可能是正常到达 EOF，也可能是 Reader 返回了 I/O 错误，还可能是 token 超过默认缓冲上限。循环后不检查 Err()，会把“只读了一半”误认为“已经读完”，这会让排查变得更混乱。

// 读取每行后，必须把 false 的原因交给 Err 判断。
for scanner.Scan() {
    line := scanner.Text()
    if line == "" {
        // 空行是否跳过是业务选择，与资源释放无关。
        continue
    }
    // 在这里处理有效行，失败时直接 return 也会触发上面的 defer。
}
if err := scanner.Err(); err != nil {
    // 这里能区分普通结束与底层读取失败，避免静默丢数据。
    return fmt.Errorf("读取未完成: %w", err)
}

需要注意，检查 Err() 不能代替 Close()。一个负责读取阶段的错误，一个负责底层资源的生命周期，二者是两条独立的责任链。

长 token 或复用场景怎么处理

标准 Scanner 默认会使用内部缓冲区，并限制单个 token 的最大尺寸。日志行、JSON 行或用户输入可能超过默认上限时，先判断是否确实适合继续使用 Scanner，再设置更大的缓冲区；如果需要更强的错误控制、读取超长内容或在同一个 Reader 上做连续扫描，可以考虑 bufio.Reader。

// 在第一次 Scan 之前调整缓冲区，避免长行直接触发 token too long。
scanner := bufio.NewScanner(file)
scanner.Buffer(make([]byte, 32*1024), 1024*1024)
for scanner.Scan() {
    // 这里只处理不超过 1 MiB 的单个 token。
    consume(scanner.Bytes())
}
if err := scanner.Err(); err != nil {
    return fmt.Errorf("读取长行失败: %w", err)
}

Buffer 只影响 Scanner 的 token 缓冲，不会改变文件句柄的关闭责任。若把一个打开的文件传给多个扫描器，还要明确谁负责整个文件的生命周期，避免一个函数提前关闭而另一个函数仍在读取。

排查资源没有释放时，我会先看这四处

1. 打开文件、连接或管道后，是否在成功分支立刻登记了 defer Close()。
2. 是否把关闭动作写在某个很晚的正常分支，导致错误返回和校验失败绕过它。
3. 是否只看了 Scan() 的返回值，却没有检查 scanner.Err()。
4. 是否在循环里频繁创建资源，应该把函数边界或批处理生命周期重新划清。

我的经验是，看到“Scanner 资源没有释放”时，先沿着 NewScanner(reader) 向前追踪 Reader 的创建点，再沿着所有 return 路径检查关闭责任。只要底层资源由当前函数创建，当前函数就应在获得它之后马上安排释放。

常见追问

Scanner 扫完文件后会自动关闭文件吗？

不会。Scanner 读到 EOF 只代表扫描结束，文件仍由打开它的代码负责关闭。

只调用 scanner.Err() 能释放资源吗？

不能。Err 只返回扫描阶段遇到的非 EOF 错误，释放仍要显式调用底层 Reader 的 Close 方法。