直接回答：Svelte 没有运行时框架内核——编译器把 .svelte 文件（模板、响应式声明 $:、store）直接编译成原生 JS：组件实例化函数里精确创建 DOM、状态赋值编译成对应节点的赋值语句、响应式依赖由编译期静态分析确定。产物没有虚拟 DOM、没有 diff、框架代码接近零，bundle 体积与更新性能都逼近手写 vanilla JS。

展开解析：编译产出的样子：let count 的状态变量被追踪，模板里 {count} 编译成 text.data = count 的直接赋值，$: doubled = count * 2 编译进状态变更后的脏检查与重算——脏检查是位标记（bitmask），微任务内批量 flush。优势场景清楚：首屏包体小（无框架运行时，嵌入组件与低配置设备受益明显）、更新路径短（无中间抽象层）。边界同样清楚：组件数量上去后每个组件都内联自己的 DOM 操作代码，总代码量反超共享运行时模式（Svelte 作者自己承认的拐点，约中型应用规模）——Svelte 5 的 runes 模式引入轻量 signals 运行时正是回应；生态与招聘池远小于 React/Vue；编译时分析对动态性强的模式（运行时组装模板）无能为力。方法论意义大于选型结论：Svelte 证明了“框架可以是编译器而非库”，推动了整个行业的编译优化竞赛——Vue 的 Vapor Mode、Angular 的部分编译策略都在此列。面试答法：讲清“抽象成本被移到构建期”这一核心权衡，再谈包体拐点与生态约束，比背 API 差异有说服力。

追问方向：runes 相比 legacy 模式改了什么？SSR 场景 Svelte 的输出形态是什么？

（约 470 字）