go高性能api核心是控资源生命周期、避免隐式阻塞、缩短http链路：禁裸goroutine，用semaphore限流；json编解码复用sync.pool管理encoder/decoder；中间件轻量，db/http调用必传context并设超时。
Go 语言写高性能 API 接口，核心不是堆协程或换框架，而是控制资源生命周期、避免隐式阻塞、让 HTTP 处理链路尽可能短。标准库 net/http 本身已足够快，瓶颈通常出在 handler 内部——比如同步数据库调用、未复用的 JSON 解码器、无节制的 goroutine 启动。
避免在 handler 中直接启动无限制 goroutine
常见错误是看到“异步”就写 go func() { ... }()，结果高并发下瞬间创建成千上万个 goroutine，压垮内存或调度器。
- 用带缓冲的 channel 或 worker pool 控制并发数，例如用
semaphore.NewWeighted(10)（来自golang.org/x/sync/semaphore）限流 - 耗时操作（如发 HTTP 请求、写日志到磁盘）必须设超时，
context.WithTimeout(ctx, 3*time.Second)不可省略 - 不要在 goroutine 里直接写 response：HTTP 连接可能已关闭，
write on closed network connection错误就是这么来的
JSON 编解码要复用 encoder/decoder 实例
每次请求都 new json.NewDecoder(r.Body) 或 json.NewEncoder(w)，会触发频繁内存分配，GC 压力陡增。
- 在 handler 外预创建
sync.Pool管理*json.Decoder和*json.Encoder - 注意
Decoder不能复用时需调用UseNumber()防止 float64 精度丢失（尤其处理 ID 字段） - 如果结构体字段固定且简单，考虑用
encoding/json.Marshal+bytes.Buffer替代 streaming encoder，实测更快
路由和中间件链必须轻量
用 Gin 或 Chi 没问题，但别在每层中间件里做全量日志、完整 body 读取、JWT 全字段校验——这些动作应按需延迟执行。
- 日志中间件只记录 method、path、status、latency，不记录 request body；需要 debug 时再单独加开关
- 认证中间件用
r.Header.Get("Authorization")提取 token 后，仅验证签名和过期时间，用户信息延后懒加载 - 避免在中间件里调用
ioutil.ReadAll(r.Body)，它会吃光整个请求体，后续 handler 再读就是空的
数据库和外部依赖必须走连接池 + 上下文传播
没上下文的 DB 查询等于放弃超时控制；没连接池的 HTTP client 会快速耗尽文件描述符。
-
database/sql的SetMaxOpenConns和SetMaxIdleConns必须显式设置，生产环境建议MaxOpenConns=20起步 - 所有外部调用（DB、Redis、HTTP）都要传入
ctx，并确保上游 context 有 deadline - 用
http.DefaultClient是危险的——它没有超时，也没有连接池配置；应自定义&http.Client{Timeout: 5 * time.Second, Transport: ...}
真正卡住性能的，往往不是语法或框架选型，而是某次忘记关的 rows.Close()、某个没设超时的 http.Get、或一个被反复 new 出来的 map[string]interface{}。高频路径上的每一行代码，都要能回答“它分配内存了吗？它会阻塞吗？它能被取消吗？”
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
