本篇面经来自 : https://www.nowcoder.com/feed/main/detail/e28ee3b477754207a97a79516d7e7101?sourceSSR=search

牛客上面最新的 golang 社招没有了，不确定是不是没有岗位面试 还是 工作了之后大家都不爱写面经导致的

随便找一个实习或者是校招的看看

开场基础

1. 自我介绍 ( 我是xxx, 毕业 xxx, 曾经工作于 xxx 负责 xxx, 拥有 xxx 经验 )

2. 当初为什么会选择做这两个核心项目？ (我这边预计一个是公司项目，一个手写的项目，一个AI项目)

   • 对于 AI 项目，AI发展是趋势，而且在公司的时候参加过黑客松，之前开过一个头，后面有空了之后就打算把他完善一下
   • 由于在之前的公司 少了一部分 微服务,高并发相关的业务需求,所以单独写一个项目用于完善该部分的经验

项目1

1. 项目中用到了分片上传、断点续传，具体如何保证最终上传的文件是完整正确的？

2. 如何保证所有分片拼接后绝对正确，不只是简单判断无缺片？

这两个不会，预计后续补充该部分知识点 。不过可以根据题目思路发散一些

1. 保证文件完整正确, 先保证分片存在

2. 如果分片存在 , 可以考虑根据 后端存放的 metaData即 后端存放每次分片发送过来的数据 。 然后每个分片单独比较该分片的数据。

AI 编程能力认知

1. 日常 Go 开发中，是依赖 AI 编程更多，还是自己手写代码更多？

• 基本上使用 AI, AI 占比率 99% 。工作的时候主要使用 codex 和 cursor 这种具有高安全性 并且性能够用的 Agent. 有时候会考虑使用 GLM 进行跑涉及多模块的需求 。

2. 平时使用 AI 编程，用过哪些实用的 Skill/能力？

• 写了一个 skills用于排查对账问题,我们服务客户60%的时间都是要解决客户的对账问题，排查是否缺少数据，是否有数据没有参与对账。通过写了一个 skill 把之前人为排查的顺序告诉 AI 让他来进行排查 。 最终效率提升了 50%

• 将内部接口暴露出来供外部使用，组内封装过过个MCP接口, 通过使用各个环境的 Apikey 进行访问每个环境的数据 。

3. 你用过的这些 AI 编程 Skill，存在哪些不好用、有局限的地方

• 局限的地方 : 对于较为明显的问题，实际上人一眼就能看出来,但是跑AI的话预计要等5-10分钟。 不好用: 因为部分接口还没有封装暴露成为MCP,导致现有 skills需要的数据需要人手动传入

项目1

1. 项目使用 Kafka 做任务调度，重试机制、失败恢复的具体实现方案是什么

这两个也没有接触过,不过可以根据感觉来回答

• 在点赞服务，使用 kafka 进行异步统计。如果在任务调度中 失败了,我们会尝试 3次重试，如果重试也失败之后,会把该数据放到死信队列中, 死信队列的数据单独启动一个定时任务来进行处理这部分数据。 如果多次失败，会有对应的告警和日志，并且可以在监控中观测到，这时候就需要人为到定位，是不是第三方服务不稳定 或者是传入了错误的请求导致的 。
• 当然我们也可以考虑业务折中的方案，我们对于点赞服务，只需要确保用户能够正常的维护是否点赞这个功能，而对于点赞数在业务上允许他可以不稳定更新

2. 重试、退避策略、失败恢复，是否依赖 MySQL 状态表 + 定时扫表 实现调度？具体流程是什么。 如上

项目 2

1. 详细介绍项目中的长会话上下文管理方案。

2. 你项目中做过受限子任务编排，具体展开讲讲实现思路与作用。

这两个完全是知识盲区了

六、场景题

1. 设计异步任务创建接口，如何保证接口幂等，避免重复创建任务？

• 根据业务字段进行重复性校验。例如一个异步任务需要 时间范围,操作对象 . 那么就查看是否已经有 <操作对象,时间范围> 的组合存在,如果存在则不创建

• 使用进程级的限流, 防止前端一秒内多次点击从而频繁发送相同的请求

2. 生产环境接口原本响应几十毫秒，突然耗时飙升至数秒：如何快速排查问题？如何紧急止损？

• 一般这种异常都会有对应的告警 同时会有完整的tracing. 如果没有的话可以考虑 通过监控图观察异常情况的发生时间,然后去对应时间点查询日志 。 并且根据对应接口最近改动进行比较

• 如果接口特别影响使用, 那么可以考虑使用本地缓存 cover一下实际请求 实现降频 . 或者是回退最近改动的代码。如果在可以接受范围内的话，可以考虑定位出来之后再解决

3. 若问题在版本更新后出现，优先从哪些方向排查根因？

• 最近代码的改动，大概率是
• 如果涉及第三方服务，可以排查第三方服务是否稳定

4. 哪些具体代码改动，会直接导致接口耗时从几十毫秒飙升至数秒？

