Svelte在大型项目中的架构设计：无虚拟DOM下的状态管理方案

以前做前端项目，状态管理基本上是绕不开的话题。用React的时候有Redux，用Vue有Vuex，到了Svelte，很多老手会突然发现，哎，怎么没有官方推荐一个统一的状态库？于是开始担心：没有虚拟DOM，状态管理还能按原来的套路玩吗？其实不用慌，Svelte虽然不走虚拟DOM那条路，但它自带了一套清爽的状态管理思路。这篇文章我就用大白话，结合具体代码，跟你聊聊在大型项目里怎么给Svelte设计一套靠谱的状态管理方案。

一、Svelte没有虚拟DOM，到底改变了什么

Svelte的“编译器”气质，决定了它跟React、Vue不是一类人。React在运行时维护一棵虚拟DOM树，状态变了，先对比新旧虚拟DOM，再算出差异，最后去改真实DOM。Svelte呢？它在编译阶段就把组件的状态和DOM节点绑死了，状态一变，直接精准更新那个地方。所以，没有虚拟DOM，其实是省掉了“中间商”，让数据流更加直白。

1.1 细粒度更新带来的心智简化

以前用虚拟DOM时，我们总要想“这个状态变化会影响多少个组件？要不要做memo？”在Svelte里，你只要在模板里用到某个变量，那这个变量一变，对应的DOM就自动更新，其他的地方完全不管。这种细粒度更新，让状态管理变成了一件很轻松的事：你把状态看作“信号”，DOM只是信号的显示屏幕。

1.2 需要重新思考的全局状态

在大型项目里，状态管理不只是“把数据存起来”这么简单。还要考虑模块怎么划分、数据怎么共享、怎么测试、服务端渲染怎么办。Svelte没有像Redux那样的官方“全家桶”，反而给了我们更大的自由去组合不同的方案。最核心的，其实就是它自带的store和context。

二、Svelte原生Store：最基础也最实在的方案

Svelte自带的writable、readable、derived，已经能覆盖大部分全局状态需求。你甚至可以把它想象成一个“带订阅功能的普通对象”。在大型项目里，最简单粗暴的做法就是：每个业务模块一个store文件，然后在组件里用$前缀自动订阅。

2.1 Store的基本用法

先看一个购物车的例子。假设我们在做一个电商后台，购物车数据需要被很多组件共享。

// 技术栈：Svelte + JavaScript
// 我们先写一个购物车的store，它保存着商品列表
import { writable, derived } from 'svelte/store';

// 定义一个初始状态
const initialCart = [
  { id: 1, name: '苹果', price: 2.5, count: 3 },
  { id: 2, name: '香蕉', price: 3.0, count: 2 },
];

// 创建可写的store
export const cart = writable(initialCart);

// 派生store：计算总价
// derived会跟踪内部依赖，当cart变化时，totalPrice自动重算
export const totalPrice = derived(cart, ($cart) => {
  // 用reduce把所有商品的价格乘以数量加起来
  return $cart.reduce((sum, item) => sum + item.price * item.count, 0);
});

// 添加商品的方法
// 注意：store提供了update方法，可以基于当前值做修改
export function addItem(item) {
  cart.update((items) => {
    // 如果已经存在同id商品，则数量+1
    const existed = items.find((i) => i.id === item.id);
    if (existed) {
      existed.count += 1;
      return items; // 直接返回原数组引用也可以
    }
    // 否则追加新商品
    return [...items, { ...item, count: 1 }];
  });
}

// 移除商品
export function removeItem(id) {
  cart.update((items) => items.filter((i) => i.id !== id));
}

接着在组件里使用。注意Svelte中$前缀是自动订阅的语法糖，必须放在组件顶层使用。

<!-- 技术栈：Svelte + JavaScript -->
<script>
  // 引入store和方法
  import { cart, totalPrice, addItem, removeItem } from './stores/cart.js';

  // 使用$前缀自动订阅
  // 当cart的值发生变化时，这个console也会重新执行
  $: console.log('购物车变化了，当前数量：', $cart.length);
</script>

