Svelte 5中可写存储对象赋值时的代理问题解析

在Svelte 5的Runes模式下，开发者报告了一个关于可写存储(writable store)赋值行为的特殊现象：当使用$前缀语法对存储对象进行重新赋值时，赋值的对象会被自动转换为Proxy代理对象，这可能引发一些预期之外的行为。

问题现象

在Svelte 5的Runes模式下，当开发者使用如下语法对存储对象进行赋值时：

<script>
	import { writable } from 'svelte/store';
	let obj = writable({ name: 'foo' });
	$obj = { name: 'bar' }; // 这里赋值的对象会被代理
</script>

编译后的JavaScript代码会将赋值的对象{ name: 'bar' }自动转换为Proxy对象：

$.store_set(obj, $.proxy({ name: 'bar' }));

这种自动代理行为在以下情况下不会发生：

1. 当赋值的是基本类型(primitive)而非对象时
2. 当使用存储对象的set方法而非=操作符时
3. 在非Runes模式下

版本行为对比

通过对Svelte 4和Svelte 5不同模式下的测试，我们发现：

版本	模式	赋值方式	是否被代理
Svelte 4	-	store.set(object)	否
Svelte 4	-	$store = object	否
Svelte 5	非Runes	store.set(object)	否
Svelte 5	非Runes	$store = object	否
Svelte 5	Runes	store.set(object)	否
Svelte 5	Runes	$store = object	是

技术分析

在Svelte 5的响应式系统中，Proxy被广泛用于实现细粒度的响应式更新。当在Runes模式下使用$前缀语法直接赋值时，编译器会生成调用$.store_set的代码，并自动将赋值的对象包装为Proxy。

这种设计可能是为了确保存储对象内部的变化也能触发响应式更新。然而，这种不一致的行为可能会带来以下问题：

1. 序列化问题：Proxy对象无法被structuredClone等序列化方法正确处理
2. 行为不一致：同样的操作在不同模式下表现不同
3. 预期不符：开发者可能期望直接赋值和使用set方法有相同的行为

解决方案建议

对于遇到此问题的开发者，目前有以下几种解决方案：

1. 使用set方法替代$前缀语法：

   obj.set({ name: 'bar' });
   

2. 在需要序列化时从存储中获取原始值：

   const rawValue = $obj;
   const clone = structuredClone(rawValue);
   

3. 等待官方修复：根据讨论，这可能是Runes模式下的一个需要修复的问题

最佳实践

基于当前情况，建议开发者在Svelte 5项目中：

1. 对于需要序列化或需要原始对象的场景，优先使用存储的set/get方法
2. 保持一致性：在项目中统一使用一种赋值方式（要么都用$前缀，要么都用方法调用）
3. 对于需要深度克隆存储值的场景，先获取存储值再克隆

随着Svelte 5的持续发展，这类边界情况的行为可能会被进一步规范和统一，开发者应关注官方更新以获取最新信息。