得物 Go 岗笔试 10.10 记录：25 道选择加一道 AI coding

《面试题目》

1. 选择题 25 道：Go 基础（map、panic、chan、递归等）以及 Redis、MySQL 基础。
2. AI coding：一道借助 AI 辅助完成的编码题，题面涉及幂等与状态流转。

《参考解析》

Go 基础选择题最爱考的几个坑。map 是这科的头号考点：Go 的原生 map 不是并发安全的，多 goroutine 同时读写会直接抛 fatal error: concurrent map read and map write（不同于 panic，recover 也拦不住），要并发就得加锁或用 sync.Map；map 的迭代顺序是随机的，依赖顺序的代码本身就写错了；取值要用 v, ok := m[k] 区分「零值」和「不存在」；另外 map 只能和 nil 比较，不能互相比较。panic 相关的坑在于 recover 只有在 defer 里调用才有效，而且只能拦住同一 goroutine 的 panic，跨 goroutine 的 panic 会直接终止进程。chan 常考缓冲与非缓冲的语义差别（非缓冲发送必须有人接收才能继续）、关闭已关闭的 channel 会 panic、从已关闭的 channel 读取会立刻返回零值且第二返回值为 false、以及 select 加 default 实现非阻塞收发的写法。递归题多半是在考闭包捕获循环变量（Go 1.22 之前 for 循环变量会被所有闭包共享，是经典错题）、以及 defer 的执行时机与参数求值时机。Redis 与 MySQL 的基础则集中在过期策略与持久化、缓存穿透击穿雪崩、索引与最左前缀、事务隔离级别这几处。

AI coding 环节怎么用 AI 才有效。帖主分享的打法很有参考价值，可以拆成四步。第一步是先裸提交一次测试，用结果反推「现在这份代码已经解决了哪些用例、哪些还没过」——这相当于用测试用例把问题空间切小，比通读需求文档快得多。第二步是把「未通过的问题 + 需求文档」一起交给 AI，并要求它分阶段开发（先搭骨架跑通主流程，再逐个补边界），这样 AI 的每一步产出都能验证，不会一次性改出一大团看不懂的代码。第三步是换新窗口做根因分析：把报错信息和现象单独拿出来问，避免长上下文里混杂的失败尝试干扰判断——帖主这次定位到的是「幂等与状态流转」问题。第四步是让 AI 对照需求文档检查现有实现对这两点的要求，再落到具体文件去改。这套流程的关键是始终让 AI 做「有明确验收标准的局部改动」，而不是「帮我实现这个功能」。

幂等与状态流转为什么这么难。这两件事是分布式与业务代码里最容易出错的地方，也是笔试/面试里区分度很高的考点。幂等的意思是同一请求重复执行多次，对系统状态的影响与执行一次相同。实现手段分几层：入口带幂等键（业务流水号、订单号）并在唯一索引或去重表里做一次「插入成功才继续」的抢占；状态更新用条件更新把前置状态写进 where，例如 update order set status = 'PAID' where id = ? and status = 'CREATED'，影响行数为 0 就说明已经被处理过，直接返回而不是重试；对外部回调则要先校验签名与业务单号，再按状态机决定是否接受。

状态流转的难点在于「合法转移」必须被显式定义：画一张状态机表，明确每个状态的合法后继、哪些转移不可逆、超时后走哪条补偿路径；代码里所有状态变更都要走同一套转移函数，禁止各处 set status 直接写库，否则并发或乱序回调会造出「已发货又回到待支付」这种脏状态。帖主最后没跑通状态流转，多半是转移条件没有全部落到 SQL 的 where 里，或者幂等键在重试路径上被换了值。

如果自己遇到类似题目，可以按这个顺序排查。先确认幂等键是什么、由谁生成、重试时是否会变；再把状态机的所有转移列成表，逐条检查代码里是否都有对应的前置条件校验；接着用并发或重复调用的方式手动复现（同一请求连发两次、把回调顺序倒过来），观察哪一步产生了非法状态；最后补上「非法转移要报错而不是静默改状态」的断言。这三个动作做完，绝大多数状态问题都能定位。至于笔试本身，这类题的得分点不完全在「全部跑通」，能把幂等键设计、条件更新、状态机校验这三件事讲清楚并实现主流程，通常已经能拿到不错的分数。