# 07 行业落地与工程迁移方法论

> 本文回答：各行业替到哪一步了、有哪些可参照的公开案例；一个信创迁移项目应该分几阶段推进、每阶段的门禁是什么；**Java / Spring Boot + MyBatis + PageHelper + Redis + MySQL/MongoDB 技术栈具体要改什么**。
>
> 前置依赖：[05 基础软件](./05-基础软件与平台软件.md)、[06 安全合规](./06-安全合规与测评认证体系.md)。后续：[09 风险挑战](./09-风险挑战与批判性视角.md)、[10 决策建议](./10-趋势展望与决策建议.md)
>
> 说明：文中出现的配置示例均为**示意**，采用 `application.yml` + 环境变量占位，不硬编码连接信息；实际以项目现有配置规范与厂商驱动文档为准。

---

## 1. 「2+8+N」行业进度：多源对照

> **口径警告**：下表渗透率来自不同机构、不同分母（系统数量 / 采购金额 / 终端台数 / 核心系统占比），**只能判断梯队顺序，不能横向相减或求平均**。

| 梯队 | 行业 | 阶段判断 | 常见转引数据 | 证据等级 |
|---|---|---|---|---|
| 先行 | 党政 / 电子政务 | 常态化采购，从办公向核心业务延伸 | 电子公文系统国产化率高；党政整体替换率约 85%；截至 2025 年底服务器 OS 替代率突破 40%〔不同口径，差异大〕 | B/C |
| 第一梯队 | 金融 | 非核心规模化落地，向核心交易系统攻坚 | **国产替换率**：非核心 50%—60%、核心约 20%（分母为系统数量/采购额，见 [03](./03-产业链全景与技术栈.md) §4）；**架构采用率**：有资料称超 50% 银行核心已采用分布式数据库。二者是不同指标——后者含 OceanBase/PostgreSQL 等非「国产替换」判定，不可相减或互相印证；均为转引、年份未披露，标「待核实」 | B/C |
| 第一梯队 | 电信 | 全面铺开，进入 CRM/BOSS/计费核心 | 业务支撑与管理支撑系统国产化率约 90%；服务器国产化率超 90% | B/C |
| 第一梯队 | 电力 / 能源 | 规模化建设高峰，调度、配网自动化推进 | 硬件替换率较高，办公软件基本国产化 | C |
| 第二梯队 | 石油、交通、航空航天 | 向生产控制、指挥调度等核心环节渗透 | 工控系统进入适配替换阶段 | C |
| 第三梯队 | 医疗、教育 | 试点增多，渗透率较低 | 渗透率不足 10%（部分口径）；统信 UOS 进入数千所学校 | C |
| N | 制造、零售、建筑、中小企业等 | 起步 / 点位验证 | 无稳定可比口径 | C |

**可核查的结构性判断**（比具体百分比更可靠）：

1. **从外围到核心**：OA/门户/邮件 → 经营管理 → 数据分析平台 → 核心交易/账务/调度，风险与工期逐级上升。
2. **从硬到软**：硬件替代占比由 2022 年约 68% 降至 2025 年约 52%，软件与服务占比上升〔B，信通院白皮书转述〕。
3. **从合规到价值**：行业观察认为政策重点从「替代比例」转向「替代质量」（性能不低于原系统、安全合规不打折扣）〔C〕。

---

## 2. 行业案例库（按可借鉴点组织）

> 案例数据均为厂商/行业媒体**公开披露口径**〔B/C〕，存在幸存者偏差，用于说明「可行路径」，不作为性能承诺或成本基准。完整数据库与电信案例清单见 [05](./05-基础软件与平台软件.md) §2.4。

