go的error是值而非异常，无法彻底屏蔽；所谓“屏蔽”实为控制错误类型、内容与传播路径，唯一可靠方式是重构api契约，提供不返回error的抽象接口（如loader.load() (data, bool)），将错误消化在内部或通过事件通知，而非暴露裸error。
不能彻底屏蔽——Go 的 error 是值，不是异常；只要函数返回了 error，调用方就必须看到它。所谓“屏蔽”，本质是控制错误的类型、内容和传播路径，而不是让它消失。
为什么直接 return error 就会“显露”？
Go 没有访问修饰符（如 private/protected），也没有运行时错误拦截机制。一旦你定义了一个导出函数（首字母大写），又让它返回 error，那调用方就必然能拿到这个 error 值，并可对其做任何操作：打印、判断、包装、忽略。
- 哪怕你把错误类型藏在
internal/包里，只要它实现了error接口且导出了方法，外部仍可通过errors.As或类型断言提取 -
internal只拦 import，不拦运行时行为——cmd/main.go里一行err := mypkg.Do(); if err != nil { ... }完全合法 - 用
panic替代error更糟：它不可预测、难测试、绕过正常控制流，且无法被静态分析识别
真正可控的“隐藏”手段：封装 + 接口 + 工厂函数
想让调用方不感知底层错误细节，唯一可靠方式是不暴露错误本身，而是提供一个“成功即可用”的抽象接口。
- 定义不返回
error的导出接口，例如：type Loader interface { Load() (Data, bool) }—— 用布尔值表达是否就绪，内部错误转为静默失败或默认值 - 工厂函数返回该接口，而非具体结构体：
func NewLoader(cfg Config) Loader，把初始化错误消化在构造阶段（比如 panic on invalid cfg，或返回 nil + log） - 所有可能出错的操作（文件读取、网络请求、解析）都在实现内部处理，只对外暴露“结果”或“状态”，不抛错误链
- 若必须通知失败，用回调或 channel 发送结构化事件（如
ErrEvent{Code: "CONFIG_MISSING", Time: time.Now()}），而非裸 error
哪些“屏蔽”做法实际无效甚至有害？
常见但错误的尝试：
- 在导出函数里
log.Fatal(err)或os.Exit(1)：直接终止进程，调用方连响应机会都没有 - 用
fmt.Errorf("something went wrong")替换原始错误：丢失了errors.Is可识别的语义（如os.ErrNotExist），下游无法做分支处理 - 把错误转成字符串再塞进自定义 struct 的 Message 字段：调用方无法用
errors.As提取原始错误，也无法做重试判断 - 依赖
internal目录阻止 import：只要模块路径匹配，github.com/user/app/internal/db仍可被github.com/user/app/cmd导入并直接调用其导出函数
最易被忽略的一点：所谓“屏蔽”，从来不是技术限制问题，而是契约设计问题。如果你的包承诺“返回 error”，那就得接受它被检查、被包装、被记录。真正要做的，是重新定义这个契约——从“我可能失败，你来处理”变成“我保证可用，失败由我兜底”。这需要重构 API，而不是加一层 wrapper。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
