在 Go 的 HTTP 中间件链中，调用 http.Error() 不会自动终止后续中间件执行；必须显式 return 才能阻止后续逻辑运行，否则可能引发重复写入响应体或状态码冲突等严重问题。
在 go 的 http 中间件链中，调用 `http.error()` 不会自动终止后续中间件执行；必须显式 `return` 才能阻止后续逻辑运行，否则可能引发重复写入响应体或状态码冲突等严重问题。
Go 的 http.Error() 是一个便捷函数，用于快速写入错误响应（如 401 Unauthorized），但它仅负责写入响应头与正文，并不终止当前处理函数的执行流。这意味着：即使你已调用 http.Error(w, "Unauthorized", http.StatusUnauthorized)，若未紧跟 return，后续代码（包括外层中间件的 next.ServeHTTP() 调用）仍会继续执行——这极易导致 http: multiple response.WriteHeader calls panic 或不可预测的响应内容覆盖。
✅ 正确做法是：在 http.Error() 后立即 return，确保当前 handler/中间件函数提前退出：
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
token := r.Header.Get("Authorization")
if token == "" {
http.Error(w, "Missing Authorization header", http.StatusUnauthorized)
return // ✅ 关键：立即返回，中断链式调用
}
// 验证 token...
if !isValidToken(token) {
http.Error(w, "Invalid token", http.StatusUnauthorized)
return // ✅ 同样需要 return
}
// 一切正常，继续调用下一个中间件或最终 handler
next.ServeHTTP(w, r)
})
}
⚠️ 注意事项：
- ❌ 不要依赖 w.Header().Get("Status") 判断是否已出错——http.Error() 并不设置 Status 头（该头已被废弃），而是直接调用 w.WriteHeader(statusCode)，而 Header().Get() 对已写入的状态码无感知；
- ❌ 不要尝试在中间件中“捕获”已写入的响应——http.ResponseWriter 接口本身不提供 Written() 方法（标准库中无此能力），强行检测易引入竞态或误判；
- ✅ 若需更结构化错误控制（如统一错误格式、日志、重定向），可封装 ResponseWriter 实现 Written() 检查（如使用 github.com/gorilla/handlers 的 ResponseWriter 包装器），但对绝大多数场景，显式 return 是最轻量、最可靠、最符合 Go 惯例的解决方案。
总结：Go HTTP 中间件的执行流完全由 Go 函数控制流决定。http.Error() 只是写响应的工具函数，不是控制流语句。牢记“写完即返”，是编写健壮、可维护中间件链的基本原则。
