# 1. SSE 的 event、data、id、retry 和空行边界如何解析，网络分块为何不等于事件边界 A 解析器应累积缓冲并按空行切分事件，网络分块不等于事件边界 ✓ 正确答案 B 一个网络 chunk 就对应一个 SSE 事件 C 一个 SSE 事件永远不会被拆成多个 chunk D event 字段是可选且无效的
# 2. 如何把 Provider 的文本、完成、usage、工具调用和错误增量转换为稳定的业务事件协议 A 直接把各 Provider 原始事件透传给前端 B 每个 Provider 用一套协议即可，无需统一 C 把文本、完成、usage、工具调用与错误归一化为统一业务事件协议，并保留可观测 ID ✓ 正确答案 D 工具调用无需归一化
# 3. HTTP/2 与 HTTP/3 下的流式响应与 HTTP/1.1 chunked 编码差异如何在客户端正确处理，避免流被截断或合并 A 各版本都用连接关闭判断流结束即可 B 网络 frame 边界即应用事件边界 C HTTP/2 仍使用 chunked 编码 D 应依据协议层结束标志（chunk 终止/END_STREAM/流结束）判断完成，并按应用层边界重组事件 ✓ 正确答案
# 4. Provider 流事件（OpenAI delta、Anthropic message_start/delta/stop、Gemini chunk）如何归一化到内部统一事件协议，并保留可观测 ID A 只需归一化文本，工具调用无需处理 B 各 Provider 事件结构相同，无需转换 C 归一化会丢失所有追踪信息 D 把文本/工具/完成/usage 增量归一化为统一事件，并保留 Provider 请求 ID 等可观测信息 ✓ 正确答案
# 5. 代理缓冲、空闲超时和连接保活会怎样破坏 SSE，心跳与反向代理应如何配置 A 代理缓冲不会影响 SSE，可保持默认 B 心跳频率越快越好 C 空闲超时对 SSE 无害 D 应关闭代理缓冲、调大超时，并用注释行心跳保活，防止空闲超时与延迟 ✓ 正确答案
# 6. 如何治理背压、慢消费者、并发连接、超时和资源释放，避免连接或线程耗尽 A 用有界缓冲与背压、并发连接限流、超时兜底与确定性资源释放，避免连接与线程耗尽 ✓ 正确答案 B 连接数无需限制 C 缓冲无限增长即可，避免背压 D 超时会导致服务不稳定，应避免
# 7. 如何处理流中穿插的非文本事件（tool_call、reasoning、citation、usage） A 把非文本事件直接拼进正文文本 B 用统一协议按类型分通道处理（tool_call 聚合、citation 待校验、usage 计统计），不混入正文 ✓ 正确答案 C citation 应立即显示，无需校验 D 只需要处理文本事件
# 8. 流式错误恢复（[DONE] 缺失、连接提前关闭、Provider 5xx）应如何被服务端捕获、记录并通知客户端 A 流连接关闭就视为正常完成 B 服务端检测不完整结束并分类记录，通过 error/finish 事件通知客户端，客户端决定重试或降级 ✓ 正确答案 C Provider 5xx 无需处理 D [DONE] 缺失可忽略
# 9. SSE、WebSocket、WebTransport 与非流式响应应如何按单向性、双向性和部署环境选型 A 所有实时场景都用 WebSocket B WebTransport 在所有浏览器都完整支持 C SSE 是双向的 D 单向下推用 SSE，双向实时用 WebSocket，低延迟场景可考虑 WebTransport，并按部署环境权衡 ✓ 正确答案
# 10. Serverless 或 Edge 环境存在执行时长和连接限制时，流式接口如何降级或续传 A 长流式可直接跑在受限函数里 B 把长流式转为异步任务 + 轮询/订阅，或分片续传，客户端用任务 ID 平滑衔接 ✓ 正确答案 C 函数时长限制不影响流式 D Edge 上必须保持长连接
# 11. text/event-stream 的 BOM、字符编码、压缩（gzip/brotli）对事件边界的影响如何测试 A 这些因素不影响事件边界，无需测试 B BOM 应被当作事件内容保留 C 压缩后无需解压即可解析事件 D 应构造含 BOM、跨块 UTF-8 字符、分块压缩的用例，验证解析器在字节重组后仍正确切分事件 ✓ 正确答案
# 12. 多 SSE 连接同时推送时，浏览器同源 6 连接限制和代理 keep-alive 限制如何绕过 A 浏览器同源连接数无限制 B 用 HTTP/2 多路复用、WebSocket 或服务端合并订阅按会话 ID 分发，绕开浏览器与代理连接数限制 ✓ 正确答案 C 代理 keep-alive 限制不影响 SSE D 每个会话都必须独立一个 SSE 连接
# 13. 如何区分“流已结束”和“流暂时没新数据”，避免误判超时关闭 A 用结束标志判断完成、心跳判断存活，并区分空闲超时与整体超时 ✓ 正确答案 B 一段时间无数据即可判定流结束 C 心跳是多余的，浪费带宽 D 无数据即应关闭连接
# 14. 为什么不应在 SSE 事件中夹杂大体积二进制（如 base64 图片） A 把 base64 图片直接塞进 SSE 事件是推荐的 B base64 膨胀不影响性能 C 大 payload 不会阻塞事件流 D SSE 事件应只带引用与元数据，二进制走独立通道，避免阻塞流与膨胀 ✓ 正确答案
# 15. EventSource 与 Fetch 流在请求方法、请求头、取消、错误处理和认证方面有何差异 A 两者在请求方法与头部支持上完全一致 B Fetch 流支持自动重连且无需处理 C EventSource 仅 GET 且不能自定义头，Fetch 流支持任意方法、自定义头与 AbortController 精细取消 ✓ 正确答案 D EventSource 可以用 Authorization 自定义头
# 16. UTF-8 字符与 SSE 事件都可能跨数据块，前端应怎样分层解码、分帧和拼接 A 每收到一个 chunk 就按 UTF-8 解码并当作完整事件 B 分层处理：字节缓冲 + 流式 TextDecoder 解码跨块字符，再按空行分帧并缓冲跨块事件 ✓ 正确答案 C UTF-8 字符不会跨数据块 D 一个 chunk 就代表一个完整事件
# 17. 增量 Markdown 尚未闭合代码块、表格或链接时，如何避免 DOM 抖动和不安全 HTML A 直接渲染未闭合 Markdown，并在完成后重建 DOM B 链接 URL 无需校验 C 流式渲染无需净化，Markdown 是安全的 D 用流式解析器维护未闭合状态，缓冲易移位结构，并对所有输出做净化防 XSS ✓ 正确答案
# 18. 打字机渲染（typewriter effect）的人为延迟与实际流延迟叠加后，用户感知 TTFT 如何更准确 A TTFT 应包含打字机渲染的人为延迟 B TTFT 与渲染无关，无需关注 C 应在收到首个 token 时记录网络 TTFT，与渲染延迟分开度量，避免打字机失真 ✓ 正确答案 D 打字机字速不影响用户感知
# 19. 大回答（>10k token）的虚拟滚动、虚拟 DOM 与分块渲染策略如何避免内存爆炸 A 用虚拟滚动限制可视节点、分块渲染与懒加载，避免全量 DOM 导致内存爆炸 ✓ 正确答案 B 虚拟滚动会增加内存占用 C 大内容无需优化，浏览器能处理 D 一次性渲染全部 token 到 DOM
# 20. 如何用 requestAnimationFrame 或时间片节流打字机渲染，同时度量首 Token 延迟和可见完成时间 A 每收到一个 token 就立即更新一次 DOM B 用 rAF/时间片节流渲染，并在收到首 token 时记录 TTFT、全结束时记录可见完成时间，二者分离度量 ✓ 正确答案 C TTFT 应等渲染完成后再记录 D 渲染节流会破坏 TTFT 度量
# 21. 停止、重试、编辑后重发、分支对话和晚到事件应如何通过会话 ID、消息 ID 隔离 A 所有事件都接受，无需区分 run B 重试后旧 run 的晚到事件也应生效 C 用 session_id 作用域、message_id/run_id 标识生成、序号定序，只接受当前 run 的合法事件 ✓ 正确答案 D 分支对话无需隔离
# 22. 断线重连时如何用事件 ID 去重和恢复；服务端不支持游标时应怎样向用户降级 A 断线后无法恢复，只能全部重来 B 支持游标时用 Last-Event-ID 续传去重，不支持时降级为保留已展示内容并重新生成，避免重复副作用 ✓ 正确答案 C 事件 ID 只用于显示顺序 D 重连后重复执行副作用工具是安全的
# 23. AbortController 取消后，服务端继续推送的“晚到事件”如何在前端安全丢弃并避免计费 A 取消后晚到事件应继续渲染 B 前端用 run_id/取消状态丢弃晚到事件，并把取消信号回传服务端停止生成、按实际消耗计费 ✓ 正确答案 C 计费按前端收到多少 token 计算 D 取消后服务端继续生成也无需停止
# 24. React Server Components、Next.js Streaming 与前端 SSE 客户端在 AI 流场景下如何结合使用 A SSE 客户端可用于服务端页面渲染 B 三者适合同一用途，任选其一即可 C Next.js Streaming 与 RSC 处理页面级流式渲染，SSE 客户端处理对话级实时流，分层并用并明确状态边界 ✓ 正确答案 D RSC 与 SSE 必然是冲突的
# 25. Markdown 中的数学公式（KaTeX/MathJax）在流式增量渲染时如何处理未闭合的分隔符与跨块公式，避免抖动与错位？ A 每个字符都立即触发 KaTeX 渲染 B KaTeX 无需处理跨块公式 C 未闭合公式直接渲染即可 D 缓冲未闭合公式到完整，在干净边界一次性渲染并缓存，避免逐块抖动与错位 ✓ 正确答案
# 26. aria-live、焦点管理与 prefers-reduced-motion 如何让流式聊天对辅助技术可用 A aria-live 应逐字播报每个 token B 焦点管理会破坏流式体验 C 用 aria-live 聚合播报、保持输入焦点、尊重 prefers-reduced-motion 关闭动画，兼顾各类用户 ✓ 正确答案 D prefers-reduced-motion 无需处理
# 27. 流式内容中混入可执行 HTML（图片 onerror、SVG script）时，前端应如何净化渲染并防止 XSS？ A 模型输出是可信的，无需净化 B 用 innerHTML 直接拼接即可 C 在插入 DOM 前对每个渲染片段用净化库过滤可执行元素与危险协议，前端为主、服务端兜底 ✓ 正确答案 D 只有图片需要净化，SVG 无需
# 28. 流式聊天中输入框、停止按钮、自动滚动、快捷键（Cmd+Enter）的交互状态应如何设计，才能在生成过程中保持输入可用且不丢失焦点？ A 生成中快捷键应失效 B 生成过程中应禁用输入框，避免干扰 C 自动滚动应一直强制到底部 D 生成中保持输入框可用与焦点、提供停止按钮、智能自动滚动、快捷键不冲突，用状态机管理 ✓ 正确答案
# 29. 多标签页同时打开同一会话时，事件流如何在标签间共享与同步，避免重复消费 A 每个标签页各自建立 SSE 连接即可 B 多标签页无需同步 C 用单连接 + BroadcastChannel/Worker 广播分发，并按事件序号幂等去重，避免重复消费 ✓ 正确答案 D 关闭标签页即断开共享流
# 30. EventSource 与 Fetch 流在取消语义上为何不同，如何在 React 中统一封装 A EventSource 用 close、Fetch 用 AbortController，React 中用 hook 统一封装 cancel() 并绑定组件生命周期清理 ✓ 正确答案 B Fetch 流有自动重连 C 两者取消语义完全相同 D 取消无需清理监听器
# 31. 如何统一建模文本 delta、对象 patch、工具参数 delta、工具结果、完成原因和 usage 事件 A 用"类型 + id + seq + 载荷"的统一模型，文本用增量、对象用 patch、工具按 call_id 聚合、完成/用量用统一枚举 ✓ 正确答案 B 工具结果无需建模 C 事件无需顺序号 D 每种事件用完全不同的自定义结构，无需统一
# 32. 模型只返回半个 JSON 或转义字符跨包时，为何不能逐块 JSON.parse，应在何种边界校验 A 半个 JSON 即可作为最终结果 B 每个数据块都应独立 JSON.parse C 转义字符跨包无需处理 D 应在完整边界（finish/结构闭合）做整体解析与 Schema 校验，中间态只做预览不做正式校验 ✓ 正确答案
# 33. 并行工具调用的参数片段交错到达时，如何按 call ID 聚合并维持每个调用的状态机 A 按 call ID 分缓冲聚合，并用状态机保证每个调用参数完整后再执行 ✓ 正确答案 B 按到达顺序把所有片段拼到同一个参数块 C 交错时无法区分调用 D 参数片段无需累积即可执行
# 34. 流式结构化输出在“半 JSON”状态时应如何向 UI 暴露 A 半 JSON 时渲染为最终结果 B 渲染已完成字段、未完成占位，并用 partial/final 状态标记，最终失败时回滚 ✓ 正确答案 C 半 JSON 时应整体隐藏，直到完整 D 状态标记无关紧要
# 35. 多个工具调用并行流式到达时，参数片段可能交叉到达（call_id A 的部分、call_id B 的部分），应如何按 call ID 缓冲重组与校验？ A 所有调用共用一个参数缓冲 B 参数校验可在零散片段上做 C 按 call ID 独立缓冲累积，完整后进行 JSON 解析与 Schema 校验，并用状态机与超时保证隔离 ✓ 正确答案 D 交叉参数无法正确重组
# 36. 工具结果回传到模型再生成回答时，中间空白（思考时间）应如何处理才能让用户感知是“思考”而非“卡死” A 思考空白无法展示 B 工具后静默等待，用户自然知道在思考 C 显示思考指示器、工具进度与超时提示，把中间态可见化，避免用户误判为卡死 ✓ 正确答案 D 工具后无需任何反馈
# 37. 流式 Structured Outputs 如何向客户端暴露“部分可见、最终已校验”两种状态 A 只暴露最终结果，不显示部分 B 用 partial 事件做增量预览、final 事件承载完整已校验结果，final 失败时回滚 partial ✓ 正确答案 C partial 与 final 无区别 D final 事件无需校验
# 38. 工具开始、等待审批、执行中、成功和失败应展示哪些信息，哪些参数和内部错误必须脱敏 A 工具参数与内部错误应完整展示给用户 B 工具状态无需展示，用户只需结果 C 各阶段展示可理解的进度信息，敏感参数与内部错误脱敏，只进审计日志 ✓ 正确答案 D 内部错误堆栈应展示给用户
# 39. 连接中途失败后，如何区分可安全回放的文本事件与不可重复执行的副作用工具 A 所有事件都可重放，包括副作用工具 B 文本事件也会造成重复副作用 C 文本事件幂等可重放，副作用工具需幂等键去重，重放时跳过已执行副作用 ✓ 正确答案 D 副作用工具重复执行是安全的
# 40. 流式事件中的错误（tool_error、rate_limit、timeout）应如何按可重试性分类，前端展示与自动重试策略如何与之对齐？ A 错误无需分类，统一处理 B 所有错误都自动无限重试 C rate_limit 属于不可重试错误 D 可重试错误（限流/超时/瞬时）用退避自动重试，不可重试错误（业务/权限/4xx）直接展示原因并降级 ✓ 正确答案
# 41. 前端在流式过程中如何区分“模型在思考”和“模型已放弃并降级”，提示文案如何随状态变化 A 只要没输出就显示"已放弃" B 用状态机与事件信号（error/finish）区分，文案随思考中/降级状态切换 ✓ 正确答案 C 思考中与已放弃无法区分 D 文案始终固定不变
# 42. 流式结束时如何确认所有工具都已回收，避免悬挂任务或未关闭的数据库连接 A 维护活跃任务/资源清单，流结束时统一清理并超时兜底，确认无悬挂任务与未关闭连接 ✓ 正确答案 B 悬挂任务无需处理 C 流结束即自动回收所有资源 D 数据库连接可一直保持
# 43. SSE 心跳（comment 注释行）应多久发一次，频率过低会被代理关闭，频率过高浪费带宽如何权衡 A 心跳越频繁越好，保证不断 B 有数据时也需额外发心跳 C 心跳间隔设为略小于代理空闲超时，仅在空闲时发送，兼顾防断线与带宽 ✓ 正确答案 D 心跳频率与代理超时无关
# 44. 流式响应中插入的引用（citation）链接如何在最终已校验阶段才显示可信标识 A 流式过程中立即显示可点击的可信链接 B 流式阶段显示占位，最终校验通过后才显示可信标识，失败则降级 ✓ 正确答案 C 引用无需校验即可显示 D 引用应该在流式前就确定
# 45. 为何流式事件协议不应包含大字段（如完整 base64），应改成“引用 + 后续 GET” A 把完整 base64 直接放进事件 B 大字段不影响事件流性能 C 事件只携带小引用，内容通过独立 GET 按需获取，保持流轻量与边界清晰 ✓ 正确答案 D 引用会阻塞事件流
# 46. 流式与工具调用同时存在时，UI 进度条、计时器、可用性指示如何让用户清楚当前阶段 A 用一个全局进度条表示整体进度即可 B 用阶段状态机区分工具/文本阶段，进度条与计时器反映当前阶段，配可用性文案 ✓ 正确答案 C 工具调用无需展示，用户只看最终文本 D 计时器会干扰用户
# 47. 如何把流式事件流转换为统一日志格式（JSONL）以便回放和审计 A 每行一个带 request_id/seq/type/ts 的统一 JSON 事件，按序写入以支持回放与审计，并脱敏 ✓ 正确答案 B 流事件无需审计 C 日志无需序号，无法回放 D 每个事件用任意格式记录即可
# 48. 流式与异步任务切换的边界判断（同步流结束 vs 异步任务 ID 返回）应依据什么信号，切换后前端如何平滑过渡？ A 用 finish/[DONE] 表示流结束、task_id 表示转异步，前端收到 task_id 后平滑迁移并衔接已有内容 ✓ 正确答案 B 流结束与转异步无法区分，靠猜测 C 切换时前端应清空已展示内容 D 转异步后无需保留上下文
# 49. 前端如何安全地做幂等合并并防止字段重复触发副作用 A 用序号/版本去重合并，且只有最终确认状态才触发副作用并配合幂等键 ✓ 正确答案 B 每个字段更新都触发一次副作用 C 幂等合并无需去重 D 重复事件会自然被忽略
# 50. 流式结构化结果与工具事件面临哪些安全风险与攻击面，应通过哪些防护手段（鉴权、签名、限流、内容审计） A 用鉴权、签名、限流、内容审计 + 输出净化 + 敏感操作确认，构成纵深防护 ✓ 正确答案 B 工具事件无需鉴权 C 流式结果可信，无需防护 D 限流与安全无关
# 51. 客户端停止生成时，取消信号怎样传播到 Java 服务、Provider 请求和计费链路 A 取消信号从前端传到 Java 服务再传到 Provider 停止生成，计费按实际已消耗 token ✓ 正确答案 B Provider 无法被取消 C 取消后计费仍按全额 D 前端取消后服务端继续生成即可
# 52. Java SseEmitter 与 Servlet 3.1 异步支持的超时、注册、心跳和异常回调生命周期有何陷阱 A SseEmitter 自动管理超时与资源，无需操心 B 需设置超时、发送心跳保活、及时注册、在回调中清理资源，complete 后不可再 send ✓ 正确答案 C 异常回调无需清理资源 D 超时不会关闭连接
# 53. 流式多模态（图像、音频）如何在文本流中插入并保持时间线对齐（先文本描述、再图像、再继续文本） A 文本与媒体独立发送，不需对齐 B 图像应阻塞在文本流中 C 把文本与媒体都作为带 seq 的统一事件按序下发，前端按 seq 渲染播放保证顺序 ✓ 正确答案 D 媒体事件无需顺序
# 54. 如何把流式事件与 Trace ID、时间戳和序号关联，用于端到端延迟与缺包排查 A 事件无需携带时序信息即可排查 B 缺包无法检测 C 延迟只取决于服务端，无需客户端时间戳 D 每事件带 trace_id、时间戳与 seq，用 ts 对比算延迟、用 seq 检测缺包 ✓ 正确答案
# 55. 流式 Markdown 解析器（Streamdown、micromark、markdown-it 流式模式）如何保持状态增量解析，避免全量重解析导致抖动？ A 每次新 token 都全量重解析整个文本 B 全量重解析没有性能问题 C 流式解析无法维护状态 D 维护解析状态并增量解析，未闭合块暂存，避免全量重解析导致的抖动 ✓ 正确答案
# 56. Vercel AI SDK、Assistant UI 和 Streamdown 应按哪些协议、定制与安全需求选型 A 按协议抽象、定制自由度与安全可控性选型，可组合使用 AI SDK、Streamdown 与 UI 组件 ✓ 正确答案 B 所有场景统一用 Vercel AI SDK 即可 C Streamdown 能提供完整前后端协议 D 安全需求与库选型无关
# 57. 流式 Markdown 解析器（Streamdown）应如何处理未闭合表格避免错位 A 每行到达立即渲染成表格 B 表格无需延迟渲染 C 维护表格进行中状态，缓冲未闭合行，到边界稳定后再一次性渲染，避免列错位 ✓ 正确答案 D 未闭合表格直接渲染为最终表格