| 案例 | 可借鉴的做法 | 出处类型 |
|---|---|---|
| **河科大一附院（三甲医院，双模式并行）** | 搭建「全信创架构」与「x86/ARM 混合架构」双环境；基础软硬件每层至少选两家伙伴；按应用软件厂商改造程度决定「自上而下」还是「自下而上」选型；梳理 **5TB 结构化数据**，剥离冷数据、绘制热数据关联图确定迁移顺序；每次迁移前定制**迁移与回退脚本**并演练；模拟超日常门诊量压测；2024 年 9—11 月分三阶段切换（集成平台/康复/病理 → 住院医生站/EMR/LIS → 门诊/收费/药房/预约） | 行业媒体（HIT 专家网） |
| **某省级政务系统 x86 → 鲲鹏 + 麒麟 V10 + 达梦** | 四步法：应用摸底（识别 Java 跨架构优势 + 两个本地 C 模块 + 一个 Windows 专属报表控件）→ 数据库迁移（结构自动转换、存储过程/触发器逐个改写、**双库并行两周字段级每日比对**，差异归零才切换）→ 中间件 Tomcat→TongWeb 配置逐项映射 → 渐进切换（先查询后写入、回退通道全程开放）；老环境完整待命两周；慢 SQL 按新执行计划重调 | 技术实施方案例 |
| **某医院 HIS（Kingbase FlySync 双轨并行）** | 初期只把查询/报告打印导到新库，挂号缴费仍留 Oracle；实时同步保证两端毫秒级对齐；逐步切核心交易；并行三个月后全量切换；解决 Oracle 隐式类型转换精度问题；全量迁移拆并发任务从预期 3 天缩至 18 小时；切换后同步任务转为单向容灾 + Kafka 数据湖 | 厂商技术博客 |
| **贵州农信全栈信创核心** | 520 天建设周期、22 小时完成切换；处理能力约原系统 6 倍，跑批效率约 2 倍；预计三年节约许可与维保约 1.7 亿元 | 行业报告转引 |
| **山东省财政厅预算管理一体化** | 全省 180+ 财政区划整合；硬件成本 -26%+，响应 5s→2s；一键部署/升级/扩容 | 厂商公开案例 |
| **某省医保局 OS 迁移**（另见中粮信托同类案例） | 单台服务器迁移控制在 30 分钟内；5000 余套 CentOS 服务器 4 个月完成迁移，与 [05](./05-基础软件与平台软件.md) §1.4 为同一案例 | 厂商/行业稿 |

**三条共性经验**：

- **兼容性预检先行**，而不是「装新系统导数据」。
- **双轨并行 + 秒级回退**是高风险核心系统的安全阀，不是保守。
- **冷/热数据分层 + 数据关联图 + 逐批演练**，比一次性全量导出导入可靠得多。

---

## 3. 迁移方法论：六阶段 + 门禁（全站唯一阶段主表）

> **口径声明（v1.1）**：本章 S0—S5 是全站**唯一**的迁移阶段划分与门禁定义。[02](./02-政策脉络与法规体系.md) §6、[06](./06-安全合规与测评认证体系.md) §7、[09](./09-风险挑战与批判性视角.md) §9 是同一 S 阶段下的**合规材料 / 风险动作清单**，不另立阶段；[10](./10-趋势展望与决策建议.md) §6 的 W1—W13 是 S0—S5 的**周计划时间展开**，同样不是独立阶段口径。

```
S0 摸底评估  →  S1 环境验证  →  S2 代码与 SQL 适配
    →  S3 数据迁移与双轨并行  →  S4 灰度切换与回退演练
    →  S5 验收与持续运维
```

### S0 摸底评估

| 项 | 内容 | 产出 |
|---|---|---|
| 资产盘点 | 服务器/终端型号、CPU 架构、OS 版本、中间件、数据库、应用清单、接口清单 | 资产台账 |
| 依赖盘点 | 第三方 jar、native 库（.so/.dll）、监控/APM Agent、JDBC 驱动、加密 UKey、外设（打印机/扫码枪/高拍仪） | **依赖矩阵（含目标架构可用版本）** |
| 闭源组件确认 | 向厂商书面确认是否提供 aarch64/loongarch64 版本与时间表 | 写入合同附录（不能靠口头承诺） |
| 合规基线 | 等保定级、是否关基、密评要求、测评等级要求、声明函要求 | 合规矩阵（见 [06](./06-安全合规与测评认证体系.md) §7） |
| 业务基线 | TPS、P99、批处理窗口、峰值并发、RPO/RTO | **可验收的性能基线** |

