go 的 net/http 默认限制请求体为 10mb，但为防范资源耗尽攻击，建议根据业务需求主动设置更严格的请求体上限；可通过 http.maxbytesreader（按 handler 精细控制）或 http.maxbyteshandler（全局统一限制）实现，并配合超时与头部限制增强安全性。
在 Go Web 开发中，限制表单（尤其是含文件上传的 POST 请求）的请求体大小，不仅是性能优化手段，更是关键的安全实践。默认的 10MB 限制（由 http.Request.ParseForm 内部调用 maxMemory 机制隐式约束）不足以抵御恶意客户端发起的“慢速大体积请求”攻击——例如发送超长无 Content-Length 的流式数据，持续占用连接与内存。
✅ 推荐方案：分层设限，兼顾灵活性与安全性
1. Handler 级精细控制（推荐用于特定路由）
在 ServeHTTP 或路由处理函数中，使用 http.MaxBytesReader 包装请求体，再解析表单：
const MaxFileSize = 5 << 20 // 5 MB
func uploadHandler(w http.ResponseWriter, r *http.Request) {
// 在 ParseForm 前包装 Body，强制截断超限数据
r.Body = http.MaxBytesReader(w, r.Body, MaxFileSize)
if err := r.ParseForm(); err != nil {
http.Error(w, "Request entity too large", http.StatusRequestEntityTooLarge)
return // 连接将自动关闭，无需手动干预
}
// 后续正常处理表单数据或文件
file, _, _ := r.FormFile("file")
defer file.Close()
// ...
}? 原理说明：http.MaxBytesReader 会在底层 ResponseWriter 上设置一个内部标记（w.(*response).reqBodyLimitHit = true）。当读取超出限制时，后续对 r.Body.Read() 的调用立即返回 http.ErrBodyReadAfterClose，且 HTTP 服务器在 handler 返回后自动关闭该连接，无需手动 Close() 或担心残留读取。
2. 全局统一限制（推荐用于整个服务）
若所有请求均需统一限制，优先使用 http.MaxBytesHandler —— 它在请求进入 handler 前即拦截，更早释放资源：
import "net/http"
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/upload", uploadHandler)
mux.HandleFunc("/", homeHandler)
// 全局限制：所有请求体不得超过 4KB（不含 multipart boundary 开销）
handler := http.MaxBytesHandler(mux, 4096)
log.Fatal(http.ListenAndServe(":8080", handler))
}⚠️ 注意：MaxBytesHandler 对 multipart/form-data 的限制包含整个原始请求体（含边界、头信息等），实际可用文件大小略小于设定值。
3. 补充防御：配置 Server 级超时与头部限制
仅限制请求体不够。恶意客户端可能通过长连接、巨量 Header 或缓慢发送数据绕过限制。务必同步配置：
server := &http.Server{
Addr: ":8080",
Handler: http.MaxBytesHandler(mux, 5<<20), // 5MB
ReadTimeout: 10 * time.Second, // 读取请求头/体的总超时
WriteTimeout: 15 * time.Second, // 写响应的超时
MaxHeaderBytes: 1 << 20, // Header 总大小上限 1MB
}
log.Fatal(server.ListenAndServe())? 常见误区与注意事项
- ❌ 不要依赖 Content-Length 校验：恶意客户端可省略该 Header，发起 chunked 编码的流式攻击；MaxBytesReader 能有效应对无长度声明的场景。
- ❌ 避免在 ParseForm() 后才检查大小：此时整个 body 已被读入内存（尤其 multipart 会暂存至磁盘或内存），失去防护意义。
- ✅ 错误响应应使用标准状态码：如 http.StatusRequestEntityTooLarge (413)，便于前端识别与日志追踪。
- ✅ 生产环境建议结合反向代理（如 Nginx）做前置限流，形成纵深防御。
通过 MaxBytesReader + MaxBytesHandler + Server 超时配置的三层组合，可高效阻断资源耗尽类攻击，在保障功能的同时显著提升服务健壮性。
