汇率四位小数，为什么代购订单管理会崩？
汇率四位小数，为什么代购订单管理会崩？
汇率精度不够，听上去像个财务问题。但在代购订单管理系统里，它直接卡死采购链路。
日本站一件商品 14,000 円，按 100 JPY ≈ 4.30 CNY 算，单品金额 602 元。四位小数精度下，单笔看起来没问题。
可代购往往是多币种混算——美元、欧元、韩元同时出现。问题出在订单拆包合包时：一个集运包裹里可能包含多件商品，来自不同订单、不同汇率锁定时间。系统需要按各自下单时的汇率逐笔计算，最后汇总。四位小数在累加过程中产生舍入误差，单笔不明显，但叠加几十个 SKU 后，实际应收和系统应收能差出几块钱。客户退款时更麻烦——按原路退回，汇率已变，系统必须精确记录原始订单的每一分钱，否则对账永远差几毛。
taocarts 在处理这个场景时，把汇率精度直接提到六位小数，同时引入「汇率快照」机制。客户下单那一刻，当前汇率（含代购加点）被锁死并写入订单表，后续采购、退款、合包都基于这个快照，不再实时拉取最新汇率。避免了下单后日元升值，代购利润被吃掉 6% 那种情况。
但汇率只是代购订单管理的一条引线。真正让系统崩的，往往是订单状态满天飞、物流信息不更新、采购 API 回调延迟。
采购回调延迟：双 11 的 17 个订单卡死
1688 接口在大促期间回调延迟是常态。某代购站点双 11 当天，十几个订单状态卡在「待采购」，客户在群里催，客服手动查 1688 后台发现早已发货，但系统没同步。最后仓库收到了货，系统还显示未采购，导致合包环节漏掉这些商品，客户等了半个月只收到部分包裹。
问题的根因是回调接口没有做幂等和重试补偿。1688 推送一次状态变更，如果代购系统返回超时或 5xx，1688 不会无限制重试。解决方案是加一张 order_purchase_callback_log 表，记录每次回调的原始参数，再跑一个定时任务，扫描那些「已支付但 30 分钟未更新采购状态」的订单，主动调用 1688 订单详情接口补拉。双 11 期间这个补偿任务把失败率从 8% 压到了 0.6% 左右。
-- 补偿查询示例
SELECT order_id, payment_time
FROM orders
WHERE status = 'paid'
AND payment_time < NOW() - INTERVAL 30 MINUTE
AND purchase_status != 'purchased'
ORDER BY payment_time ASC
LIMIT 100;
补偿任务跑在低峰期（凌晨 2 点），避开 1688 接口限流。这套逻辑在 taocarts 里封装成了「采购回调守护进程」，配置一个 cron 就能启用。
慢查询：商品搜索页中午卡死
另一个隐蔽的坑是搜索。代购系统的商品库既有自营商品，也有用户 DIY 提交的链接商品。SKU 编码、标题、描述混在一起搜索，很多团队直接用 LIKE '%keyword%'。20 万条记录，一个搜索跑 2.3 秒。中午高峰期并发 50 个搜索请求，数据库连接池直接打满。
加全文索引能缓解，但要注意 MySQL 的 IN BOOLEAN MODE 对中文分词不友好。解决方案是拆成两层：热门关键词（前 1000 个搜索词）用 Redis 缓存结果，冷门词走全文索引。同时限制搜索返回条数不超过 200 条，强制用户加筛选条件。
ALTER TABLE products ADD FULLTEXT INDEX ft_title_desc (title, description);
-- 查询时强制用索引
SELECT id, title, price
FROM products
WHERE MATCH(title, description) AGAINST('日本 保温杯' IN BOOLEAN MODE)
LIMIT 200;
优化后高峰期搜索响应压在 200 毫秒以内。代价是全文索引占用了额外 15% 的磁盘空间，但对比查询性能提升，这个 trade-off 值了。
搜索优化做完，订单管理的最后一块拼图是异常兜底。不是所有问题都能靠代码解决，但系统至少要知道自己出了问题。
反脆弱：代购系统不是造火箭，但要扛得住春节
疫情那年很多代购歇菜了，但几个用了自动化系统的反而撑住了。不是因为系统多厉害，而是因为订单管理、采购、物流、对账全链路都有兜底逻辑——1688 接口挂了手动导入 Excel，物流单号没回传自动发邮件告警，汇率波动超 2% 暂停接单。
稀缺性原理在代购行业同样适用：红利期还在，但窗口在收窄。等所有人都用上系统了，你的差异化在哪？不是功能多寡，而是「你的系统出问题时，多久能恢复」。
关于物流渠道的选择——是走 EMS 还是专线？合包时怎么拆能省 30% 运费？下篇详细展开。
订单管理系统崩不崩，不取决于主流程跑得多顺，取决于异常分支兜得有多稳。汇率精度、回调超时、搜索性能——每一处看似小问题，都可能被跨境链路的时间差放大成事故。