**门禁 S0**：依赖矩阵中不存在「无对应架构版本且无替代方案」的硬阻塞项；性能基线经业务方签字。

### S1 环境验证

- 搭建与生产 **1:1** 的国产化测试环境（同 CPU 型号、同 OS 与内核版本、同数据库大版本、同中间件版本）。
- 至少跑 2—3 周冒烟测试，验证三件事：应用能否启动、常用外设能否识别、压测结果是否达到原系统基线的约定比例。
- 行业经验值常引用「性能达到原系统 80% 以上」或「与 x86 基线差距控制在 15%—20% 以内」〔C，技术博客/实施方经验，**非国家标准**〕。**项目应在合同中自行约定阈值**，不要引用行业经验值当验收标准。
- 执行 `uname -m`、`file $(which java)` 确认架构确实切换，避免「在同一架构上做了一周迁移」。

**门禁 S1**：1:1 环境跑通核心流程；适配问题清单已建立并分派责任；性能对比报告出具（含差异说明，不回避差距）。

### S2 代码与 SQL 适配

高发问题清单（详见 §5 Java 专项）：

| 类别 | 典型症状 |
|---|---|
| 架构相关 | 本地编译 C/C++ 模块、JNI、Netty native 模块、无对应架构的闭源 SDK |
| OS 相关 | 硬编码 Windows 路径、大小写敏感、字体渲染、打印驱动、locale/时区 |
| 数据库 | 分页语法、序列/自增、隐式类型转换、递归查询、存储过程/触发器/包体、函数差异、执行计划与索引策略失效 |
| 中间件 | `javax.*` → `jakarta.*` 命名空间、部署描述符、JNDI/JMS、连接池与会话保持参数 |
| 前端/控件 | ActiveX / OCX 在国产浏览器下不可用、报表控件无国产版本 |
| 安全 | RSA/SHA/AES → SM2/SM3/SM4、TLCP 支持、JCE 策略、随机数熵源 |

**门禁 S2**：适配问题跟踪表（现象 → 定位 → 方案 → 回归结果）全部闭环；全量回归测试通过。

### S3 数据迁移与双轨并行

- 原则：**先备份、再迁移、多校验**；全量 + 增量同步；冷数据一次性导入、热数据分批。
- 校验三层：**行数比对 → 抽样比对 → 字段级/业务逻辑比对**；核心系统建议字段级每日比对，差异归零才准切换。
- 双轨：新旧库实时同步，新环境并行运行（案例周期从两周到三个月不等），持续观测同步延迟与错误日志。
- 不要忽略 **DDL 同步**：源端表结构变更常是盲点，需确认同步工具对特定 DDL 的支持范围。
- 高频 TOP SQL 在迁移**前**做语法优化，迁移后继续观测资源占用与慢事务。

**门禁 S3**：数据一致性差异归零；同步延迟在约定阈值内；回退脚本演练成功。

### S4 灰度切换与回退

- 流量顺序：**先查询后写入**，先非核心后核心，先单部门试点后全量。
- 双轨期间新旧两套并行录入或实时同步比对，周期通常 1—2 周起，核心系统更长。
- **回退通道全程开放**，老环境完整待命（案例建议两周），严禁为腾机柜提前关闭旧环境。
- 切换窗口选业务低峰；准备一键回滚脚本与决策人。

**门禁 S4**：灰度各阶段无 P0/P1 缺陷；回退演练在真实数据规模下成功。

### S5 验收与运维

- 交付：适配问题清单及解法、性能基线对比、安全测评报告、试运行报告（含适配调优专项）、运维培训记录、声明函与证书归档。
- 持续：三级等保每年测评、密评每年至少一次、测评证书三年到期预警、SBOM 与漏洞治理、版本升级后重测适配。
- 迁移工具导出的中间数据**用完即毁**，并留存销毁记录。

