Wms

把旧 WMS RF 迁移到新的移动技术栈，不能只把页面搬到手机尺寸。RF 是仓库执行入口，会直接改变库存、任务和设备状态，必须处理身份、仓库隔离、并发领取、弱网重试和真实硬件。

这次实现采用 Ionic Vue 与 Capacitor，PWA 和 Android 共用业务代码。后端继续使用现有 WMS 领域服务作为唯一状态机，移动接口只负责认证范围、任务编排、扫码校验、幂等和适合手持设备的响应。

仓库范围必须进入身份

UPM 增加 RF 操作角色和仓库授权。登录后的 JWT 携带允许访问的仓库范围，后端从认证上下文解析当前操作者。

客户端不能通过请求参数伪造公司或仓库。切换仓库时也必须在服务端 …

一个订单状态页面在测试环境正常，生产环境的入库、出库和各节点数量却全部显示为 0。页面列表能看到大量订单，数据库也确认近期业务数据存在，因此页面显示的“0”是汇总请求未及时成功返回后的默认值，与实际数据不符。

旧接口为了统计数量，分别发起多次超大分页查询，把明细加载到 Java 后再分组。每次分页还会额外执行 count SQL。一次页面刷新最终串行触发多条重查询。

测试库数据量很小，这种实现仍能在很短时间内返回；生产流转记录规模大几个数量级，同样的查询需要十几到二十多秒，多项统计串行后超过页面等待时间。前端没有明确失败态，于是保留初始化的 0，看起来就像生产没有订单。

两套 …

在物流系统中，公司、经营组织、项目和仓库经常同时出现在登录上下文、业务单据和查询条件里。它们看起来都像“数据归属”，但不能互相替代。

这次我没有按字段名称猜测，而是从主数据表、典型关联 SQL 和用户会话中检查它们的真实用法。

公司或分公司是平台的数据隔离边界，业务表中的 org_id 通常保存公司主数据的内部 ID，而不是公司编码。

大量订单、库存和配置查询都先按 org_id 过滤。它决定当前用户能进入哪一个公司范围，也是项目、仓库和经营组织共同的上级归属。

project_id 指向项目主数据。一个项目属于某家公司，并通常绑定默认仓库或仓 …

一个刚创建的出库单，在订单状态页面按单号搜索可以查到，但直接打开默认出库总览却看不到。接口、权限和仓库范围都没有报错，这种现象很像列表 SQL 漏查或缓存没有刷新。

排查首先对比了两条查询路径。按单号查询使用明确的唯一条件，默认总览还会附加最近时间窗口。数据库中的单据状态正常，但创建时间沿用了被复制旧单的日期，没有落在当天。

复制功能复用了原单对象和明细。业务字段需要继承，但审计和生命周期字段也被一起带了过来，包括单头与明细的创建时间、修改时间。

于是系统出现了一个矛盾的新单：

一个 WMS 波次计划列表查询一页数据需要约 6 秒。这篇文章记录实际排查路径：从应用日志拿到真实 SQL，检查现有索引，测试并回退无效索引，最后验证新的 SQL 执行结构。

文中的环境和业务标识均已脱敏，SQL 结构、耗时数据和判断过程来自实际排查。

页面需要查询波次主表，关联明细与出库单，聚合 OMS 订单号和 Homebase，关联创建人、修改人信息，并查询装车时间，最后按创建时间倒序返回 50 条。

日志中的关键筛选条件是修改时间范围、组织和项目条件，同时按照创建时间排序。

问题就在这里：SQL 在确定页面最终需要的 50 个波次前，已经开始展开明细、聚合并排序。