Go 后端面试里，候选人经常被问 interface、结构体传值还是传指针、goroutine 什么时候退出、context 有什么用。这些题看起来像语法基础，但真正考察的是工程判断：抽象边界是否清楚，对象生命周期是否可控，并发任务是否会泄露。
如果回答只停在“interface 是一组方法”“结构体大就传指针”，会显得很薄。更好的方式，是把语言特性放回服务端开发场景里：接口是为了隔离变化，指针是为了控制复制和修改，context 是为了让请求链路有明确结束点。
interface 要从使用方长出来
Go 的 interface 更适合由使用方定义能力，而不是提前设计一堆抽象层。比如订单服务需要发送通知，它关心的是“能发送”，而不是具体是短信、邮件还是站内信。这样测试时可以替换实现，业务代码也不依赖具体通道。
但 interface 不是越多越好。如果一个接口只有一个实现，且未来没有替换需求，过早抽象会增加阅读成本。面试里可以直接说：我会在调用方需要隔离依赖、方便测试、支持多实现时引入 interface，而不是为了“看起来高级”把所有结构都接口化。
一个常见追问是：接口应该定义在实现方还是调用方？更自然的回答是，看谁需要稳定边界。业务调用方只依赖少量能力，就在调用侧定义小接口；底层库需要对外提供能力集合，再暴露更完整的接口。这样说，比死记“Go 提倡小接口”更像实际写过服务。
指针不是默认答案
结构体传值会复制数据，传指针可以避免复制，也能修改原对象。但不能简单得出“都传指针”的结论。小结构体传值更简单安全；需要修改对象状态、结构体较大、包含锁或不可复制字段时，传指针更合适。
这里还有一个容易被追问的点：指针会带来共享可变状态。多个 goroutine 同时修改同一个对象，就必须考虑锁、通道串行化或不可变设计。指针还可能让对象生命周期变长，甚至发生逃逸。面试不一定要背编译器细节，但要知道指针不是免费优化。
我会用三个问题判断：这次调用是否要修改原对象？复制成本是否值得在意？这个对象会不会被多个 goroutine 同时访问？如果三个答案都指向共享和修改，就传指针并补同步边界；如果只是一个小的值对象，传值往往更清晰。
goroutine 要有归宿
很多 Go 项目问题不是 goroutine 开不起来，而是停不下来。请求取消、超时、客户端断开后，后台任务如果还继续跑，就会浪费资源，甚至继续写入已经无意义的数据。context 的价值就在于把取消信号、超时时间和请求级数据沿调用链传下去。
高质量回答可以说：我会让下游调用、数据库查询、并发子任务都接收 context；一旦请求超时或取消，子任务要尽快退出；如果某些任务必须完成，比如支付后的补偿记录，就不应该直接绑定用户请求的 context，而要转成可靠后台任务。
更像项目经历的回答
如果面试里被问 Go 并发和接口，可以这样说：我不会只从语法解释，而会先说这个抽象解决什么依赖问题；传值还是传指针看是否修改、对象大小和并发风险；goroutine 必须有退出条件，context 负责把取消和超时传递下去。这样回答既有语言基础，也有服务端工程边界。