P2 并入清单核对：跨模块调用有没有"断了"的
结论先行：895 处活跃
<dubbo:reference>里，只有 6 处的实现方不在并入清单内， 而且集中在 2 个接口上。其余 889 处要么就地解析，要么已经在搬。生成方式：<code>tools/dubbo_dependency_scan.py</code>， 明细见 <code>dubbo-dependency-report.md</code> 与
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 |
口径说明（三个容易把数字算错的地方，脚本里都已修）：
- provider XML 的
interface=" com.zteits..."引号内带前导空格 —— 不 strip 会 让大批"其实有提供方"的接口误判成"找不到实现方"（实测从 27 处降到 20 处）- 大量
<dubbo:reference>是被<!-- -->包起来的历史残留（如dubbo-order-consumer.xml第 63、74 行整条注释掉），不去注释会凭空多出假引用- 老仓库的
@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. 下一步
| 事项 | 状态 |
|---|---|
| 六库重名表结构比对 | ✅ 已完成，见 <code>../sql/legacy-db-actual.md</code>（19 组重名，12 组结构不一致） |
| 表清单与归属 | ✅ 见 <code>../sql/table-inventory.md</code> |
| 迁移源实例 | ✅ 张北 renniting-prod-net（模块×库命中矩阵 87~100%） |
zt_pay 是否存在 |
✅ 不存在该问题：pay 域的表物理上在 zt_order 里 |
| Dubbo 依赖对账 | ✅ 本文档 |
⚠️ zteits-business 11 张表（在另一实例 zt_business） |
⏸ 待定：随迁还是砍掉 |
⚠️ zt_order 里 2018 年订单归档是否搬 |
⏸ 待定：影响迁移体量（该库 88 GB 多为归档） |
SendMessageService 随迁 |
待 P2 动手时执行 |
DfGroundLockMsgPushService 定性 |
待确认调用是否已是死代码 |