Echo默认不带任何中间件，e.New()返回裸实例，必须显式注册CORS、JWT、RequestID等中间件，且顺序为CORS→RequestID→JWT→业务中间件，否则跨域失败、鉴权失效、日志无trace ID。
echo.New() 之后必须显式注册中间件，否则 CORS、JWT、日志等全失效
很多人跑通 e.GET("/health", healthHandler) 就以为 Echo 跑起来了，结果上线后前端跨域报错、接口没鉴权、日志查不到 trace ID。Echo 默认不带任何中间件，e.New() 返回的是一个“裸”实例。
常见错误现象：OPTIONS /api/v1/orders 返回 404；JWT token 在 c.Get("user") 拿不到；所有请求日志都只有时间戳，没有 request_id。
- 必须手动加
e.Use(middleware.CORS())，且要放在所有路由注册之前 - JWT 鉴权要用
middleware.JWTWithConfig()，别直接用jwt.ParseToken手动校验——它不自动注入 context - 日志中间件推荐
middleware.RequestID()+ 自定义 logger（如zerolog），否则c.Request().Context()里没有 trace ID - 注意中间件顺序：CORS → RequestID → JWT → 自定义业务中间件，顺序错会导致 header 被覆盖或 context 未初始化
分布式场景下 echo.Context 不能存全局状态，比如用 map[string]interface{} 缓存用户权限
在单机服务里把用户权限塞进 c.Set("perms", perms) 看似方便，但一旦接入服务发现（如 Consul）+ 多实例部署，不同节点的缓存不一致、过期策略难统一，极易出现「A 节点刚授予权限，B 节点仍返回 403」。
使用场景：管理员后台批量修改角色权限后，用户在另一个 API 实例上刷新页面，权限未同步。
立即学习“go语言免费学习笔记（深入）”；
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 权限校验必须走中心化存储：PostgreSQL 的
role_permissions表（配行级锁读）或 Redis 的HGETALL user:123:perms -
c.Set()只能用于单次请求生命周期内的临时数据（如解析后的 JWT payload），禁止跨请求复用 - 如果真要缓存，用带 TTL 的 Redis key，例如
SET user:123:perms "[\"order:write\"]" EX 300，并配合更新时的DEL清理 - 别依赖
sync.Map做本地缓存——水平扩容后完全无效
文件上传路由 e.POST("/upload", upload) 必须配 echo.MultipartForm 解析，且超大文件要关 multipart 内存缓冲
电商系统常需上传商品图、资质文件，但默认 c.FormFile() 会把整个文件读进内存，100MB 文件直接 OOM。错误日志里看不到明显报错，只表现为连接超时或 http: request body too large。
参数差异：echo.MaxMultipartMemory 默认是 32MB，远低于电商常见上传需求（资质扫描件常 50–200MB）。
- 启动时必须设置：
e.MaxMultipartMemory = 200 - 上传 handler 里别用
file.Open()后全量读取，改用src, _ := file.Open()+io.Copy(dst, src)流式写入对象存储（如 MinIO） - 对敏感文件（如营业执照），上传前先校验
file.Header.Size和file.Header.Filename后缀，防 .php 伪装 - 别在 handler 里直接
os.Create()写本地磁盘——节点重启就丢，且无法做多副本
订单创建接口不能用 SELECT ... FOR UPDATE 锁整张 orders 表，库存扣减必须分离到独立服务
电商最典型踩坑点：在同一个 db.Transaction 里查库存、扣库存、建订单、发消息。看似原子，实则锁表时间随并发线性增长，TPS 卡在 200 以下。
性能影响：PostgreSQL 中 SELECT stock FROM products WHERE id = $1 FOR UPDATE 在高并发下会排队等待，事务堆积导致连接池耗尽。
- 库存服务必须独立部署，暴露 gRPC 接口如
DeductStock(ctx, &DeductRequest{ProductID: 123, Qty: 1}) - 订单服务调用库存服务成功后，才写
orders表；失败则直接返回，不进 DB - 库存服务内部用 Redis
DECR stock:123做预扣减，再异步落库（避免 DB 成瓶颈） - 绝对不要在 Echo handler 里写
tx.QueryRow("UPDATE products SET stock = stock - 1 WHERE id = $1 AND stock >= $2", id, qty)—— 条件未命中索引时会锁全表
真实复杂度不在框架语法，而在服务边界怎么切、状态一致性靠什么保证、以及故障时哪条链路先倒。Echo 再快，也救不了没拆开的库存和订单耦合。
