n8n测试数据构造：静态Mock数据与复杂对象构建（附：时间格式标准化解析）

作者： Dr.n8n 更新时间：2025-12-18 18:00:41 分类：n8n教程

为什么你的 n8n 工作流总在“测试数据”上栽跟头？

你是否也遇到过这种情况：明明流程逻辑写得滴水不漏，Webhook 接口也能正常触发，可一到“解析数据”环节就报错——“Cannot read property 'user_id' of undefined”。别慌，这大概率不是你的节点配置错了，而是测试数据没构造好。就像盖楼前没打好地基，再漂亮的架构也会塌。

我在帮一家跨境电商客户搭建订单自动分发系统时，就因为测试阶段用了错误的时间格式，导致正式上线后所有订单都被判定为“过期”。老板差点把我当“过期员工”给开了。

静态 Mock 数据：不是“假数据”，而是“可控的沙盒”

很多新手把 Mock 数据当成“随便填点东西应付测试”，这是大错特错。Mock 数据的本质是可控的输入沙盒，它让你在不依赖真实 API、数据库或用户行为的情况下，验证整个工作流的健壮性。

举个生活化的例子：测试消防系统时，你不会真放一把火，而是用烟雾模拟器——这就是 Mock。在 n8n 中，你可以用 Set 节点或 Function 节点手动生成结构清晰的 JSON 对象：

{
  "user": {
    "id": 1001,
    "name": "张三",
    "email": "zhangsan@example.com"
  },
  "order": {
    "id": "ORD-20240520-001",
    "amount": 299.99,
    "created_at": "2024-05-20T14:30:00Z"
  }
}

关键点在于：字段名、嵌套层级、数据类型必须与真实生产环境一致。否则，你测了个寂寞。

复杂对象构建：像搭乐高一样组合数据结构

现实中的业务数据往往不是扁平的，而是多层嵌套的对象或数组。比如一个电商订单可能包含用户信息、商品列表、收货地址、优惠券等多个子对象。这时候，你需要用 n8n 的 Function 节点编写 JavaScript 来动态构建。

想象你在拼乐高：每个积木块（基础数据）都有标准接口（属性名和类型），只要按说明书（数据结构文档）拼起来，就能组成复杂的机器人（完整对象）。

// 在 Function 节点中构建复杂订单对象
return {
  json: {
    order_id: $input.item.json.order_id || 'TEST-001',
    customer: {
      name: '李四',
      phone: '+8613800138000',
      address: {
        province: '广东省',
        city: '深圳市',
        detail: '南山区科技园腾讯大厦'
      }
    },
    items: [
      { sku: 'SKU-APPLE-IPHONE15', qty: 1, price: 5999 },
      { sku: 'SKU-AIRPODS-PRO2', qty: 1, price: 1899 }
    ],
    total: 7898,
    timestamp: new Date().toISOString() // 注意！这里埋了个坑，下文详解
  }
};

时间格式标准化：ISO 8601 是你的唯一真理

时间处理是自动化流程中最容易“阴沟里翻船”的地方。不同系统、不同地区、不同语言对时间的表示千奇百怪：有人用 2024/05/20 14:30，有人用 May 20, 2024 2:30 PM，还有人直接塞个时间戳 1716201000。

在 n8n 中，请无条件使用 ISO 8601 格式：YYYY-MM-DDTHH:mm:ss.sssZ，例如 2024-05-20T14:30:00.000Z。这是国际标准，也是绝大多数现代 API 和数据库的默认格式。

错误格式	正确格式	生成方式
new Date().toString()	2024-05-20T14:30:00.000Z	`new Date().toISOString()`
"2024-05-20 14:30:00"	2024-05-20T14:30:00.000Z	`new Date("2024-05-20 14:30:00").toISOString()`

如果你收到非标准时间字符串，可以用 Moment.js 或原生 Date.parse() 先转成 Date 对象，再调用 .toISOString() 输出。别偷懒，一步错步步错。