软件国产化部署避坑指南（一）

政企项目里，“要国产化”这四个字越来越常见，但它是四个字，不是一件事。我们完整交付过一套：PHP 8.1、ThinkPHP 6、集中式数据库、离线内网、甲方不给管理型权限。下面按真实顺序讲一遍，国产化部署从头到尾怎么做，以及怎么判断一家团队有没有这个能力。

1、接到要求，先别急着说能做

国产化需求下来，第一反应不该是报价，是提问：范围是什么？只换数据库，还是连操作系统、中间件一起换？边界在哪？做完怎么算验收通过？

这三个问题没答案就开工，工期必然失控。我们的做法是先出一页盘点表，把要动的层全列出来，再逐层给判据。

2、盘点清单：国产化远不止数据库

信创清单里数据库是必选项，所以大家盯着数据库。但实际要盘的是五样：CPU 架构、操作系统、数据库、中间件、密码算法。

每一样的换法都不一样。CPU 架构决定驱动包，操作系统决定依赖能不能装，数据库决定框架适配，密码算法决定安全改造量。只盘数据库，等于只盘了五分之一。

3、最大的约束不是技术，是环境

这个项目最大的难点不在选型，在现场：甲方不允许远程操作，离线内网装不了东西，每改一版脚本要等甲方跑一轮，反馈以天计。

解法是自建环境。我们自购云上服务器和数据库实例，做 1:1 的脏环境复刻，先复现、再修复、再验证，闭环之后才整包交付。这一步省下的不是钱，是以天计的反馈周期。

4、双架构是常态，不是例外

国产化现场 x86_64 和 aarch64 并存是常态。同一个驱动包，两边表现不同，自测通过不代表客户现场通过。

我们的脚本按 uname -m自动选架构包，两种架构各带一份，客户内核版本特殊的，配套驱动单独放进 custom/目录。原则只有一条：不改驱动包去弥合版本差异，改了包，后面的验证都不作数。

5、数据库替换：协议兼容只是入场券

数据库是最大头，但坑不在“能不能连上”。协议、认证、SQL 语义、框架、编码、权限，每层都可能单独断：认证方式社区驱动不认，要重编扩展；框架连表结构写死了 public schema，要自建连接器；库编码建库时就定死，提资不讲清整库作废。

一句话总结：换库只是第一步，换完之后每一层都要重新证明能跑。这五层我们各自单独拆过，这里不展开。

6、应用适配的原则：业务代码不动

很多人以为国产化要重写应用，其实原则相反：业务代码一行不动，动的只有适配层。

以我们这套为例：PHP 8.1 和 ThinkPHP 6 原样保留，连接数据库的部分用自建连接器处理 schema 和编码，安全部分用独立的国密实现。适配层薄、边界清楚，出问题能定位到层，不用在业务代码里翻。

7、安全与权限：国产化验收的另一半

国产化验收不只查数据库，还查三件事：国密、口令存储、后台权限。

离线内网装不上密码扩展，国密只能纯 PHP 实现 SM2、SM3、SM4，慢的算法只覆盖低频写接口，高频路径不硬扛。口令用 bcrypt，后台做菜单级权限控制。权限的另一半在数据库侧：甲方不给管理权限，就把 DBA 的动作压到三件一次性的事，之后建表建函数全由业务账号自己做。

8、现场改不起，所以交付要脚本化

离线内网里，手工操作每一步都是风险：改错了没有回滚，说不清就背锅。

所以我们的交付包是三个脚本：一键装驱动、一键验证、一键用业务账号建表。每个脚本执行前后都打印证据，执行前打印环境信息，执行后打印结果。现场人员不需要懂原理，跑完截图就行。

9、验收写成能截图的行

验收判据不是“系统正常”，是能截图的具体行：驱动加载指向哪个库、认证模式是什么、服务端编码和客户端编码各是什么、schema 归属是谁、四个核心接口是否返回成功。

每一条都能在甲方现场独立复现，截图留档。验收材料是证据链，不是说明书。

10、边界要写进方案

能力有边界，方案里要写清楚：国密是软件实现，要过密评上硬件密码机，只换适配层，工期另算；特定内核版本的配套驱动，仍要现场验证。

写边界不是示弱，是对工期负责。含糊的“都能做”，最后变成无限期的返工。

11、具备国产化部署能力，是什么意思

不是“装过国产数据库”，是这一整套都独立跑通过：会盘点、能适配、懂约束、交付靠脚本、验收有判据，并且沉淀成了可复用的资产。

换个现场，变的是库名、schema、内核版本、CPU 架构，不变的是流程和判据。知道每层会断在哪，工期就能估准。这套流程，我们在真实项目里完整跑通过。

总结

国产化部署不是把某个组件换成国产的，是接住一套新约束：范围要盘清、环境要复刻、适配不动业务、安全一并验收、交付全靠脚本。能把这些变成可复现的判据，才叫具备国产化部署能力。