探索使用io.ReadAt()进行末尾输入源的行为

在Golang实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《探索使用io.ReadAt()进行末尾输入源的行为》，聊聊，希望可以帮助到正在努力赚钱的你。

我有一个程序，在最初将文件分割成该范围的倍数（即“n”个窗口范围）之后，不断读取输入文件的字节（1MB 范围）。源文件的类型为 *os.File，我使用 io 包中的 ReadAt 方法来读取每个窗口的特定起始地址。

问题是，当读到文件末尾时，例如在最后一个窗口中，尽管文件仍在范围内，但我收到 EOF 错误。当我查找 go.dev 文档时，它说

如果 ReadAt 返回的 n = len(p) 字节位于输入源的末尾，则 ReadAt 可能返回 err == EOF 或 err == nil。

目前尚不清楚，在什么情况下它会返回 nil，因为我不断收到 EOF，即使我仍在范围内阅读。为什么会发生这种情况以及如何避免这种情况？

或者我应该在这种情况下使用 io.SectionReader ？

无法为此场景生成 MCVE。抱歉！

正确答案

如果 readat 返回的 n = len(p) 个字节位于输入源的末尾，readat 可能返回 err == eof 或 err == nil。

此引用与 ReaderAt.ReadAt() 方法相关：

ReadAt(p []byte, off int64) (n int, err error)

您传递一个要读入的切片，以及一个要读取的偏移量。该方法返回读取的字节数和错误。引用的部分意味着如果传递的切片被完全读取并且此操作耗尽了输入（意味着到达末尾），则 err 可能是 nil 或可能是 io.eof。这取决于实现，您应该编写不依赖于具体实现返回的内容的代码。

实际上，这意味着如果返回 io.eof，您立即知道没有更多输入。如果 n == len(p) 且 err == nil，这仅意味着您还不知道是否还有更多数据要读取，您必须调用 read() 或再次readat()，如果没有更多数据，则会读取0个字节（n == 0），这次err肯定是io.eof（假设没有其他错误发生）。

readerat.readat() 的文档还指出：

当 readat 返回 n < len(p) 时，它返回一个非零错误，解释为什么没有返回更多字节。在这方面，readat比read更严格。

这意味着如果 readat() 无法从源完全填充 p （例如，因为在 len(p) 字节可以被读取之前到达其末尾），readat() 将返回非 nil错误将是 io.eof （如果原因是到达源结尾）。

正如第二个引用所述：readat() 比 read() 更严格，readat() 将尝试填充传递的切片（类似于 io.ReadFull()）。因此，只有当 io.SectionReader 使您的代码更具可读性或为您提供方便时，您才应该使用它（例如，如果您不希望 1 mb 缓冲区一步读取该部分，io.sectionreader 可能会使该代码更简单），否则它会获胜给你的不多。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。