**门禁 S5**：全部合规材料齐备并与 [06](./06-安全合规与测评认证体系.md) §7 清单逐项勾对。

---

## 4. 六层适配检查单（可直接用于项目自查）

| 层 | 检查项 | 通过标准 |
|---|---|---|
| L1 芯片 | `uname -m` 架构标识；native 库/驱动有对应架构版本；闭源 Agent 可用 | 全部有版本或已确认替代 |
| L2 整机固件 | BIOS/BMC 可自主更新；BOM 关键元器件溯源；外设驱动 | 供应链溯源材料齐备 |
| L3 OS | 内核版本一致；locale/时区/字符集；systemd 启动脚本；字体与打印 | 1:1 环境跑通 |
| L4 数据库 | 驱动类名/URL；SQL 方言；分页；事务与隔离级别；连接池；执行计划 | 全量 SQL 回归 + 压测 |
| L4 中间件 | Java EE/Jakarta EE 版本；部署方式；会话保持；消息 SDK | 联调通过 |
| L5 应用 | 路径、控件、报表、附件、文件编码、第三方 SDK | 业务 UAT 通过 |
| L6 安全 | 等保基线、国密算法、密评、审计日志、声明函 | 合规包齐备 |
| 横向 | 多架构镜像、CI 多架构构建、监控告警、备份恢复、回退 | 演练记录齐备 |

---

## 5. Java / Spring Boot 技术栈专项

> 针对 Spring Boot + MyBatis + PageHelper + Redis + MySQL/MongoDB 这一典型栈，给出逐层改造点与验收动作。**这是全站与工程实践最贴合的一节。**

### 5.1 为什么 Java 栈相对好迁

JVM 字节码屏蔽了大部分指令集差异，纯 Java 应用的核心代码通常无需修改。因此「信创迁移 = 改 Java 业务代码」是错误认知。**工作量分布的经验判断**：数据库方言与 SQL 改写占比最高，其次是闭源依赖与控件、中间件配置、OS/驱动，最后才是 CPU 架构本身〔C，多篇迁移实践一致〕。

反过来也要警惕：正因为「Java 天然跨平台」的说法流行，团队容易漏查 **native 依赖**（Netty 的 `netty-transport-native-epoll`、JNI 库、APM Agent、加密 UKey 驱动、lib 字体库），这些才是启动失败或性能骤降的高频根因。

### 5.2 JDK 选型与验证矩阵

| 目标架构 | 推荐发行版 | 必查项 |
|---|---|---|
| 鲲鹏 / 飞腾（aarch64） | 毕昇 JDK（ARM 优化最充分）；Kona、Dragonwell 亦可 | JDBC 驱动版本、GC 策略、JCE 策略、国密 Provider |
| 海光 / 兆芯（x86_64） | 标准 OpenJDK 或任一国产发行版 | 无需更换 JVM 架构，重点在授权合规与国密支持 |
| 龙芯（loongarch64） | 龙芯 JDK | 全量依赖是否有 loongarch64 版本 |
| 申威（sw_64） | 对应厂商 JDK | 生态最窄，需专项评估 |

**四个隐形杀手**〔C，迁移实践共性〕：

1. **JCE 无限制强度策略**：部分 Java 8 国产发行版默认关闭 unlimited policy，使用 AES-256 时抛 `Illegal key size`。检查 `$JAVA_HOME/jre/lib/security/java.security` 中 `crypto.policy=unlimited`。
2. **SecureRandom 阻塞**：国产服务器熵源不足时，`/dev/random` 会导致启动卡住数分钟、加密性能骤降；需评估 `securerandom.source` 与熵源服务。
3. **字符集与时区**：国产 OS 默认 locale 未必 UTF-8，中文乱码与 8 小时时差高发。**JDK 18+ 起 JEP 400 已默认 UTF-8**，Java 8/11 发行版仍需显式确认 `-Dfile.encoding`；`sun.jnu.encoding` 是 JVM 依据平台 locale 推导的**只读系统属性**，用 `-D` 指定通常不生效，不应列为必选启动参数。最小启动参数示例：
   ```
   java -XX:+UseG1GC \
        -Dfile.encoding=UTF-8 \
        -Duser.timezone=Asia/Shanghai \
        -jar app.jar
   ```
