Go HTTP服务需启用TLS加密、安全解析URL参数、禁用interface{}反序列化、中间件避免http.Error()误用。
Go 的 http.Server 默认不加密，必须显式启用 TLS
Go 标准库的 http.ListenAndServe 默认走 HTTP 明文，任何中间节点都能看到请求头、Cookie 和响应体。生产环境绝不能直接暴露 http.ListenAndServe(":8080", nil)。
正确做法是用 http.ListenAndServeTLS，并提供有效的证书文件：
http.ListenAndServeTLS(":443", "server.crt", "server.key", handler)
注意：server.crt 必须包含完整证书链（如含 intermediate CA），否则某些客户端（尤其是 iOS、Java）会校验失败；server.key 权限应设为 0600，避免被非 root 用户读取。
使用 http.Request.URL.RawQuery 时需手动解码，否则可能绕过参数校验
Go 的 http.Request.URL.Query() 返回的是已解码后的 url.Values，但 RawQuery 是原始字符串。如果业务逻辑直接拼接或正则匹配 RawQuery（比如做 WAF 规则），攻击者可通过双重编码（如 %252e%252e 表示 ../）绕过过滤。
立即学习“go语言免费学习笔记（深入）”；
安全写法是统一走 req.URL.Query() 获取参数，并对关键字段做白名单校验：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免用
strings.Contains(req.URL.RawQuery, "../")做路径遍历防护 - 文件名、路径段等敏感输入，优先用
filepath.Clean()+ 白名单目录前缀比对 - 若必须解析原始 query，先调用
url.QueryUnescape()解一次，再判断
JSON 反序列化要禁用 interface{}，防止类型混淆与 DoS
用 json.Unmarshal([]byte, &v) 且 v 是 interface{} 时，Go 会将数字默认转为 float64，对象转为 map[string]interface{}，数组转为 []interface{}。这不仅导致类型断言繁琐，更可能引发两类问题：
- 攻击者发送超深嵌套 JSON（如 100 层对象），触发栈溢出或内存耗尽
- 服务端未检查字段类型，把
float64当整数用，造成精度丢失或越界（如 ID 字段误用int(v.(float64))）
推荐方案：定义明确结构体，用 json.Number 控制数字解析行为：
type Req struct {
ID json.Number `json:"id"`
Name string `json:"name"`
}
后续可安全调用 idInt, _ := req.ID.Int64() 或 idFloat, _ := req.ID.Float64()，避免隐式转换。
HTTP 中间件里别用 http.Error() 终止流程，它不阻止后续 handler 执行
http.Error() 只是向 ResponseWriter 写入状态码和错误体，但不会中断 handler 调用链。如果在中间件中调用它后还继续执行 next.ServeHTTP()，可能导致响应头重复写入（http: superfluous response.WriteHeader call）或敏感数据泄露。
正确方式是用返回值控制流程：
- 定义中间件返回
bool表示是否已处理完毕 - 或用闭包包装 handler，检查条件不满足时直接 return，不调用 next
- 绝对不要在中间件里写完
http.Error()后再调用next.ServeHTTP()
尤其注意：Go 1.22+ 对重复写 header 的 panic 更严格，这类 bug 容易在压测时集中暴露。
