alice优于net/http原生嵌套，因其将h:=m3(m2(m1(h)))的深层嵌套转为扁平声明式链，提升中间件顺序控制、复用性与测试性，尤其适用于微服务中认证/日志/限流逻辑的统一管理。
为什么不用 net/http 原生中间件而选 Alice
Go 标准库的 http.Handler 链式组合靠手动嵌套，比如 h := middleware3(middleware2(middleware1(handler)))，可读性差、错误处理分散、调试困难。Alice 把这种嵌套变成扁平声明式写法，核心价值不是“多一个库”，而是让中间件顺序、复用、测试变得可控——尤其在微服务里多个服务共用同一套认证/日志/限流逻辑时，它能避免每个 main.go 里重复写五层嵌套。
Alice.Constructor 和 Alice.Then 的实际差异
两者都返回 http.Handler，但语义和适用场景不同：
- Alice.Constructor 接收一个函数，该函数必须返回 http.Handler（即支持初始化逻辑，比如从配置加载 JWT 密钥）；
- Alice.Then 直接接收 http.Handler 或 func(http.ResponseWriter, *http.Request)，适合无状态中间件（如日志、CORS）。
常见错误是把需要初始化的中间件（比如带 Redis 客户端的 rate limiter）塞进 Then，导致每次请求都新建实例或 panic。
- 正确：用
Alice.Constructor(func() http.Handler { return NewRateLimiter(redisClient) }) - 错误：用
Alice.Then(NewRateLimiter(redisClient))—— 实例被提前创建，且无法传参
和 Gin / Echo 等框架混用时的典型陷阱
Alice 是标准 http.Handler 兼容器，不能直接套 Gin 的 gin.Engine。常见误操作是：router := gin.Default() → alice.New(...).Then(router) —— 这会失败，因为 gin.Engine 不是 http.Handler，它实现了 http.Handler 接口但需调用 router.ServeHTTP 才生效。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确做法：用
alice.New(...).Then(http.HandlerFunc(router.ServeHTTP)) - 更推荐：微服务中统一用标准
http.ServeMux+ Alice，避免框架耦合；若已用 Gin，直接在router.Use()里注册中间件，不引入 Alice - 注意：Alice 中间件里的
panic不会被 Gin 的 Recovery 中间件捕获，得自己加 recover
调试中间件执行顺序的最快方法
中间件没生效？顺序错？最简单办法是在每个中间件开头加一行日志：log.Printf("[middleware] %s: %s", "auth", r.URL.Path)
然后启动服务，curl 一次，看日志输出顺序是否符合 Alice 链中声明的顺序（从左到右执行进入，从右到左执行退出）。
- 别依赖 IDE 调试：Go 中间件闭包嵌套深，断点容易跳过关键路径
- 别只测成功路径：加个 401 请求，确认 auth 中间件是否真拦截了，而不是静默放行
- 注意：如果某个中间件用了
return却没写w.WriteHeader()，后续中间件不会执行，但 HTTP 状态码默认是 0，curl 看不到响应体也不报错
微服务里中间件链越长，单点失效越隐蔽。Alice 本身不解决业务逻辑错误，它只保证链的结构可靠——真正要盯住的，是每个中间件对 ResponseWriter 和 Request 的修改是否可逆、是否污染上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
