牛客面经精选

Appearance

面经精选 2026-10-18 ​

收录概览 ​

本期检索 AI/Agent、Golang 后端、服务端/后台开发方向，优先收录 2026-10-17 至 2026-10-18 发布且能获取正文的公开面经；排除正文为空、纯 HR 面和近 7 日已收录的重复内容。共收录 5 篇，重点覆盖 Agent Loop、动态 UI、MCP/Skill、DDS 与可靠性、Go 内存模型、并发安全、MySQL MVCC、线程池、缓存一致性、幂等和服务端内存治理。以下为公开技术问题的结构化改写，不代表整理者亲历。

  • 字节 AI Agent 开发岗：Agent Loop、MCP/Skill、动态 UI、流式渲染、前端性能与数据库
  • 58 同城 Agent 开发：数据分析 Agent、MCP、工作流、Text-to-SQL 与 JVM 内存问题
  • 得物 Golang 开发：DDS、Gin 路由、内存逃逸、goroutine 与 Map 并发安全
  • 多益网络软件工程师：MVCC、线程池、缓存一致性、AOP、Redis 热 Key/大 Key、幂等、Kafka
  • 搜狐畅游服务器开发：RSS 排查、对象池、分配器、多线程内存与伪共享

来源索引 ​

说明：只保留公开技术问题和可迁移的工程考点，不复制个人隐私或原帖长段落。回答中的工程展开是通用复习思路；没有可靠指标时不虚构数字。

一、Agent 与 AI 应用开发 ​

Q1：Agent Loop 如何避免死循环？ReAct、Workflow、Replan 怎么选？ ​

回答思路： 先说明 Loop 的基本状态：读取用户目标和当前 state，选择计划或下一步动作，调用工具，校验结果，再更新 state；终止条件包括任务完成、最大步数、Deadline、Token/费用预算、错误上限和人工接管。ReAct 适合边观察边决策的不确定任务；Workflow 适合审批、发布等边界清晰且需审计的流程；Replan 适合执行中发现前置条件变化、需要重新规划的长任务。实际工程常用固定主流程加有限自主节点。

易踩坑 / 追问： 只设置最大步数不够，还要做重复工具参数指纹、状态是否有进展、相同错误熔断和副作用幂等。回答时区分 state、context、memory，以及 checkpoint 恢复和跨会话记忆，不要把“多轮调用模型”直接等同于 Agent。

Q2：MCP、Skill、Function Calling 分别解决什么问题？工具很多时怎么办？ ​

回答思路： Function Calling 是模型和应用约定结构化参数的调用机制；MCP 是连接外部工具、资源和提示能力的协议层；Skill 更偏向可复用的任务方法、流程和约束。每个工具应声明用途、输入输出 Schema、权限、前置条件、副作用、超时、重试语义和错误码。工具数量大时，先按领域、租户权限和风险做候选召回，再进行 Schema 校验，避免把 100 个工具完整描述全部塞进上下文。

易踩坑 / 追问： MCP 并不自动保证安全；服务端仍需重新鉴权、审计、限流和幂等。参数错误、权限错误、限流、暂时性网络错误和业务失败要分开处理，只有明确幂等的暂时性错误才适合自动重试。

Q3：动态 UI 或 A2UI 的 JSON 如何保证可渲染、可交互？ ​

回答思路： 模型输出不能直接当 HTML 或任意代码执行，而应经过版本化 Schema、字段白名单、类型校验和默认值补全，生成受控组件树。组件动作只携带 action ID 和参数，前端通过注册表映射到后端接口；涉及写入的操作由服务端重新鉴权、校验状态和执行幂等。流式输出要支持增量 JSON 的缓冲、序号、断线恢复和最终快照，不能假定一次网络分片就是完整对象。

易踩坑 / 追问： 需说明失败降级：Schema 不合法时展示文本或错误卡片；动作版本不兼容时拒绝执行；用户编辑后的状态要回传后端持久化，而不是只改前端。还要关注 XSS、越权、重复点击和慢客户端背压。

二、Golang 与运行时 ​

Q4：Go 的内存逃逸、Map 并发安全和 goroutine 线程安全怎么答？ ​

回答思路： 内存逃逸是编译器判断变量生命周期可能超过当前栈帧或需要被堆上对象引用时，将其分配到堆上的优化结果，常见触发包括返回局部变量指针、闭包捕获变量、接口装箱等，最终应以 go build -gcflags=-m 观察而不是背固定规则。普通 Map 不能并发读写；多 goroutine 共享写入需用互斥锁、读写锁、单 goroutine 所有权模型或合适的并发容器，计数器还要考虑原子操作。

