Meteor Methods 完全指南：定义、调用、错误处理与底层生命周期原理

Meteor Methods 完全指南定义、调用、错误处理与底层生命周期原理【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteorMeteor Methods 是 Meteor 框架内置的远程过程调用RPC系统是客户端向服务端写入数据库、执行业务逻辑的标准通道。本文将以官方 Guide 的 methods 章节为主体结合当前仓库packages/ddp-client、packages/ddp-server、packages/ddp-common等核心源码系统讲解 Method 的定义与调用方式、错误处理约定、表单集成方案、数据加载场景以及 Method 从客户端模拟到服务端执行的完整生命周期。读完本文你将掌握从最简 Method到可测试的工程化 Method的完整演进路径并理解 Optimistic UI、randomSeed一致 ID 生成、Method 重试等底层机制是如何在源码中实现的。什么是 MethodMethods 是 Meteor 的远程过程调用RPC系统用于保存来自客户端的用户输入事件与数据。如果你熟悉 REST API 或 HTTP可以把 Method 想象成发往服务端的 POST 请求——但它针对现代 Web 应用做了大量优化提供了普通 HTTP 端点不具备的能力。后面会详细讨论这些收益。本质上Method 就是服务端的一个 API 端点你可以在服务端定义一个 Method同时在客户端定义它的副本stub然后用一些数据调用它写入数据库并在回调中拿到返回值。Meteor Methods 与 Meteor 的 pub/sub 和数据加载系统紧密集成从而支持 Optimistic UI乐观 UI——即在客户端模拟服务端操作让应用响应快于真实网络往返。注意本文中的 Method大写 M特指 Meteor 的 RPC 机制以区别于 JavaScript 中的类方法class method。在源码层面Method 的注册与调用由两个包承载客户端packages/ddp-client/common/livedata_connection.js其中LivedataConnection.prototype.methods()把方法注册到this._methodHandlers同名冲突会抛出A method named ... is already definedMeteor.call/Meteor.apply等调用入口也都在该文件中。服务端packages/ddp-server/livedata_server.js其中methods()把方法注册到self.server.method_handlersDDP 协议层的method消息处理器负责接收调用并执行。定义和调用 Methods基础 Method直接使用 Meteor 核心 API在简单应用中定义一个 Meteor Method 就像定义一个函数一样简单。以下示例使用simpl-schemanpm 包来校验参数Guide 多篇文章推荐使用它import SimpleSchema from simpl-schema; Meteor.methods({ todos.updateText({ todoId, newText }) { new SimpleSchema({ todoId: { type: String }, newText: { type: String } }).validate({ todoId, newText }); const todo Todos.findOne(todoId); if (!todo.editableBy(this.userId)) { throw new Meteor.Error(todos.updateText.unauthorized, Cannot edit todos in a private list that is not yours); } Todos.update(todoId, { $set: { text: newText } }); } });定义 Method 时需要注意方法体应放在客户端和服务端都能加载的公共代码中这样客户端才能运行 Method 模拟stub实现 Optimistic UI。如果 Method 内含机密逻辑请参考 安全指南的 Secret server code 一节 了解如何对客户端隐藏。方法内部的this是当前 Method 调用上下文DDPCommon.MethodInvocation实例见packages/ddp-common/method_invocation.js通过this.userId可以拿到当前登录用户 ID。从源码看DDPCommon.MethodInvocationpackages/ddp-common/method_invocation.js为每个调用维护了以下关键字段nameMethod 名称isSimulation是否为客户端模拟stub执行userId调用该 Method 的用户 ID未登录时为nullconnection服务端收到的连接对象服务端发起的调用为nullrandomSeed用于客户端/服务端一致 ID 生成的随机种子unblock()允许同一客户端的后续 Method 不必等待当前 Method 完成setUserId(userId)在 Method 内切换当前连接的用户且在调用unblock()之后禁止调用源码会抛出Cant call setUserId in a method after calling unblock。调用 Method使用Meteor.call即可在客户端和服务端调用上面定义的 MethodMeteor.call(todos.updateText, { todoId: 12345, newText: This is a todo item. }, (err, res) { if (err) { alert(err); } else { // success! } });调用语义如果 Method 抛出错误错误会出现在回调的第一个参数err中如果成功结果在第二个参数res中此时err为undefined。关于错误处理的更多细节见下文。需要强调的是只有在需要从客户端调用代码时才应该使用 Method。如果只是想模块化仅由服务端调用的代码请使用普通 JavaScript 函数而不是 Method。Meteor.call在packages/ddp-server/livedata_server.js中的实现本质上就是对this.apply(name, args, callback)的薄封装其异步版本callAsync返回 Promise同样位于该文件中。客户端侧对应的callAsync/applyAsync实现位于packages/ddp-client/common/livedata_connection.jsMeteor.callAsync会拒绝传入回调要求使用await或.then()获取结果。对应的 TypeScript 类型签名可在packages/meteor/meteor.d.ts中查看Meteor.methods、Meteor.call、Meteor.callAsync、Meteor.apply、Meteor.applyAsync以及MethodApplyOptions。进阶 Method 样板拆解验证与执行Meteor Methods 有许多不易察觉的特性复杂应用迟早会用到。这些特性是多年间以向后兼容的方式逐步加入的因此要完全解锁 Methods 的能力需要不少样板代码。一个理想的 Method 应该具备以下能力只运行校验代码不运行 Method 主体可覆盖 Method 以进行测试尤其是测试时可以用自定义用户 ID 调用 Method即 Discover Meteor 提出的两层 Method 模式通过 JS 模块引用 Method而不是使用魔法字符串拿到 Method 模拟stub的返回值以获取插入文档的 ID客户端校验失败时不再调用服务端 Method以节省服务端资源。下面是把这些能力逐一落地的完整样板export const updateText { name: todos.updateText, // 抽出校验逻辑使其可独立运行 (1) validate(args) { new SimpleSchema({ todoId: { type: String }, newText: { type: String } }).validate(args) }, // 抽出 Method 主体使其可独立调用 (3) run({ todoId, newText }) { const todo Todos.findOne(todoId); if (!todo.editableBy(this.userId)) { throw new Meteor.Error(todos.updateText.unauthorized, Cannot edit todos in a private list that is not yours); } Todos.update(todoId, { $set: { text: newText } }); }, // 通过引用 JS 对象来调用 Method (4) // 同时把 Meteor.apply 的选项固化在 Method 实现里 // 调用方无需在调用处重复指定。 call(args, callback) { const options { returnStubValue: true, // (5) throwStubExceptions: true // (6) } Meteor.apply(this.name, [args], options, callback); } }; // 真正把 Method 注册进 Meteor 的 DDP 系统 Meteor.methods({ [updateText.name]: function (args) { updateText.validate.call(this, args); updateText.run.call(this, args); } })这样调用 Method 就变成了调用普通 JS 函数import { updateText } from ./path/to/methods.js; // 调用 Method updateText.call({ todoId: 12345, newText: This is a todo item. }, (err, res) { if (err) { alert(err); } else { // success! } }); // 只调用校验 updateText.validate({ wrong: args}); // 测试中以自定义 userId 调用 Method updateText.run.call({ userId: abcd }, { todoId: 12345, newText: This is a todo item. });这种对象化 Method的开发方式能显著改善工作流可以分别处理 Method 的各个部分测试时无需触碰 Meteor 内部机制。代价是定义侧需要编写较多样板代码。其中returnStubValue与throwStubExceptions两个选项在客户端源码packages/ddp-client/common/livedata_connection.js的_apply()中有精确实现returnStubValue: true时Meteor.apply直接返回 stub 的返回值result options.returnStubValue ? stubReturnValue : undefined这样在客户端插入文档后可以立刻拿到新文档的_idthrowStubExceptions: true时如果 stub 抛出了异常会直接重新抛出并不再把 Method 发给服务端if (options.throwStubExceptions) { throw exception; }从而避免浪费一次注定失败的服务端调用。用 jam:method 简化进阶样板为减轻正确编写 Method 所需的样板代码可以使用jam:method这个 Atmosphere 包它替你完成了大部分工作。上面同一个 Method 用该包定义如下import { createMethod } from meteor/jam:method; export const updateText createMethod({ name: todos.updateText, schema: new SimpleSchema({ todoId: { type: String }, newText: { type: String } }), async run({ todoId, newText }) { const todo await Todos.findOneAsync(todoId); if (!todo.editableBy(this.userId)) { throw new Meteor.Error(todos.updateText.unauthorized, Cannot edit todos in a private list that is not yours); } Todos.updateAsync(todoId, { $set: { text: newText } }); } });调用方式与上面的进阶 Method 完全相同但定义侧显著更简洁。这种方式能让你一眼看清三个关键要素线上传输的 Method 名称name、期望的参数格式schema、以及可供 JS 引用的命名空间导出的对象。注意jam:method是第三方包不在当前仓库内本例中的findOneAsync/updateAsync对应 Meteor 3 的异步 Mongo API。jam:method默认会为Meteor.apply开启returnStubValue与throwStubExceptions它会阻止 stub 抛错时继续调用服务端实现。错误处理普通 JavaScript 函数通过抛出Error对象来表示错误。Meteor Method 抛错的方式几乎一样但多了一层复杂性错误对象有时要通过 WebSocket 传回客户端。因此 Meteor 引入了两种新的错误类型Meteor.Error和ValidationError。它们与普通 JSError适用于不同的场景。服务端内部错误使用普通Error当错误不需要上报给客户端、只属于服务端内部问题时抛出普通 JS 错误对象即可。这类错误会被服务端包装成完全不透明的内部服务错误传给客户端——客户端拿不到任何细节。从packages/ddp-server/livedata_server.js的wrapInternalException()可以看到确切机制普通异常没有isClientSafe标记会被转换成new Meteor.Error(500, Internal server error)并在服务端日志中打印原始堆栈只有带isClientSafe标记的错误才会原样传给客户端。此外如果异常带有sanitizedError属性且该属性isClientSafe则优先使用这个净化版错误。一般运行时错误使用Meteor.Error当服务端因为某个已知条件而无法完成用户期望的操作时应向客户端抛出描述性的Meteor.Error。例如在 Todos 示例应用中用它报告当前用户无权执行某操作或该操作在应用内不被允许如删除最后一个公开列表。Meteor.Error接受三个参数error、reason、details。error简短、唯一、机器可读的错误码字符串客户端据此理解发生了什么。建议以 Method 名作为前缀以方便国际化例如todos.updateText.unauthorized。reason面向开发者的简短错误描述应足以让同事据此调试。不要直接把reason展示给终端用户——否则你必须在服务端先做国际化而且 UI 开发者也不应该为了决定界面展示内容而关心 Method 的实现细节。details可选携带帮助客户端理解问题的额外数据。特别是可以与error字段组合向终端用户输出更有帮助的错误信息。在源码packages/meteor/errors.js中Meteor.Error通过Meteor.makeErrorType构造并设置了self.isClientSafe true这是 DDP 判断错误可否回传客户端的关键标记同时提供了clone()方法以保证经 EJSON 克隆后error/reason/details字段不丢失。注意部分内置函数如check出于历史原因会在error字段放一个数字。参数校验错误使用ValidationError当 Method 调用因参数类型错误而失败时建议抛出ValidationError。它的工作方式与Meteor.Error类似但它是自定义构造函数强制了一种标准的错误格式可被不同的表单和校验库读取。特别是如果 Method 是从表单调用的抛出ValidationError就能在表单的特定字段旁边展示友好的错误信息。ValidationError属于mdg:validation-error包不在当前仓库内其约定格式为err.error validation-error且err.details是一个形如[{ name, type, ... }]的数组每个元素对应一个字段的错误。处理错误调用 Method 时它抛出的任何错误都会出现在回调中。此时应判断错误类型并向用户展示合适的消息。以只处理未授权错误为例// 调用 Method updateText({ todoId: 12345, newText: This is a todo item. }, (err, res) { if (err) { if (err.error todos.updateText.unauthorized) { // 真实应用中不应使用 alert // 应该用优雅的 UI 展示错误并配合 i18n 库 // 根据错误码生成消息。 alert(You aren\t allowed to edit this todo item); } else { // 意外错误在 UI 中另行处理 } } else { // success! } });ValidationError的页面处理方式见下文从表单调用 Method一节。Method 模拟stub中的错误调用一个 Method 时它通常会执行两次一次在客户端模拟stub用于 Optimistic UI另一次在服务端执行真正的数据库写入。这意味着如果 Method 抛错很可能在客户端和服务端各失败一次。因此jam:method会开启Meteor.apply的throwStubExceptions选项在模拟阶段抛错时直接跳过服务端实现避免浪费服务端资源。这个行为适合注定失败的 Method但必须确保在服务端 Method 本可以成功的情况下stub 不要抛错例如客户端没加载 Method 模拟所需的数据。此时可以把仅依赖服务端环境的逻辑包在isSimulation判断里if (!this.isSimulation) { // 依赖服务端环境的逻辑写在这里 }this.isSimulation正是DDPCommon.MethodInvocation的字段packages/ddp-common/method_invocation.js在客户端 stub 中为true在服务端真实执行为false。从表单调用 MethodValidationError约定带来的最大价值就是打通 Method 与调用它的表单之间的集成。通常你的应用里UI 表单与 Method 是一一对应的。首先为业务逻辑定义一个 Method// 定义邮箱与金额校验用的正则表达式 const emailRegEx /^[\w-\.]([\w-]\.)[\w-]{2,4}$/g; const amountRegEx /^\d*\.(\d\d)?$/; // 这个 Method 内嵌了表单的校验要求。 // 把校验定义在 Method 里客户端与服务端就只需写一份校验逻辑。 export const insert createMethod({ name: Invoices.methods.insert, schema: new SimpleSchema({ email: { type: String, regEx: emailRegEx }, description: { type: String, min: 5 }, amount: { type: String, regEx: amountRegEx } }), run(newInvoice) { // 进入这里时可以确信 newInvoice 参数已通过校验。 if (!this.userId) { throw new Meteor.Error(Invoices.methods.insert.not-logged-in, Must be logged in to create an invoice.); } Invoices.insertAsync(newInvoice) } });出于安全考虑建议为email、amount这类字段自定义 regEx 表达式对 Meteor 相关的功能如文档 ID可以使用SimpleSchema.RegEx.Id表达式。更多正则用法可参考 simpl-schema 文档。接下来定义 HTML 表单使用 Blaze 模板template nameInvoices_newInvoice form classInvoices_newInvoice label foremailRecipient email/label input typeemail nameemail / {{#each error in errors email}} div classform-error{{error}}/div {{/each}} label fordescriptionItem description/label input typetext namedescription / {{#each error in errors description}} div classform-error{{error}}/div {{/each}} label foramountAmount owed/label input typetext nameamount / {{#each error in errors amount}} div classform-error{{error}}/div {{/each}} /form /template再写 JavaScript 来优雅地处理这个表单import { insert } from ../api/invoices/methods.js; Template.Invoices_newInvoice.onCreated(function() { this.errors new ReactiveDict(); }); Template.Invoices_newInvoice.helpers({ errors(fieldName) { return Template.instance().errors.get(fieldName); } }); Template.Invoices_newInvoice.events({ submit .Invoices_newInvoice(event, instance) { const data { email: event.target.email.value, description: event.target.description.value, amount: event.target.amount.value }; insert(data, (err, res) { if (err) { if (err.error validation-error) { // 初始化错误对象 const errors { email: [], description: [], amount: [] }; // 遍历 Method 返回的校验错误 err.details.forEach((fieldError) { // XXX i18n errors[fieldError.name].push(fieldError.type); }); // 更新 ReactiveDict错误会出现在 UI 上 instance.errors.set(errors); } } }); } });可以看到在表单里优雅地处理错误需要相当数量的样板代码但其中大部分都可以由一个现成的表单框架或你自己封装的通用组件来抽象掉。这里的核心约定是Method 的 schema 校验失败时抛出ValidationErrorerr.error validation-errorerr.details中的每一项包含字段名name与错误类型type表单据此把错误渲染到对应字段下方。用 Method 加载数据由于 Method 是通用的 RPC它也可以用来拉取数据而不用 publication。这种方案与 publication 相比各有优劣但 Guide 最终建议加载数据始终使用 publication。Method 拉取数据的适用场景是从服务端获取一个复杂计算结果且该结果不需要随服务端数据变化而自动更新。Method 方案最大的缺点是数据不会自动进入 MinimongoMeteor 的客户端数据缓存需要手动管理数据生命周期另一个缺点是数据库查询无法像 publication 游标那样在客户端之间共享——每个调用该 Method 的客户端都会独立执行一次包括其中的查询。用本地集合local collection存储和展示 Method 取回的数据集合是客户端存储数据的便捷方式。如果通过订阅之外的方式取数据可以手动放进一个集合。以下示例中我们有一个复杂的算法要为多名玩家计算一系列游戏的平均分。之所以不用 publication是因为我们想精确控制它的运行时机且不希望数据被自动缓存。首先创建一个本地集合——只存在于客户端、不对应服务端数据库集合的集合。创建方式参见 集合指南的 Local collections 一节// 在客户端代码中传入 null 即声明一个本地集合 ScoreAverages new Mongo.Collection(null);然后用 Method 拉取数据并写入该集合import { calculateAverages } from ../api/games/methods.js; function updateAverages() { // 清空结果缓存 ScoreAverages.remove({}); // 调用执行昂贵计算的 Method calculateAverages.call((err, res) { res.forEach((item) { ScoreAverages.insert(item); }); }); }之后就可以像使用普通 MongoDB 集合一样在 UI 组件中使用本地集合ScoreAverages的数据。区别在于它不会自动更新每次需要新结果时都要手动调用updateAverages。高级概念你可以照 Meteor 入门教程用 Method 开发应用但要把它用好尤其是用在生产环境中必须理解它的底层工作原理。框架替你做得多你反而更容易忽视背后发生了什么。Method 调用生命周期当一个 Method 被调用时按顺序依次发生以下事情1. 客户端执行 Method 模拟stub如果 Method 按规范定义在客户端与服务端公共代码中发起调用的客户端会先执行一次 Method 模拟。客户端进入一种特殊模式跟踪对客户端集合的所有改动以便稍后回滚。这一步完成后用户会立刻看到 UI 基于客户端数据库新内容更新但此时服务端还没收到任何数据。如果 Method 模拟抛出了异常默认情况下 Meteor 会忽略它并继续步骤 (2)。但如果你使用jam:method或给Meteor.apply传入throwStubExceptions选项模拟阶段的异常会阻止服务端 Method 继续执行。Method 模拟的返回值默认被丢弃除非调用时传入returnStubValue选项——此时返回值会交给调用方。jam:method默认开启该选项。客户端这一过程在packages/ddp-client/common/livedata_connection.js的apply()中实现先通过_stubCall()取出注册在_methodHandlers里的 stub 并以isSimulation: true的MethodInvocation上下文执行DDP._CurrentMethodInvocation.withValue(invocation, stubInvocation)再通过_saveOriginals()/_retrieveAndStoreOriginals()记录 stub 修改过的文档原值供后续回滚使用。2. 向服务端发送methodDDP 消息Meteor 客户端构造一条 DDP 消息发往服务端包含 Method 名称、参数以及一个自动生成的 Method ID代表本次具体调用。从源码看packages/ddp-client/common/livedata_connection.js的_apply()这条消息的形态是const message { msg: method, id: methodId, // 由 self._nextMethodId 生成 method: name, params: args };如果 stub 使用过随机数生成器消息中还会附带randomSeed见下文一致的 ID 生成。3. 服务端执行 Method服务端收到消息后会再次执行 Method 代码。客户端的版本只是稍后会被回滚的模拟这一次才是写入真实数据库的版本。在服务端执行真实逻辑至关重要因为服务端是可信环境安全关键代码可以确定地按预期运行。服务端入口在packages/ddp-server/livedata_server.js的method: async function (msg, unblock)处理器中先校验消息格式然后从self.server.method_handlers[msg.method]找到处理器找不到时返回new Meteor.Error(404, Method ... not found)构造isSimulation: false的MethodInvocation并在DDP._CurrentMethodInvocation.withValue(...)上下文中执行 handler。如果应用启用了ddp-rate-limiter包这里还会先做限流检查too-many-requests错误。此外若安装了audit-argument-checks包maybeAuditArgumentChecks()会校验 Method 内的所有参数是否都经过了check/Match检查。4. 返回值发送给客户端服务端 Method 执行完毕后向客户端发送一条携带第 2 步 Method ID 和返回值本身的result消息。客户端会先存储这个结果但暂时不调用 Method 回调。如果给Meteor.apply传了onResultReceived选项此时会触发该回调。5. 受 Method 影响的 DDP publications 被更新如果页面上有任何 publication 受该 Method 数据库写入的影响服务端会把相应的数据更新发送给客户端。注意客户端数据系统在这一步不会把更新暴露给 UI。6. 发送updated消息客户端用服务端结果替换本地数据触发 Method 回调相关数据更新发送完毕后服务端发出 Method 生命周期的最后一条消息——携带 Method ID 的 DDPupdated消息。客户端回滚第 1 步 Method 模拟对客户端数据做的改动替换为第 5 步来自服务端的真实改动。最后传给Meteor.call的回调才真正以第 4 步的返回值触发。回调必须等到客户端数据同步完成这样你的 Method 回调才能假定客户端状态已反映 Method 内的所有改动。服务端侧updated消息的发送时机由 WriteFence 机制控制packages/ddp-server/livedata_server.js服务端为每个 Method 调用创建一个_WriteFencefence.onAllCommitted()在所有观察者含订阅对 Method 写入做出反应后发送{msg: updated, methods: [msg.id]}。错误场景以上流程没有覆盖服务端 Method 抛错的情况。此时没有返回值客户端收到的是错误。Method 回调会立刻以错误作为第一个参数被触发。错误处理细节见上文。Methods 相比 REST 的优势Guide 认为对构建现代应用而言Method 是比基于 HTTP 的 REST 端点更好的原语。下面列出用 Method 就能免费获得、而用 HTTP 需要自己操心的事情。这一节的目的不是论证 REST 不好而是提醒你在 Meteor 应用里这些事不需要你亲自处理。同步风格 API但非阻塞注意上面的示例 Method与 MongoDB 交互时没写任何回调但 Method 依然具备人们所熟知 Node.js 回调风格代码的非阻塞特性。Meteor 借助协程库 Fibers让你能用返回值与异常写代码避免大量嵌套回调。注Meteor 3 已转向async/await即上文createMethod示例中的async runfindOneAsync/updateAsync。有序执行与返回访问 REST API 时可能连续发出两个请求但结果乱序返回。Meteor 的底层机制保证 Method 不会出现这种情况来自同一客户端的多个 Method 调用Meteor 会逐个执行完毕再开始下一个。如果某个特别耗时的 Method 需要让出执行权可以使用this.unblock()允许下一个 Method 在当前 Method 仍在进行时开始执行。此外由于 Meteor 基于 WebSocket 而非 HTTP所有 Method 调用与结果都保证按发送顺序到达。也可以给Meteor.apply传wait: true选项等待此前所有 Method 返回后再发送该 Method并且在该 Method 返回前不发送任何后续 Method。unblock机制在服务端packages/ddp-server/livedata_server.js的method处理器中通过unblock回调实现并随MethodInvocation暴露为this.unblock()而wait选项在客户端MethodInvoker中维护排队顺序packages/ddp-client/common/livedata_connection.js。变更追踪支撑 Optimistic UI当 Method 模拟与服务端执行运行时Meteor 会追踪它们对数据库产生的所有变更。这正是 Meteor 数据系统能够回滚 Method 模拟的改动、并用服务端真实写入替换它们的前提。没有这种自动的数据库追踪要实现正确的 Optimistic UI 几乎不可能。在 Method 中调用另一个 Method有时你需要在 Method 里调用另一个 Method——比如已有某个功能实现想加一个自动填充部分参数的包装。这是完全合理的模式Meteor 还为此做了两件好事在客户端 Method 模拟内部调用另一个 Method 不会额外向服务端发请求——假设服务端实现会执行它。但它会运行被调 Method 的模拟使客户端的模拟与服务端将要发生的事尽可能一致。在服务端 Method 执行内部调用另一个 Method 会如同被同一客户端调用那样运行。也就是说userId、connection等上下文会沿用最初那次 Method 调用的值。从客户端源码可以验证这一点_stubCall()中如果检测到当前已在模拟中alreadyInSimulation就不会发起 RPC而是直接返回 stub 的执行结果。一致的 ID 生成与 Optimistic UI当你在客户端 Method 模拟中向 Minimongo 插入文档时每个文档的_id是一个随机字符串。服务端执行同一 Method 时 ID 会重新生成。如果实现得很粗糙服务端生成的 ID 可能与客户端不同导致 Method 模拟被回滚、替换为服务端数据时出现恼人的闪烁和重渲染。但 Meteor 不会这样每次 Method 调用都会与发起它的客户端共享一个随机种子randomSeed因此客户端与服务端 Method 生成的任何 ID 都保证相同。这意味着你可以放心地在 Method 发送到服务端期间使用客户端生成的 ID 做事比如先创建文档、再立即重定向到包含该新文档 ID 的 URL并确信 Method 完成时 ID 依然一致。底层机制在packages/ddp-common/random_stream.js中实现客户端在 stub 需要随机数时通过DDPCommon.makeRpcSeed(enclosing, methodName)生成randomSeed随methodDDP 消息发送给服务端见livedata_connection.js的_apply()if (randomSeed.value ! null) { message.randomSeed randomSeed.value; }服务端用DDPCommon.RandomStream以该 seed 作为种子创建可复现的伪随机序列Alea 算法。两端从同一个 seed 出发沿着相同的调用路径消费随机数产出的 ID 自然一致。Method 重试与幂等性如果从客户端调用 Method 后、收到结果前用户断网Meteor 会假定该 Method 没有真正执行。连接恢复后该 Method 调用会被重新发送。这意味着某些情况下 Method 可能被发送不止一次。这种情况很少见但如果额外的调用可能带来负面后果就值得花力气保证 Method 是幂等的——即多次调用不会导致数据库产生额外变化。好消息是许多 Method 操作天然幂等插入重复执行会因 ID 冲突而抛错对集合的remove第二次执行不会有任何效果$set这类大多数更新操作符重复运行结果相同。真正需要担心执行两次的地方是会叠加的 MongoDB 更新操作符如$inc、$push以及对外部 API 的调用。与 allow/deny 的历史对比Meteor 核心 API 提供了一套 Method 之外的、从客户端操作数据的替代方案不显式定义带参数的 Method而是直接从客户端调用insert、update、remove并用allow和deny规则来约束安全性。Guide 在此采取明确立场应避免该特性改用 Method。关于 allow/deny 的问题参见安全指南的 Avoid allow/deny 一节。历史上对 Meteor Methods 与 allow/deny 存在一些误解例如认为用 Method 更难实现 Optimistic UI。实际上客户端侧的insert、update、remove功能恰恰是构建在 Method 之上的所以 Method 严格更强大。只要按照上文生命周期所述把 Method 代码同时定义在客户端和服务端你就能获得开箱即用的优质 Optimistic UI。源码速查以下是本文涉及的核心实现与文档路径便于进一步深入客户端 Method 注册与调用packages/ddp-client/common/livedata_connection.jsmethods()、call()、callAsync()、apply()、applyAsync()、_apply()、_stubCall()服务端 Method 注册与 DDP 处理packages/ddp-server/livedata_server.jsmethods()、method消息处理器、wrapInternalException()、maybeAuditArgumentChecks()Method 调用上下文packages/ddp-common/method_invocation.jsDDPCommon.MethodInvocationname、isSimulation、userId、connection、unblock()、setUserId()错误类型packages/meteor/errors.jsMeteor.Error与Meteor.makeErrorType一致 ID 的随机种子机制packages/ddp-common/random_stream.jsRandomStream与makeRpcSeedTypeScript 类型签名packages/meteor/meteor.d.tsMeteor.methods、Meteor.call、Meteor.apply、MethodApplyOptions等相关文档Meteor 安全指南、Meteor 集合指南【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考