guke
3663b5b11c
fix(compare): 「已下单」从店级改按 trace_id 精确对齐 (#224)
背景 / 问题
比价记录页「已下单」tab 混进大量本不该出现的记录:同一家店比价多次、只下过一单,却把这家店的每一条比价(含失败灰卡、没真正下单的成功比价)都塞进「已下单」。
根因
「已下单」原先是店级判定——下单上报(POST /order/report)不带 trace_id、savings_record 也没有指向具体某次比价的键,服务端只能用 savings_record.shop_name == comparison_record.store_name 做店名匹配 → 同店所有比价一并命中。属"先有省钱记账、后蹭已下单"的历史债(见 docs/database/savings_record.md 的 Join Key 注释)。
方案
把 trace_id 从比价会话打通到下单上报,「已下单」改为按 trace_id 精确对齐到那一条比价:
下单上报带上本次比价 trace_id → 落 savings_record.trace_id;
「已下单」过滤/打标(C 端 + admin)统一改成 savings_record.trace_id == comparison_record.trace_id(comparison 侧 trace_id 本就是 NOT NULL UNIQUE);
不做店名回退、不回填历史:没有 trace_id 的订单(历史/老客户端)对齐不上任何记录 → 不进「已下单」。
行为变化(评审必看)
上线后「已下单」只反映"更新版客户端下的新单":历史订单 + 老客户端过渡期订单没 trace_id,不再进「已下单」,随客户端铺量回血。
失败/终止比价不再进「已下单」(本就没真正下单;trace_id 只会指向有价可点的成功比价)。
后台看板「下单数」会掉:历史 savings_record 全是 trace_id=NULL,period_ordered_count 上线当天明显下跌——是口径变化、非回归,请知会看数据的同学。
必须与客户端一起上:只上服务端 → 订单永远不带 trace_id → 任何订单都对不上 → 「已下单」永远空。见关联 android PR。
---------
Co-authored-by: guke <guke@autohome.com.cn>
Reviewed-on: #224
2026-08-07 18:16:55 +08:00
..
2026-08-07 18:16:55 +08:00
2026-08-01 23:09:21 +08:00
2026-08-04 18:49:30 +08:00
2026-06-04 03:02:41 +08:00
2026-06-04 03:02:41 +08:00
2026-07-22 17:22:09 +08:00
2026-07-31 17:08:06 +08:00
2026-07-31 17:08:06 +08:00
2026-06-04 03:02:41 +08:00