得物 Golang 开发一面：内存逃逸、Map 并发与 Gin 路由

《面试题目》

1. 自我介绍。
2. 实习项目里的 DDS 是什么？它是什么数据结构？和 Redis 有什么区别？
3. Gin 的接口路由是怎么做的？
4. 讲讲你的两个 Agent 项目？召回命中率是一开始就达到 89% 吗？
5. 这些项目都有上线或发布吗？都是 Go 写的吗？
6. 内存逃逸了解吗？什么情况下会分配到堆、什么情况下在栈上？
7. goroutine 的线程不安全问题通常怎么解决？
8. Go Map 的底层原理是什么？可以并发地读写吗？怎么解决线程不安全？
9. 反问。

《参考解析》

内存逃逸：判断的是「变量能不能证明活不过函数返回」。 Go 编译器做逃逸分析，能在编译期确定生命周期、且大小固定的变量放栈上，否则放堆上。常见逃逸场景：函数返回局部变量的指针；变量被赋给 interface{}（装箱）；变量被闭包捕获且闭包逃出函数；编译期大小未知的切片/对象（如 make([]int, n) 里 n 是变量）；发送到 channel 或存入全局变量；在 goroutine 里引用。可以用 go build -gcflags="-m -m" 看编译器的逃逸结论。答题时要补一句代价：堆分配不是「错」，但会增加 GC 压力；优化手段是减少不必要的指针返回、避免小对象装箱、预分配容量、把热点小结构改成值传递。

Go Map 的底层结构与并发问题。 运行时是 hmap：桶数组（buckets）+ 每个桶 8 个 bmap 槽位（tophash 数组、8 个 key、8 个 value，溢出桶指针），负载因子超过 6.5 触发扩容，扩容分等量扩容（清理溢出桶）和翻倍扩容（桶数量 ×2），采用渐进式搬迁（每次读写搬一两个桶）。查找是 hash 低位定桶、tophash 高位快速比对、再比 key。Map 不能并发读写：运行时用 flags 的 hashWriting 位检测，写的时候另一个 goroutine 写会直接 fatal error: concurrent map writes（不是 panic，recover 不住）。解决方案：sync.RWMutex 包一层（读多写少）、sync.Map（读多写少、key 集合相对稳定的场景，内部 read/dirty 双 map 减少锁竞争）、分片锁（把 key 哈希到 N 个 map 降低锁粒度）、或改用 channel 串行化访问。注意 sync.Map 不是万能：频繁新增 key 会退化，泛型场景还要考虑类型断言开销。

Gin 路由：本质是压缩前缀树。 Gin 基于 httprouter 改造，为每种 HTTP 方法维护一棵 radix tree，把公共前缀压缩成节点，支持静态路径、:param 命名参数和 *catchAll 通配。注册时按段拆分插入、冲突会 panic（比如同一位置既有静态段又有参数段）；匹配时逐字符走树，命中参数节点就把值写进 Params。中间件是一条 HandlersChain，c.Next() 控制执行顺序，c.Abort() 截断后续 handler。答题时可以补：路由树是并发只读的，注册阶段完成后不再加锁；参数获取用 c.Param，查询参数用 c.Query，绑定用 ShouldBind。

DDS 这类自研中间件怎么答。 面试官问的不是背书，而是你有没有真的用过。回答结构应该是：先定位它解决的问题（是分布式数据结构服务、配置/注册中心，还是消息/缓存网关），再讲数据模型（支持哪些结构：String/List/Map/Set、是否有 TTL、是否持久化），然后讲一致性模型（单机内存 + 主从复制？强一致还是最终一致？失败重试与幂等怎么做），最后和 Redis 做对比——数据结构是否完整、持久化与主从方案、扩展性、运维成本、以及团队为什么不用 Redis（性能、成本、已有基础设施、特殊语义）。如果确实不熟，就诚实说明自己只用到 API 层，再把话题引到自己负责的部分，别硬编底层实现。

Agent 项目的追问要点。 「召回命中率 89%」这种数字一定会被追问口径：命中率怎么定义（Top-K 命中？人工标注？离线评测集多大）、基线是多少、有没有做消融、线上有没有灰度。上线问题要区分「demo 跑通」「内部试用」「真实用户在用」，并说清部署形态、QPS、失败降级。语言问题则是在确认你是否真的写过 Go——如果项目是 Java/Python，就直说，同时讲清你熟悉的语言里对应的并发模型，别把没写过的说成写过。