# P2 并入清单核对：跨模块调用有没有"断了"的

> 结论先行：**895 处活跃 `<dubbo:reference>` 里，只有 6 处的实现方不在并入清单内**，
> 而且集中在 2 个接口上。其余 889 处要么就地解析，要么已经在搬。
>
> 生成方式：[`tools/dubbo_dependency_scan.py`](../tools/dubbo_dependency_scan.py)，
> 明细见 [`dubbo-dependency-report.md`](./dubbo-dependency-report.md) 与 `dubbo-references.csv`。

## 0. 为什么必须查这个

合成单 Jar 之后 Dubbo 注册中心没了，所有 `<dubbo:reference>` 会被翻成 `@Resource` 字段。
**如果某个 reference 的实现类所在模块没有并进 reactor，那么老代码里那个字段
永远没有对应 Bean**——编译能过、启动能过，一调用就是 `NoSuchBeanDefinitionException`。
这是典型的"上线才发现"故障，所以要在动手前把清单核到位。

## 1. 核对结果

| 分类 | 处数 | 含义 |
|---|---:|---|
| 提供方在并入清单内 | **869** | 正常工作 |
| **提供方不在并入清单内** | **6** | ⚠️ 见 §2，**必须处理** |
| 有实现类、但老系统从没在 provider XML 里声明 | 8 | 见 §3，合并会自动修好，需验证 |
| 完全找不到实现方 | 12 | 见 §4，**全部由即将下线的 portal 消费**，不影响单 Jar |

> 口径说明（三个容易把数字算错的地方，脚本里都已修）：
> 1. **provider XML 的 `interface=" com.zteits..."` 引号内带前导空格** —— 不 strip 会
>    让大批"其实有提供方"的接口误判成"找不到实现方"（实测从 27 处降到 20 处）
> 2. **大量 `<dubbo:reference>` 是被 `<!-- -->` 包起来的历史残留**（如
>    `dubbo-order-consumer.xml` 第 63、74 行整条注释掉），不去注释会凭空多出假引用
> 3. 老仓库的 `@Service("...")` 值填的是**实现类 FQN**、不是接口 FQN，
>    所以不能拿注解值去匹配接口；实现类要靠 `implements` 兜底识别

## 2. ⚠️ 必须处理的 6 处（提供方不在并入清单）

### 2.1 `SendMessageService`（企业微信发消息）—— 4 处，**优先级最高**

| 项 | 值 |
|---|---|
| 接口 | `com.zteits.clouds.api.service.wxcp.SendMessageService` |
| 实现类 | `zteits-wxcp-portal/.../wxcp/service/impl/SendMessageServiceImpl.java` |
| 暴露处 | `zteits-wxcp-portal/.../dubbo/dubbo-wx-pc-provider.xml:21` |
| 消费方 | `zteits-bill`、`zteits-order`、`zteits-park`、`zteits-pay`（**全是核心模块**） |

**问题**：实现类躺在一个 **portal 模块**里，而方案对 portal 的处理是
"不整体搬迁、Controller 按业务域拆进各模块"。也就是说按原计划搬迁，这 4 个调用会全部断掉。

**处置**：把 `SendMessageServiceImpl` 作为**随迁例外**，落到
`parking-module-system`（或 `parking-module-infra`）的 `api/` 包，类名保留、逻辑不动。
不要试图"顺手重写"——它是对接企业微信的，报文格式要原样。

### 2.2 `DfGroundLockMsgPushService`（地锁消息推送）—— 2 处

| 项 | 值 |
|---|---|
| 接口 | `com.zteits.clouds.api.service.datacollect.DfGroundLockMsgPushService` |
| 实现类 | `zteits-glock-collection/.../glockcollect/biz/DfGroundLockMsgPushServiceImpl.java` |
| 暴露处 | `zteits-glock-collection/.../dubbo/dubbo-glock-provider.xml:25` |
| 消费方 | `zteits-bcp-portal`（**要下线，忽略**）、`zteits-order`（**核心模块，必须处理**） |

**问题**：`zteits-glock-collection` 整个模块不在本次并入范围（方案里它属于二期）。
但 `zteits-order` 有一处活跃调用。

**处置**：先确认 `zteits-order` 里那处调用**在业务上是否还在用**（地锁是历史业务，
很可能已经是死代码）。若还在用 → 随迁这 1 个 impl；若已不用 → 删掉字段与引用，
比"为了一个死调用拖进一整个模块"划算。

## 3. 有实现类但老系统没声明（8 处）—— 合并会自动修好，但要验证

