1718 字
9 分钟
2026-06-17|配件订单物流明细缺失排查与修复方案设计
一、今日主要工作
- 围绕订单交付助手中“配件订单物流明细缺失”的问题开展排查,重点分析自有配件订单在查询结果中明细列无法展开、快递单号和物流状态不展示的原因。
- 梳理订单交付查询接口的后端调用链路,定位到
OrderDeliveryService中 SN 明细加载判断逻辑对pmGenre=3配件类型存在过滤,导致配件订单未进入 SN 明细与物流轨迹查询流程。 - 同步检查前端页面展开逻辑,发现
app.js中同样只允许pmGenre=1硬件类产品展开明细,后端修复后仍可能被前端拦截,因此制定了前后端同步修复方案。 - 补充测试验证思路与测试用例设计,基于纯配件订单构造测试数据,用于验证修复后配件行是否能够正常返回 SN 明细、快递单号和快递公司信息。
二、核心完成内容
1. 模块开发与功能实现
- 对订单交付查询功能进行问题定位,确认问题影响范围为自有配件产品,即
product_attribute=1且pmGenre=3的订单产品行。 - 梳理
/api/pangugong/delivery/order接口的处理流程,明确当前链路包括订单头查询、产品行查询、SN 明细加载判断、order_sninfo查询以及物流轨迹补充等步骤。 - 定位后端拦截点在
OrderDeliveryService.java的shouldLoadDeliverySnDetail方法中,原逻辑仅允许自有/联合开发产品中的硬件整机pmGenre=1加载 SN 明细,导致配件pmGenre=3被直接排除。 - 制定后端修复方案,将自有/联合开发产品的 SN 明细加载范围由
pmGenre=1扩展为pmGenre=1 || pmGenre=3,使自有配件订单能够进入后续 SN 明细查询流程。 - 检查前端展示逻辑,确认
app.js中明细展开条件也存在同类限制,制定同步修改方案,将可展开范围从硬件类产品扩展到硬件与配件两类产品。
2. 接口设计与文档沉淀
- 沉淀《配件订单物流明细缺失 — 问题分析与修复方案》,记录问题现象、影响范围、接口链路、根因分析、前后端修复方案、影响评估和测试验证点。
- 明确当前问题的核心原因不是接口整体不可用,而是业务类型判断逻辑遗漏了配件类型,导致配件订单在后端 SN 明细加载阶段被提前拦截。
- 对可能的数据源问题进行了预判:如果放开
pmGenre=3后,order_sninfo中存在配件快递单号,则当前修复即可解决;如果order_sninfo中无配件快递信息,则需要进一步确认 OMS/SCM 侧快递数据来源。 - 补充测试文档结构,包含测试订单、构造数据、API 调用方式、预期返回结果、前后端修复清单以及可选清理 SQL,为后续复测和回归提供依据。
3. 测试验证与问题处理
- 设计了针对纯配件订单的测试场景,测试订单为
999900000001,产品类型为pmGenre=3,用于验证无硬件产品的配件订单是否能够正常展示物流明细。 - 构造测试数据覆盖 5 条 SN 记录,并配置对应快递单号与承运商信息,用于验证修复后
snList是否非空,以及每条 SN 是否包含deliverExpressNum和deliverCompanyName。 - 明确修复前后对比结果:修复前配件行
snList为空或不返回明细,页面明细列显示—;修复后预期配件行可返回 SN 明细,并展示快递单号和快递公司。 - 制定真实订单回归验证点,后续可使用
202604215003、202604245039、202604245415等订单验证配件发运集是否可展开,以及物流信息是否正常展示。
三、今日工作产出
- 完成了配件订单物流明细缺失问题的链路排查,明确问题发生在 SN 明细加载判断逻辑,而不是订单头或产品行查询阶段。
- 完成了后端
OrderDeliveryService.java的修复方案设计,将自有配件pmGenre=3纳入 SN 明细加载范围。 - 完成了前端
app.js展开条件的同步修复方案设计,避免后端已返回数据但页面仍无法展开的问题。 - 沉淀了问题分析与修复方案文档,便于后续代码评审、问题复盘和同类问题排查复用。
- 补充了测试验证文档和构造测试订单方案,为后续本地验证、测试库验证和真实订单回归提供依据。
四、遇到的问题与解决情况
- 问题:订单交付助手中部分纯配件订单产品行可以展示,但明细列显示
—,无法展开,快递单号、快递公司和物流状态均不展示。 - 处理:沿接口链路逐步排查,确认订单头和产品行查询正常,问题出现在
shouldLoadDeliverySnDetail对产品类型的过滤逻辑中;该逻辑只允许pmGenre=1的硬件类产品加载 SN 明细,遗漏了pmGenre=3的配件类产品。 - 结果:形成前后端同步修复方案,后端放开
pmGenre=3的 SN 明细加载,前端同步放开配件行展开条件,并通过构造测试订单设计验证方案,确保修复后配件订单能够返回并展示物流明细。
五、明日计划
- 基于测试库构造数据继续进行接口验证,重点检查纯配件订单返回结果中的
snList、deliverExpressNum、deliverCompanyName等字段是否完整。 - 使用真实问题订单进行回归验证,确认配件发运集明细列能否正常展开,以及 OMS 中存在的快递信息是否能够在助手页面展示。
- 回归验证硬件订单和第三方产品订单,确认本次调整不会影响原有产品类型的物流明细展示逻辑。
- 若真实配件订单在
order_sninfo中缺少快递数据,继续排查 OMS/SCM 侧数据来源,并评估是否需要新增 Mapper 查询或补充兜底数据链路。
六、总结
今日主要围绕配件订单物流明细缺失问题展开排查和修复方案设计,完成了从问题现象、接口链路、后端判断逻辑、前端展示逻辑到测试验证方案的完整梳理。通过本次排查,明确了问题根因是产品类型判断逻辑遗漏自有配件类型,并形成了前后端同步修复方案及测试验证文档,为后续联调验证、真实订单回归和同类物流明细问题排查奠定了基础。
2026-06-17|配件订单物流明细缺失排查与修复方案设计
https://jupiter-ws.cn/posts/internship/实习日报-2026-06-17/