4. **GC 参数不可移植**：x86 上调优过的 CMS/G1 参数不是可移植资产；ARM 多核场景需重新评估 G1/ZGC 与堆分代比例，并按 TPS/P99 重测。

**版本矩阵风险**：Spring Boot 2.1.x 属 Java 8 时代、`javax.*` 命名空间。若外置到国产应用服务器，需核对其支持的 Servlet / Java EE 版本；若保留 Spring Boot 内嵌容器，则改动最小。**JDBC 驱动对高版本 JDK 的支持常滞后**（早期达梦驱动在 JDK 17+ 撞过模块化反射限制），因此「文档写支持」不等于「组合可用」，必须用**实际驱动版本 × 目标 JDK × 目标架构**压测。

### 5.3 Spring Boot 配置改造（yml 示意）

```yaml
spring:
  datasource:
    driver-class-name: ${XC_JDBC_DRIVER}     # 例：dm.jdbc.driver.DmDriver / com.kingbase8.Driver
    url: ${XC_JDBC_URL}
    username: ${XC_DB_USER}
    password: ${XC_DB_PASSWORD}
    hikari:
      maximum-pool-size: ${XC_POOL_MAX:20}
      connection-test-query: ${XC_TEST_QUERY}
  redis:
    host: ${XC_CACHE_HOST}
    port: ${XC_CACHE_PORT}
    password: ${XC_CACHE_PASSWORD}
  data:
    mongodb:
      uri: ${XC_MONGO_URI}

pagehelper:
  helper-dialect: ${XC_PAGE_DIALECT}        # 见 5.4
  reasonable: "true"
  support-methods-arguments: "true"
```

要点：

- **禁止硬编码**连接信息、驱动类名、方言；全部通过配置/环境变量注入，便于一套代码在 x86 与信创双环境并行。
- 建议用 **Spring Profile**（`application-xinchuang.yml`）隔离差异，避免为迁移拉分支。
- `connection-test-query` 需按目标库调整（部分国产库不支持 `SELECT 1` 的写法或需要 `FROM DUAL`）。
- 连接池参数（最小/最大、超时、验证间隔）需按国产库的连接建立成本重新压测，不能沿用 MySQL 经验值。

### 5.4 MyBatis / PageHelper 与 SQL 方言

**PageHelper 方言**：需确认项目所用 PageHelper 版本是否内置目标数据库方言（常见发行版内置部分国产库方言标识）；若不支持，应通过 `PageHelper` 的自定义 `Dialect` 扩展或改用显式物理分页，而**不是在 XML 里散落 `LIMIT/?` 硬编码**。切换方言后必须对每个分页查询做边界回归（首页/末页/空结果/排序/总数）。

**MyBatis 层改造清单**：

| 项 | MySQL / Oracle 习惯 | 国产库注意点 |
|---|---|---|
| 分页 | `LIMIT ?,?` / `ROWNUM` | 依赖方言配置或改写为窗口函数；核对 `count` 与排序一致性 |
| 主键 | `AUTO_INCREMENT` / `SEQUENCE` | 序列语法、`<selectKey>` 写法、`useGeneratedKeys` 支持度 |
| 字符串 | `CONCAT`、`GROUP_CONCAT` | 函数差异、空串与 NULL 语义 |
| 日期 | `NOW()`、`DATE_FORMAT` | 函数映射、时区、精度 |
| 递归 | `CONNECT BY`（Oracle） | 改为递归 CTE 或目标库等价写法 |
| 批量 | 多值 `INSERT` / `MERGE` | 批量语法与事务日志行为差异 |
| 存储过程 | PL/SQL 包体 | 逐个人工改写，兼容模式通常只能覆盖大部分 |
| 隐式类型转换 | Oracle 隐式转换 | 易引发精度问题，需显式 `CAST` |
| 索引与执行计划 | 沿用原索引策略 | **必须按新库执行计划重调**，照搬索引常导致慢 SQL |
| 保留字 | — | 国产库保留字集合不同，字段名冲突需转义 |

