fiber的basicauth中间件需手动处理响应与流程控制才生效：校验失败时须显式调用c.status(401).sendstring()并return，不可依赖next()；放行才调next()；应配合group()限制作用域，避免全局拦截，并用subtle.constanttimecompare安全比对密码。
BasicAuth中间件在Fiber里怎么配才生效
Fiber自带的 fiber.BasicAuth 中间件不是开箱即用的“插上就认证”，它只做请求头解析和凭据校验，**不自动返回401响应或拦截未授权访问**——你得手动配合 Next() 和返回逻辑才能真正拦住请求。
常见错误是直接注册中间件后发现没效果，或者所有请求都 401，本质是没理解它只提供 username 和 password 解析，后续逻辑全靠你自己写。
- 必须在中间件内部显式调用
c.Status(401).SendString("Unauthorized")或类似响应，否则即使校验失败，请求仍会继续往下走 - 推荐把校验逻辑封装成闭包，避免在每个路由里重复写判断
- 注意：Fiber v2.48+ 的
fiber.BasicAuth接收的是func(string, string) bool类型函数，不是 map 或配置对象
怎么安全比对账号密码（别硬编码、别明文存）
基础认证的凭据是 Base64 编码的 user:pass，但解码后仍是明文。中间件传进来的 username 和 password 是原始字符串，**务必避免用 == 直接比对密码**——存在时序攻击风险。
实际项目中应使用恒定时间比对（constant-time compare），Fiber 不内置该能力，需自行引入或手写。
- Go 标准库有
crypto/subtle.ConstantTimeCompare，适合比对哈希后的密码（比如你存的是bcrypt哈希值，先查库再比对） - 如果只是开发测试，可用
strings.EqualFold+subtle.ConstantTimeCompare([]byte(a), []byte(b))组合，但仅限非生产环境 - 千万别把密码明文存在代码里或 config 文件中；哪怕测试也建议从环境变量读：
os.Getenv("ADMIN_USER")和os.Getenv("ADMIN_PASS")
为什么用了BasicAuth中间件，/health这类接口也被拦了
因为 app.Use(fiber.BasicAuth(...)) 是全局中间件，所有路由都会经过它。如果你只想保护部分路由（比如 /api/users），就不能用 Use()，而要用 Group() 配合 Use()。
另一个典型问题是：有些前端工具（如 Swagger UI）发预检请求（OPTIONS），BasicAuth 中间件默认不跳过这些方法，导致预检失败。
- 正确做法是创建受保护的路由组：
auth := app.Group("/api", fiber.BasicAuth(...))，然后auth.Get("/users", handler) - 如需放行特定路径（如
/health），单独挂载在根路由下，不要放进受保护 group - 若要跳过
OPTIONS请求，可在中间件内加判断：if c.Method() == "OPTIONS" { c.Next(); return }
BasicAuth和JWT混用时要注意什么
BasicAuth 是无状态的每次请求校验，JWT 是有状态的 token 签发与校验。两者混合常见于「用 BasicAuth 换取 JWT」的登录接口，但容易出错的是：同一个中间件链里同时用了 BasicAuth 和 jwt.New()，结果 BasicAuth 把 Authorization: Bearer xxx 当成 Basic 凭据去解码，直接 panic 或返回 401。
关键点在于请求头格式冲突：Authorization: Basic xxx 和 Authorization: Bearer xxx 不能共存于同一中间件逻辑中。
- 登录接口单独用
BasicAuth，成功后签发 JWT 并返回给前端 - 其他接口统一用
jwt.New()中间件，且确保它只检查Bearer前缀 - 切勿在一个中间件里试图兼容两种 scheme；Fiber 的中间件是顺序执行的，按需组合即可
- 调试时用
c.Get("Authorization")打印原始头，确认前端发的是哪种格式
BasicAuth 很轻量，但正因为它不封装响应逻辑和路由过滤，所以每个使用点都得自己补全边界处理——漏掉一个 c.Status(401) 或一个 c.Next()，认证就形同虚设。
