Go strings.Reader.Len 怎样判断剩余可读内容

我在把一段字符串交给多个读取组件时，最容易误判的不是 Read 返回了多少，而是把 strings.Reader.Len() 当成“原字符串长度”或“字符数”。正确的理解是：Len 返回当前读取位置之后还没有读过的字节数。刚创建 Reader 时它接近原始字符串的 len(s)；每次顺序读取后都会减少，读完后变成 0。

官方地址：https://pkg.go.dev/strings#Reader.Len

如果要判断顺序读取还剩多少内容，用 Len()；如果要得到底层字符串的原始总字节数，用 Size()。两者都按字节计数，不按 Unicode 字符数计数。

先看清 Len 绑定的是哪个位置

strings.NewReader 创建的是只读字符串 Reader。它同时实现了 io.Reader、io.ReaderAt、io.Seeker 等接口，但 Len 只跟顺序读取位置有关。调用 Read、ReadByte、ReadRune 或 WriteTo 后，未读部分减少；而 ReadAt 是按指定偏移读取，不改变这个顺序位置。

package main

import (
    "fmt"
    "strings"
)

func main() {
    r := strings.NewReader("Go语言")
    fmt.Println(r.Len(), r.Size()) // Len 与 Size 都是 8 个字节

    buf := make([]byte, 2)
    n, err := r.Read(buf)
    if err != nil {
        // 真实业务中要区分 io.EOF 与其他读取错误。
        fmt.Println("读取失败:", err)
        return
    }
    fmt.Println(n, string(buf), r.Len(), r.Size()) // 读取后 Len 减少，Size 不变
}

这里的关键不是某次读取恰好拿到两个字节，而是 Reader 内部的顺序位置向前移动了两个字节。Size() 描述原始内容的总字节数，因此不会因为 Read 改变。

中文场景要按字节理解结果

Go 字符串的 len、Reader.Len 和 Reader.Size 都是字节口径。一个中文汉字通常占多个 UTF-8 字节，所以“剩余两个字符”和“剩余两个字节”不能互换。需要按字符读取时，应看 ReadRune 返回的 size；需要按协议字段或网络载荷切片时，才用 Len 判断字节预算。

package main

import (
    "fmt"
    "strings"
)

func main() {
    r := strings.NewReader("Go语言")
    for r.Len() > 0 {
        ch, size, err := r.ReadRune()
        if err != nil {
            // ReadRune 出错时停止，避免把无效字符继续交给下游。
            fmt.Println("读取字符失败:", err)
            break
        }
        fmt.Printf("字符=%q，占用=%d字节，剩余=%d字节\n", ch, size, r.Len())
    }
}

循环条件仍然是 Len() > 0，因为它是在判断是否还有底层字节；每次字符的实际占用由 ReadRune 的 size 返回。这样既不会把多字节字符误拆成固定长度，也能在协议解析中保留明确的字节边界。

Len、Size 和字符数量不要混用

排查“长度不对”时，我会先把三个概念拆开：

Size() 还是 int64，适合和文件偏移、分片范围等更大的长度语义对齐；Len() 是 int，更适合当前内存 Reader 的剩余读取判断。若业务关心用户看到的“字数”，还要进一步明确是否按码点、字素簇还是展示宽度统计，不能直接套用 Len。

在读取循环里怎样写得稳

把 Len 用作“是否还有待读数据”的快速判断即可，不要用它替代 Read 的错误处理。读取组件可能返回 n > 0 同时带有 io.EOF，因此真正消费数据时仍应先处理已读字节，再处理错误。

func consume(r *strings.Reader) error {
    buf := make([]byte, 4)
    for r.Len() > 0 {
        n, err := r.Read(buf)
        if n > 0 {
            // 先消费有效字节；不要因为同时出现 EOF 就丢掉这段数据。
            handle(buf[:n])
        }
        if err != nil {
            // 读到结尾是正常结束，其他错误才需要向上返回。
            if err == io.EOF {
                return nil
            }
            return err
        }
    }
    return nil
}

上面的片段需要额外导入 io，handle 代表业务消费函数。固定大小缓冲区适合按字节处理的场景；如果内容要按字符处理，应改用 ReadRune，不要通过不断切片猜测 UTF-8 边界。

最后的判断清单

• 刚创建 Reader：用 Len 看当前剩余字节，用 Size 看原始总字节。
• 顺序读取后：Len 会减少，Size 不变；ReadAt 不推进顺序位置。
• 涉及中文：不要把字节数当字符数，按字符读取就检查 ReadRune 的 size。
• 循环结束：仍以 Read 返回的 n 和 err 为准，Len 只负责提供剩余量线索。

相关问题

Len 会返回负数吗？正常的 Reader 使用中不会；空 Reader 返回 0，读取位置到末尾后也返回 0。

为什么中文只读一个字符后 Len 减少不止 1？因为 Len 统计 UTF-8 字节，而不是 Unicode 码点；应使用 ReadRune 的 size 观察该字符占用的字节数。

ReadAt 会不会让 Len 变小？不会。ReadAt 使用显式偏移读取，Len 仍对应顺序读取位置。