商户对数据归属与可迁移性的要求越来越高。看店通支持订单、会员、商品等数据的批量导出与迁移校验，本文说明导出方式、字段范围、异步任务与切换到其他系统时的清单建议。
一、导出渠道
| 渠道 | 适用体量 | 产出格式 | 限制 |
|---|---|---|---|
| 管理后台手动导出 | 10 万行以内 | CSV / Excel | 单次筛选范围不超过 90 天，需人工操作 |
| OpenAPI 异步导出任务 | 百万行级 | CSV（可 gzip） | 同一 AppId 并发任务数上限 3 个 |
| 数据库只读副本 | 不限 | 原始表 | 仅私有化部署客户，需合同约定与安全评估 |
选型建议很简单：一次性的运营取数走后台；需要定期跑的对账、报表走 OpenAPI 异步任务；只有自建数仓、要做全量入仓的场景才申请只读副本。不要用列表接口翻页硬拉全量数据，那既慢又会挤占实时交易的数据库资源，超过 10 万行时几乎一定会触发限流。
二、常见数据集
| 数据集 | type 取值 |
主要字段 | 注意事项 |
|---|---|---|---|
| 订单 | order |
order_no、status、pay_amount_fen、商品行、收货地址 |
含个人信息，必须加密传输并限定可下载人员 |
| 会员 | member |
member_id、level、points、registered_at |
手机号默认脱敏，需明文须单独申请并留审批记录 |
| 商品 | product |
sku_id、barcode、price_fen、stock_qty |
建议与 ERP 主数据映射表一并导出，便于核对 |
| 优惠券 | coupon |
批次号、领取记录、核销记录 | 未过期券能否迁移取决于目标系统是否支持同类规则 |
| 售后单 | aftersale |
aftersale_no、order_no、status、退款金额 |
需与订单数据同批次导出，否则对不上账 |
字段命名与 OpenAPI 完全一致，统一 snake_case；时间字段为 ISO 8601 带时区格式，金额字段以「分」为单位的整数。导入目标系统前请先确认对方的金额单位，把「分」当成「元」是迁移中最常见也最致命的错误。
三、异步导出流程
异步导出是「创建任务 → 查询进度 → 下载文件」三步，全程遵循API 鉴权说明中的通用约定。第一步创建任务：
POST /v1/exports HTTP/1.1
Host: api.kandiantong.com
Authorization: Bearer your_access_token
Content-Type: application/json
Idempotency-Key: export-order-20260901-20260930
{
"type": "order",
"start_time": "2026-09-01T00:00:00+08:00",
"end_time": "2026-09-30T23:59:59+08:00",
"format": "csv",
"compress": "gzip"
}创建成功返回 HTTP 201 与任务 ID：
{
"code": 0,
"message": "success",
"request_id": "req_2b8e4d6f1a03",
"data": {
"job_id": "exp_20260930_0001",
"status": "pending",
"created_at": "2026-09-30T01:05:00+08:00"
}
}
第二步查询进度，用 GET /v1/exports/{job_id}。status 的取值依次为 pending、running、succeeded、failed。轮询间隔建议 30
秒起步并逐步放大，不要每秒轮询。更省事的做法是订阅 export.completed 事件，由我们主动通知，配置方式见事件回调 Webhook。
第三步下载。任务完成后响应中会带一个临时签名下载地址：
{
"code": 0,
"message": "success",
"request_id": "req_4f7a2c9e8b15",
"data": {
"job_id": "exp_20260930_0001",
"status": "succeeded",
"row_count": 128640,
"file_size_bytes": 20447232,
"sha256": "your_file_checksum",
"download_url": "https://export.kandiantong.com/...",
"expires_at": "2026-10-01T01:20:00+08:00"
}
}
下载地址有效期 24 小时，过期后需要重新查询任务获取新地址（任务本身不必重跑）。拉取完成后务必做两项校验：一是比对
sha256 确认文件完整；二是比对 row_count 与后台报表的同口径数字，行数对不上说明时间范围或时区理解有偏差，最常见的原因是把 +08:00 当成了 UTC。
四、迁移清单
更换系统是一次性动作，出错代价高，建议按下面的顺序推进，每一步都留书面确认：
- 切换前两周：冻结优惠券发放与长周期营销活动，避免出现「旧系统发的券新系统认不了」。
- 切换前一周：完成最后一轮完整对账（订单数、金额、库存、券核销四项），把差异清零或形成书面说明。
- 切换前一天：导出全量数据并在目标系统做一次试导入，验证字段映射与编码，不要等到切换当天才第一次试。
- 切换窗口内：停止写入，导出最后一段增量，完成导入后再开放。窗口时间提前在小程序公告与客服话术中同步给用户。
- 切换后三个月：旧系统保留只读状态，用于历史订单查询与纠纷举证，不要立刻销毁。
有一项必须提前评估：会员密码通常以不可逆哈希存储，无法明文迁移到目标系统。可选方案是目标系统兼容原哈希算法（最省事，但受限于对方支持情况），或者引导用户通过短信验证码重新激活账号（体验有损但最稳妥）。这件事需要产品与运营一起定，不是技术单方面能决定的。
五、合规要求
所有导出操作都会记入审计日志，包含操作人、时间、数据范围与行数，日志保留 180 天。这不是形式主义——发生数据泄露时，审计日志是界定责任范围的唯一依据。
三条红线请务必遵守：导出文件不得存放在公网网盘或个人云盘；含个人信息的文件在传输和落盘时必须加密，交接用密码保护的压缩包而不是明文附件；导出文件用完即删，不要长期留在个人电脑上。涉及跨境传输、委托处理、用户行使删除权等场景，请先阅读个人信息合规再动手。
六、性能与排错
导出任务与实时交易共享底层资源，请尽量安排在凌晨 1 点到 6 点执行。大促当天和次日不要跑全量导出，那时数据库压力最大。跨度超过 90 天的范围请拆成多个窄时间片分批导出，单任务处理的数据量越小，失败后重跑的代价越低。
几个常见问题：任务长时间停在 running，通常是时间范围过大，建议取消后拆片重建；返回 failed 且 error_code 为 range_too_large，同样是拆片；下载到的 CSV 用 Excel
打开中文乱码，是因为文件是无 BOM 的 UTF-8，请在创建任务时指定 "bom": true 或改用文本编辑器打开。调用导出接口建议使用只开通了 order:read、member:read 等只读 scope 的独立
AppId，这样即使凭证泄露也无法改动业务数据。
