# 1. OpenAI/Anthropic 函数调用（tool use） A 两家的工具调用协议完全相同 B 两者协议与事件结构不同（并行 tool_calls vs tool_use 块），前端应抽象统一层做参数累积、校验与结果回传 ✓ 正确答案 C 参数增量不需要校验即可执行 D Anthropic 依赖客户端/代理串行或循环多轮，不支持同轮并行工具调用
# 2. LLM 流中断恢复（Last-Event-ID/本地补包/客户端 history） A 断线后只能整段重新生成 B Last-Event-ID 不需要服务端配合 C 本地补包会覆盖用户已读内容 D 可组合 Last-Event-ID 续传、本地补包（IndexedDB 缓存已收增量）与客户端 history 重建三种方式恢复 ✓ 正确答案
# 3. Opus / 思维链（chain-of-thought）逐步流式渲染的工程价值 A 思考过程应作为最终答案的一部分直接展示 B 将 reasoning 与 answer 在协议层分离并分别渲染，思考过程用折叠面板展示且默认不回传下一轮 ✓ 正确答案 C 思维链渲染没有工程价值 D 思考内容应与用户消息一起发给模型
# 4. AbortController 取消生成、超时、重试、幂等、断线恢复 A 取消与超时是同一回事，无需区分 B abort 后无需清理资源 C 用 signal 统一取消与超时（AbortSignal.timeout），区分 AbortError 与网络错误，以 requestId 保证重试幂等，并配合断线续传 ✓ 正确答案 D 重试时每次都应生成新的 requestId
# 5. IndexedDB 在长对话历史与恢复的工程价值 A IndexedDB 适合存储少量键值对 B 用对象仓库与索引持久化会话与消息，节流批量写入并支持刷新后的幂等恢复，同时需处理版本迁移与配额 ✓ 正确答案 C IndexedDB 的事务是同步的 D 历史消息不需要持久化
# 6. 浏览器原生 Streaming + IndexedDB 持久化恢复 A 流式内容可以在流结束后一次性写入 B IndexedDB 写入失败不影响流式功能 C 应边收边存、节流写入，游标与内容同事务提交保证崩溃一致，恢复时渲染已存内容并续传 ✓ 正确答案 D 崩溃后游标不一致无法恢复
# 7. 配额（rate limit）与 429 / Retry-After 退避策略的工程价值 A 应优先按 Retry-After 等待，辅以指数退避加 jitter、重试封顶，并在 UI 展示配额与降级选项 ✓ 正确答案 B 收到 429 应立即重试 C jitter 只会增加延迟，没有价值 D 429 重试不需要封顶
# 8. 流式响应回放（如何避免重复请求/渲染）的工程边界 A 回放与重试是同一概念 B 用 requestId 做请求层幂等、消息 id 与游标做渲染层幂等追加，避免重复请求与重复渲染 ✓ 正确答案 C 客户端保证不重复消费即可，服务端无需幂等 D 回放时消息可以整体覆盖
# 9. AI 流式响应的超时控制与指数退避重试 A 所有超时都应无限自动重试 B 应区分首包超时与总时长超时，用 AbortSignal 组合控制，指数退避加 jitter 重试且只对可重试错误生效 ✓ 正确答案 C 4xx 错误也应该自动重试 D 超时后已收内容应该丢弃
# 10. 滚动与长内容性能（虚拟列表、分片渲染、IntersectionObserver 节流） A 虚拟列表会渲染全部消息，只是隐藏滚动条 B 分片渲染适合条目数量巨大的列表 C 列表级用虚拟滚动、单条超长内容用分片渲染、昂贵渲染用 IntersectionObserver 懒触发，并配合 content-visibility ✓ 正确答案 D IntersectionObserver 与懒渲染无关
# 11. AI 请求的 AbortController 取消在用户取消与组件卸载的工程实践 A 组件卸载后请求会自动取消 B 取消后不需要保留已生成内容 C 用户取消与组件卸载都应 abort 请求，区分 AbortError 不告警，并在 cleanup 中清理监听器、定时器与流资源 ✓ 正确答案 D 取消请求必须弹错误提示
# 12. AI 请求的超时（Timeout）处理与用户重试提示的现代应用 A 超时后应清空已生成内容 B 重试按钮应等用户自己发现 C 所有超时都应自动无限重试 D 超时后保留已收内容并给出自动/手动重试或"继续生成"入口，阈值按场景配置并上报监控 ✓ 正确答案
# 13. AI 请求的速率限制（Rate Limit）在客户端的工程处理 A 客户端限速没有必要，服务端会处理 B 限速器与 429 响应无关 C 队列任务不支持取消 D 用令牌桶/滑动窗口限速并管理并发队列，展示排队状态，结合服务端剩余额度动态校准 ✓ 正确答案
# 14. AI 请求的乐观更新（Optimistic Update）与失败回滚的工程应用 A 失败时直接清空整个会话 B 乐观更新只用于用户消息上屏 C 乐观更新先渲染预期状态，失败时按消息级快照回滚或标记错误态，保留用户输入并可见提示，重试复用同一槽位 ✓ 正确答案 D 回滚不需要提示用户
# 15. AI 请求的会话恢复（Session Resume）在断线重连的现代实践 A 断线后只能开始新会话 B 多端同步以客户端快照为准 C 恢复时消息可能重复插入 D 持久化会话快照与游标，重连后先渲染本地内容再续传或重建，以服务端 session id 保证一致性与幂等 ✓ 正确答案
# 16. AI 请求的 Cost Limit（用户成本限制）与提示工程边界 A 成本限制只对免费用户生效 B 用户不需要看到用量信息 C 为了省成本可以无限裁剪安全指令 D 按 token 单价分层核算预算，软硬限制结合，并通过缓存、裁剪与降级做成本感知的提示工程 ✓ 正确答案
# 17. AI 请求的 Token Limit（输入输出限制）的客户端校验工程 A 输入超限时应直接报错拒绝请求 B 发送前按模型编码器计数并修剪/拆包，输出超限时标记截断并提供"继续生成"入口 ✓ 正确答案 C max_tokens 只影响输入 D 截断后继续生成必须从头开始
# 18. AI 请求的 SSE 心跳（Heartbeat）检测与超时重连的现代应用 A 心跳用注释行或专用事件周期性发送，客户端超时未收到则重连，可对抗代理空闲回收并预警连接质量 ✓ 正确答案 B 心跳事件应展示在聊天消息中 C 心跳只在断网时发送 D 心跳间隔固定不可调整
# 19. AI 请求的多模型切换（GPT-4、Claude、Gemini） A 多模型切换就是切换 API key B 通过统一抽象层适配各厂商，支持手动选择、任务路由与降级切换，并处理好上下文迁移与成本权衡 ✓ 正确答案 C 流式中途切换模型没有任何影响 D 自动路由不需要用户知情
# 20. AI 请求失败重试与降级到小模型路由的工程实践与价值 A 按错误分类幂等重试，重试耗尽后按阶梯降级（失败/成本/质量触发），关键任务 fail closed 并记录审计 ✓ 正确答案 B 任何失败都应该降级到小模型 C 降级不需要用户知情 D 重试与降级互斥，不能组合使用
# 21. 客户端流式响应超时（AbortSignal.timeout）的工程价值 A 超时后 signal 可以继续复用 B 超时后已收内容必须丢弃 C 超时与取消无法区分 D 用 AbortSignal.timeout 声明式超时，并与用户取消经 AbortSignal.any 组合，按 TimeoutError/AbortError 分类处理重试与提示 ✓ 正确答案
# 22. AI 请求的 Batch API（非流式批量）在异步任务的工程价值 A Batch API 适合实时对话 B Batch API 延迟与流式相同 C Batch API 提交任务异步获取结果，成本低、吞吐高，适合标注/翻译等非实时批量任务，需配套任务进度与失败重跑 ✓ 正确答案 D 批处理任务无法重试
# 23. AI 请求的 Stream 与 Non-Stream 切换的工程取舍 A 所有 AI 请求都应该使用流式 B 流式失败后不能降级为非流式 C 非流式响应首 token 延迟更低 D 交互对话用流式、后台批量用非流式，可按任务类型/网络/设备切换，并设计统一响应抽象兼容两者 ✓ 正确答案
# 24. AI 请求的 Quota 与用户限流的前端提示工程实践 A 配额不足时应强制弹窗打断用户 B 客户端可以自行决定配额数量 C 分层展示配额进度与限制（软/硬），区分限流（频率）与配额（总量），以服务端数据为准并提供升级/等待引导 ✓ 正确答案 D 限流与配额是同一概念
# 25. AI 请求的 Latency（延迟）与用户感知的工程优化 A 只要总时长短，用户感知就一定好 B 延迟优化只能靠升级带宽 C TTFT 不影响用户感知 D 延迟由排队/网络/TTFT/生成组成，应组合感知优化（乐观 UI、骨架屏、流式）与真实优化（缓存、边缘、模型降档），TTFT 优先 ✓ 正确答案
# 26. AI 请求的 Failure Mode（部分响应、损坏响应）的工程处理 A 部分响应无需特殊处理 B 应分类处理部分响应（保留+继续）、损坏响应（校验+重试降级）与错误响应（可见提示），做到可见、可恢复、可诊断 ✓ 正确答案 C 损坏响应应直接展示原始 JSON D 模型拒绝回答时不需要提示用户