• 数据库层面, 开发环境和线上环境数据不一致，可能新增了某些 大量查询 或者是 更新的操作，但是后端没有做限制和处理
• 缓存层面, 可能引入了某些大型配置文件,但是这些配置文件的 json.unmarshal没有使用缓存进行控制或者说未命中缓存导致频繁 unmarshal
• 网络层面, 代理或者是某些三方接口网络不稳定。 导致等待http请求，并且http timeout设置的很大，导致等待了很长
• 硬件层面, 其他进程的占用飙升导致我们服务只能拥有少部分资源导致速度变慢

5. 项目主要使用 MySQL 吗？有没有实际做过慢查询优化、SQL 调优相关工作？

用的 pgSQL .有过 慢查询优化 的经历

1. 最主要常见的就是，业务需要支持 账户+时间的 查询。但是历史表结构并没有 <account + timestamp>的索引。 主要优化就是在其上面创建索引

2. 其他优化方向也大同小异。 主要是根据业务方向进行调整，使用 ESR 原则进行优化

综合评分：58 / 100

按 2 年 Golang 社招标准看：方向对、有真实业务痕迹，但项目深度、技术闭环和面试表达都偏弱，目前更接近「能聊几句」而不是「能扛住追问」。

分项打分

优点

1. AI 工程有真实产出：对账 Skill、MCP 暴露内部接口、效率提升 50%，比空谈「会用 Cursor」强很多，2 年经验里这是差异化点。
2. 知道业务折中：点赞数允许最终一致，说明有业务取舍意识，不只堆组件。
3. 慢查优化有落点：account + timestamp 索引、提到 ESR，说明碰过真实 PG/MySQL 问题。
4. 耗时飙升题有分层意识：库 / 缓存 / 网络 / 机器都想到了，方向基本正确。

缺点

1. 项目答不上核心题
   分片完整性、长会话、子任务编排直接写「不会 / 盲区」。面试官会默认：项目是挂上去的，不是你做的。

2. 技术答案停在「感觉层」

   • 分片：只说到 metaData 比对，没提分片 hash、整文件 MD5、ETag、合并校验。
   • Kafka：重试/死信方向对，但缺幂等、offset、重试是否可重入、和「定时扫表」方案的对比。
   • 幂等：业务唯一键有思路，但「进程级限流」解决不了分布式重复创建，应用层锁 / Redis SETNX / DB 唯一索引没讲。

3. AI 占比 99% 很危险
   面试官会追：没有 AI 时你怎么 debug？怎么读 pprof？怎么自己写并发？建议改成「生成 + 审查 + 自测」比例，强调你负责设计和验收。

4. 排查题缺「可操作清单」
   耗时飙升应落到：QPS、P99、DB 慢查、连接池、GC、锁等待、下游 RT、最近发布；止损应有限流、降级、回滚、熔断，而不是只说「本地缓存 cover」。

5. 准备姿态偏被动
   多处「这两个不会，后续补充」「根据感觉来回答」——面试现场不能这样说，要说「这块我负责的是 X，完整方案是 Y，边界是 Z」。

建议（按优先级）

1. 先补项目闭环（最高优先级）

每个项目至少能讲清：背景 → 你的职责 → 关键路径 → 数据一致性 → 失败怎么处理 → 指标。

分片上传建议补齐并能口述：

• 上传前：文件 hash / uploadId
• 分片：chunkIndex + chunkHash，落盘后校验
• 续传：查已上传分片列表
• 合并：校验分片齐全 + 按序合并 + 整文件 hash
• 可选：秒传（文件 hash 已存在则跳过）

Kafka / 异步任务建议补齐：

• 至少一种可靠方案：本地消息表 / Outbox，或 Kafka + 幂等消费
• 重试：有限次 + 指数退避 + 死信 + 告警
• 明确：为什么不用「只扫 MySQL 状态表」，或两者如何配合

AI 项目（长会话 / 子任务）若写在简历上：

• 上下文：滑动窗口 / 摘要 / 向量检索，各自取舍
• 子任务：状态机或 DAG，超时、取消、部分失败怎么处理

写了却讲不清，比不写更伤。

2. 场景题改成「标准答题模板」

幂等：客户端 requestId + Redis/DB 去重表 + 业务唯一键；限流只防刷，不是幂等。
耗时飙升：监控定位时段 → 看发布/依赖 → 拆 RT（本机/DB/下游）→ 止损（回滚/限流/降级）→ 再查根因。
版本后出问题：优先 diff 发布内容、配置、SQL、缓存 key、依赖版本。

3. 调整 AI 叙事

建议口径：

AI 提效写样板和排查脚本；核心协议、一致性、并发、线上问题由我设计并验证；Skill 是把可重复排查流程固化，不是替代判断。

准备 1～2 个「没有 AI 也搞定」的案例（慢 SQL、死锁、goroutine 泄漏等）。

4. 把「不会」改成「边界诚实」

可以说：「合并校验是同事做的，我负责分片落盘和续传列表；完整方案我了解是 hash 校验这条链路。」
不要说「根据感觉答」。

5. 针对深信服多补一块

这类公司常挖：网络、并发、资源占用、稳定性。建议再准备：

• goroutine / channel / context 取消
• 连接池、超时、熔断
• pprof 怎么用
• 一次真实线上/准线上问题的复盘（现象→排查→根因→防再发）

结论

如果你愿意，我可以按这份面经，直接帮你改一版「可上场口述」的标准答案（分片上传 + Kafka 重试 + 幂等 + 耗时排查）。