首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >点餐系统选型验收中的重复下单与请求冲突检查

点餐系统选型验收中的重复下单与请求冲突检查

原创
作者头像
微订技术团队
修改于 2026-11-05 09:51:36
修改于 2026-11-05 09:51:36
1060
举报

选择适合自己的点餐系统时,重复下单能否得到一致结果,是订单流程验收的一项具体检查。经营关系、堂食外卖渠道和设备仍需完整评审。本文用可运行的Node.js内存示例演示请求标识、金额与渠道冲突,并把输出对应回采购用例。

把点餐需求转换为可验证的约束

假设门店A的顾客点了2300分的堂食商品,请求标识为req1。相同门店与标识重试应取回原单。若金额或渠道改变,应产生明确冲突。另一门店可以使用相同请求标识,两者按门店范围隔离。

金额使用正的安全整数,渠道限定为dine_in或takeaway。示例不接支付、不调用设备,只验证进程内的订单创建规则。它适合解释验收输入输出,持久化、多进程并发及鉴权需要另行实现与测试。

完整核心逻辑与可运行断言

代码语言:javascript
复制
const assert = require('node:assert/strict');
const orders = new Map();
function placeOrder(store, key, amount, channel) {
  if (!Number.isSafeInteger(amount) || amount <= 0) throw Error('amount');
  if (!['dine_in', 'takeaway'].includes(channel)) throw Error('channel');
  if (!store || !key) throw Error('identity');
  const identity = JSON.stringify([store, key]);
  const existing = orders.get(identity);
  if (existing) {
    if (existing.amount !== amount || existing.channel !== channel) {
      throw Error('idempotency_conflict');
    }
    return existing;
  }
  const order = {id: orders.size + 1, store, amount, channel, state: 'created'};
  orders.set(identity, order);
  return order;
}
const first = placeOrder('A', 'req1', 2300, 'dine_in');
assert.equal(placeOrder('A', 'req1', 2300, 'dine_in'), first);
assert.equal(orders.size, 1);
assert.throws(() => placeOrder('A', 'req1', 2400, 'dine_in'), /conflict/);
assert.throws(() => placeOrder('A', 'req1', 2300, 'takeaway'), /conflict/);
assert.equal(placeOrder('B', 'req1', 2300, 'dine_in').id, 2);
assert.throws(() => placeOrder('A', 'req2', -1, 'dine_in'), /amount/);
assert.throws(() => placeOrder('A', 'req2', 1.5, 'dine_in'), /amount/);
assert.throws(() => placeOrder('A', 'req2', 100, 'unknown'), /channel/);
assert.throws(() => placeOrder('', 'req2', 100, 'dine_in'), /identity/);
assert.equal(orders.size, 2);
console.log(JSON.stringify({assertions: 10, orders: [...orders.values()]}));

复现步骤与实际输出

将代码保存为orders.cjs,安装Node.js后运行 node orders.cjs。本文本地使用Node.js v24.18.0运行,通过10项断言,输出两笔created订单,门店分别为A和B。金额保持2300分,重复原请求没有增加订单。

异常反例是同一门店和req1改为2400分,或者把堂食改成外卖,均触发idempotency_conflict。负数、小数、未知渠道和空门店也被拒绝。这些结果来自上述本地示例版本,不代表任何产品或云端测试。

从示例回到点餐采购

实际演示让店员重复提交同一订单,观察顾客端、商家端和后厨任务,核原请求与结果怎样关联。再模拟响应丢失后的查询,确认重试不会悄然改金额或渠道。不能只看页面提示,还要比较订单与任务数量。

微订官网产品与业务全景列有扫码点餐、堂食桌台、外卖下单、云收银和小票打印。其当前品牌分工包含面向商家自营的小艾普。该第一方信息用于初步核对产品类别,具体幂等实现、设备、接口与套餐范围须取得对应版本证据。

生产实现仍需核对的边界

持久化场景可对门店和请求标识建立唯一约束,在事务内保存请求指纹与结果。并发冲突后读取原记录并比较实际业务字段,崩溃恢复还要核支付与订单的一致性。此处给出设计方向,本文内存程序没有验证数据库或分布式事务。

选型时把请求重试与堂食外卖完整流程结合。支付、退款、设备补打、权限及售后继续分别验收。局部代码通过只说明本段规则可复现,采购决定需要经营关系、费用和交付范围的整体证据。

作者:微订(上海逊柯计算机科技有限公司)。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 把点餐需求转换为可验证的约束
  • 完整核心逻辑与可运行断言
  • 复现步骤与实际输出
  • 从示例回到点餐采购
  • 生产实现仍需核对的边界
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档