Go应用层无法可靠拦截Payload级攻击，因此时连接已建、goroutine已分配、TLS已解密、内存已占用；正则扫描在handler中会加剧CPU压力、易被绕过且导致OOM；真正防护应前置至Nginx/Envoy/CDN，在协议解析前完成匹配与拦截。
Go 应用层无法可靠拦截特定 Payload 的高频恶意攻击——这不是能力问题，而是定位错误。Payload 级检测（如匹配 "union select"、"<script>"</script>、base64-encoded shellcode）天然属于协议解析之后、业务逻辑之前，此时连接已建立、goroutine 已分配、TLS 已解密、内存已分配，攻击流量早已吃掉关键资源。
为什么不能在 http.HandlerFunc 里做 Payload 扫描
这是最常见也最危险的误用：把正则或字节扫描塞进 handler，以为能“拦住 SQL 注入”。实际后果是：
- 每个请求都触发一次完整 body 读取 + 多次正则匹配，CPU 毛刺明显；实测含 10 个
regexp.MustCompile的扫描逻辑，在 5k QPS 下 CPU 占用可飙升至 40%+ -
r.Body是 io.ReadCloser，一旦被中间件提前读取（比如日志、鉴权），后续 handler 调用io.ReadAll(r.Body)会返回空；你写的扫描可能永远不生效 - 攻击者只需把
union select拆成un/**/ion sel/**/ect、或用 URL 编码绕过字符串匹配，规则就失效 - 对 multipart/form-data 或 JSON 流式 body，无法安全截断——你得全量读入内存才能扫描，直接放大 OOM 风险
真正该拦截 Payload 的位置：Nginx / Envoy / CDN
所有有效的 Payload 过滤必须发生在 Go 进程之外，且越早越好。标准做法是：
- Nginx 用
ngx_http_lua_module或modsecurity在access_by_lua_block阶段检查$request_body或$args，匹配即return 403；注意开启client_body_buffer_size和client_max_body_size防止缓冲区溢出 - Envoy 通过
ext_authz或自定义 WASM filter，在 decode headers 后、decode body 前调用外部鉴权服务；WASM 可嵌入轻量级 YARA 规则引擎，支持二进制 payload 匹配 - Cloudflare / 阿里云 WAF 提供“自定义规则”，可直接写正则匹配
request.body，并设置速率阈值（如“10 秒内出现 3 次exec\(|system\(|passthru\(”）
Go 层唯一可行的 Payload 相关防御：结构体绑定 + 白名单校验
如果你非要在 Go 层做点什么，只能放弃“扫描”，转向“约束”——靠类型系统和验证器把非法 payload 拦在解码阶段：
- 对 JSON API，强制使用
json.Decoder.DisallowUnknownFields()，拒绝任何未定义字段；配合github.com/go-playground/validator/v10做字段级白名单，例如：type LoginReq struct { Username string `json:"username" validate:"required,alphanumunicode,min=3,max=20"` Password string `json:"password" validate:"required,min=8,excludesall=<>\"'()"` } - 对表单，不用
r.FormValue，改用r.ParseForm()后遍历r.PostForm，只取白名单 key（如map[string]bool{"username":true, "email":true}），其余一概丢弃 - 对文件上传，绝不用
r.MultipartReader()全量读取，而是在ParseMultipartForm后立刻检查form.File["file"]的Header.Header.Get("Content-Type")是否在白名单（如"image/jpeg","application/pdf"），不是则直接http.Error(w, "", 400)
真正难防的从来不是明文 payload，而是那些绕过所有字符串匹配的变体：编码嵌套、分块传输、HTTP/2 伪头注入、WebSocket frame 分片。别指望 Go handler 能兜底——它连连接建立都来不及干预，更别说解析完再判断。
