Gin 不过滤控制字符是因为其直接透传 Go 标准库的 http.Request，而标准库遵循 RFC 7230 但不强制校验请求头和 URL 中的字符合法性，导致日志污染、响应头注入等风险，需手动白名单过滤。
Go 的 net/http 和 Gin 都不自动过滤请求头或 URL 中的控制字符（如 \x00、\r、\n、\t），必须手动拦截，否则可能引发日志污染、响应头注入、JSON 序列化 panic 或 XSS。
为什么 Gin 不拦控制字符
Gin 的 c.Request 直接透传底层 http.Request，而 Go 标准库对请求头、URL 路径、查询参数均不做任何字符合法性校验——r.Header.Get("X-Trace-ID") 返回的就是原始字节，c.Request.URL.Path 也未去除首尾空白或替换 %00。RFC 7230 明确规定 header value 只能含可见 ASCII（0x21–0x7E）、空格和制表符，且不能首尾空白，但 Go 不 enforce 这条规则。
常见错误现象：
-
log.Printf("path: %s", c.Request.URL.Path)因含\r\n导致日志换行错乱 - 前端构造
X-Forwarded-For: 127.0.0.1\r\nSet-Cookie: x=1，服务端未过滤就透传给下游，触发响应头分裂 - 将恶意 header 值直接拼进
fmt.Sprintf("INSERT INTO logs (ua) VALUES (%q)", ua)，造成 SQL 注入
用白名单方式清理 header 和 path
别用黑名单替换（比如删掉 \x00），攻击者总能绕过；应只保留 RFC 允许的字符集，其余一律丢弃。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 对每个 header value 调用
strings.Map：只保留rune >= 0x20 && rune （可见 ASCII）和 <code>rune == ' '、rune == '\t'，其他映射为-1（即删除） - 对
c.Request.URL.Path和c.Request.URL.RawQuery同样处理，避免路径遍历或 query 注入 - 先用
utf8.ValidString()检查，无效则跳过或替换为"??"，防止后续json.Marshalpanic - 跳过
Cookie和Authorization头——它们含 Base64 或二进制 token，不应做字符级过滤，应走专用解析逻辑
Gin 中间件里怎么写才不拖慢请求
控制字符过滤必须轻量，不能在中间件里做正则匹配、URL 解码或 JSON 解析——这些操作是 O(n) 且易被恶意 payload 拖垮。
实操建议：
- 全局单例初始化一个清理函数，比如
func clean(s string) string，用strings.Map实现，避免每次分配新闭包 - 中间件内只对必要字段过滤：
c.Request.URL.Path、c.Request.Host、c.Request.UserAgent()、以及你业务明确要读取的自定义 header（如X-Request-ID） - 不要遍历
r.Header全部 key——有些 header（如Accept-Encoding）含逗号分隔值，清理逻辑更复杂，优先过滤你真会用到的 - 若需高性能，可改用
bytes.Map处理[]byte，避免字符串转字节切片的额外拷贝
容易被忽略的边界点
最常漏掉的是多值 header 和空格规范化。
注意：
-
r.Header是map[string][]string，同一个 key 可能有多个值，c.Request.Header["X-Trace-ID"]是切片，不能只取c.Request.Header.Get("X-Trace-ID") - RFC 要求 header value 不能以空格或制表符开头/结尾，但 Go 不 trim，需手动
strings.TrimSpace再清理 - 某些代理（如 Nginx）会自动合并重复 header，但 Go 不保证顺序，
Header["X-Forwarded-For"][0]不一定是最外层 IP - 清理后若为空字符串，应视为非法输入并主动
c.AbortWithStatus(http.StatusBadRequest)，而不是放行空值
