Go 后端面试里，并发几乎绕不开。很多候选人会说 goroutine 很轻量、channel 用来通信、锁用来保护共享变量。但项目面里，面试官通常会追问更具体的问题：并发任务什么时候退出？请求取消后后台任务还跑不跑？并发量太大怎么限制？channel 堵住怎么办？有没有资源泄露？
并发能力不体现在“能开多少协程”，而体现在“能不能让并发行为可控”。
并发场景先讲为什么需要
不要一上来就讲语法。可以先讲业务场景：批量查询多个下游服务、并行处理文件分片、异步写日志、消费消息、处理大量网络连接。不同场景的并发模型不同。查询下游服务强调超时和取消，消息消费强调限流和失败重试，后台任务强调生命周期管理。
面试官听到业务场景后，才会继续判断你的并发设计是否合理。
超时和取消是高频追问
Go 项目里，上下文取消很重要。一次用户请求如果已经超时，后面的下游调用和后台计算不应该无限继续。回答时可以讲：请求入口设置超时时间，下游调用传递上下文，任务收到取消信号后及时退出，避免无意义占用连接和内存。
如果有必须完成的异步任务，也要和请求生命周期拆开。比如订单状态写入不能因为用户断开连接就随便中止，但日志上报、推荐补充信息这类非核心任务可以取消或降级。边界讲清楚，回答才不会机械。
并发安全不要只说加锁
共享数据读写需要保护，但加锁不是唯一答案。可以通过减少共享状态、使用消息传递、把数据限制在单个任务内、使用只读快照来降低锁复杂度。必须加锁时，要注意锁范围、死锁风险和性能影响。
面试里如果被问到数据竞争，可以举例：多个任务同时更新统计 map，可能造成并发写异常或结果不准。解决方式可以是加锁、分片统计后汇总，或者通过 channel 汇聚到单个聚合任务。讲出替代方案，会比只说互斥锁更成熟。
资源泄露要主动提
Go 并发常见问题包括协程泄露、定时器未释放、channel 永远没人读、下游连接不关闭。项目里如果请求量上来，这些问题会逐渐变成内存上涨、连接耗尽、响应变慢。
面试回答可以补充监控：协程数量、内存、连接池使用、任务队列长度、超时次数。并发系统没有监控，很难证明它真的稳定。
一段更像项目经历的回答是：我在批量查询场景里用并发提高速度，但设置了最大并发数，避免打爆下游；每个下游调用都有超时，请求取消后未完成任务会退出；结果通过 channel 汇总，汇总任务负责关闭通道；上线后看平均耗时、超时率、协程数量和下游错误率。这样的表达比单纯背 goroutine 更有工程含量。
Go 并发回答要说退出条件
Go 并发题如果只说 goroutine 很轻，很容易被追问击穿。真实项目里更重要的是 goroutine 什么时候退出、错误怎么传递、并发量怎么限制、共享数据怎么保护。
请求取消后任务怎么办：低分回答是让它跑完，更稳回答是用 context 传递取消信号，风险是后台任务泄露。并发量太大怎么办：低分回答是多开 goroutine，更稳回答是worker 池或信号量限制，风险是打垮下游。
- 多任务错误怎么处理：低分回答是打日志，更稳回答是收集错误并决定是否中断，风险是部分失败不可见。
- 共享 map 怎么写：低分回答是加锁就行，更稳回答是明确读写边界和锁粒度，风险是数据竞争。
面试里可以主动提资源泄露：channel 没关闭、发送方阻塞、goroutine 等不到退出信号，都会让线上服务越来越不稳定。