Fiber不能当微服务框架用，因其缺乏服务发现、熔断降级、配置热加载和链路追踪等核心能力；电商场景下应仅作边缘网关或HTTP接口层，核心链路须用go-zero或Kratos。
电商场景下直接用 Fiber 搭微服务是危险的——它不提供服务发现、熔断、配置中心，硬套会导致上线即雪崩。真正能落地的方案是：Fiber 仅作为边缘网关或商品/订单 HTTP 接口层，核心链路必须用 go-zero 或 Kratos。
为什么不能把 Fiber 当微服务框架用
Fiber 本质是高性能 Web 框架，不是微服务框架。它不内置以下能力：
- 服务注册与发现（没集成 Consul/Etcd）
- 熔断降级（没 CircuitBreaker 中间件）
- 配置热加载（
config.yaml改了要重启） - 链路追踪透传（
c.Get("X-Trace-ID")得自己写中间件塞，http.Request相关标准库工具全不能用）
电商大促时流量突增 5 倍，若依赖 Fiber 自己拼熔断逻辑，90% 的 case 是 panic 后全量 fallback 失败。实测某订单服务在 QPS 8k 时因未设 SetMaxOpenConns，3 分钟内 MySQL 连接池耗尽，错误日志刷屏 dial tcp: i/o timeout。
fiber.New() 必须替代 fiber.Default() 上线
开发阶段用 fiber.Default() 没问题，但上线前不换会立刻出事：
-
Logger中间件默认打印完整请求头，Authorization: Bearer xxx直接落盘，安全扫描直接标高危 - 每秒几百次日志写入，在 4 核 8G 机器上实测增加
TTFB0.3–0.8ms，QPS 超过 1w 后磁盘 I/O 成瓶颈 -
Recover中间件捕获 panic 后仍返回 200，前端收不到错误码，订单状态卡在“提交中”
正确做法：app := fiber.New(&fiber.Config{StrictRouting: true, DisableStartupMessage: false})，再按需加 api.Use(auth)、app.Use(cors.New())。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
路由分层必须严格：根 → Group → 子路由
电商接口常见混乱写法：app.Use("/order", auth) 或 app.Group("/v1").Get("/order", h)，结果是权限漏执行或 /order/:id 匹配失败。
- 全局中间件（CORS、BodyLimit）必须挂
app.Use()，不带路径参数 - 业务前缀和权限边界必须用
api := app.Group("/api")，再api.Use(auth) - 版本控制别只靠路径前缀：用中间件提取
API-Version头存c.Locals["version"]，handler 内部调 service.v1.OrderCreate()或v2.OrderCreate() -
StrictRouting: true下，/order和/order/是两条路由，别关它；统一重定向中间件比关掉更安全
数据库与 Redis 连接必须显式调优
Fiber 不管连接池，gorm 和 redis 客户端初始化时漏配参数，压测必挂：
-
db, _ := gorm.Open(mysql.Open(dsn), &gorm.Config{})后必须立刻：db.DB().SetMaxIdleConns(10)、db.DB().SetMaxOpenConns(50)、db.DB().SetConnMaxLifetime(1 * time.Hour) - Redis 用
redis.NewClient(&redis.Options{Addr: "rds:6379", Password: "xxx", PoolSize: 20})，Password: ""会认证失败，PoolSize小于并发数会阻塞 - 启动时不做健康检查：
if err := client.Ping(ctx).Err(); err != nil { log.Fatal(err) }，服务可能带着坏连接跑一整天
最易被忽略的是：所有中间件和 handler 都得用 ctx.Context() 传 cancelable context，否则超时订单查询会卡住整个 goroutine，内存缓慢泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
