实际问题复盘

前端显示超时失败，预约却已经提交

现象：接入 LangGraph Agent 后，涉及查询和预约的对话容易在前端超时报错。更麻烦的是，前端已经报错，后端却已经把预约写入数据库；用户以为失败了再发一次确认，收到的却是「该时段已预约」，以为被别人抢了，结果和界面提示对不上。

原因：Agent 一次请求可能多次调用模型和工具，比单次对话慢，容易超过前端给 AI 接口设置的超时（第 21 节设为 60 秒）。前端超时不代表后端已经停止执行，也不会自动撤销已经提交的事务。第 18 节的冲突检查会拦住同一资源、同一时段的第二次提交，因此在前一次提交已成功、重试参数不变且对应预约仍占用时段时，顺序重试会被拦截；真正可能重复的是两个请求同时处于「查冲突」和「插入」之间，或者模型第二次换了时段、资源。

解决：把 AI 接口的前端超时调到 90 秒，联调失败时先查库确认是否已经写入，再决定是否重试；第 25 节改为 SSE 流式输出，把「正在思考」「正在查询」等过程实时推给用户，减少用户因为长时间没反应而重复提交。

收获：前端报错不等于后端失败。加大超时只能缓解，长耗时的 AI 请求需要让用户看到进度；有写操作的接口还要让重试拿到原来的结果，例如提交时带上唯一的请求 ID，服务端据此返回已有记录，而不是报冲突。

被追问时：面试官很可能问「你不是有冲突检查吗，为什么还要幂等」。可以讲冲突检查只能拒绝重复、不能返回原结果，而且「先查后插」在并发下有窗口；幂等键和行锁的设计见面试追问中「重复调用、多人抢时段」一题。

对应章节：第 24 节、第 25 节。