Svelte 顶层 await 后 style:color 没生效

组件的顶层 await 已完成，文字也显示出来了，style:color 却没有应用预期颜色。项目如果开启了 Svelte 的 experimental.async，可以先比较样式指令简写与显式表达式。

Svelte 5.57.3 有这条具体编译路径：style:color 与 style:color={color} 没有得到相同的异步等待处理。客户端的相关回归从 5.55.10 出现，服务端简写还有更早的不同路径，不能把回到 5.55.9 当作 SSR 和客户端的统一修复。

保留异步数据，展开指令写法

在原有开启异步编译的组件中，将简写改为明确读取同一个变量。下面的独立片段展示形状，不代表项目应另行打开该实验选项：

<script>
  const color = await Promise.resolve('tomato');
</script>

<p style:color={color}>状态文字</p>

不要为了让样式提前设置，就把实际需要等待的数据改成固定颜色，或把依赖尚未准备好的计算搬到 await 之前。显式表达式的目的，是让编译器走能够识别该读取的路径，原来的数据来源与完成时序仍要保留。

如果没有顶层异步依赖，或者显式写法也没有颜色，应继续检查 CSS 优先级、值是否合法、节点是否被替换，以及实际运行的客户端资源；不能把所有 style 指令失败都判断成这条缺口。

简写的异步依赖没有等价传递

5.57.3 的 style 指令分析对简写有专门分支，会记录某些状态与依赖信息；显式表达式则遍历对应表达式并合并元数据。它们在异步等待所需信息上的处理存在差异，不能仅以语法上通常等价就认定生成代码也相同。

这项处理应只改受影响的指令表达式。不要顺手改成拼接完整 style 字符串，造成原有 CSS 自定义属性、important 或其他指令之间的覆盖关系变化。动态属性值本身也应保持原来的类型和单位约定。

服务端和客户端分别检查

如果应用有 SSR，先查看服务端实际返回的 HTML 是否带有预期样式，再等待客户端 hydration 和异步数据完成，检查元素最终计算样式。只看浏览器最后出现颜色，可能漏掉服务端缺失或 hydration 后短暂覆盖。

随后覆盖异步成功、失败及后续数据变化的原业务入口，确认样式没有停留在初始值，也没有为修复颜色而绕过错误边界。纯客户端应用则保留首次加载和相关异步更新的检查，不必凭空增加 SSR。

需要回退时，只恢复本次局部指令变更与原配置，保留用于比较的构建产物。关闭整个异步编译选项会改变组件可用语法和执行方式，不是这条局部样式问题的等价替代。