<div class="cart">
  <h2>购物车</h2>
  <ul>
    {#each $cart as item (item.id)}
      <li>
        {item.name} - 单价{item.price}元 x {item.count}个
        <button on:click={() => addItem(item)}>+</button>
        <button on:click={() => removeItem(item.id)}>-</button>
      </li>
    {/each}
  </ul>
  <p>总价：{$totalPrice}元</p>
</div>

2.2 在大型项目中如何组织Store

当项目变大后，不建议把所有的store都堆在一个文件里。我一般会按业务模块来划分文件夹。比如这样：

src/
  stores/
    index.js        # 统一导出
    user.js         # 用户模块
    cart.js         # 购物车模块
    notification.js # 通知/弹窗模块

每个store文件就是一个“状态模块”，它对外只暴露需要被外部使用的方法和store，内部细节全部藏起来。这种方式让团队协作变得很干净：每个人负责自己的模块，改起来互不干扰。

来看一个用户store的完整写法，顺便加入持久化功能，这在大型项目里很常用。

// 技术栈：Svelte + JavaScript
// stores/user.js 管理当前登录用户的信息
import { writable } from 'svelte/store';

// 初始化时从localStorage读取，实现刷新页面后不丢失登录状态
const storedUser = JSON.parse(localStorage.getItem('user') || 'null');

// 创建store
export const user = writable(storedUser);

// 订阅变化时自动写入localStorage
// 注意：这里返回的是一个取消订阅函数，但因为我们是在模块顶层订阅，所以不需要取消
user.subscribe((value) => {
  // 如果是null就删除，否则存字符串
  localStorage.setItem('user', JSON.stringify(value));
});

// 登录：直接设置用户信息
export function login(userInfo) {
  user.set(userInfo);
}

// 登出：清空用户
export function logout() {
  user.set(null);
}

你可能会问：这样每个store都是模块级单例，会不会有Test污染？没关系，Svelte的store写起来很轻，测试的时候可以重新创建store实例，或者直接覆写对应模块方法。我们后面再聊测试。

三、Context与Store的配合：实现依赖注入

Store是全局的，适合放“尸体级别”的数据，比如登录用户、购物车。但有些数据只属于某个组件子树，比如一个列表页的筛选条件。这时候如果还放进全局store，就会造成命名冲突和内存浪费。Svelte提供了Context API，用来在组件树中传递数据，而且支持传递store本身。

3.1 Context是什么

简单来说，setContext和getContext有点像是“组件树里的私有频道”。父组件用setContext(key, value)往频道里发数据，后代组件用getContext(key)取数据。这个value可以是任意值，当然也可以是一个store。和全局store的区别在于：Context只在当前组件树里生效，不会污染其他无关的组件。

3.2 示例：用户上下文

在大型项目中，我们常常需要把当前用户信息注入到某个模块的组件里，而不是全局。比如一个后台管理页面，它的左侧导航、顶部栏、内容区都需要知道当前登录角色，但又不希望把用户store作为全局单例。用Context就很舒服。

<!-- 技术栈：Svelte + JavaScript -->
<!-- Layout.svelte 作为模块的根组件 -->
<script>
  import { setContext } from 'svelte';
  import { writable } from 'svelte/store';
  import Sidebar from './Sidebar.svelte';
  import Header from './Header.svelte';
  import Content from './Content.svelte';

  // 创建一个user store，只在这个模块内传递
  const user = writable({ name: '张三', role: 'admin' });

  // 把store放进context
  // key建议用一个常量，后面再统一维护
  setContext('module-user', user);
</script>

<div class="layout">
  <Sidebar />
  <Header />
  <Content />
</div>

然后子组件就可以取用：

<!-- 技术栈：Svelte + JavaScript -->
<!-- Sidebar.svelte -->
<script>
  import { getContext } from 'svelte';

  // 从context取出store
  const user = getContext('module-user');
</script>

<div>
  <!-- 这里可以用$user自动订阅 -->
  当前角色：{$user.role}，你好，{$user.name}
</div>

这样，即使多个模块都有类似的user context，只要key不同，就完全不会打架。而且如果哪天这个模块不需要user了，删掉父组件里的setContext就行，一点都不影响其他模块。

四、自定义状态管理：用发布订阅满足特殊需求

有些时候，官方的writable可能有局限性。比如你想做一个“有历史记录”的表格，或者你需要同时控制多个派生状态。没关系，我们可以基于Svelte的readable或者直接实现一个简单的订阅器，来定制自己的状态机。

4.1 发布订阅模式的利与弊

发布订阅本质上就是一套“你给我回调函数，我状态变了就通知你”的机制。优点是很灵活，可以和任何库配合；缺点是要自己管理订阅的添加和移除，容易泄漏。不过Svelte提供了readable，能帮我们自动处理“第一个订阅者出现时初始化，最后一个取消时清理”的逻辑，用起来省心很多。

4.2 示例：自定义counter

假设我们要做一个可复用的“计数器组件”，它需要维护一堆内部状态，并且允许外部控制。我们可以把它封装成一个“可写store的工厂函数”。

// 技术栈：Svelte + JavaScript
// 一个简单的计数器状态工厂
import { readable } from 'svelte/store';

// 导出一个创建函数，每次调用都会生成独立的store
export function createCounter(initialValue = 0) {
  // 内部保存值
  let count = initialValue;

  // 用一个Set存储所有订阅者
  const listeners = new Set();

  // readable接收一个set函数
  // 当订阅者从0变成1时，set函数会执行一次，并提供一个更新值的回调set
  const store = readable(count, (set) => {
    // 拉取新值给所有订阅者
    const update = () => set(count);

    // 先把当前值发给订阅者
    update();

    // 把update函数加入监听器集合
    listeners.add(update);

    // 返回清理函数：当最后一个订阅者取消时执行
    return () => {
      listeners.delete(update);
    };
  });

  // 内部更新函数，通知所有监听者
  function emit() {
    listeners.forEach((fn) => fn());
  }

  // 对外暴露操作方法
  return {
    // 让组件可以使用$store语法
    subscribe: store.subscribe,
    // 增加
    increment: () => {
      count += 1;
      emit();
    },
    // 减少
    decrement: () => {
      count -= 1;
      emit();
    },
    // 重置
    reset: () => {
      count = initialValue;
      emit();
    },
  };
}

在组件里用起来非常方便：

<!-- 技术栈：Svelte + JavaScript -->
<script>
  import { createCounter } from './counter.js';

  // 创建一个独立的计数器
  const counter = createCounter(10);
</script>

<div>
  <button on:click={counter.increment}>+1</button>
  <button on:click={counter.decrement}>-1</button>
  <button on:click={counter.reset}>重置</button>
  <span>当前值：{$counter}</span>
</div>

看，这里的$counter能自动更新，因为createCounter返回的对象里有subscribe方法，符合store规范。在大型项目里，这种工厂函数特别适合做“局部的复杂状态”，比如日历组件的月份、表格的排序状态等。

五、应用场景与优缺点分析

5.1 适合Svelte状态管理的典型场景

Svelte的状态管理方案，很适合以下这些场景：

• 交互密集的B端系统：比如后台管理界面，有大量表单、弹窗、联动下拉框，状态更新频繁，Svelte的细粒度更新让页面体验非常流畅。
• 实时数据仪表盘：比如监控大屏，数据几秒钟就更新一次，用writable store配合derived做数据聚合，代码简洁，性能也稳。
• 电商平台：像购物车、用户信息、优惠券这些全局数据，用store模块化组织，易维护，好扩展。
• 高复用的组件库：用Context把共享状态注入组件树，能让组件库的API保持干净。

5.2 无虚拟DOM的优缺点

总结一下Svelte这种模式的好处和坑。

优点：

• 心智能负担小。不用考虑“什么时候该优化”，状态更新天然精确，性能下限高。
• 代码量更少。没有虚拟DOM那一套运行时，打包体积也小，对于大型应用优化首屏很有帮助。
• store和订阅机制是语言自带的，不需要安装额外库，学习路径很短。

缺点：

• 生态里没有像Redux那样统一的状态管理中间件。你需要自己约定一些规范，比如模块如何组织、异步Action怎么处理。
• 调试工具相对React和Vue不那么丰富。虽然Svelte的DevTools也在完善，但遇到复杂的状态流转，可能还是得靠console。
• 虚拟DOM的“diff”在某些极端场景下可以做一些批量跳跃更新，而Svelte虽然也有微任务调度，但如果你手动操作DOM，依然要小心频繁更新。

不过这些缺点在大型项目里都不是硬伤，只要提前约定好规范，反而会让代码更清爽。

六、注意事项与最佳实践

想把Svelte状态管理用好，有几个小坑值得避开。

第一，不要解构store。在组件里写const { name } = $store，会丢失响应性。因为$store是自动订阅的代理，解构出来的普通变量不再和store挂钩。正确做法是直接在模板中用$store.name，或者用$:派生变量。

第二，手动订阅后记得取消。如果你在组件中用store.subscribe(callback)而不是$前缀，一定要在onDestroy里调用返回的取消函数，否则会造成内存泄漏。$前缀会自动帮我们处理，所以能自动订阅就自动订阅。

第三，Context的key要统一维护。不要到处写'user'这种裸字符串，我建议建一个contexts.js，统一导出key常量。比如：

// 技术栈：Svelte + JavaScript
// contexts.js
export const USER_CONTEXT = Symbol('user-context');
export const SETTINGS_CONTEXT = Symbol('settings-context');

注意：如果用Symbol作为key，那么getContext和setContext都要引用同一个Symbol，所以必须跨文件共享。

第四，异步状态要放在store里。比如请求后端的用户信息，直接一个async函数调用user.set，然后组件通过store订阅。千万不要在组件内部用setInterval或fetch往store外面放飞自我，那样会把状态管理搞成一团乱麻。

第五，为store写单元测试。store是纯数据逻辑，非常适合单测。用get函数可以读取当前值：

// 技术栈：Svelte + JavaScript
// store.test.js (概念示例)
import { get } from 'svelte/store';
import { cart, addItem, totalPrice } from './cart.js';

// 测试添加商品
addItem({ id: 3, name: '梨', price: 1.8, count: 1 });
console.log(get(cart).length); // 应该输出3
console.log(get(totalPrice));  // 应该输出总价

第六，注意Service Worker和SSR场景。如果你的项目用了服务端渲染，不能在模块顶层访问localStorage。需要做一个环境判断，或者在store初始化时延迟加载。

七、总结

Svelte虽然没有虚拟DOM，但它用编译期的魔法，让状态管理和DOM更新变得无比直接。在大型项目里，你不一定需要一个像Redux那样庞大的状态库，简单的writable加derived，配合Context做依赖注入，再加上一点自定义工厂函数，就能覆盖绝大多数场景。最重要的不是工具本身，而是你对数据流的理解：哪些状态是全局的，哪些是局部的，哪些属于组件树。把这个想明白了，Svelte的状态管理方案反而会让你越写越舒服，越写越觉得自己像是开了智慧圈。