go中http参数污染通过发送重复查询参数（如?id=1&id=2）触发，net/http不合并而存为[]string；r.formvalue("id")和req.url.query().get("id")均只取首值，需手动校验len(req.url.query()["id"])==1防绕过。
HTTP参数污染（Parameter Pollution）在Go里怎么触发
Go的net/http默认不主动合并或报错重复参数，而是把所有同名key都塞进req.URL.Query()或req.PostForm的map[string][]string里。你以为r.FormValue("id")拿的是第一个值，其实它只取[]string的第一个元素——但攻击者可以故意发?id=1&id=2&id=sql_inject，后端若直接拼SQL或透传给下游服务，就可能被绕过校验。
用req.URL.Query().Get()还是req.FormValue()？
两者行为一致：都只返回同名参数的第一个值，且忽略后续重复项。这不是bug，是设计使然，但容易让人误以为“系统已去重”。真正危险的是你手动遍历req.URL.Query()["id"]却没做长度校验，或者用ParseMultipartForm后直接取req.MultipartForm.Value["id"][0]而没检查数组长度。
-
req.FormValue("id")和req.URL.Query().Get("id")安全性等价，都只取首值 - 若业务逻辑要求“参数必须唯一”，得自己加校验：
if len(req.URL.Query()["id"]) > 1 { http.Error(w, "duplicate param", http.StatusBadRequest); return } - 注意
req.ParseForm()会把URL查询参数和body表单合并到req.Form，此时req.Form["id"]可能是混合来源的多值数组
中间件层统一拦截重复参数
靠每个handler手写校验不可持续，适合用中间件提前拦截。关键是不能只看GET，还要覆盖POST/PUT的application/x-www-form-urlencoded和multipart/form-data（后者需先调ParseMultipartForm才能拿到Value字段）。
- 对
GET：遍历req.URL.Query()每个key，len(values) > 1即拒绝 - 对
POST/PUT：先req.ParseForm()，再检查req.Form；若含文件上传，还需额外检查req.MultipartForm.Value - 别忘了
Content-Type: application/json场景——它不走Form解析，但前端若用fetch拼query string再发JSON body，仍可能触发URL层污染
为什么gorilla/schema或go-playground/validator不自动防PP
这些库专注结构体绑定和字段校验，不介入HTTP参数原始解析阶段。比如schema.Decode把req.Form映射到struct时，若字段类型是string，它默认也只取第一个值；若定义成[]string，反而会把所有重复值全收进来——这等于放大风险。
立即学习“go语言免费学习笔记（深入）”；
- 用
schema时，避免将敏感字段（如user_id、redirect_url）定义为[]string -
validator.v10的unique标签只校验切片内元素是否重复，不校验HTTP参数是否重复提交 - 真正有效的防御点只有一个：在参数进入业务逻辑前，确保每个键对应唯一字符串值，而不是依赖下游库“帮忙过滤”
参数污染的难点不在技术实现，而在思维惯性——总假设“HTTP服务器会帮我去重”。Go选择暴露原始数据结构，是给了你控制权，但也意味着你得亲手检查len(req.URL.Query()["x"]) == 1这种事。漏掉一次，就可能让一个?next=/admin&next=//evil.com绕过跳转白名单。
