io.eof 是哨兵错误，本质是包级导出的 error 变量，可用 == 比较因其指向同一内存地址；但自定义 errors.new("...") 多次调用会生成不同地址的对象，故不可用 == 判断。
什么是 io.EOF 这类错误，为什么不能用 == 判断自定义错误
Go 的哨兵错误本质是导出的、包级的 error 变量，比如 io.EOF、os.ErrPermission。它们不是类型，也不是构造出来的实例，而是固定地址的变量指针。所以能用 == 安全比较——因为比较的是指针是否指向同一内存地址。
但如果你自己写 var ErrNotFound = errors.New("not found")，然后在另一个文件里又写一遍同样的 errors.New("not found")，这两个值就**不相等**：它们是两个独立分配的错误对象，地址不同。
- 只在包内定义一次哨兵错误，并导出（首字母大写）
- 下游必须 import 该包后直接使用
pkg.ErrNotFound，而不是重新errors.New - 别对非导出哨兵错误做跨包
==判断，它可能根本不可见
什么时候该用哨兵错误，而不是自定义类型或 errors.Is
哨兵错误适合表达「状态已知、含义单一、无需携带额外信息」的错误，比如“文件结束”“权限拒绝”“路径不存在”。它轻量、判断快、语义清晰。
但一旦你需要区分“为什么找不到”，比如是路径错、还是没权限、还是网络超时，哨兵就不够用了——它无法携带上下文，也不支持嵌套。
立即学习“go语言免费学习笔记（深入）”；
- 纯状态信号（如读到流末尾）→ 用哨兵
- 需要诊断原因（如 “failed to connect: timeout after 5s”）→ 用
fmt.Errorf("...: %w", err)+errors.Is - 需要结构化字段（如错误码、trace ID、重试建议）→ 自定义 error 类型，实现
Error()和Unwrap()
errors.Is 能替代哨兵比较吗？哪些情况会失效
errors.Is 是为处理错误链设计的，它会递归调用 Unwrap()，直到找到匹配的哨兵或返回 nil。但它不是万能的：
- 如果错误链里某一级返回了
nil（比如自定义 error 的Unwrap()实现错了），errors.Is就提前终止，可能漏判 - 如果哨兵错误被包装了但没用
%w（比如用%s拼字符串），errors.Is完全找不到它 -
errors.Is(err, io.EOF)在绝大多数场景下比err == io.EOF更安全，但性能略低；高频路径（如循环读取）仍建议优先用==判断已知哨兵
如何正确导出和测试一个哨兵错误
导出哨兵错误不是简单加个大写字母。它得有明确归属、稳定语义、且文档说明使用边界。
比如你在 pkg/search 里定义 var ErrNotFound = errors.New("item not found")，那就意味着这个错误只表示“查无此条目”，不包含“数据库连不上”或“缓存未命中但 DB 有”这类中间态。
- 导出名要带包/领域前缀，避免冲突：
search.ErrNotFound，而非裸名ErrNotFound - 在 godoc 注释里写清触发条件和调用方应如何响应（例如：“调用方应返回 HTTP 404，不重试”）
- 测试时不要检查错误消息字符串，而要测
errors.Is(got, search.ErrNotFound)或got == search.ErrNotFound - 别把哨兵错误混进
fmt.Errorf("%w", ...)链里再抛出去——除非你明确希望调用方还能用errors.Is捕获它
哨兵错误的脆弱点不在定义，而在传播路径上：只要中间有人用字符串拼接、忽略 %w、或手动 new 一个同名错误，整个判断逻辑就断了。
