浏览器请求返回了 HTTP 200，响应体却是空的，页面也没有数据。状态码看起来成功，后端日志却给出了另一条链路：映射 SQL 在调用 WM_CONCAT 时触发了 ORA-00904。

这次修复不能只做全局文本替换。字符串聚合包含排序、重复值、分隔符、别名和溢出语义。安全迁移到 Oracle 19c，需要逐项保留这些契约，证明运行时产物已经同步变化，并把“源码与数据库验证完成”和“部署后页面已恢复”严格分开。

从第一个失败边界开始

有效的执行链是：

HTTP 200 空响应
  -> 异常被捕获
  -> 映射 SQL 失败
  -> ORA-00904: …

一个分页业务页面只返回约 10 KB 数据，却需要 27.49 秒。响应体很小，基本可以排除网络传输是主要瓶颈；但浏览器耗时本身还不能说明延迟来自页面渲染、应用代码，还是数据库。

真正有用的证据是：一次页面请求会执行两条高成本 SQL，一条用于计算分页总数，另一条用于取得当前十行数据。数据库统计显示，计数 SQL 平均约 21.3 秒，读取约 448 万个缓冲块；数据 SQL 还需要 7.8 至 9.0 秒。两者相加，几乎完整解释了前端观测到的耗时。

改写前的证据

原查询在知道用户实际需要哪些订单之前，就先构造了多个派生数据集：对大范围流转记录执行窗口排序，聚合明细和质检记录，最后才按组织、项 …

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

根因不是索引差异

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

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

两套 …