Go 云原生后端工程师

结构建议：一句话定位（年限+方向+代表性成果）→ 技术栈匹配（Go、gRPC、Kubernetes、消息队列与你们 JD 的重合点）→ 一个量化项目（如「重构支付网关，P99 从 800ms 降到 200ms」）→ 收尾表达对目标业务的理解。避免流水账式罗列经历；每句话都应服务于「我能胜任这个岗位」。可提前研究对方技术博客或开源仓库，把自我介绍落到对方的技术语境里。常见减分项：只讲做了什么不讲结果、超时、与简历信息矛盾。

GMP 指 G（goroutine）、M（内核线程）、P（逻辑处理器，持可运行 G 队列）。P 的数量默认等于 GOMAXPROCS，M 必须绑定 P 才能执行 G；当 G 发生阻塞系统调用时 M 会与 P 解绑，P 转给其他 M 保持并行能力；网络等待的 G 由 netpoller 就绪后重新入队。Work-stealing 让空闲 P 从其他 P 的队列偷任务。泄漏排查：pprof 的 goroutine profile 看 goroutine 数量与创建栈，常见根因是 channel 无接收方、锁未释放、context 未取消导致的阻塞；可用 runtime.NumGoroutine 做监控告警。

分层作答：入口用负载均衡 + 无状态服务水平扩展；发号器可选自增 ID+base62（简单有序但暴露规律）、号段模式（DB 批量取号，本地缓存，性能与实现折中）或雪花 ID（分布式免协调）；映射存储读多写少，用 Redis 缓存热点 + MySQL/分库分表持久化，命中率决定扩容成本；301 与 302 的选择（301 浏览器缓存减压力但丢失统计，302 可埋点）；高阶补充布隆过滤器防穿透、热点长尾分析、监控降级。展示「从简单方案演进到高并发」的思路比直接抛终极方案更加分。

用 STAR 组织：背景（业务规模、痛点、约束）→ 任务（你的职责边界）→ 行动（技术选型的对比与决策理由、关键难题的解法、跨团队协调）→ 结果（量化指标 + 业务影响）。重点放在「为什么这么选」：如为什么选 Kafka 而非 RabbitMQ（吞吐、顺序性、团队熟悉度），为什么当时没上某个更先进的方案（成本、风险）。也要坦诚讲遗憾与改进，展示复盘能力。切忌把团队成果说成个人功劳，面试官会追问细节验证。

先止损再定位：看监控大盘确认影响面（全部接口还是个别、是否与发布相关），必要时回滚或扩容。定位沿调用链下钻：入口 Nginx/网关 → 应用（goroutine 堆积、GC 停顿、慢日志）→ 依赖（DB 慢查询、Redis 大 key、下游 RPC）。常见根因：慢 SQL 打满连接池、缓存集中失效、流量突增打垮下游、FullGC。用 pprof/trace/慢查询日志找证据，不要凭感觉。回答时给出明确顺序与方法论（黄金四指标：延迟、流量、错误、饱和度），并可举例说明一次实际经历。