**Hibernate/JPA（若项目使用）**：需引入厂商提供的 Dialect 类或社区实现，并核对 DDL 自动生成、序列生成策略与分页 SQL。

### 5.5 中间件替换

| 原组件 | 处理建议 |
|---|---|
| Spring Boot 内嵌 Tomcat | **优先保留**（纯 Java、跨架构）。若招标要求国产应用服务器，再评估外置 WAR 部署到 TongWeb / BES / InforSuite / Apusic |
| WebLogic / WebSphere | 映射到 TongWeb / BES / InforSuite / Apusic / PAS；重点核对 Java EE 版本、部署描述符、JNDI/JMS、类加载顺序、`weblogic.xml` 等专有描述符清理 |
| spring-session / Redis 会话 | 若换国产缓存，需验证命令兼容性、过期策略、集群协议与序列化格式 |
| 消息队列 | RocketMQ 等纯 Java 组件可直接跑在 aarch64；若换 TongLINK/Q 等，需替换客户端 SDK 并做事务消息回归 |

### 5.6 Redis 与 MongoDB 的替代路径

| 组件 | 可选路径 | 关键验证 |
|---|---|---|
| Redis | 保留 Redis（编译到目标架构，须先核定所用版本的许可证）；或使用国产缓存服务/兼容产品（如 TongRDS、云托管兼容服务） | 命令覆盖、Lua 脚本、Pipeline、持久化 RDB/AOF、Cluster/Sentinel 协议、Spring Data Redis 版本兼容；**Redis 7.4 起改为 RSAL/SSPL 双许可，不再属 OSI 开源许可证，商用前需做法务确认** |
| MongoDB | 保留（若提供目标架构构建）；或评估兼容 MongoDB 协议的国产文档数据库（如巨杉 SequoiaDB 类方案） | **驱动兼容性、聚合管道、索引类型、事务、GridFS、Change Stream**；这是替换风险最高的一类，建议优先「保留 + 架构适配」而非换库。**MongoDB 自 2018 年起改用 SSPL（Server Side Public License），OSI 不认定为开源许可证**，涉及托管/分发场景须单独评估许可义务 |

> 判断原则：**许可证允许商用、纯 Java/无 native 依赖、可自行编译的组件优先保留**（「开源」需按当前许可证核对，不能沿用历史称谓）；把改造预算集中在被招标或合规明确点名的层，以及确实无法获得目标架构版本的闭源组件。

### 5.7 国密改造

| 场景 | 改造点 |
|---|---|
| 加解密 / 签名 | RSA/SHA-256/AES → SM2/SM3/SM4；引入支持国密的 Provider（如 BouncyCastle 国密扩展）或厂商 SDK |
| 传输 | HTTPS → TLCP（GB/T 38636-2020）；Spring Boot 内嵌容器基于 JSSE，通常需替换 Provider 或由国密网关卸载，不宜在应用层硬改协议栈 |
| 证书 / UKey | 国密证书、智能密码钥匙接口（GB/T 35291、GM/T 0017） |
| 密钥管理 | 对接服务器密码机 / 签名验签服务器（GM/T 0030、GB/T 38629） |
| 合规 | 密码应用方案密评 → 运行前密评 → 每年至少一次；密码产品须检测认证合格 |

**注意**：国密改造属于**密评范畴**，不是「信创适配」的副产品；应在立项阶段单列工作包与预算（见 [06](./06-安全合规与测评认证体系.md) §3）。

### 5.8 构建、镜像与 CI

