国企做信创改造时，最常见的情况是：系统在原有 x86 服务器上运行正常，搬到国产 CPU 的服务器后，启动变慢、某个功能报错，或者压力一上来就出现服务不可用。这类问题大多不是代码逻辑写错了，而是软件栈里某一层与新的指令集、操作系统或驱动没有对齐。
下面按「现象 → 可能原因 → 排查顺序 → 预防措施」来梳理，适用于 B/S 管理系统、APP 后端和常见的系统集成项目。
现象一：能启动但性能下降明显，先查什么
系统能跑起来，但登录、查询、报表生成比原来慢，是最常见的反馈。原因通常在三处：一是所依赖的运行时或中间件在国产平台上没有对应优化版本，走的是兼容层；二是数据库连接池、线程池参数沿用了旧环境的经验值；三是个别计算密集的模块对指令集敏感。
排查时不要一上来就改代码。先确认 JDK、应用服务器、数据库的实际运行版本与平台架构是否匹配，再看慢在哪一段：是数据库慢查询，还是应用侧 CPU 打满。用现成的监控和慢日志通常就能区分。
- 确认运行时与中间件是否有该 CPU 架构的正式支持版本，避免用非官方适配包凑合；
- 对比迁移前后的慢日志，定位到具体接口，而不是笼统地看平均响应时间；
- 检查线程池、连接池、缓存大小是否随新环境的核数与内存重新设定。
如果确认是运行时层面的问题，需要在架构上做取舍，这部分可以结合软件定制开发与系统集成服务中的技术评估环节一起做。
现象二：编译、安装或启动阶段直接报错
编译报错、安装脚本中断、启动时提示找不到共享库，这类问题通常更直接，原因也比较集中：依赖了只有 x86 版本的二进制组件，或者本地库文件、驱动、字体包在国产操作系统上没有对应包。
排查重点是把依赖清单摊开。工程里引入的本地库、第三方 SDK、加密组件、报表导出组件，都需要逐一确认是否有目标平台版本。纯 Java 或 .NET 的托管代码相对容易迁移，带本地库的组件是主要风险点。
依赖层面的排查要点
- 列出全部第三方组件与本地库，标注是纯托管代码还是带原生库；
- 确认每个组件在目标 CPU 与操作系统组合上有没有官方支持；
- 对没有支持的组件，评估替代方案或自行封装兼容层；
- 记录每一项的结论，形成可复核的依赖台账。
这一步的价值在于留下证据。信创改造通常需要向主管部门说明适配范围，台账本身就是材料。类似的做法我们在政府与国企国产化改造案例中已经按项目形成固定模板。
现象三：功能测试都过，一上压力就出问题
单点功能验证没问题，但并发一上来出现连接超时、内存溢出或进程异常退出，通常是并发模型与硬件特性不匹配。国产 CPU 的核数与主频组合和原有服务器差异较大，按旧经验配置的线程数和内存参数容易失衡。
排查顺序建议由浅入深：先做单机基线压测，再扩到集群，最后做混合场景。压测里要区分应用侧和数据库侧的瓶颈，避免把数据库参数问题误判为应用适配问题。
- 先确认单节点在目标配置下的稳定承载区间，再谈集群扩展；
- 留意文件锁、内存映射、大页等与平台相关的配置项；
- 长时间稳定性测试比短时峰值测试更能暴露问题，建议安排持续运行观察。
兼容性测试的排查顺序
把上面的方向串起来，推荐按以下顺序推进，每一步有结论再进入下一步，避免问题交叉导致定位困难。
- 明确范围：列出待测系统清单、依赖的中间件与数据库、使用的客户端环境。
- 搭环境：在与生产一致的国产 CPU、操作系统、中间件、数据库组合上搭测试环境，配置尽量对齐。
- 静态梳理：检查编译产物、本地库、驱动、字体、加密组件的平台支持情况，形成依赖台账。
- 功能验证：按业务主流程逐条走通，重点覆盖导入导出、报表、打印、文件上传等外围环节。
- 接口联调：验证与 ERP、HR、财务、OA 等系统的接口在国产环境下是否正常，必要时在校验、编码、时间格式上做兼容处理。
- 性能与稳定性：先单机后集群，分场景压测并观察长时间运行表现。
- 回归与记录：把发现的问题、修改点、复测结果整理成可交付的测试报告。
国产 OA 的二次开发在这种场景下尤其要留意：组织权限、流程表单、与业务系统的对接，都要在目标平台上重新验证一遍。这部分不属于版本细节，关键是确认功能行为一致。
预防措施：把适配工作前置
等到临近上线才发现平台不兼容，代价往往比预想的高。比较稳妥的做法是在项目早期的 POC 阶段就把目标平台验证纳入进来，尤其是新立项的定制开发。
- 技术选型时优先选有明确国产平台支持的运行时、中间件和数据库组合；
- 在需求调研与方案阶段就确定适配范围与验收口径，写进交付物清单；
- 把兼容性测试报告作为上线验收的必备材料之一，而不是可选项；
- 保留依赖台账并随版本更新，方便下一次环境变更时复用。
如果系统已经在线运行多年，改造时要把旧系统升级与重构的工作量一并考虑，避免为了适配而打乱原有业务节奏。相关工作可以参照我们的服务范围与交付流程做分阶段安排。
可直接照做的兼容性测试清单
把下面这份清单作为开工前的对照表，逐项打勾，能减少大部分返工。
- 目标环境的 CPU 架构、操作系统版本、中间件版本、数据库版本是否已确认并记录；
- 全部第三方组件与本地库是否完成平台支持核对，是否留有台账；
- 主业务流程、外围功能、打印导出是否都已列入测试用例；
- 与外部系统的接口是否在国产环境下完成验证；
- 性能测试是否覆盖单机、集群与长时间运行；
- 发现的问题是否有修改记录与复测结论；
- 测试报告是否包含环境说明、范围、结论与遗留风险；
- 是否明确上线后的观察期与回退预案。
按这份清单推进，兼容性测试就不再是一次性的救火，而是有据可查的工程步骤。