易踩坑 / 追问： “goroutine 轻量”不代表可以无限创建；要有生命周期、取消、超时和 WaitGroup 管理。发现竞态应使用 go test -race，并解释锁保护的是哪段共享状态，而不是笼统说“加锁就安全”。

Q5：DDS 和 Redis 有什么区别？Gin 的接口路由怎么工作？ ​

回答思路： DDS 属于面向数据的实时数据分发中间件，围绕 Topic、发布订阅、QoS、发现和数据一致性设计，适合对实时性、可靠性和数据分发有要求的系统；Redis 是内存数据存储，常用于缓存、集合、队列、计数和分布式协调。比较时要从通信模型、持久化、数据所有权、延迟、可靠性和使用边界说，而不是只说“一个快一个慢”。Gin 通常在启动时把路由注册到树结构，收到请求后按 method/path 匹配参数、执行中间件链和 handler，再统一处理错误与响应。

易踩坑 / 追问： 不要把项目实际使用的语言、上线状态和指标说成未经证实的事实；DDS 的可靠性还要落到 QoS、丢包、重传和时延取舍，Redis 则要说明过期、淘汰和故障后的影响。

三、服务端、数据库与性能 ​

Q6：MySQL MVCC 为什么让快照读通常不阻塞写？ ​

回答思路： InnoDB 通过隐藏事务字段、undo log 版本链和 Read View 实现 MVCC。普通 SELECT 是快照读，按照隔离级别和 Read View 判断版本可见性，不可见就沿 undo log 找历史版本，因此通常不需要给目标记录加共享锁。SELECT ... FOR UPDATE、UPDATE、DELETE 属于当前读，要读取最新有效版本并加锁，可能等待或死锁。回答 RC/RR 时补充：RC 通常每条语句生成新的 Read View，RR 通常复用事务中的快照。

易踩坑 / 追问： 不要说“MVCC 没有锁”；当前读仍然有记录锁、间隙锁和 Next-Key Lock。幻读还要区分快照读与当前读，并结合索引范围说明锁的作用。

Q7：线程池大小怎么定？缓存一致性和幂等如何设计？ ​

回答思路： CPU 密集任务的线程数通常接近可用 CPU 核数；I/O 密集任务可结合等待时间、CPU、队列长度和下游容量调大，常用近似模型是 CPU核数 × (1 + 等待时间/计算时间)，但最终要用 activeCount、队列、拒绝数、P99、数据库连接池和下游 QPS 验证。Cache Aside 通常是读 Redis 未命中查库回填，写请求先改库再删缓存，并用重试、消息或 binlog 补偿删除失败。幂等需用稳定 requestId、数据库唯一约束或幂等状态机兜底，Redis SET NX EX 只能做快速拦截。

易踩坑 / 追问： 线程数不能脱离数据库连接池谈；盲目扩消费者或线程可能把下游压垮。缓存“先改库再删”也不是强一致，需明确旧读回填、删除失败和最终校正窗口。

Q8：RSS 持续上涨但业务对象稳定，怎么排查？Redis 热 Key/大 Key 怎么治理？ ​

回答思路： 先区分真实泄漏、分配器缓存和内存碎片：用 heap profiler、ASan/LSan 或 jemalloc profiling 看存活对象和 allocation stack；若对象稳定但 RSS 高，可能是 arena、tcache 或碎片没有及时归还内核。Redis 热 Key 可能让单节点 CPU、带宽或单线程命令处理成为瓶颈，可用本地缓存或 key 分片；大 Hash/Set/ZSet 要用 MEMORY USAGE、SCAN 和 bigkeys 做抽样分析，拆分结构，删除时优先 UNLINK，不要线上 KEYS *。

易踩坑 / 追问： RSS 不是业务对象大小，不能看到上涨就直接下结论。对象池也不一定比 malloc 快，线程本地缓存可能换来更高内存；高并发更新不同字段还要警惕 64 字节 Cache Line 导致的伪共享，可用 padding/alignment 验证和治理。

本期高频考点与复习建议 ​

  • Agent：Loop 终止、ReAct/Workflow/Replan、MCP/Skill、动态 UI Schema、流式增量与安全边界。
  • Golang：逃逸分析、Map 并发、goroutine 生命周期、DDS 与服务路由。
  • 服务端：线程池容量、缓存一致性、幂等、RSS 排查、热 Key/大 Key、伪共享。
  • 数据库：MVCC、Read View、当前读与间隙锁。

准备面试时，建议画两张图：一张是“用户输入—Agent state—模型—工具—Schema 校验—结果验证”，另一张是“请求—线程池—缓存—数据库—消息补偿”。所有项目数据都说明口径、基线、改动和验证方式；没有真实数据就明确评测计划。