准备AI全栈工程师面试，可以拿一条“提交问题—后台生成—页面增量显示—保存结果”的链路，练清流式响应、会话归属、断线恢复与取消。能展示文字逐步出现，还不足以说明系统可靠；你需要解释刷新后怎样找回结果、旧请求为什么不会改写新会话，以及用户点停止时哪些工作真正结束了。
下面是8道编辑自拟练习题和一个虚构事件推演，不是企业真题、统一考纲或实际线上事故。适用于参与AI应用前后端联调的候选人；数据库、语言与框架等基础仍按目标JD准备。没有实现的方案应称为设计思路，不能把阅读本文当作完成项目。
1. SSE、WebSocket和普通请求，怎样按交互需要选择？
先问清页面需要接收什么：只等一个最终结果、持续接收文本与进度，还是双方持续交换低延迟消息？再说明认证方式、运行环境、代理限制和维护成本。不要把“AI应用必须用SSE”当成结论，也不要只以组件新旧判断方案。
MDN的SSE说明介绍了服务端向客户端推送事件的单向连接。发送用户输入可以是另一条请求，不意味着SSE本身变成双向通道。若选择原生EventSource，还要核对它的构造方式与现有认证是否匹配；不能默认它具有普通fetch的全部请求选项。
回答时给出项目条件下的选择及代价。例如先提交生成任务，再订阅该任务事件，是一种可讨论的设计，并非所有服务都必须这样拆分。如果系统只需要很短的一次性回答，普通请求也可能更容易维护。
2. 使用fetch读取流时，为什么一次read不等于一条消息？
网络读取交付的是数据块，业务事件有自己的边界。实现时应分别处理增量字节解码、协议事件解析和业务状态更新；不能假定每次read都恰好包含一个完整JSON对象。一个事件可能分多次到达，一次读取也可能带回多个事件。
WHATWG事件流规范规定了UTF-8解码、行与事件字段的解析规则。自行用fetch处理SSE时，需要保留未完成的数据，并在事件完整后再解析其中的业务负载；简单对每个数据块直接JSON.parse，不能覆盖这些边界。原生EventSource与自己编写的流解析器也不能混为一谈。
可以用同一组事件的不同分块方式做练习：拆开一个中文字符、将两条事件放进同一个块、在事件中途结束连接。检查重组后的事件与原始输入是否一致，异常结束时是否保留“未完成”状态。只有亲自运行过，才在面试中说自己验证了这些情况。
3. 页面切换会话后，晚到的旧响应怎样处理？
先定义一次生成属于哪个用户、会话、消息和生成版本。这里的标识名称由项目决定，关键是前后端对含义一致：同一消息的重新生成，不应自动覆盖另一个版本；同一页面切换到新会话后，旧回调也不能仅凭“当前输入框”决定更新位置。
一种设计是让生成结果携带明确的归属标识，前端将其与当前接收目标核对，再更新相应状态。离开页面时取消订阅，同时让状态更新逻辑能够识别已失效的接收目标。仅调用一次取消方法，不足以解释取消前已排队的回调如何处理。
面试时可推演：用户在A会话发起生成，切到B会话后A仍有事件到达。你会继续更新A的后台记录，还是停止任务？这由产品语义决定，但B的消息不应被A改写。说明你实际采用的行为、存储位置和页面提示，不把一种设计说成唯一答案。
4. 连接断了，重连应该恢复任务还是重新生成？
把“传输连接”和“生成任务”分开讨论。连接中断时，服务端任务可能仍在运行，也可能已经失败或完成。恢复页面应先找回原任务及权威状态，再决定订阅后续事件或读取最终结果；不能默认刷新页面就应再启动一次模型生成。
SSE可以携带事件ID，原生EventSource具有重连相关行为，但这不等于服务端已经保存事件或实现了业务续传。需要说明事件保存多久、怎样按游标读取、重复事件如何识别，以及游标过期后怎样取得快照。若用fetch读取流，这些恢复行为还需由应用明确实现。
特别区分“传输层收到的事件ID”和“应用已应用到状态并保存的进度”。只保存较新的游标、却没有保存对应文本，刷新后可能缺一段内容。可讨论通过权威快照加后续事件恢复，或让状态与应用游标一致保存；最终应展示项目实际支持到哪一步。
5. 点“停止生成”，是否证明服务端与上游都停止了？
不能只根据前端不再显示文字下结论。MDN的AbortController文档说明abort可取消相关fetch操作、响应体消费或流；它不是某个服务端生成任务已终止、上游已经停止计费的证明。后端是否感知取消、怎样传递到上游，要看具体实现与服务协议。
准备说明三件事：页面何时停止接收；后台怎样记录停止请求与实际任务状态；上游是否支持取消及如何确认。若无法确认上游结束，就保留未知部分，不向用户保证费用已经归零。取消过程中任务可能先完成，也需要定义最终状态，不能把已完成结果随意覆盖成失败。
练习时分别模拟取消早于首个文本、生成途中取消、完成事件与取消请求先后到达。只在隔离环境或自己有权使用的测试服务中操作，记录实际行为；不要把上述场景当作自己经历过的生产故障。
6. 知道会话ID，是否就可以读取历史、续传或取消任务？
不可以仅凭对象ID作授权判断。OWASP关于对象级授权的说明强调，对接收对象标识并访问对象的接口，需要检查当前用户是否有权执行相应操作。使用随机ID能减少可预测性，但不能代替权限检查。
把检查落实到生成创建、事件订阅、历史读取、快照恢复和取消等入口。前端传来的用户ID不是身份凭据；后端应依据可信身份与实际对象关系处理请求。支持组织或共享会话时，还要说明成员权限与操作类型，不能只检查“这个用户已登录”。
可以用两个测试账号核对：各自只能读取或取消获授权的任务，重连与快照接口也遵守同一规则。不要对不属于自己的系统做权限探测；面试材料使用测试数据，不展示真实令牌、个人聊天或内部日志。
7. 流结束了，页面为什么还不能直接显示“完成”？
连接关闭可能来自正常结束、网络故障、服务端错误或客户端取消。先定义业务完成需要哪些证据，例如服务端已保存最终结果并给出终态；不能仅因读取循环结束，就把半段回答标为成功。部分文本可保留供用户理解，但应明确是未完成内容。
一种接口设计是区分增量内容事件与终态事件，再提供可查询的任务状态。终态事件丢失时，页面回查原任务；任务状态也暂不可取时，展示待确认而非盲目重发。具体事件名与保存策略由项目决定，不是SSE协议替你定义的业务约定。
日志可以用任务和生成标识串联各阶段，记录状态、时间和错误类别。模型首个输出、页面首次显示、最终保存是不同观测点，不能把其中一个耗时换名成整条链路的时延。没有实际测量，不编写并发量、成本节省或性能提升数字。
8. 怎样用一次事件推演，证明自己理解了恢复与隔离？
以下是虚构练习，不是实测结果。假设摘要应用中的A任务已经保存并应用到事件33，刷新后服务端重放34、35、36，网络又重复送达35。随后用户切到B会话，A任务的37才到达。先写预期，再实现或用测试替身验证，不要先补一个“全部通过”的结论。
- 恢复后，34—36应按既定顺序应用一次；重复35不能让同一段文字显示两次。记录去重范围是哪个任务和生成版本。
- 如果33只是收到却没有对应状态落盘，应先用权威快照恢复，不能假设页面已有前33条内容。游标过期或事件缺口也需要明确处理。
- 切到B后，A的37不能进入B的消息。是否继续保存A，按事先定义的后台行为核对。
- 没有取得最终状态时，页面保持未完成或待确认；收到并核对权威终态后，再显示对应状态。
将材料整理为一页事件契约、一份状态图、测试输入与预期、实际结果及未实现项。真正跑过后，再说明本人负责的代码与修改；未运行就只作为设计练习。简历表达可参考AI全栈开发的研发交付证据。若项目还会预约、发消息或写外部业务系统，继续练Agent工具执行与结果核验题，不要把“文字恢复正确”当成外部操作已经成功。
需要整理求职表达时，可使用AI简历姬辅助准备，再逐句核对个人经历。本文由AI简历姬编辑团队整理，技术资料核验于2026年10月30日；题目、应用契约与推演为编辑设计，未实测示例系统，不承诺面试命中、录用或性能结果。
关于编辑团队