- 多架构镜像：`docker buildx` + manifest list，分别为 `linux/amd64`、`linux/arm64`（必要时 `linux/loong64`）构建；**容器平台标识用 Go/Docker 的 `loong64`，不是 `uname -m` 的 `loongarch64`**，写错会导致 manifest 不被识别、拉取失败。基础镜像中的 JDK、glibc、字体、CA 证书、时区数据需逐架构对齐。
- CI：增加目标架构构建节点（或交叉编译 + QEMU），并在流水线中加入「目标架构启动冒烟测试」。
- 依赖仓库：配置国产 Maven/Gradle 镜像；核对私有二方包是否含 native 依赖。
- 监控/APM：确认 Agent 有目标架构版本，否则上线后将出现「应用正常但无可观测性」。

### 5.9 Java 栈迁移验收清单（20 项）

1. `uname -m` 与 `file $(which java)` 输出符合预期架构
2. JDK 发行版、版本与 `crypto.policy` 已核对
3. 启动参数含 UTF-8 字符集与 Asia/Shanghai 时区
4. `SecureRandom` 无阻塞，启动耗时在基线内
5. GC 策略已按目标架构重测（TPS/P99 对比报告）
6. 全量第三方 jar 与 native 库完成架构盘点
7. 监控/APM/日志 Agent 有对应架构版本
8. JDBC 驱动版本 × JDK 版本 × 架构 组合压测通过
9. 数据源配置全部外置到 yml / 环境变量，无硬编码
10. `connection-test-query` 在目标库可用
11. 连接池参数按目标库重压测
12. PageHelper 方言已确认并覆盖所有分页查询回归
13. 全量 SQL 已扫描：分页/序列/函数/递归/隐式转换/保留字
14. 存储过程、触发器、包体逐个改写并回归
15. 高频 TOP SQL 按新执行计划重调索引
16. 应用服务器（如替换）部署描述符与命名空间核对完成
17. 缓存/消息/文档库客户端 SDK 兼容性与协议回归完成
18. 国密算法与 TLCP 链路通过密评相关验证
19. 多架构镜像、CI 构建与启动冒烟测试通过
20. 双轨并行数据比对差异归零、回退脚本演练成功

---

## 6. 工期与成本的主要变量

| 变量 | 影响 | 缓解 |
|---|---|---|
| 无源码的老旧系统 | 只能二进制兼容运行，稳定性与性能难保证 | 优先外围系统重建；或采用指令转译方案并实测损耗 |
| 闭源控件 / ActiveX / 报表 | 厂商不提供国产版本即硬阻塞 | S0 阶段书面确认并写入合同附录 |
| 存量 SQL 规模 | 十年核心系统 SQL 可能数以万计 | 自动扫描 + 按调用频次排序，先高频后长尾 |
| 多路线并行 | 适配成本随组合数增长 | 收敛到 1—2 套主流组合；用一云多芯屏蔽差异 |
| 双轨周期 | 直接决定人力与硬件占用 | 按风险分级设定，非核心可缩短 |
| 证书三年有效期 | 可能诱发二次选型 | 合同约定重测与免费适配义务 |
| 人才与培训 | 国产栈排障资料少 | 交付培训 + 建立适配问题清单知识库 |

---

## 7. 本章小结

- 行业进度呈「党政先行 → 金融/电信/电力攻坚 → 医疗教育起步」的梯队，但**渗透率数字口径混乱，只看梯队顺序不看绝对值**。
- 可复用的成功路径是：**预检先行、1:1 环境、双轨并行、字段级比对、灰度切换、回退通道全程开放**。
- 六阶段各有明确门禁，且为全站唯一阶段口径（§3）；任何阶段跳过门禁，问题都会在切换当晚集中爆发。
- Java 栈的改造重点不在 CPU 而在 **SQL 方言、闭源 native 依赖、中间件配置、国密与多架构构建**；纯 Java/开源组件优先保留。
- 性能验收阈值应由项目自行约定并写入合同，不引用「行业经验值」当标准；所有案例数据仅作可行性证据。