# 1. TC39 Signals 提案（Stage 1）的 Signal.State/Computed/Effect 设计 A Computed 在被写入 State 变化时立即重新计算 B Signal.State 是可写状态单元，Computed 是惰性求值并缓存的派生值，effect 订阅依赖变化后执行副作用 ✓ 正确答案 C effect 每次依赖变化都会同步执行多次以保证准确 D Computed 可以直接修改 State 的值
# 2. Signals 与虚拟 DOM diff 的边界，何时仍需组件级更新 A Signals 出现后虚拟 DOM 完全失去存在价值 B 虚拟 DOM diff 在值级更新上比 Signals 更高效 C 值级变化由 Signals 细粒度更新，结构级变化（增删、插槽、条件分支）仍需 diff 或结构协调机制 ✓ 正确答案 D Signals 无法更新任何 DOM 内容
# 3. Signals 与 Virtual DOM 的更新机制对比，什么场景下 Signals 收益最大？ A 虚拟 DOM 的更新成本只与实际变化量有关 B Signals 每次更新都需要重新执行整个组件的 render C Signals 收益最大的场景是大组件树中高频局部状态更新与高频值流，其成本与变化量相关而虚拟 DOM 与组件规模相关 ✓ 正确答案 D 虚拟 DOM 在深层属性更新时比 Signals 更高效
# 4. 原生 Signals 与现有框架响应式系统的互操作路径 A 原生 Signals 的目标是取代所有框架的响应式系统 B 可通过包装（框架底层换用原生信号）、桥接（边界处同步）与适配工具实现互操作，关键是保证单向数据流与调度、生命周期对齐 ✓ 正确答案 C 原生 signal 与框架状态之间不需要任何同步机制 D 互操作只能在编译期完成，运行时无法桥接
# 5. 异步 Signal（async computed/loading 态）的提案进展，Suspense 集成与竞态处理 A computed 可以直接返回 promise 而无需状态建模 B 异步请求返回顺序不影响最终结果，无需竞态处理 C 异步派生值建模为 pending/success/error 状态机，可与 Suspense 集成，并用代次校验与取消处理请求竞态 ✓ 正确答案 D 异步 signal 无法表达加载中状态
# 6. Vue 3.5+ 的响应式重构与 Vapor Mode 对 Signals 的借鉴 A Vapor Mode 仍然依赖虚拟 DOM diff 更新视图 B Vue 3.5 的响应式重构放弃了依赖追踪机制 C Vapor Mode 只能在运行时追踪依赖，无法静态分析 D Vue 3.5 优化了响应式性能（版本计数、调度去重），Vapor Mode 通过编译期生成细粒度更新代码实现无虚拟 DOM 渲染，借鉴了 Signals 的细粒度范式 ✓ 正确答案
# 7. 如何定位响应式系统的「过度计算」与「无效依赖」 A 无效依赖是指 computed 依赖太少导致结果不更新 B 过度计算是依赖粒度过粗导致的冗余重算，无效依赖是订阅了不影响结果的节点；应通过调试工具定位并拆分粒度、收敛依赖 ✓ 正确答案 C 响应式系统的依赖集合越大更新越精确 D 过度计算只能通过减少代码量解决，无法定位
# 8. Signal 图的循环依赖检测与防护 A 循环依赖不会影响 computed 的正常求值 B 循环依赖只能靠开发者肉眼发现 C 循环依赖源于 computed 自读、相互依赖或 effect 写回读，框架通过活跃求值链检测并报错防护，设计上要求 computed 保持纯函数 ✓ 正确答案 D effect 写入自己读取的 signal 是推荐做法
# 9. 细粒度响应式与不可变数据（Immer）的协作与冲突 A 不可变状态装入 signal 并配合引用相等判定可裁剪更新，但深代理的字段级追踪与不可变整体替换存在粒度冲突，应分层使用 ✓ 正确答案 B 不可变数据必须搭配深代理才能用于 Signals C Immer 的 produce 与 Signals 完全冲突，无法共存 D 引用比较会让每次更新都触发全量重算
# 10. 在大型表格/画布场景中 Signals 的渲染优化实证 A 高频值更新场景中 Signals 更新成本与变化量成正比，可通过基准对比量化收益，但虚拟滚动与批处理等渲染预算管理仍然必需 ✓ 正确答案 B Signals 的更新成本与总节点数成正比，适合大表格 C 大型表格场景中虚拟 DOM diff 比 Signals 更高效 D Signals 不需要任何渲染预算管理即可支撑大画布
# 11. 原生 Signal 作为底层、框架响应式作为上层的分层架构 A 原生信号层负责组件渲染与 DOM 更新 B 分层架构完全没有性能与心智成本 C 分层后框架不再需要任何自有响应式实现 D 底层提供通用依赖图与调度机制，上层负责渲染语义；价值是统一与互操作，风险是抽象泄漏与调度对齐成本 ✓ 正确答案
# 12. Signal 的只读视图（Signal.readonly）与封装性 A readonly 会复制一份独立的状态副本 B readonly 视图的内部修改不会反映到外部 C readonly 返回同一状态的只读视图，类型层面禁止写入，用于强化单一写入者与模块边界 ✓ 正确答案 D readonly 只影响运行时，不影响类型检查
# 13. Signals 在服务端（SSR）的水合对齐问题 A SSR 中信号只需服务端求值，客户端无需重建 B 水合时 DOM 与信号不一致会自动消失，无需处理 C effect 在服务端执行副作用是推荐做法 D 通过序列化传递服务端状态快照初始化客户端信号、effect 仅在客户端订阅执行、保证双端求值确定性，可解决水合不一致 ✓ 正确答案
# 14. 如何在 React 中通过 polyfill 使用 TC39 原生 Signals A 通过 polyfill 与适配层（如 useSyncExternalStore 桥接）让信号驱动 React 更新，高频场景可绕过 React 渲染直接更新实例，同时需处理并发调度与清理 ✓ 正确答案 B React 组件天然支持信号订阅，无需任何适配 C 信号变化会精确重渲染单个 DOM 节点，无需组件重渲染 D polyfill 只能用于类组件
# 15. Signals 与 Angular/Vue/Solid 类型系统的统一尝试 A 各框架信号类型完全相同，无需统一 B 通过通用信号接口与转换工具层统一信号类型，但框架读写语义差异与工具链分歧使统一只能以兼容层形态落地 ✓ 正确答案 C 统一类型必须删除各框架的个性化 API D 类型统一后各框架 Devtools 无需任何适配
# 16. Signal 与 React 状态、Vue ref、Solid store 的语义对齐与差异 A React 状态是可变的，支持直接修改值 B 四种状态原语的订阅粒度完全相同 C React 是不可变快照 + 重渲染，Vue ref 是深响应式代理，Solid 是细粒度访问器，TC39 Signal 是显式订阅的值容器，四者在读写模型与订阅粒度上各有差异 ✓ 正确答案 D Solid store 的更新是组件级粗粒度
# 17. Signals 的「拉取（lazy）」计算与响应式图（dependency graph）更新 A 状态变化先沿依赖图做脏标记传播，读取时按需重算并缓存，effect 在微任务中批量执行 ✓ 正确答案 B computed 在依赖变化时立即同步重新计算 C 每次读取 computed 都会全量重算其所有依赖 D 拉取式计算不需要缓存机制
# 18. Signal.subtle.Watcher 与 effect 的语义差异及调度时机（微任务批处理 vs 同步触发） A effect 自动收集依赖并在微任务中批量执行副作用，Watcher 是底层受控订阅点，由调用方管理观察与调度，适合框架接入 ✓ 正确答案 B Watcher 自动管理订阅生命周期，适合业务代码直接使用 C effect 每次状态变化同步执行多次 D Watcher 与 effect 的语义完全相同
# 19. Signals 提案中「equals」函数（去重/相等判定）的作用 A equals 决定读取信号时返回哪个值 B 自定义 equals 对复杂对象深比较没有任何开销 C equals 每次读取都会执行，用于缓存结果 D equals 在写入时判定新旧值是否相等，相等则不传播更新，可用于结构相等、容差与引用相等场景以过滤无效刷新 ✓ 正确答案
# 20. Signal.Computed 的缓存失效（dirty/checked）状态机 A computed 依赖变化时立即重算并同步传播 B 状态写入先标 dirty，读取时按 clean/dirty/checking 分流重算或复用缓存，值未变的传播可停止，版本号用于快速判定 ✓ 正确答案 C dirty 状态表示缓存一定失效，必须全量重算 D 状态机只用于防止循环依赖，与缓存无关
# 21. SolidJS 的 createSignal/createStore 无虚拟 DOM 更新原理 A Solid 依赖虚拟 DOM diff 计算最小更新 B Solid 每次更新都会重建整个组件树 C 编译器把模板表达式转译为细粒度更新函数，运行时信号订阅直达对应 DOM 节点更新，createStore 基于路径代理实现不可变式更新 ✓ 正确答案 D createSignal 的 setter 只能同步更新整页
# 22. Preact Signals 如何在 React 生态中实现细粒度更新 A 信号变化仍然触发整组件重渲染与 diff B Preact Signals 只能用于 Preact，无法用于 React C 通过渲染期订阅与提交期精准 DOM 更新绕过组件级重渲染，但依赖 React 内部实现、对版本敏感且有并发边界限制 ✓ 正确答案 D 信号更新与 React 的 startTransition 完全无冲突
# 23. Angular Signals 与 Zone.js 解耦后的变更检测模型 A 信号在模板中被读取时建立依赖，变化时只标记并检测受影响组件，实现 zoneless 的按需变更检测 ✓ 正确答案 B 解耦后仍由 Zone.js 通知全树执行变更检测 C 信号变化时 Angular 仍会扫描全部组件绑定 D zoneless 模式不需要处理任何异步触发
# 24. 为什么 Signals 有望成为跨框架统一的状态原语 A 状态原语需求与渲染模型解耦且各框架已收敛到信号模型，统一带来互操作与工具共享，但框架差异化与标准落地节奏是主要障碍 ✓ 正确答案 B 信号模型只适合 Solid，其他框架无法借鉴 C TC39 提案已完全落地，无需框架自研实现 D 统一后所有框架必须放弃自身渲染优化
# 25. 从 Redux/MobX 迁移到 Signals 心智模型的转变 A Redux 的全局 store 应原样迁移为全局信号以保持一致性 B 迁移需从集中显式数据流转向局部信号组合，注意 computed 不应含副作用、订阅生命周期要随组件清理，并建议渐进式迁移 ✓ 正确答案 C Signals 的派生计算与 Redux selector 完全等价，无任何差异 D 信号的 effect 订阅会自动随组件销毁而清理
# 26. 细粒度响应式对高频更新（实时数据/协作编辑）的收益量化 A 细粒度响应式能优化布局重排与绘制成本 B 高频小值场景细粒度更新成本与变化量相关、与组件规模弱相关，实测吞吐显著高于组件级重渲染，但批量写、结构变化与渲染预算是收益边界 ✓ 正确答案 C 细粒度在任何场景都优于组件级更新，无边界 D 量化只需对比单次更新耗时，无需关注帧率与内存
# 27. 响应式调试工具（如 Solid Devtools）追踪依赖关系 A 工具在运行时包装信号并记录依赖与更新触发链，可排查无效依赖、过度重算、订阅泄漏与渲染根因 ✓ 正确答案 B 调试工具通过静态分析源码即可展示依赖图 C 调试工具只能显示信号值，无法显示依赖关系 D 依赖图可视化仅对框架作者有意义
# 28. 跨框架的 Signal 标准提案（TC39）现状与生态影响？ A 提案已完全落地，所有浏览器原生支持 B 提案处于 Stage 1 并配套 polyfill，落地后框架可对齐标准信号实现互操作，库与工具链围绕统一语义演进，过渡期标准信号与框架自有 API 并存 ✓ 正确答案 C 提案只影响 Solid 一个框架 D 原生支持后信号只能用于非框架代码
