Dexie.js 中嵌套对象更新问题的分析与解决

问题背景

在使用 Dexie.js 这个轻量级 IndexedDB 封装库时，开发者经常会遇到嵌套对象更新的问题。特别是在 Svelte 5 与 TypeScript 的组合中，当尝试更新嵌套在数组中的对象时，可能会出现更新操作看似成功但实际上未生效的情况。

典型场景

考虑一个健身应用的数据模型，其中 Workout 对象包含嵌套的 workout_exercises 数组，每个练习又包含 sets 数组。开发者需要实现添加新训练组(set)的功能，但发现有时更新操作不会持久化到数据库中。

问题复现

开发者最初尝试了以下几种更新方式：

1. 通过 map 方法创建新数组后整体更新
2. 使用 Dexie 的点符号路径更新特定嵌套属性
3. 直接使用 put 方法替换整个对象

但所有这些方法都表现出不稳定的行为——有时更新成功，有时却无效。

根本原因分析

经过深入排查，发现问题出在 Svelte 的响应式系统与 Dexie 操作的交互方式上。具体来说：

1. 缺少事务保护：在没有显式事务的情况下，多个并发的读取-修改-写入操作可能导致竞态条件
2. 响应式副作用：Svelte 的 $effect 在组件初始化时自动执行，可能触发意外的数据库操作
3. 状态同步问题：直接操作嵌套对象而没有正确处理对象引用和不变性

解决方案

1. 使用显式事务

确保所有数据库操作都在事务中执行：

await db.transaction('rw', db.workouts, async () => {
  // 读取和更新操作
});

2. 优化响应式更新

避免在 $effect 中直接执行数据库操作，改为在用户交互事件处理器中显式调用：

function handleSetUpdate() {
  workoutsStore.updateExerciseSet(workoutId, workoutExerciseId, {
    weight,
    reps
  });
}

3. 使用不可变更新模式

确保每次更新都创建新的对象引用：

const updatedExercises = workout.workout_exercises.map(exercise => {
  if (exercise.id === workoutExerciseId) {
    return {
      ...exercise,
      sets: [...exercise.sets, newSet]
    };
  }
  return exercise;
});

最佳实践建议

1. 始终使用事务：对于任何涉及读取后修改的操作
2. 最小化响应式副作用：避免在自动执行的副作用中进行重要操作
3. 明确操作边界：将数据库操作限制在明确的用户动作触发时
4. 考虑性能影响：对于大型嵌套对象，评估是否需要更细粒度的更新策略

总结

Dexie.js 虽然简化了 IndexedDB 的使用，但在处理复杂嵌套对象时仍需注意事务管理和状态同步。通过采用显式事务控制和合理的架构设计，可以避免这类更新不一致的问题。对于 Svelte 应用，特别需要注意响应式系统与数据库操作的交互方式，确保数据流动的可预测性。