Svelte 5为何不自动将旧语法转为Rune语法？何时不用Rune？

为啥编译器不自动把let foo = 42转成$state(42)？ #

Svelte虽然是编译器，但Runes的核心设计之一就是让响应式状态更显式。旧语法里的普通let默认是响应式的，这在简单组件里没问题，但复杂场景下很容易让开发者搞不清哪些变量是会触发重渲染的状态，哪些只是临时变量。

如果编译器自动转换，会带来几个实际问题：

• 混淆状态与普通变量：比如你在组件里定义了一个临时计算用的let temp = 0，编译器自动把它转成$state，就会无端触发响应式追踪，导致不必要的组件更新，还会让代码意图变得模糊。
• 破坏迁移的可控性：Svelte 5是渐进式升级的，开发者需要逐步把旧代码迁移到Runes语法。自动转换会让开发者失去对哪些变量该变成状态的控制权，反而增加迁移的复杂度。
• 违背Runes的设计初衷：Runes就是要把“隐式响应式”改成“显式声明”，让代码更易读、更易维护。自动转换相当于又回到了旧语法的隐式逻辑，和Runes的设计方向完全相悖。

哪些场景用标准let比$state更好？ #

• 临时计算变量：比如在事件处理函数或渲染逻辑里，用来存储中间计算结果的变量，不需要触发组件更新，用普通let更高效，也不会额外增加响应式追踪的开销。
  例子：

  function handleClick() {
    let total = a + b; // 只是临时计算，不需要响应式
    alert(total);
  }
  

• 非响应式的固定配置：组件内部的常量、固定参数，比如某个弹窗的默认宽度、接口请求的固定参数，这些值不会变化，也不需要响应式，用普通let（或const）更合适。
• 避免不必要的重渲染：如果某个变量只是用来存储一次性数据（比如接口返回后处理的临时结果、用户输入的临时缓存），不需要触发组件更新，用标准let可以避免编译器对它进行响应式追踪，提升性能。
• 与外部非Svelte代码交互：当你调用第三方库的API、处理纯JS逻辑时，这些场景不需要Svelte的响应式能力，用普通let更符合JS的常规写法，也不会引入不必要的响应式绑定。

内容的提问来源于stack exchange，提问作者tobiasBora