Go dwarf.LineReader 怎么用 Tell 和 Seek 恢复行表读取位置

如果你已经拿到了一个编译单元对应的 *dwarf.LineReader，想先读一段行表、稍后回到原位置再读，直接保存 pos := reader.Tell()，之后对同一个 reader 调用 reader.Seek(pos) 即可。LineReaderPos 是给该行表 reader 使用的不透明位置值，不要把它当成可以跨 reader 或跨编译单元传递的通用偏移。

最稳妥的用法是：在“下一次要读取的位置”调用 Tell，在同一个 LineReader 上调用 Seek 恢复，然后继续 Next。Tell 保存的是读取器状态，不是某一行的源码行号或 PC 地址。

本文只讨论同一行表上的 Tell/Seek 恢复，不把它和按程序计数器定位的 SeekPC 混在一起。

Tell 保存的到底是什么

LineReader.Tell 返回当前行表位置，类型是 dwarf.LineReaderPos。这个类型的字段对包外代码不可见，调用方只需要保存它、原样传给同一行表的 Seek。它记录的是 reader 为继续解析行表所需的游标和状态，而不是一个可以自行加减的整数。

因此，下面两种保存时机表达的是不同语义：

• 在调用 Next 之前保存：恢复后会从这条尚未读取的表项开始。
• 成功调用 Next 之后保存：恢复后会从下一条表项继续。

用同一个 LineReader 保存和恢复

最小模式是先记录暂停点，读取若干行，再恢复暂停点。示例中的 lr 来自某个编译单元的行表；它没有展示如何从 ELF、Mach-O 或 PE 文件取得 DWARF 数据，避免把文件格式初始化和游标恢复混在一起。

package main

import (
	"debug/dwarf"
	"fmt"
	"io"
)

// readAfterRestore 从保存的位置继续读取，直到行表结束。
func readAfterRestore(lr *dwarf.LineReader, saved dwarf.LineReaderPos) error {
	// Seek 只能接收同一行表上 Tell 返回的位置。
	lr.Seek(saved)

	var entry dwarf.LineEntry
	for {
		// Next 成功后，entry 就是当前位置对应的行表项。
		err := lr.Next(&entry)
		if err == io.EOF {
			// 正常结束，不把行表末尾误判成故障。
			return nil
		}
		if err != nil {
			// 解析错误需要交给调用方处理，不能继续使用不确定状态。
			return err
		}
		fmt.Printf("%s:%d\\n", entry.File, entry.Line)
	}
}

func scanWithCheckpoint(lr *dwarf.LineReader) error {
	var first dwarf.LineEntry
	if err := lr.Next(&first); err != nil {
		// 空行表可能直接返回 EOF，其他错误需要保留。
		return err
	}

	// 此时保存的是“first 之后”的位置，恢复后不会重复 first。
	saved := lr.Tell()
	var second dwarf.LineEntry
	if err := lr.Next(&second); err != nil && err != io.EOF {
		return err
	}

	// 复用同一个 lr，从 saved 对应的下一条记录继续读取。
	return readAfterRestore(lr, saved)
}

如果业务需要重新处理刚刚读过的 first，就把 Tell 放到第一次 Next 之前。这个位置差异比“保存了哪一个行号”更重要，因为行号可能重复、倒退或跨文件，而 reader 位置描述的是解析游标。

恢复后为什么要继续调用 Next

Seek 只负责把 reader 恢复到某个已保存的位置，不会把当前行表项写入你传入的 LineEntry，也不会替代下一次读取。恢复后仍然要调用 Next(&entry)，并按 io.EOF、其他错误和成功三种结果处理。

行表读取是顺序读取模型。把位置保存下来，适合做“预览一段后回放”“两种解析策略从同一个检查点分叉”或“先索引一小段，再按检查点重新遍历”。它不等于为任意 PC 建立了 O(1) 查询索引；按 PC 查找是另一个 SeekPC 语义。

LineReaderPos 不能跨行表复用

官方约束很明确：传给 Seek 的位置必须来自同一个 line table 的 Tell。下面这些组合都不应使用同一个位置值：

如果需要跨进程或跨文件保存“恢复点”，应自己定义稳定的业务索引，例如编译单元标识、文件名、地址范围和业务记录序号，再在重新打开 DWARF 数据后重新定位；不要依赖 LineReaderPos 的内部布局。

把检查点封装成小结构

在同一个 reader 的生命周期内，可以把位置和用途放到一个小结构中，但结构本身仍然只对当前 reader 有效。这样能避免把保存时机写散在多个分支里。

type lineCheckpoint struct {
	// label 说明业务为什么保存这个位置，便于排查分支差异。
	label string
	// pos 必须来自绑定的同一个 LineReader。
	pos dwarf.LineReaderPos
}

func checkpoint(lr *dwarf.LineReader, label string) lineCheckpoint {
	// 调用方应在“下一次要读取的位置”创建检查点。
	return lineCheckpoint{label: label, pos: lr.Tell()}
}

func restore(lr *dwarf.LineReader, cp lineCheckpoint) {
	// 不根据 label 推算偏移，只原样恢复 Tell 返回的位置。
	lr.Seek(cp.pos)
}

封装后仍要保留两个约束：检查点不能离开它所属的 LineReader 生命周期；恢复后必须重新调用 Next 获得表项。若要处理错误，也应让恢复和读取的错误边界保持在调用方可见的位置。

常见误区与速查

• 把 Tell 当成行号：它是 reader 位置值，不能用来直接显示源码行。
• 保存后忘记 Seek：只保存位置不会改变 reader，恢复动作必须显式调用。
• Seek 后不调用 Next：Seek 不会自动填充 LineEntry。
• 跨 reader 复用：位置必须由同一行表的 Tell 产生并回传给同一行表。
• 把 Tell/Seek 当成 SeekPC：前者是检查点恢复，后者是按 PC 查找并有独立的错误和定位语义。

相关问题

Tell 应该放在 Next 前还是后？

取决于恢复后是否要重复当前表项。放在 Next 前会从当前表项开始，放在成功的 Next 后会从下一条开始。

LineReaderPos 能保存到数据库吗？

不建议。它是同一行表 reader 的内部位置值，适合进程内短生命周期检查点，不是稳定的跨进程协议字段。

Seek 能跳到另一个编译单元吗？

不能把一个行表的 Tell 结果用于另一个编译单元的 LineReader。需要跨单元定位时，应重新创建目标行表 reader 并采用适合的业务索引。

读到 EOF 后还能用之前的 Tell 恢复吗？

如果位置是此前由同一行表的 Tell 返回并保存的，可以在该 reader 上 Seek 回去；EOF 只表示当前顺序读取已经到达末尾。