Go plan9obj.Section 两个读取者为什么应分别调用 Open

两个读取者要分别调用 Section.Open()，因为每次调用都会得到一个新的 io.ReadSeeker，各自保存读取位置。若把一次 Open 的结果交给两个解析器，它们仍共享同一个游标；一个解析器的 Seek 会改变另一个解析器随后 Read 的位置。分别 Open 隔离的是游标，不是底层文件内容。

官方地址：https://pkg.go.dev/debug/plan9obj

先让每个读取者持有自己的 Open 结果

假设一个分析工具要从同一节区读取两个窗口：一个组件读取头部字段，另一个组件读取指定偏移的数据。它们不应依赖对方上一次停在哪里。下面的辅助函数接收可信 Plan 9 a.out 文件及节区名，限制单个窗口的大小，并在关闭文件之前完成读取。它可以放进自己的 Go 包中使用；这里没有给出实际文件的运行输出。

package sectionread

import (
    "debug/plan9obj"
    "errors"
    "fmt"
    "io"
)

// ReadTwoWindows 从可信文件的同一节区读取两个窗口；偏移相对于节区起点。
func ReadTwoWindows(path, section string, left, right int64, size int) (a, b []byte, err error) {
    if left  4096 {
        return nil, nil, fmt.Errorf("偏移或窗口长度不合法")
    }
    f, err := plan9obj.Open(path)
    if err != nil { return nil, nil, fmt.Errorf("打开目标文件: %w", err) }
    // 所有读取完成后再关闭文件，并保留关闭错误。
    defer func() { err = errors.Join(err, f.Close()) }()
    s := f.Section(section)
    if s == nil { return nil, nil, fmt.Errorf("节区不存在: %s", section) }
    for _, off := range []int64{left, right} {
        // 先做范围判断，减法写法避免 off+size 溢出。
        if off > int64(s.Size) || int64(size) > int64(s.Size)-off {
            return nil, nil, fmt.Errorf("窗口超出节区")
        }
    }
    first, second := s.Open(), s.Open()
    // 两个变量来自两次 Open，Seek 操作分别修改各自的游标。
    if _, err = first.Seek(left, io.SeekStart); err != nil { return nil, nil, err }
    if _, err = second.Seek(right, io.SeekStart); err != nil { return nil, nil, err }
    a, b = make([]byte, size), make([]byte, size)
    if _, err = io.ReadFull(first, a); err != nil {
        return nil, nil, fmt.Errorf("读取左窗口: %w", err)
    }
    if _, err = io.ReadFull(second, b); err != nil {
        return nil, nil, fmt.Errorf("读取右窗口: %w", err)
    }
    return a, b, nil
}

示例先分别设置两个位置，再读取第一个窗口。这种写法强调了对象归属：第二个读取者的定位不会覆盖第一个读取者的位置。调用方仍要检查返回错误；若关闭文件产生错误，也应按自己的业务规则处理，不能只判断返回切片是否非空。

比较共享游标与独立游标

first := s.Open(); second := first 只是复制接口值，不会复制游标。即使给变量起不同名字，两个接口仍指向同一个读取对象。真正需要的是代码中的两次 Open。这个问题并不以 goroutine 为前提：顺序调用两个会 Seek 的解析器，也可能产生逻辑干扰。

给共享对象加锁可以避免同时访问，但若只在单次 Seek 或 Read 外加锁，仍不能保护“定位后读取”这一完整操作。若遗留接口必须共享一个读取对象，需要统一锁住整个语义操作，并约定是否恢复位置；这种协调往往比直接给每个消费者一个 Open 结果复杂。不要把独立 Open 理解为同一个返回对象可以任意并发 Seek。

固定偏移读取时选择 ReadAt

如果算法本来就知道每个字段的位置，并不需要流式接口，可以直接使用节区的 ReadAt。它的偏移相对于节区起点，无须先对共享对象调用 Seek。调用时仍要检查返回字节数和错误，不能把短读当成完整字段。

// s 是有效的 *plan9obj.Section，off 是节区内偏移。
// 此写法适合固定位置字段；完整读取要求同时关注 n 和 err。
buf := make([]byte, 16)
n, err := s.ReadAt(buf, off)
if err != nil {
    return fmt.Errorf("读取字段，仅取得 %d 字节: %w", n, err)
}
// 只有成功后才把 buf 交给字段解码器。

这段片段放在返回 error 的函数中，s 和 off 由调用方提供。与它不同，接收 io.Reader 的解码器通常会连续消费字节，用 Open 更自然；需要回退位置的解码器则可使用返回的 ReadSeeker。选择依据是消费者要求的接口，而不是哪一种方法名更短。

保留底层文件的使用期限

Section.Open 不会重新按文件名打开一份文件，也不提供内容快照。底层文件被关闭以后，原有读取对象继续使用可能失败；底层数据被修改也不在“独立游标”的承诺之内。因此，不要在创建读取者的函数中 defer 关闭文件后，仅返回读取者供外层继续使用。可以像完整示例一样在函数内部返回读取完成的字节，或者让上层明确持有并负责关闭 File。

由 plan9obj.Open 建立的 File 负责关闭它打开的文件。若使用 plan9obj.NewFile 包装自己提供的 ReaderAt，应由提供者管理底层资源，不能把 File.Close 当作底层资源的统一关闭入口。本文示例面向可信输入，读取位置的隔离也不能替代输入来源控制。

用决策表选择读取方式

Open 会返回错误吗？Section.Open 的返回值只有 io.ReadSeeker；真正的数据访问错误需要在 Seek、Read 或 ReadFull 处处理。Section 不存在时先处理 nil，不能把它直接交给 Open。

能否把节区偏移当作文件绝对偏移？不能混用。示例中的位置都从节区起点计算；若自己改用文件级 ReaderAt，需要自行处理节区的文件位置。

为什么 Section 没直接提供共享的 Read 和 Seek？其接口设计保留 ReaderAt，让需要游标的消费者显式创建自己的读取对象。把“谁持有游标”落实到对象归属，后续解析代码才容易组合。