useState与useRef：画面状态和可变句柄的边界

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

• 讨论函数组件；ref.current更新不触发render，state setter安排后续render。DOM操作与数据模型不能任意混用。
• 以下是API语义与聊天场景分析，没有未运行的React代码片段。

解题路线

1. 显示回复文本、loading/error状态属于state；AbortController、timer ID和待flush缓冲可用ref。需要显示的buffer最终仍要发布到state。
2. state在当前render中是snapshot，setter不会改变这次函数已经读取的值；连续依旧值更新需functional updater。对象/数组更新保持不可变，否则相同引用可能不能产生期望更新。
3. ref作为跨render保持的可变容器适合imperative handle，不应在render期间随意读写影响输出。事件订阅需要cleanup，避免旧连接在组件卸载/会话切换后继续更新。
4. 闭包捕获旧state时要检查依赖和事件身份，不盲目把所有state塞ref。request ID和取消/cleanup解决错误归属，latest ref只是某些事件桥接手段。

手动走一遍

三个setCount(count+1)基于同一render的count，不是三个连续最新值；functional update可以基于排队前值。连接句柄放ref便于取消，但message文本只放ref不会自动在屏幕显示。

规模与取舍

setState成本由组件树和更新次数决定；ref赋值本身常数，但不是提高全部渲染性能的万能替代。列表结构和批量flush更直接影响高频stream。

易错点与追问

容易失分的边界

• 把ref当所有state的更快版本。
• 修改state对象原地不创建新引用。

继续深挖

• stream callbacks如何避免读取旧conversation ID？
• Strict Mode暴露重复副作用时怎样检查初始化与cleanup？