errormiddleware不可用反射调用业务handler，因其破坏http执行模型；正确做法是用反射从错误对象提取statuscode/errorcode，需确保错误实现unwrap()以支持errors.is()穿透。
反射调用无法直接用于 errorMiddleware 的 handler 包裹逻辑
中间件本质是函数装饰器，errorMiddleware 接收的是 http.HandlerFunc 类型，它签名固定为 func(http.ResponseWriter, *http.Request)。反射调用（如 reflect.Value.Call()）适用于动态调用任意结构体方法，但不能替代 HTTP 处理流程的控制权移交。试图用反射“调用 handler”会绕过 net/http 的执行模型，导致 w 和 r 无法正确传递、response 已写入却未结束等隐性崩溃。
真正该用反射的地方：错误类型自动提取 StatusCode 和 ErrorCode
当业务层返回一个自定义错误（比如 *AppError 或实现了 ErrorStatuser 接口的类型），中间件需要从该错误中安全读取状态码。手动类型断言（if e, ok := err.(*AppError); ok { ... }）可读但脆弱——一旦新增错误类型就得改中间件。此时可用反射辅助解耦：
- 检查错误是否实现了
StatusCode() int方法，有则调用获取 HTTP 状态码 - 检查是否实现了
ErrorCode() int方法，有则提取业务码用于日志或响应字段 - 避免
errors.As()无法覆盖嵌套包装（如fmt.Errorf("wrap: %w", e)）时的 fallback 场景
示例片段（不推荐全量反射，仅关键字段）：
func getStatusCode(err error) int {
if err == nil {
return http.StatusOK
}
v := reflect.ValueOf(err)
if v.Kind() == reflect.Ptr {
v = v.Elem()
}
if method := v.MethodByName("StatusCode"); method.IsValid() {
if ret := method.Call(nil); len(ret) > 0 && ret[0].Kind() == reflect.Int {
return int(ret[0].Int())
}
}
return http.StatusInternalServerError
}
为什么不要在中间件里反射调用业务函数
常见误区是想用反射把 handleUserGet 这类函数“泛化注册”，再由中间件统一 invoke。这会引入三类问题：
- 参数绑定不可靠：HTTP 请求参数需手动解析并匹配到函数签名，
reflect.Type.In(i)无法自动识别 query/body/json 绑定逻辑 - 上下文丢失：
context.Context无法自然注入，超时、取消、traceID 等信息断裂 - panic 捕获失效：反射调用发生在中间件 goroutine 内，但业务 handler 本身可能启动新 goroutine 并 panic，
recover()无法跨协程捕获
正确的分层是：路由 → 中间件（recover + 错误标准化）→ handler（显式调用 service 层函数，返回 error 或 *AppError）→ service 层内部可安全使用反射（如通用 DAO 查询）。
容易被忽略的兼容点：Unwrap() 和 errors.Is() 必须存在
如果业务错误用了 fmt.Errorf("xxx: %w", underlying) 包装，而你又依赖反射提取 ErrorCode()，那反射只作用于最外层错误。真正需要判断底层错误类型（比如 errors.Is(err, context.DeadlineExceeded)）时，必须确保所有包装错误都实现了 Unwrap() error。否则 errors.Is() 无法穿透，中间件就只能按最外层错误处理，导致数据库超时被当成 500 而非 503。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
