数据库NoSQL嵌入式数据库实时数据库【免费下载链接】rxdbThe local-first database that runs on every JS runtime and replicates with your existing backend - no vendor, no lock-in - https://rxdb.info/项目地址https://gitcode.com/gh_mirrors/rx/rxdb点击查看免费下载RxDB 14.0.0 是用于大规模重构与 API 变更的主版本发布核心聚焦于文档对象模型的重塑、文档更新方法命名体系的统一、复制与存储插件的标准化以及围绕写入路径、文档缓存与打包体积的多项性能优化。本文以官方发布说明为主线结合当前仓库源码src/rx-document.ts、src/incremental-write.ts、src/doc-cache.ts、src/plugins/replication-couchdb/index.ts等逐项解读这些变更帮助读者完成从 13.x 到 14.0 的平滑迁移并掌握新版本推荐的数据操作与复制启动方式。版本定位以 API 重构为主复制与存储层仅小幅调整14.0.0 是一次大刀阔斧的版本升级其目的不是引入新存储或新复制协议而是对既有 API 进行大规模重构。官方发布说明明确指出本版本的复制replication与存储层storage layer只被边缘性地触及真正的改动集中在文档对象、方法命名、插件组织与运行时性能上。因此熟悉 13.x 的开发者升级到 14.0 时遇到的大部分破坏性变更都发生在代码调用方式层面而不是数据同步逻辑层面。以下仅列出主要变更所有次要变更可查阅仓库根目录的 CHANGELOG.md。移除废弃特性告别 PouchDB 存储与旧版复制插件14.0 兑现了 13 版本中的废弃计划正式移除了两项旧能力PouchDB RxStorage 被彻底移除。该存储方案自 13 版本起被标记为废弃14.0 中正式从代码库删除相关说明见 rx-storage-pouchdb。如果你仍依赖 PouchDB 作为底层存储需要改用仓库中其他存储插件如storage-dexie、storage-memory、storage-sqlite等见 rx-storage。旧的replication-couchdb插件被移除取而代之的是曾以replication-couchdb-new名义存在的重写版本现已正式更名为replication-couchdb。也就是说CouchDB 复制插件的导入路径保持不变但内部实现已经是全新代码新版本说明见 replication-couchdb。API 变更详解RxDocument 对象改为不可变immutable这是 14.0 最具感知度的行为变更。在 13.x 及更早版本中RxDocument 实例会随着数据库中的变更事件ChangeEvent自动修改自身例如某文档在数据库中被更新为name bar那么之前拿到的那个 JavaScript 对象其doc.name属性也会同步变成bar。这种自变异行为在 Angular、Vue 这类具备变更检测的框架中非常方便——可以直接在模板中使用文档属性而无需手动订阅。但它也带来了明显的困惑数据库状态变化时对象属性究竟在哪个时间点发生改变并不清晰同时自变异对象与 Vue/React 开发者工具的对象克隆机制存在兼容性问题。在 RxDB 14 中所有 RxDocument 都是不可变的。当你订阅一个查询query并多次收到同一文档时每次返回的都是全新的 JavaScript 对象旧引用不会再被原地修改。这要求开发者以不可变数据流的方式组织视图更新。与之配套的另一处行为变化是RxDocument.$现在发射的是RxDocument实例而不再是纯文档数据plain document data。如果你之前的订阅代码直接消费了$发出的数据对象升级后需要改用文档实例的属性访问器或通过.toJSON()获取原始数据。从源码可以印证不可变设计的落地方式在 src/rx-document.ts 中modify()与patch()都基于clone(oldData)产生新数据对象再通过_saveData()写回存储并返回新的RxDocument 实例this.collection._docCache.getCachedRxDocument(...)旧对象的数据保持不变。重构findByIds()返回标准 RxQuery过去findByIds和findByIds$直接返回结果集一个Map或可观察对象这与 RxDB 其他查询的返回风格不一致容易造成混淆。14.0 中它们统一返回一个RxQuery对象行为与任何其他数据库查询完全一致可以继续链式调用.exec()获取结果、通过.$订阅实时结果const results await myRxCollection.findByIds([foo, bar]).exec(); const results$ await myRxCollection.findByIds([foo, bar]).$;源码层面src/rx-collection.ts 中的findByIds现在构造一个以主键字段为 selector{ [primaryPath]: { $in: ids } }的 Mango 查询并调用createRxQuery(findByIds, mangoQuery, this)返回RxQuery实例——也就是说按主键批量查询现在完全复用了统一的查询执行与缓存管道既保持高性能注释中明确说明其性能优于多次findOne()或复杂的$or查询又获得了与其他查询一致的 API 体验。RxDocument 更新/修改函数统一重命名文档修改方法的命名在过去相当混乱例如update()与atomicUpdate()的行为差异很大却难以从名字上区分。14.0 统一了所有文档修改方法的命名并为每个方法同时提供增量incremental即原先的 atomic与非增量两个版本旧名称新名称说明atomicUpdate()incrementalUpdate()增量执行 MongoDB 风格的UpdateQueryatomicPatch()incrementalPatch()增量合并指定的字段atomicUpsert()incrementalUpsert()增量插入或更新—新增incrementalUpdate()RxDocument 上的增量更新方法—新增incrementalRemove()增量删除文档—新增patch()/modify()非增量版本patch()合并字段modify()传入变异函数在 src/rx-document.ts 中可以清楚地看到这套新命名体系incrementalModify(mutationFunction)会将变异函数与文档当前状态一起加入collection.incrementalWriteQueue.addWrite(...)由写入队列统一调度对应批量写入优化一节incrementalPatch(patch)内部直接委托给incrementalModify在克隆的数据上合并patch的字段非增量的modify()与patch()则走_saveData()立即写回存储语义上是读取-修改-写入的原子替代品。实际使用中高频、并发场景应优先使用 incremental 系列方法它们经由写入队列合并后性能更优一次性、依赖前置状态的更新可继续使用非增量方法。复制改为纯函数启动13.x 时代启动一次复制需要先向 RxDB 注册复制插件然后在 RxCollection 上调用类方法如myRxCollection.syncGraphQL()。这种设计带来了两方面的长期问题一是难以对插件代码进行 tree shaking摇树优化二是类型推导不够准确。14.0 改为用纯函数启动复制不再依赖 RxCollection 上的类方法import { replicateCouchDB } from rxdb/plugins/replication-couchdb; const replicationState replicateCouchDB({ /* ... */ });在 src/plugins/replication-couchdb/index.ts 中可以看到replicateCouchDB是一个接受SyncOptionsCouchDB选项对象的普通导出函数它在内部读取options.collection、校验options.url必须以/结尾、默认启用waitForLeadership并据此构建 pull/push 的复制原语与pullStream$。这意味着复制逻辑完全与集合实例解耦可按需按模块导入对打包器友好且类型完整。GraphQL、Appwrite、Firestore 等复制插件的启动方式同理均改为replicateXxx({ ... })纯函数形式。存储插件统一加storage-前缀为了命名一致性所有存储插件都被加上storage-前缀导入路径随之改变// 旧写法 import { getRxStorageDexie } from rxdb/plugins/dexie; // 新写法 import { getRxStorageDexie } from rxdb/plugins/storage-dexie;这同样适用于 memory、localstorage、sqlite、mongodb、foundationdb、remote、denokv、opfs、filesystem-node、filesystem-expo 等存储插件。升级时只需批量调整 import 路径函数名本身不变。加密插件更名为encryption-crypto-js为了让未来可以出现多种加密实现原encryption插件更名为encryption-crypto-js导出函数也一并改名// 旧写法 import { wrappedKeyEncryptionStorage } from rxdb/plugins/encryption; // 新写法 import { wrappedKeyEncryptionCryptoJsStorage } from rxdb/plugins/encryption-crypto-js;加密整体概念与配置方式不变详见 encryption。值得注意的关联修复是复制状态元数据replication state meta data现在也必须一并加密避免复制检查点等信息以明文落盘。worker 插件重写并移入 RxDB Premium旧版 worker 插件基于threads库实现14.0 将其完全重写改为使用原生 JavaScript API 并基于 remote storage 插件 工作。但请注意重写后的 worker 插件已移入RxDB Premium 付费包不再随开源仓库发布。相关功能说明见 rx-storage-worker。性能改进不再用哈希作为修订号revision过去RxDocument 数据中的_rev字段填的是文档数据的哈希值。这存在两个问题JavaScript 中哈希计算很慢——仅在插入时跳过哈希计算性能即可提升约 33%哈希相同导致冲突不可区分——当两个客户端对文档做了完全相同的写入时两份文档会拥有完全相同的哈希比较文档状态无法判断它们来自不同写入这使得某些冲突解决策略无法实现。14.0 改为使用 RxDatabase 的token加上修订高度revision height来构成_rev既避免了哈希开销又保证了不同客户端写入的修订号天然可区分为冲突处理留出空间。对应地修复项中还包括复制在解决冲突后写入存储时必须提供._rev确保修订链在复制场景下连续可信。批量合并增量写入过去当对多个文档或同一文档连续写入时RxDB 会为每次写入各发起一次存储调用。在高频写入场景例如把当前鼠标位置持续写入一个文档下写入会不断排队直到用户能感知到性能卡顿。14.0 引入了增量写入队列挂起的文档更新会被合并为单次存储写入。这一点在 src/incremental-write.ts 中有完整的实现证据IncrementalWriteQueue按文档 id 维护待处理队列queueByDocIdaddWrite()将修改器入队并触发triggerRun()一次批量运行中同一文档的多个修改器会被串行应用每次传给修改器的都是克隆数据不同文档的写入则汇总为一次bulkWrite()。这样既避免了对同一文档的重复写也把对多个文档的写入压进单次存储调用。这也解释了为什么 14.0 推荐使用incrementalPatch()/incrementalModify()系列方法它们天然走写入队列享受批量合并的红利。改进 tree shaking显著缩小打包体积本次发布在代码组织上做了大量调整包括复制改纯函数、存储插件独立化等大幅提升了 RxDB 的可摇树性直接结果是更小的 bundle 体积与更快的应用启动。重构文档缓存基于 WeakRef 自动清理整个 RxDocument 缓存被重构现在基于 WeakRef API 运行不再被引用的缓存文档会被自动清理从而降低内存占用使 RxDB 更适合在 Node.js 服务端长期运行。源码 src/doc-cache.ts 印证了这一点缓存内部存储的是WeakRefRxDocumentMapstring, WeakRef...读取缓存时通过.deref()还原文档同时对不支持 WeakRef 的 JavaScript 运行时提供了createWeakRefFallback回退实现HAS_WEAK_REF探测。兼容性注意WeakRef API 仅在现代浏览器中可用因此RxDB 14 不再支持 IE11。如果你的用户群仍包含 IE11需要停留在旧版本。不再转译若干现代 JavaScript 特性为减小体积并提升性能以下特性不再被转译transpile因为它们在现代浏览器中已原生支持async/await箭头函数Arrow functionsfor...of简写属性shorthand properties展开运算符Spread operator解构赋值destructuring默认参数default parameters对象展开object spread这些优化与前述 tree shaking 改动叠加后仓库 config/bundle-size.js 所监控的测试 bundle 体积从74148字节降至36007字节缩减超过一半。这意味着使用 RxDB 的现代浏览器应用可以显著减少首屏加载的 JavaScript 量。其他变更新增push/pull.initialCheckpoint允许从给定的检查点checkpoint启动复制适用于断点续传、从备份状态恢复复制等场景。该选项在 src/plugins/replication/index.ts 及各复制插件couchdb、appwrite、firestore、google-drive、microsoft-onedrive、supabase的replicateXxx()选项中均有接入底层复制协议的 upstream/downstream 流程src/replication-protocol/upstream.ts、src/replication-protocol/downstream.ts会基于该检查点初始化拉取/推送游标。以下插件正式脱离 beta 模式RxStorage Sharding分片存储RxStorage Remote远程存储RxStorage FoundationDB新版 Replication CouchDBCleanup 插件旧数据清理Bugfixes 一览14.0 还包含一批针对各存储与复制实现的修复按官方发布说明整理如下内存存储memory RxStorage关闭存储时不再清理数据库状态仅在调用remove()时清理。CouchDB 复制使用正确的默认 fetch 方法修复因缺少修订号导致 push 抛错#4299修复冲突处理相关问题。schema 哈希尊重字段的排序顺序#4005。复制冲突解决后写入存储时必须提供._rev修复复制集合上的复合主键Composite Primary Keys问题#4190修复复制状态元数据未加密的问题。远程存储remote storage确保并行 create 调用时缓存正常工作修复$regex查询在远程存储上不生效的问题。SQLite 存储修复$in查询#4278。通用移除Buffer的使用全面改用Blob修复 socket.io 的导入问题#4307修复复合主键导致的 id 长度超限问题#4315。dev-mode新增console.warn()提示确保开发者不会在生产环境误用该插件见 dev-mode。从 13.x.x 迁移到 14.0.0迁移涉及数据格式变更需要特别留意schema 哈希与归一化方式已改变。为了迁移 13.x 存储的数据你必须将 schema 版本号1并添加对应的迁移策略migration strategy流程见>赞分享数据库NoSQL嵌入式数据库实时数据库【免费下载链接】rxdbThe local-first database that runs on every JS runtime and replicates with your existing backend - no vendor, no lock-in - https://rxdb.info/项目地址https://gitcode.com/gh_mirrors/rx/rxdb点击查看免费下载相关推荐OmniRoute 国际化i18n工程实战30 语言的配置架构、自动翻译流水线与质量门禁OmniRoute 国际化i18n工程实战30 语言的配置架构、自动翻译流水线与质量门禁 OmniRoute 是一个面向 AI 网关的开源项目其国际化数据库NoSQL嵌入式数据库实时数据库终极ripgrep 14.0到14.1.1版本升级指南7个重要变化详解终极ripgrep 14.0到14.1.1版本升级指南7个重要变化详解 ripgrep是一款高效的命令行搜索工具它能递归搜索目录中的正则表达式模式同时尊重CLI开发工具Flipper Zero 固件应用清单FAM完全指南从 application.fam 到构建系统Flipper Zero 固件应用清单FAM完全指南从 application.fam 到构建系统 FAMFlipper App ManifestFl数据库NoSQL嵌入式数据库实时数据库上一篇3分钟上手MiniCPM5-1BvLLM与Transformers部署教程终极指南 下一篇突破90%FilePizza单元测试覆盖率提升实战关键模块测试策略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/20 3:20:50 · 阅读 1.2k RxDB 14.0 升级指南：不可变 RxDocument、增量写入 API 与性能重构详解
数据库NoSQL嵌入式数据库实时数据库【免费下载链接】rxdbThe local-first database that runs on every JS runtime and replicates with your existing backend - no vendor, no lock-in - https://rxdb.info/项目地址https://gitcode.com/gh_mirrors/rx/rxdb点击查看免费下载RxDB 14.0.0 是用于大规模重构与 API 变更的主版本发布核心聚焦于文档对象模型的重塑、文档更新方法命名体系的统一、复制与存储插件的标准化以及围绕写入路径、文档缓存与打包体积的多项性能优化。本文以官方发布说明为主线结合当前仓库源码src/rx-document.ts、src/incremental-write.ts、src/doc-cache.ts、src/plugins/replication-couchdb/index.ts等逐项解读这些变更帮助读者完成从 13.x 到 14.0 的平滑迁移并掌握新版本推荐的数据操作与复制启动方式。版本定位以 API 重构为主复制与存储层仅小幅调整14.0.0 是一次大刀阔斧的版本升级其目的不是引入新存储或新复制协议而是对既有 API 进行大规模重构。官方发布说明明确指出本版本的复制replication与存储层storage layer只被边缘性地触及真正的改动集中在文档对象、方法命名、插件组织与运行时性能上。因此熟悉 13.x 的开发者升级到 14.0 时遇到的大部分破坏性变更都发生在代码调用方式层面而不是数据同步逻辑层面。以下仅列出主要变更所有次要变更可查阅仓库根目录的 CHANGELOG.md。移除废弃特性告别 PouchDB 存储与旧版复制插件14.0 兑现了 13 版本中的废弃计划正式移除了两项旧能力PouchDB RxStorage 被彻底移除。该存储方案自 13 版本起被标记为废弃14.0 中正式从代码库删除相关说明见 rx-storage-pouchdb。如果你仍依赖 PouchDB 作为底层存储需要改用仓库中其他存储插件如storage-dexie、storage-memory、storage-sqlite等见 rx-storage。旧的replication-couchdb插件被移除取而代之的是曾以replication-couchdb-new名义存在的重写版本现已正式更名为replication-couchdb。也就是说CouchDB 复制插件的导入路径保持不变但内部实现已经是全新代码新版本说明见 replication-couchdb。API 变更详解RxDocument 对象改为不可变immutable这是 14.0 最具感知度的行为变更。在 13.x 及更早版本中RxDocument 实例会随着数据库中的变更事件ChangeEvent自动修改自身例如某文档在数据库中被更新为name bar那么之前拿到的那个 JavaScript 对象其doc.name属性也会同步变成bar。这种自变异行为在 Angular、Vue 这类具备变更检测的框架中非常方便——可以直接在模板中使用文档属性而无需手动订阅。但它也带来了明显的困惑数据库状态变化时对象属性究竟在哪个时间点发生改变并不清晰同时自变异对象与 Vue/React 开发者工具的对象克隆机制存在兼容性问题。在 RxDB 14 中所有 RxDocument 都是不可变的。当你订阅一个查询query并多次收到同一文档时每次返回的都是全新的 JavaScript 对象旧引用不会再被原地修改。这要求开发者以不可变数据流的方式组织视图更新。与之配套的另一处行为变化是RxDocument.$现在发射的是RxDocument实例而不再是纯文档数据plain document data。如果你之前的订阅代码直接消费了$发出的数据对象升级后需要改用文档实例的属性访问器或通过.toJSON()获取原始数据。从源码可以印证不可变设计的落地方式在 src/rx-document.ts 中modify()与patch()都基于clone(oldData)产生新数据对象再通过_saveData()写回存储并返回新的RxDocument 实例this.collection._docCache.getCachedRxDocument(...)旧对象的数据保持不变。重构findByIds()返回标准 RxQuery过去findByIds和findByIds$直接返回结果集一个Map或可观察对象这与 RxDB 其他查询的返回风格不一致容易造成混淆。14.0 中它们统一返回一个RxQuery对象行为与任何其他数据库查询完全一致可以继续链式调用.exec()获取结果、通过.$订阅实时结果const results await myRxCollection.findByIds([foo, bar]).exec(); const results$ await myRxCollection.findByIds([foo, bar]).$;源码层面src/rx-collection.ts 中的findByIds现在构造一个以主键字段为 selector{ [primaryPath]: { $in: ids } }的 Mango 查询并调用createRxQuery(findByIds, mangoQuery, this)返回RxQuery实例——也就是说按主键批量查询现在完全复用了统一的查询执行与缓存管道既保持高性能注释中明确说明其性能优于多次findOne()或复杂的$or查询又获得了与其他查询一致的 API 体验。RxDocument 更新/修改函数统一重命名文档修改方法的命名在过去相当混乱例如update()与atomicUpdate()的行为差异很大却难以从名字上区分。14.0 统一了所有文档修改方法的命名并为每个方法同时提供增量incremental即原先的 atomic与非增量两个版本旧名称新名称说明atomicUpdate()incrementalUpdate()增量执行 MongoDB 风格的UpdateQueryatomicPatch()incrementalPatch()增量合并指定的字段atomicUpsert()incrementalUpsert()增量插入或更新—新增incrementalUpdate()RxDocument 上的增量更新方法—新增incrementalRemove()增量删除文档—新增patch()/modify()非增量版本patch()合并字段modify()传入变异函数在 src/rx-document.ts 中可以清楚地看到这套新命名体系incrementalModify(mutationFunction)会将变异函数与文档当前状态一起加入collection.incrementalWriteQueue.addWrite(...)由写入队列统一调度对应批量写入优化一节incrementalPatch(patch)内部直接委托给incrementalModify在克隆的数据上合并patch的字段非增量的modify()与patch()则走_saveData()立即写回存储语义上是读取-修改-写入的原子替代品。实际使用中高频、并发场景应优先使用 incremental 系列方法它们经由写入队列合并后性能更优一次性、依赖前置状态的更新可继续使用非增量方法。复制改为纯函数启动13.x 时代启动一次复制需要先向 RxDB 注册复制插件然后在 RxCollection 上调用类方法如myRxCollection.syncGraphQL()。这种设计带来了两方面的长期问题一是难以对插件代码进行 tree shaking摇树优化二是类型推导不够准确。14.0 改为用纯函数启动复制不再依赖 RxCollection 上的类方法import { replicateCouchDB } from rxdb/plugins/replication-couchdb; const replicationState replicateCouchDB({ /* ... */ });在 src/plugins/replication-couchdb/index.ts 中可以看到replicateCouchDB是一个接受SyncOptionsCouchDB选项对象的普通导出函数它在内部读取options.collection、校验options.url必须以/结尾、默认启用waitForLeadership并据此构建 pull/push 的复制原语与pullStream$。这意味着复制逻辑完全与集合实例解耦可按需按模块导入对打包器友好且类型完整。GraphQL、Appwrite、Firestore 等复制插件的启动方式同理均改为replicateXxx({ ... })纯函数形式。存储插件统一加storage-前缀为了命名一致性所有存储插件都被加上storage-前缀导入路径随之改变// 旧写法 import { getRxStorageDexie } from rxdb/plugins/dexie; // 新写法 import { getRxStorageDexie } from rxdb/plugins/storage-dexie;这同样适用于 memory、localstorage、sqlite、mongodb、foundationdb、remote、denokv、opfs、filesystem-node、filesystem-expo 等存储插件。升级时只需批量调整 import 路径函数名本身不变。加密插件更名为encryption-crypto-js为了让未来可以出现多种加密实现原encryption插件更名为encryption-crypto-js导出函数也一并改名// 旧写法 import { wrappedKeyEncryptionStorage } from rxdb/plugins/encryption; // 新写法 import { wrappedKeyEncryptionCryptoJsStorage } from rxdb/plugins/encryption-crypto-js;加密整体概念与配置方式不变详见 encryption。值得注意的关联修复是复制状态元数据replication state meta data现在也必须一并加密避免复制检查点等信息以明文落盘。worker 插件重写并移入 RxDB Premium旧版 worker 插件基于threads库实现14.0 将其完全重写改为使用原生 JavaScript API 并基于 remote storage 插件 工作。但请注意重写后的 worker 插件已移入RxDB Premium 付费包不再随开源仓库发布。相关功能说明见 rx-storage-worker。性能改进不再用哈希作为修订号revision过去RxDocument 数据中的_rev字段填的是文档数据的哈希值。这存在两个问题JavaScript 中哈希计算很慢——仅在插入时跳过哈希计算性能即可提升约 33%哈希相同导致冲突不可区分——当两个客户端对文档做了完全相同的写入时两份文档会拥有完全相同的哈希比较文档状态无法判断它们来自不同写入这使得某些冲突解决策略无法实现。14.0 改为使用 RxDatabase 的token加上修订高度revision height来构成_rev既避免了哈希开销又保证了不同客户端写入的修订号天然可区分为冲突处理留出空间。对应地修复项中还包括复制在解决冲突后写入存储时必须提供._rev确保修订链在复制场景下连续可信。批量合并增量写入过去当对多个文档或同一文档连续写入时RxDB 会为每次写入各发起一次存储调用。在高频写入场景例如把当前鼠标位置持续写入一个文档下写入会不断排队直到用户能感知到性能卡顿。14.0 引入了增量写入队列挂起的文档更新会被合并为单次存储写入。这一点在 src/incremental-write.ts 中有完整的实现证据IncrementalWriteQueue按文档 id 维护待处理队列queueByDocIdaddWrite()将修改器入队并触发triggerRun()一次批量运行中同一文档的多个修改器会被串行应用每次传给修改器的都是克隆数据不同文档的写入则汇总为一次bulkWrite()。这样既避免了对同一文档的重复写也把对多个文档的写入压进单次存储调用。这也解释了为什么 14.0 推荐使用incrementalPatch()/incrementalModify()系列方法它们天然走写入队列享受批量合并的红利。改进 tree shaking显著缩小打包体积本次发布在代码组织上做了大量调整包括复制改纯函数、存储插件独立化等大幅提升了 RxDB 的可摇树性直接结果是更小的 bundle 体积与更快的应用启动。重构文档缓存基于 WeakRef 自动清理整个 RxDocument 缓存被重构现在基于 WeakRef API 运行不再被引用的缓存文档会被自动清理从而降低内存占用使 RxDB 更适合在 Node.js 服务端长期运行。源码 src/doc-cache.ts 印证了这一点缓存内部存储的是WeakRefRxDocumentMapstring, WeakRef...读取缓存时通过.deref()还原文档同时对不支持 WeakRef 的 JavaScript 运行时提供了createWeakRefFallback回退实现HAS_WEAK_REF探测。兼容性注意WeakRef API 仅在现代浏览器中可用因此RxDB 14 不再支持 IE11。如果你的用户群仍包含 IE11需要停留在旧版本。不再转译若干现代 JavaScript 特性为减小体积并提升性能以下特性不再被转译transpile因为它们在现代浏览器中已原生支持async/await箭头函数Arrow functionsfor...of简写属性shorthand properties展开运算符Spread operator解构赋值destructuring默认参数default parameters对象展开object spread这些优化与前述 tree shaking 改动叠加后仓库 config/bundle-size.js 所监控的测试 bundle 体积从74148字节降至36007字节缩减超过一半。这意味着使用 RxDB 的现代浏览器应用可以显著减少首屏加载的 JavaScript 量。其他变更新增push/pull.initialCheckpoint允许从给定的检查点checkpoint启动复制适用于断点续传、从备份状态恢复复制等场景。该选项在 src/plugins/replication/index.ts 及各复制插件couchdb、appwrite、firestore、google-drive、microsoft-onedrive、supabase的replicateXxx()选项中均有接入底层复制协议的 upstream/downstream 流程src/replication-protocol/upstream.ts、src/replication-protocol/downstream.ts会基于该检查点初始化拉取/推送游标。以下插件正式脱离 beta 模式RxStorage Sharding分片存储RxStorage Remote远程存储RxStorage FoundationDB新版 Replication CouchDBCleanup 插件旧数据清理Bugfixes 一览14.0 还包含一批针对各存储与复制实现的修复按官方发布说明整理如下内存存储memory RxStorage关闭存储时不再清理数据库状态仅在调用remove()时清理。CouchDB 复制使用正确的默认 fetch 方法修复因缺少修订号导致 push 抛错#4299修复冲突处理相关问题。schema 哈希尊重字段的排序顺序#4005。复制冲突解决后写入存储时必须提供._rev修复复制集合上的复合主键Composite Primary Keys问题#4190修复复制状态元数据未加密的问题。远程存储remote storage确保并行 create 调用时缓存正常工作修复$regex查询在远程存储上不生效的问题。SQLite 存储修复$in查询#4278。通用移除Buffer的使用全面改用Blob修复 socket.io 的导入问题#4307修复复合主键导致的 id 长度超限问题#4315。dev-mode新增console.warn()提示确保开发者不会在生产环境误用该插件见 dev-mode。从 13.x.x 迁移到 14.0.0迁移涉及数据格式变更需要特别留意schema 哈希与归一化方式已改变。为了迁移 13.x 存储的数据你必须将 schema 版本号1并添加对应的迁移策略migration strategy流程见>赞分享数据库NoSQL嵌入式数据库实时数据库【免费下载链接】rxdbThe local-first database that runs on every JS runtime and replicates with your existing backend - no vendor, no lock-in - https://rxdb.info/项目地址https://gitcode.com/gh_mirrors/rx/rxdb点击查看免费下载相关推荐OmniRoute 国际化i18n工程实战30 语言的配置架构、自动翻译流水线与质量门禁OmniRoute 国际化i18n工程实战30 语言的配置架构、自动翻译流水线与质量门禁 OmniRoute 是一个面向 AI 网关的开源项目其国际化数据库NoSQL嵌入式数据库实时数据库终极ripgrep 14.0到14.1.1版本升级指南7个重要变化详解终极ripgrep 14.0到14.1.1版本升级指南7个重要变化详解 ripgrep是一款高效的命令行搜索工具它能递归搜索目录中的正则表达式模式同时尊重CLI开发工具Flipper Zero 固件应用清单FAM完全指南从 application.fam 到构建系统Flipper Zero 固件应用清单FAM完全指南从 application.fam 到构建系统 FAMFlipper App ManifestFl数据库NoSQL嵌入式数据库实时数据库上一篇3分钟上手MiniCPM5-1BvLLM与Transformers部署教程终极指南 下一篇突破90%FilePizza单元测试覆盖率提升实战关键模块测试策略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考