这是后端面试中一道体现工程化水平的题，需要展现出从宏观到微观，从现象到本质的工程思维。不要上来就说加缓存、优化SQL这种空话，你都不知道哪里出了问题，你往哪去优化？
应该分两步走，先定位排查，再优化解决。
排查（定位瓶颈）
当接口慢时，时间通常花在三个地方：网络传输、Go应用程序本身（CPU/GC）、下游依赖（DB、RPC）
宏观定位：链路追踪
这是最快的方法，如果系统接入了Jaeger、Zipkin或者SkyWalking：
- 看瀑布图
- Gap很大：比如Span A和Span B之间有很长的空白，说明是Go代码逻辑处理慢（CPU密集或锁等待）
- 大量短Span：比如这一层有100个短的SQL Span，说明发生了N+1问题。
- Span很长：比如一条SQL执行条很长，说明是数据库慢
微观定位：Golang PProf
如果确定是Go 服务内部处理满（非下游原因），可以用pprof
- CPU Profile（go tool pprof profile）
- 查看是不是某个算法时间复杂度太高
- 查看是不是序列化/反序列化消耗大量cpu
- 查看是不是GC占比过高（runtime.mallocgc排名靠前说明分配太多临时对象）
- Trace（go tool trace)
- 查看G的调度延迟。是不是P太少了，G都在排队
- 查看STW的时间是否过长
- Block Profile(go tool pprof block)
- 查看是不是卡在锁竞争上
外部定位：DB与网络
- 数据库：查看慢查询日志，分析SQL执行计划（EXPLAIN）
- 网络：检查Nginx日志的upstream_response_time和request_time，判断是网络传输慢还是后端处理慢
优化
根据定位排查结果，从不同维度进行优化：
数据库/下游依赖优化
- 索引失效：使用EXPLAIN检查SQL，确保走索引
- N+1问题：改为Preload或手动Join查询
- 大字段查询：不要SELECT * ，只查需要的字段
- 并发调用：如果一个接口要查ABC三个下游服务，且它们无依赖，使用errgoup并发调用
Go 代码层面优化
- 减少内存分配
- 使用sync.Pool复用对象（如bytes.Buffer)，减少GC压力
- Slice预分配内存：make\[\]T,0,capacity,避免append时多次扩容
- Json序列化优化
- 标准库encoding/json性能一般，对于高频热点接口，替换为json-iterator或sonic
- 锁粒度控制
- 将大锁拆分成小锁
- 读多写少的场景用RWMutex代替Mutex
- 尽量减小锁的临界区（Lock和Unlock之间只放必须加锁的代码）
架构层面优化
- 缓存
- Redis：将热点数据放入Redis，拦截DB请求
- 本地缓存：使用bigcache或go-cache存储极热数据，消除网络IO
- 异步化：
- 如果接口包含非核心逻辑（如发短信、记录审计日志、更新统计数据），不要在接口里同步等，丢进消息队列或丢进内存Channel异步处理，立刻返回前端成功
- 聚合层裁剪
- 如果是微服务，确保没有为了获取一个字段而调用了一个返回几千行数据的重型接口。
总结
先问数据，再谈优化（Trace------>Pprof------>SQL log）
IO慢：并发查、加索引、加缓存
CPU慢：优化算法、换JSON库、减少GC