Go 问答：net/http Request.BasicAuth 如何区分没有认证与空密码

接口日志里出现了两类 401：一类根本没有 Authorization，另一类却带着 Basic Authentication，只是密码为空。Go 的 net/http.Request.BasicAuth 已经把这两个情况拆开了，关键不是判断用户名或密码是否为空，而是读取第三个返回值 ok。

ok == false 表示请求没有携带可解析的 Basic Authentication；ok == true 时，即使用户名或密码是空字符串，也代表认证头已经被解析出来。

BasicAuth 返回值分别表示什么

BasicAuth 的签名是 username, password string, ok bool。前两个值是解析后的凭据，ok 表示请求头是否存在并能按 Basic Authentication 规则解析。它不是“用户名密码是否正确”的结果，真正的凭据校验仍由业务代码完成。

username, password, ok := r.BasicAuth()
if !ok {
    http.Error(w, "missing basic authentication", http.StatusUnauthorized)
    return
}
if username != "report" || password != "" {
    http.Error(w, "invalid credentials", http.StatusUnauthorized)
    return
}
w.WriteHeader(http.StatusNoContent)

这里的判断顺序很重要：先用 ok 判断认证材料是否存在，再判断用户名和密码是否符合策略。若把 password == "" 直接当成未认证，就会把“空密码已被解析”与“请求没有认证头”混成一个原因。

用三个请求头样例拆开边界

可以直接构造 http.Request 做小实验，不需要启动监听端口。下面三组请求分别表示没有认证头、带有空密码的认证头，以及凭据不符合业务规则的认证头：

func TestBasicAuthBoundaries(t *testing.T) {
    cases := []struct {
        name, header, wantUser, wantPassword string
        wantOK                              bool
    }{
        {name: "missing", wantOK: false},
        {name: "empty-password", header: "Basic cmVwb3J0Og==", wantUser: "report", wantPassword: "", wantOK: true},
        {name: "wrong-password", header: "Basic cmVwb3J0Ondyb25n", wantUser: "report", wantPassword: "wrong", wantOK: true},
    }

    for _, tc := range cases {
        r := httptest.NewRequest(http.MethodGet, "http://example.test/report", nil)
        if tc.header != "" {
            r.Header.Set("Authorization", tc.header)
        }
        user, password, ok := r.BasicAuth()
        if user != tc.wantUser || password != tc.wantPassword || ok != tc.wantOK {
            t.Fatalf("%s: got (%q, %q, %v)", tc.name, user, password, ok)
        }
    }
}

第一个请求的 ok 是 false；第二个请求的密码是空字符串，但 ok 仍为 true。第三个请求同样能被解析，是否允许它访问资源，要由凭据校验策略决定。

认证失败日志应该记录哪一层

建议至少分两层记录：解析层记录 ok 是否为真，策略层记录用户名是否匹配以及密码校验是否通过。这样排查 401 时，能知道是调用方没带头、头部格式无法解析，还是凭据本身不被接受。

不要把密码写进日志，也不要把完整的 Authorization 头复制到错误响应。可以记录请求路径、认证解析是否成功、用户名是否命中，以及最终的 HTTP 状态码；用户名本身也应根据业务敏感级别做脱敏。

容易踩坑的判断方式

只判断 username 是否为空

空用户名不等于没有认证。是否存在可解析的 Basic Authentication，要看 ok，而不是只看某个字符串字段。

把 BasicAuth 当成密码校验器

BasicAuth 只负责解析请求头。它不会替你查询用户表、比较哈希或决定权限，业务层仍要完成凭据验证和授权。

用真实密码写单元测试

测试只需要覆盖行为边界，不应把生产凭据放进测试代码。示例中的 Base64 内容是公开的固定样例，实际系统仍应使用 HTTPS，并避免记录认证头。

相关问题

BasicAuth 的 ok 为 false 时用户名和密码可靠吗？

不应使用它们做认证判断。只有 ok 为 true 时，才进入后续的凭据校验分支。

空密码应该允许通过吗？

这取决于业务规则。技术上它可能是可解析的认证结果；安全策略上通常还要明确禁止空密码或限制在专用内网场景。

为什么不直接读取 Authorization 头自己拆分？

除非有明确的协议扩展需求，否则优先使用 BasicAuth 统一处理解析，再把业务校验放在清晰的独立分支中。

小结

处理 Go 的 Basic Authentication 时，先看 ok，再看用户名和密码，最后才决定是否授权。无认证、认证头可解析但凭据不合格、认证成功这三层边界分开后，代码、日志和测试都会更容易核对。