BasicAuth中间件需通过basicauth.New()初始化并传入含Users和Realm的Config，挂载时用app.Party("/admin", middleware)限定路径，避免全局拦截；校验失败默认返回401及WWW-Authenticate头，仅Realm可自定义；常见失败原因包括缺失Authorization头、凭证未Base64编码、特殊字符未处理及包路径错误；不建议与JWT/Session混用，因其无状态特性与令牌机制语义冲突。
BasicAuth中间件怎么初始化并挂载到路由？
直接用 basicauth.New() 创建中间件实例，传入 basicauth.Config；注意 Users 字段必须是 map[string]string，键为用户名、值为明文密码（生产环境应替换为哈希比对逻辑）。
挂载时不能直接用 app.Use() 全局启用——那样会拦截所有请求，包括登录页和静态资源。正确做法是通过 app.Party() 限定路径前缀：
-
needAuth := app.Party("/admin", authentication)只对/admin及其子路径生效 - 后续在
needAuth.Get(...)中注册的 handler 才受保护 - 别漏掉
ctx.Next()—— 虽然basicauth内部已处理，但自定义包装时容易误删
BasicAuth失败时返回什么响应？如何自定义？
默认返回 401 Unauthorized 和 WWW-Authenticate: Basic realm="Authorization Required" 头。客户端收到后会弹出系统级登录框。
无法通过中间件返回 HTML 或 JSON 响应覆盖它——这是 HTTP 协议层行为，浏览器强制触发弹窗。若需自定义登录页，必须放弃 BasicAuth，改用表单 + Session/JWT。
唯一可调的是 Realm 字段，它会出现在弹窗标题中：
authConfig := basicauth.Config{
Users: map[string]string{"admin": "pass123"},
Realm: "后台管理区",
}
为什么BasicAuth校验总失败？常见原因有哪些？
最常踩的坑不是代码写错，而是请求构造不合规：
- 前端没加
Authorization: Basic base64(username:password)头——手动拼错或忘记 Base64 编码 - 用户名/密码含特殊字符（如冒号、@），未做 URL 编码就塞进 header
- 服务端用
ctx.Request().BasicAuth()提取时，没检查返回的ok bool值，直接用空字符串参与逻辑 - Iris 版本升级后，
basicauth包路径从github.com/kataras/iris/middleware/basicauth变为github.com/kataras/iris/v12/middleware/basicauth，路径错导致编译失败
BasicAuth能和JWT或Session混用吗？
技术上可以，但语义冲突。BasicAuth 是无状态、每次请求都传输凭证的协议；JWT/Session 是有状态或带签名的令牌机制。强行混合会导致权限判断逻辑分裂、调试困难。
真实项目中，BasicAuth 仅适合内部工具、运维接口等低交互场景。一旦涉及用户登录态维持、角色分级、token 刷新，必须切换到 JWT 或 Session 方案。Iris 的 jwt 和 sessions 中间件已内置支持，不要硬套 BasicAuth 做登录。
特别注意：basicauth 中间件不会自动把认证成功的用户名注入上下文，后续 handler 需要自己调用 ctx.Request().BasicAuth() 提取——这和 JWT 中间件自动设置 ctx.Values().Get("user") 完全不同。
