需在中间件中手动校验：对GET请求检查r.URL.RawQuery长度，超4KB返回400；对POST/PUT，ParseForm前检查ContentLength，超1MB拒绝并返回400。
Go 的 http.Request 本身不校验请求参数内容，超长字符串和非法控制字符（如 \x00、\r\n、\u202E 等）会原样透传到业务逻辑层——拦截必须由中间件或 handler 自行实现，没有默认防护。
如何在中间件中统一截断或拒绝超长参数
超长参数（如 GET 的 query string 超过 4KB，或 POST body 超过 1MB）容易引发内存耗尽或 DoS 风险。标准库不设限，需手动控制：
- 对
URL查询参数：用r.URL.RawQuery获取原始字符串长度，超过阈值直接http.Error(w, "Bad Request", http.StatusBadRequest)并return - 对
POST/PUT表单参数：调用r.ParseForm()前先检查r.ContentLength，若超出预设上限（如10 即 10MB），直接拒绝，避免 <code>ParseForm内部分配大内存 - 对 JSON body：不要直接
json.NewDecoder(r.Body).Decode(&v)，先用io.LimitReader(r.Body, maxBodySize)包装，再传给 decoder；否则恶意构造的超大数组可能触发 OOM - 注意：
r.FormValue("key")会隐式触发ParseForm，所以校验必须在它之前完成
怎样识别并清理非法控制字符
控制字符本身不是语法错误，但可能干扰日志解析、数据库写入、前端渲染或安全策略（如富文本 XSS 绕过）。Go 没有内置“合法字符串”定义，需按场景定制：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 通用清理：用
strings.Map过滤掉unicode.IsControl且非换行/制表符的 rune，例如保留\n、\t、\r，但剔除\x00、\u202E（RTL 控制符）、\uFEFF（BOM）等 - 路径/文件名参数：额外过滤
unicode.IsSpace和os.PathSeparator相关字符，防止目录遍历 - JSON 字段值：若已知字段语义（如用户名），建议白名单匹配
^[a-zA-Z0-9_\u4e00-\u9fa5]{1,32}$，比黑名单更可靠 - 避免在中间件里修改
r.Form或r.PostForm—— 它们是只读映射，修改无效；应提取后清洗再传给业务 handler
为什么不能只靠 net/http 默认行为
标准 http.Server 对参数内容完全放行，仅做基础解析：
立即学习“go语言免费学习笔记（深入）”；
-
r.URL.Query()不校验 key/value 是否含控制字符，也不限制长度 -
r.FormValue返回的是未经清洗的原始字节，ParseForm也不会拒绝含\x00的 value - HTTP/2 下某些代理（如 nginx）可能自动截断超长 header，但 Go server 仍会收到被截断后的残缺数据，无法感知原始长度
- 如果依赖框架（如 Gin、Echo），它们的绑定（
Bind）默认也不清理控制字符，需额外配置或自定义 validator
真正关键的点在于：控制字符拦截必须与业务语义耦合。一个 \u202E 在用户名里是高危，在加密 token 里可能是合法 base64 编码的一部分。别指望通用中间件一劳永逸，得在参数进入领域逻辑前，按字段做针对性判断和处理。
