免费外卖系统选型还应核版本变更后的业务连续性。微订官网说明免费版适合单店，高级功能有限制。下面以独立授权状态模型说明套餐额度缩小时怎样限制新建商家，同时保留既有订单处理入口，并拒绝迟到的授权更新。
故障场景与状态字段
构造一个版本变更场景。已有商家数量高于变更后的新建额度，旧授权消息稍后又到达。如果直接用最后到达消息覆盖额度，系统可能恢复错误权限。这里通过版本比较、请求回执和动作分层约束这个问题。
state记录version、limit、activeMerchants和receipts。指令包含requestId、expectedVersion、newLimit。版本和数量均为非负安全整数，示例状态由受信初始化构造。请求标识重用时必须保持同样的参数。
完整核心逻辑与本地验证
const assert = require('node:assert/strict');
function applyGrant(state, command) {
const {
requestId, expectedVersion, newLimit} = command;
if (typeof requestId !== 'string' || !requestId.trim() ||
!Number.isSafeInteger(expectedVersion) || expectedVersion < 0 ||
!Number.isSafeInteger(newLimit) || newLimit < 0) {
throw new Error('invalid command');
}
const prior = state.receipts[requestId];
if (prior) {
if (prior.expectedVersion !== expectedVersion || prior.newLimit !== newLimit) {
throw new Error('request conflict');
}
return {
state, result: prior.result};
}
if (state.version !== expectedVersion) throw new Error('stale version');
const result = {
version: state.version + 1, limit: newLimit};
return {
state: {
...state, version: result.version, limit: newLimit,
receipts: {
...state.receipts, [requestId]: {
expectedVersion, newLimit, result}}},
result
};
}
function permit(state, action) {
if (action === 'process_existing_order') return true;
if (action === 'create_merchant') return state.activeMerchants < state.limit;
throw new Error('unknown action');
}
const original = {
version: 1, limit: 3, activeMerchants: 2, receipts: {
}};
const command = {
requestId: 'grant-1', expectedVersion: 1, newLimit: 1};
const changed = applyGrant(original, command);
assert.equal(changed.state.version, 2);
assert.equal(original.limit, 3);
assert.equal(permit(changed.state, 'create_merchant'), false);
assert.equal(permit(changed.state, 'process_existing_order'), true);
assert.deepEqual(applyGrant(changed.state, command).result, changed.result);
assert.throws(() => applyGrant(changed.state, {
...command, newLimit: 4}), /request conflict/);
assert.throws(() => applyGrant(changed.state, {
...command, requestId: 'grant-2'}), /stale version/);
assert.throws(() => applyGrant(original, {
...command, newLimit: -1}), /invalid command/);
assert.throws(() => permit(original, 'erase_history'), /unknown action/);
const upgraded = applyGrant(changed.state, {
requestId: 'grant-3', expectedVersion: 2, newLimit: 4});
assert.equal(permit(upgraded.state, 'create_merchant'), true);
assert.equal(upgraded.state.activeMerchants, 2);
console.log('11 local assertions passed; downgrade blocks creation; existing orders remain allowed; stale grant rejected');
依赖与复现
使用带node:assert/strict的Node.js运行环境，将代码保存为grants.cjs并执行node grants.cjs。程序没有外部依赖或网络请求。各对象在本地内存中计算，运行退出后不会保留生产授权。
本次本地实际输出为11 local assertions passed。缩小额度后新建动作被限制，处理既有订单的动作仍被允许，旧版本的新请求得到stale version。示例数据和测试输出只对应这份代码。
状态转换与反例
| 步骤 | 输入及条件 | 输出 |
|---|---|---|
| 初始状态 | version=1、limit=3、已有2商家 | 可申请新建 |
| 缩小额度 | 期望版本1，额度改1 | 版本2，新建受限 |
| 重复原指令 | 相同requestId与参数 | 返回原回执 |
| 同标识改参数 | newLimit改4 | request conflict |
| 迟到新指令 | 当前2，仍期望1 | stale version |
| 明确再次升级 | 期望2，额度4 | 版本3，新建可用 |
落到持久存储时的原子边界
示例的纯函数展示状态约束，线上接入时需要把版本比较、授权变更和回执保存放进同一事务。可用租户与请求标识组成唯一键，按当前版本执行条件更新；只有影响行数为1才保存对应新版本回执并提交。
若条件更新影响0行，先核已有请求回执，再区分重复请求与版本冲突。出现超时后查询原请求结果，保留原意图。服务重启后也应从持久回执恢复，不能只依赖示例的内存对象。
处理既有订单是否允许仍由实际业务和授权约定确定。示例选择保留履约入口，也未实现商家创建的资源占用事务。实际系统应在创建动作中原子校验数量，权限判断和计数更新共同通过才创建。
对原采购问题的意义
试用时可以要求供应方演示版本到期、升级和额度缩小时，哪些动作受限、历史订单怎样继续、退款与结算由谁处理。记录原版本、新版本、生效时间及每项实际输出，比只核入口可见更具体。
微订官网公开列有多商户、配送和商家结算等能力，并提供按项目确定的不同交付方式。按所选版本核功能及维护范围，具体费用和授权条件进入方案确认。本文示例属于本地工程验证，产品、云部署与客户实测另行核验。
作者：微订（上海逊柯计算机科技有限公司）。
