Go文件操作错误不能用recover捕获，必须统一返回可分类的自定义错误（如AppError），结合os.IsNotExist等判断分支处理，并通过errors.As在中间件中全局响应，配合errgroup实现并发错误聚合。
文件操作错误不能靠recover捕获
Go 的 recover 对 os.Open、io.Copy 这类系统调用失败完全无效——它们返回的是 error 值，不是 panic。试图在文件操作函数外加 defer+recover，只会漏掉 99% 的真实错误，还掩盖了本该显式处理的路径问题、权限拒绝或磁盘满等场景。
真正要做的，是让所有文件操作函数统一返回可识别、可分类的错误类型，并在调用点强制检查。比如 os.IsNotExist(err) 和 os.IsPermission(err) 必须被主动分支处理，而不是笼统打日志后忽略。
- 别写
if err != nil { log.Fatal(err) }—— 这会直接 kill 进程，且无法区分“文件不存在”和“磁盘只读” - 不要用
strings.Contains(err.Error(), "permission")判断权限错误，它脆弱、易误判、不跨平台 -
os.PathError是底层常见错误类型，但不应直接断言；应封装一层业务语义，比如ErrFileNotFound或ErrAccessDenied
用自定义错误包装文件操作结果
裸调 os.Open 返回的 *os.PathError 没有业务码、无 traceID、不可扩展。你需要一个轻量 wrapper，在打开、读取、写入时注入上下文并标准化错误出口。
示例：封装 OpenReadonly 函数，统一处理常见路径错误：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
func OpenReadonly(path string, traceID string) (*os.File, error) {
f, err := os.Open(path)
if err != nil {
switch {
case os.IsNotExist(err):
return nil, &AppError{
Code: 404,
Message: "file not found",
Detail: fmt.Sprintf("path=%s", path),
TraceID: traceID,
}
case os.IsPermission(err):
return nil, &AppError{
Code: 403,
Message: "access denied",
Detail: fmt.Sprintf("path=%s", path),
TraceID: traceID,
}
default:
return nil, &AppError{
Code: 500,
Message: "failed to open file",
Err: err, // 保留原始 error，供 debug.Stack() 或 errors.Unwrap()
TraceID: traceID,
}
}
}
return f, nil
}
- 每个分支返回具体
*AppError，而非fmt.Errorf("xxx: %w", err)—— 后者适合链式传播，但此处需要明确状态码和用户提示 -
Detail字段只放安全信息（路径、操作名），绝不含内容体、密码、token 等敏感字段 - 如果调用方不需要 traceID，传空字符串即可；不要为省事删掉该参数——它是一致性日志追踪的唯一锚点
中间件级统一响应需配合 HTTP handler 结构
你写了 *AppError，但若 handler 还是自己写 w.WriteHeader(404); json.NewEncoder(w).Encode(...)，就白封装了。真正的“全局”体现在 HTTP 入口层对 error 的统一消费。
必须让 handler 函数签名变成 func(http.ResponseWriter, *http.Request) error，再套一层中间件：
func WithFileErrorHandling(next func(http.ResponseWriter, *http.Request) error) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
err := next(w, r)
if err == nil {
return
}
var appErr *AppError
if errors.As(err, &appErr) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(appErr.Code)
json.NewEncoder(w).Encode(map[string]interface{}{
"code": appErr.Code,
"message": appErr.Message,
"trace_id": appErr.TraceID,
})
return
}
// 非 AppError，兜底为 500
w.WriteHeader(500)
json.NewEncoder(w).Encode(map[string]interface{}{
"code": 500,
"message": "internal error",
})
})
}
- 这个中间件只处理
error返回值，不碰 panic —— 文件操作不该 panic，panic 留给真正致命的初始化失败 -
errors.As是关键：它能穿透fmt.Errorf("xxx: %w", wrappedErr)找到最内层的*AppError，比类型断言更健壮 - 不要在中间件里记录所有 error —— 只记录
Code >= 500的错误；4xx 错误应在业务逻辑点单独打日志，带完整参数
并发文件操作必须显式收集错误
用 go 启多个 goroutine 去读不同文件？recover 依然无效，而且你根本收不到子 goroutine 的 error。必须用同步机制把错误聚回来。
推荐用 errgroup.Group，它天然支持 context 取消和错误聚合：
g, ctx := errgroup.WithContext(r.Context())
for _, path := range paths {
path := path // 避免循环变量复用
g.Go(func() error {
f, err := OpenReadonly(path, getTraceID(ctx))
if err != nil {
return err // 自动被 g.Wait() 收集
}
defer f.Close()
// ... 处理文件
return nil
})
}
if err := g.Wait(); err != nil {
return err // 直接返回，由上层中间件处理
}
- 每个子 goroutine 的错误都会被
g.Wait()返回，无需 channel 手动收集 -
errgroup会在任一子任务出错后自动 cancel 其他正在运行的任务，避免资源浪费 - 注意闭包中捕获
path要显式复制，否则所有 goroutine 可能读同一个路径
errors.As 断言、是否与 traceID 绑定、是否在并发场景下不丢失。漏掉其中任何一环，所谓的全局框架就只剩个壳。 
