对于一个Golang开发者来说，牢固扎实的基础是十分重要的，编程网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《检测Golang中使用bufio.Read或bufio.ReadByte是否达到文件末尾EOF》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！
问题内容我希望通过尝试再读取一个字节（并捕获 EOF）来确认没有更多字节可从缓冲读取器（既不是从内部缓冲区读取，也不是从底层文件对象读取）。
使用 bufio.Read 或 bufio.ReadByte 是否适合此目的？
从 bufio.Read 文档中不清楚在非 EOF 情况下返回的整数是否可以为零。即，如果 len(p) > 0> 0，0, nil 是否是有效的返回值？
func (b *Reader) Read(p []byte) (n int, err 错误) Read 将数据读入 p。它返回读入 p 的字节数。这些字节是从底层 Reader 上最多一次读取中获取的，因此 n 可能小于 len(p)。要准确读取 len(p) 个字节，请使用 io.ReadFull(b, p)。在 EOF 处，计数为零，错误将为 io.EOF。
类似地，bufio.ReadByte 文档没有很好地将错误情况与 EOF 情况分开，并且它没有准确定义“可用”的含义（即在内部缓冲区中可用，或在底层文件中可用） ）？
func (b *Reader) ReadByte() （字节，错误） ReadByte 读取并返回单个字节。如果没有可用字节，则返回错误。
解决方案
将长度为 1 的缓冲区传递给 bufio.Read，当读取器支持底层 os.File 时，如果文件位于 EOF，则确实会返回 n==0、io.EOF .
文档有点不精确，因为某些行为取决于您传递给 bufio 阅读器的底层阅读器。 bufio.Read()的代码绘制出更准确的图。我将概述逻辑。
bufio.Read：仅当内部缓冲区中的所有字节都已耗尽时，才向底层读取器发出 Read。因此，据推测，如果您已经从缓冲读取器读取了与底层文件中的字节数一样多的字节，那么当您最后一次调用 bufio.Read(buf[0:1]) 时，该内部缓冲区应该会耗尽 检查 EOF。
当内部缓冲区耗尽，并且您向 bufio 读取器请求更多缓冲区时，bufio.Read 将至多对底层读取器进行一次调用。您收到的错误类型将取决于您的底层读者。
当读取指针已位于 EOF 时，要求从 os.File 读取 n > 0 字节应返回 0, io.EOF （根据 os.File File.Read 上的文档）。但是，如果您的底层读取器是其他东西，也许是特定于您的应用程序的自定义类型，旨在在 EOF 处返回 0、nil，那么 bufio.Read 会回显该内容。
bufio.ReadByte： bufio.ReadByte 背后的逻辑略有不同，但在底层读取器是 os.File 的情况下，结果应与 bufio.Read 相同。与 bufio.Read 的主要区别在于 bufio.ReadByte 可以多次尝试重新填充内部缓冲区。如果在重新填充期间遇到错误（对于 EOF 处的 os.File 读取器来说就是这种情况），则在第一次错误读取尝试后返回该错误。因此，如果您的底层阅读器是 os.File 阅读器，那么当且仅当您的底层文件位于 EOF 时，您才会得到 0, io.EOF。如果您的底层读取器是仅在 EOF 处返回 0、nil 的自定义读取器类型，则 bufio.ReadByte 最终会发出“NoProgress”错误。我不确定为什么重试逻辑仅在 bufio.ReadByte 中，但好消息是，如果您的底层文件的行为类似于 os.File，则可以使用任一选项。
其他信息：
这并不直接适用于 golang，但您可能会发现以下线程很有趣：Can read(2) return zero bytes when not at EOF。它的主题是 read() 系统调用的语义 (POSIX)。在非阻塞套接字/文件上读取，即使没有数据准备好，也应该返回 -1，而不是 0，并设置 errno EAGAIN（或中断时的 EINTR）。非阻塞套接字/文件并不是真正的 go 原生概念（据我所知），特别是 bufio 模块将 panic() 每当/如果底层读取器返回负数，所以你不必担心这个。
终于介绍完啦！小伙伴们，这篇关于《检测Golang中使用bufio.Read或bufio.ReadByte是否达到文件末尾EOF》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~编程网公众号也会发布Golang相关知识，快来关注吧！
