第 17 章测验

对应章节：Web 前端 v04：流式渲染

共 8 题，答对率 ≥ 80% 即通过。请完成全部题目后点击「提交」。

Q1在流式 Agent 前端里，「拿到事件就直接改 DOM」为什么是反模式？因为 DOM 操作在浏览器里被严格限流，事件一多就会被浏览器丢弃因为界面状态会散落在各处 DOM 操作里：无法回放、无法测试、事件乱序或断线重连时无法恢复出一致的界面因为事件对象不能跨浏览器传递，必须转成字符串因为修改 DOM 一定会触发页面重载

Q2本章的 reducer（状态机）是纯函数，它最直接的收益是什么？代码看起来更函数式、更有高级感同一份事件日志重放永远得到同一个视图模型——因此可被自动判题、可离线回放调试纯函数执行速度一定比副作用代码快纯函数可以自动并行执行，天然解决乱序

Q3text_delta 事件到达时，reducer 应该如何累积文本？每次新建一条独立消息，每条消息只装一个 delta 追加到当前 streaming 的 assistant 消息的最后一个文本块；若最后一块是工具块则新建文本块直接覆盖上一帧的文本文本必须先拼成完整句子再显示，单字一律丢弃

Q4tool_call_start 到达时，视图模型发生什么？状态机立即进入 error，因为工具调用意味着失败在 assistant 消息尾部插入一个 status 为 running 的工具块（callId/name/args），UI 借此显示「正在执行工具」的中间态直接删除该消息的全部文本，防止与工具结果混淆工具调用不属于 UI 状态，reducer 直接忽略

Q5tool_result 事件 ok 为 false 时，匹配的工具块应该如何变化？整条对话直接崩溃，用户需要刷新页面匹配的工具块置为 status failed 并记录 error 字符串，UI 显示失败原因，对话继续工具块保持不变，等下一个事件覆盖只更新状态机为 error，不碰消息内容

Q6approval_request 事件到达后，状态机如何变化？进入 waiting_approval 并记录 pendingApproval（requestId/toolName/args/risk），UI 展示审批提示；只有 requestId 匹配的 approval_result 才能放行回 streaming 直接跳过审批，自动批准继续执行进入 done，因为审批意味着回合结束状态不变，只是往消息里塞一段审批文本

Q7流式生成进行中，用户又输入了一句话，前端应该怎么做？直接丢弃新输入，提示用户等上一轮结束把输入入队到 inputQueue；当前回合 done 后自动排空队列，开启下一回合立刻打断旧回合并开启新回合，旧文本全部清空把两句话拼在一起当作一条消息发给模型

Q8用户点了「停止生成」之后，旧流里已经缓冲的 text_delta 还会陆续到达，前端如何处理？状态机进入 interrupted，残留事件被各处理函数的状态守卫丢弃；只有旧流的 done/error 能关闭该回合（并触发排队）继续把这些 delta 拼进下一条消息忽略一切事件直到用户刷新页面把残留 delta 全部当作新回合的文本