不能直接读 r.Body 两次，因其是单次读取的流，一旦被读取就会耗尽；需在框架解析前缓存并替换为 bytes.Reader，且须注意中间件注册顺序与路径匹配策略。
为什么不能直接读 r.Body 两次？
Go 的 http.Request.Body 是单次读取的流，一旦被框架（如 Gin、Echo）或你自己的代码调用 io.ReadAll(r.Body) 或 json.NewDecoder(r.Body).Decode()，后续再读就返回空字节。很多中间件在解析 JSON 或表单前没做缓冲，导致敏感词过滤拿不到原始 body。
解决思路是：在框架解析前，把原始 body 缓存一份，再替换 r.Body 为可重复读的 bytes.Reader。但要注意——不是所有框架都允许安全替换 r.Body，尤其是用了 Request.ParseForm() 或 BindJSON() 的场景。
- Gin 中必须在
gin.Engine.Use()注册的中间件里做，且要早于gin.Recovery()和任何绑定逻辑 - Echo 要在
echo.MiddlewareFunc中调用c.Request().Body = io.NopCloser(bytes.NewReader(buf))，且不能在c.Bind()后再操作 - 别用
httputil.DumpRequest，它会自动 consume body，且包含 header，体积大、性能差
如何只拦截特定路由路径？
硬编码 if r.URL.Path == "/api/v1/submit" 不够灵活，也难维护。推荐用路径前缀匹配 + 白名单 map，避免正则开销和误匹配。
示例（Gin 场景）：
立即学习“go语言免费学习笔记（深入）”；
var sensitivePaths = map[string]struct{}{
"/api/v1/comment": {},
"/api/v1/feedback": {},
"/user/profile": {},
}
func SensitiveFilterMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
if _, ok := sensitivePaths[c.Request.URL.Path]; !ok {
c.Next()
return
}
// 继续执行 body 拦截和过滤逻辑
...
}
}
- 注意：路径需与注册路由完全一致（含 trailing slash），建议统一用无尾斜杠风格
- 若用通配符（如
/api/v1/*），改用strings.HasPrefix(c.Request.URL.Path, "/api/v1/")，但需排除静态资源路径（如/api/v1/assets/xxx.js） - 不要在中间件里调用
c.Abort()后还继续执行后续逻辑，容易引发 panic 或响应冲突
怎么安全提取并过滤请求体内容？
不能假设所有请求都是 JSON；常见类型包括 application/json、application/x-www-form-urlencoded、multipart/form-data。后两者需分别处理 form value 和 file 字段，而 multipart 里的文本字段才需要过滤。
实操建议：
- 先检查
r.Header.Get("Content-Type")，仅对json和form-urlencoded类型做全文本扫描；multipart只遍历ParseMultipartForm后的r.PostForm值，跳过文件字段 - 敏感词匹配用 AC 自动机或简单
strings.Contains即可，除非词库超万级；避免正则，尤其带 Unicode 的词容易出错 - 过滤后返回错误时，用
c.AbortWithStatusJSON(400, gin.H{"error": "包含敏感词"})，别用panic或裸http.Error - 原始 body 最大长度建议限制（如 2MB），防止 OOM：
body, err := io.ReadAll(io.LimitReader(r.Body, 2
为什么 Gin 的 c.Request.Body 替换后 BindJSON 还失败？
因为 Gin 的 BindJSON 内部会再次调用 io.ReadAll，如果你替换的是 bytes.Reader，它支持多次读，但 Gin 默认会在读完后重置指针——前提是没被其他中间件提前 consume。
关键点：
- 确保你的中间件在
gin.Default()的默认链最前面（即engine.Use(SensitiveFilterMiddleware())放在所有Use调用之前） - 不要在中间件里调用
c.ShouldBind*，否则 body 被读走，后续绑定失效 - 如果用了
gin.BasicAuth或其他依赖 body 的中间件，顺序错乱会导致 body 已空，此时需调整顺序或改用c.Request.Header.Get("Authorization")手动解析 - 调试时打印
r.ContentLength和实际读取长度，确认是否被截断或提前关闭
真正麻烦的永远不是“怎么加中间件”，而是 body 生命周期和框架内部消费顺序的耦合。多打几行 log，比查文档更快定位问题。