这些接口**在老的 Dubbo 世界里根本没人暴露**：`<dubbo:reference>` 指向一个不存在的
provider，老系统靠 `check="false"` 起得来，真调用时才失败 —— 属于**存量潜伏缺陷**。

合成单体后按类型注入，实现类只要在同一个 ApplicationContext 里就会被解析到，
**等于合并顺手修好了它**。

| 消费方 | 接口 | 实现类模块 | 备注 |
|---|---|---|---|
| `zteits-order` | `...park.carchargeaudit.query.XcCarChargeAuditQueryService` | `zteits-park` | ⚠️ **唯一涉及核心模块的一处**，且确认在被调用 |
| `zteits-bcp-portal` | 同上 | `zteits-park` | portal，随下线消失 |
| `zteits-bcp-portal` | `...park.carchargeaudit.oper.XcCarChargeAuditOperService` | `zteits-park` | 同上 |
| `zteits-bcp-portal` | `...clouds.CloudsParDurationService` | `zteits-pay` | 同上 |
| `zteits-bcp-portal` | `...order.OrderParkBjxcService` | `zteits-order` | 同上 |
| `zteits-bcp-portal` | `...pay.CustPersonCreditService` | `zteits-pay` | 同上 |
| `zteits-pay-portal` | `...pay.CustPersonCreditService` | `zteits-pay` | 同上 |
| `zteits-minipay-portal` | `...pay.InvoiceHelperService` | `zteits-pay` | 同上 |

**唯一要跟的是第一行**：`zteits-order` 的 `XcCarChargeAuditService:67` 与
`HivDataCommService:104` 都注入了它，`XcCarChargeAuditService:67` 确有调用。
验证方法：单元/联调时确认 `XcCarChargeAuditQueryServiceImpl`
（`@Service("com.zteits.park.biz.carchargeaudit.query.XcCarChargeAuditQueryServiceImpl")`）
被扫进容器且按类型能唯一解析。

> ⚠️ 反过来也要警惕：**"合并顺手修好"是双刃剑**。老系统里这 8 处调用一直是失败的，
> 说明**业务上可能从没真正跑通过**。合并后它们会突然开始真正执行 ——
> 如果实现里有副作用（写库、发消息），这是**行为变化**，要在回归里专门过一遍。

## 4. 找不到实现方的 12 处 —— 不影响单 Jar

12 处的消费方**全部**是即将下线的 portal：

| 消费方 | 处数 |
|---|---:|
| `zteits-bcp-portal` | 6 |
| `zteits-gcp-portal` | 4 |
| `zteits-pay-portal` | 1 |
| `zteits-business-portal` | 1 |

这些 portal 按方案只在"迁一个前端页面时搬一个接口"，且 `zteits-gcp-portal` 已确认废弃
（其路由被政务 PTMS 取代）。所以这 12 处**不构成单 Jar 的启动或运行风险**，
但**核对前端页面清单时要留意**：如果有页面依赖这几个接口，说明该页面在老的 Dubbo
体系里本来就是坏的，迁页面时要顺带确认它到底该调哪个新接口。

未实现的接口清单：`InOutParkStatisticService`、`ParkDurationStatisticService`、
`ParkingReportService`、`ParkTransactionService`、`OrderExamineService`、`IParkService`、
`TdCCustBusinessMsgQueryService`、`ParkOrderService`、`ThirdPlatformApiService`。

## 5. 下一步

| 事项 | 状态 |
|---|---|
| 六库重名表结构比对 | ✅ 已完成，见 [`../sql/legacy-db-actual.md`](../sql/legacy-db-actual.md)（19 组重名，12 组结构不一致） |
| 表清单与归属 | ✅ 见 [`../sql/table-inventory.md`](../sql/table-inventory.md) |
| 迁移源实例 | ✅ **张北 `renniting-prod-net`**（模块×库命中矩阵 87~100%） |
| `zt_pay` 是否存在 | ✅ **不存在该问题**：pay 域的表物理上在 `zt_order` 里 |
| Dubbo 依赖对账 | ✅ 本文档 |
| ⚠️ `zteits-business` 11 张表（在另一实例 `zt_business`） | ⏸ 待定：随迁还是砍掉 |
| ⚠️ `zt_order` 里 2018 年订单归档是否搬 | ⏸ 待定：影响迁移体量（该库 88 GB 多为归档） |
| `SendMessageService` 随迁 | 待 P2 动手时执行 |
| `DfGroundLockMsgPushService` 定性 | 待确认调用是否已是死代码 |