Go 的 net/http 未内置 Digest Auth 支持，因其协议复杂（含 nonce 管理、qop、HA1/HA2 计算、防重放等），标准库主动舍弃；需手动处理 WWW-Authenticate 头、解析并校验 Authorization: Digest 头，重点防范重放与状态爆炸。
Go 的 net/http 没有内置 Digest Auth 支持
Go 标准库的 net/http 只提供了基础的 Basic 认证（靠 Request.Header.Set("Authorization", "Basic ...")），对 Digest Auth 完全不提供解析、生成或验证逻辑。这不是遗漏，而是设计取舍：Digest Auth 协议复杂（含 nonce 管理、qop、HA1/HA2 计算、防重放等），标准库选择不背这个包袱。
所以你没法靠 http.DefaultServeMux 或 http.HandleFunc 加几行就跑起来。必须自己处理 WWW-Authenticate 响应头、解析客户端发来的 Authorization: Digest ...、校验响应值（response 字段）。
手动实现 Digest Auth 要填的几个关键坑
核心不是“怎么算 response”，而是“怎么不让攻击者重放请求”和“怎么避免服务端状态爆炸”。常见翻车点：
-
nonce不能是纯时间戳或随机字符串——得带服务端可验证的签名（比如base64(sha256(timestamp + secret + clientIP))），否则无法防篡改 -
nc（请求计数）必须和nonce绑定存储，且只接受严格递增（不能跳变、不能回退），否则重放攻击成立 - 客户端传来的
uri字段必须和当前请求的req.URL.RequestURI()完全一致（注意 query 参数顺序、编码），不一致就拒绝，这是 Digest 最容易被绕过的点 -
qop=auth-int几乎没人用，也别碰；坚持用qop=auth，并确保服务端生成nonce时带上qop和algorithm信息，用于后续校验上下文一致性
用 gorilla/handlers 或自定义中间件最实际
别从零写一个完整 Digest 解析器。直接用社区已验证的轮子更稳，比如 gorilla/handlers 的 Secure 选项不支持 Digest，但它的中间件结构适合封装。更推荐轻量方案：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
抄一段经过生产验证的 Digest 工具函数（比如 abbot/go-http-auth），然后按需裁剪。它把核心逻辑收在 auth.DigestValidate 里，你只需提供：
- 用户密码明文或预计算的
HA1（MD5(username:realm:password)） - 一个
func(nonce string) bool验证 nonce 是否未过期且未用过 - 一个
func(nonce string, nc string) bool校验该客户端此 nonce 下的nc是否合法递增
示例关键判断：
if !digestValidator.IsValidNonce(req.Header.Get("Authorization")) {
w.Header().Set("WWW-Authenticate", `Digest realm="myapp", qop="auth", algorithm=MD5, nonce="`+newNonce()+`"`)
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
客户端发来的 Authorization: Digest ... 解析失败常见原因
不是你的 Go 代码错了，大概率是客户端构造错了。重点查这三项：
- 客户端是否把
username里的特殊字符（比如@或:）做了 URL 编码？Digest 规范要求不编码，但很多 HTTP 库会自动 encode，导致服务端解出的 username 对不上数据库 -
response字段长度必须是 32 字符（MD5 hex），少一位或多一位都说明客户端用了错误算法（比如 SHA256 当 MD5 用） - 客户端是否漏传了
qop？如果服务端强制要求qop=auth，而客户端没发，Authorization头会被整个忽略——此时日志里看不到任何 digest 字段，只当没认证 - 浏览器原生支持 Digest 的只有老版本 Firefox/IE；现代前端几乎都用 fetch + 手动拼头，务必确认你控制的客户端代码里
response是按 RFC 2617 附录 A 算的：MD5(HA1:nonce:nc:cnonce:qop:HA2)
真要调试，先用 curl -v 手动构造一次最简请求，比看前端 JS 更快定位是协议层还是业务层的问题。
nonce 管理和 nc 校验这两块最容易写错，而且一错就是安全漏洞。别图省事用内存 map 存 nonce —— 过期清理、分布式部署、并发冲突都会让你半夜被 call。
