企业官网建设流程全解析

做信创项目这几年，被客户问得最多的一句话就是“你们的产品过国测了没有？在不在2024的信创目录里？”说句实话，很多同行自己都没把这个问题完全搞清楚，有人拿着一个过时的截图当依据，有人把“适配认证”和“名录收录”混为一谈，真到投标评审环节才发现问题。这篇文章把信创国测清单名录这件事从头到尾讲一遍，包括清单到底是什么、2023与2024年有什么变化、怎么查、怎么用，同时把我自己在实际项目里踩过的坑和总结的排查套路一并交代清楚。无论你是集成商的售前、甲方信息中心的选型负责人，还是刚接触信创基础设施的研发，应该都能从中找到用得上的东西。

1. 国测清单到底是什么：先把概念对齐

1.1 为什么会有这份清单

信创要解决的核心问题是整个IT产业链的国产化替代，从最底层的CPU、操作系统，到中间的数据库、中间件，再到上层的办公软件、业务应用。但“国产化替代”不能靠厂商自己说“我国产”就算数，总得有一把能横向比较的尺子。于是就有了由国家级权威测评机构牵头，依据一批测试规范和标准，对送测产品做功能、性能、兼容性、安全性检测，通过之后把型号纳入官方目录，形成对外公示、可查询的产品清单。这就是大家口中常说的“国测清单”或“信创名录”。

这份清单存在的意义，我给客户打过这样一个比方：装修买材料，不能光听建材店老板说“这个瓷砖环保达标”，你得看质检报告、看合格证。清单就是那个“质检报告合集”，它让甲方在选型时有据可依，让集成商在投标时能快速证明“我用的东西是合规的”，也让项目评审有一个统一的抓手。所以清单不是给厂商自嗨的，它的核心服务对象是用户和项目验收方。

1.2 清单、目录、适配认证：三个名字别搞混

这也是我这些年见到的第一大认知误区。大家平时嘴里说的“信创目录”“国测名单”“适配认证”其实是三件关联但不等同的事情：

• 国测清单/名录：国家级测评机构对产品进行正式检测后，通过的型号被收录到官方名录中，包含证书编号、有效期和测试结论。这是最硬的一个依据，投标和验收时评审专家主要看这个。
• 信创产品目录：更多指地方政府或行业主管部门发布的推荐目录，比如某些省份的信息技术应用创新产品目录。它通常以国测清单为基础，再结合本地适配验证进行增补，部分目录会收录“经过本地适配验证”的产品，这些产品不一定都有国家级测评证书。
• 适配认证：指芯片厂商、整机厂商、操作系统厂商之间互相做的兼容性互认，比如某软件厂商和麒麟软件联合出具的兼容性认证证书。它解决的是“能不能跑起来”的问题，不能替代国测。

三者的关系可以这样理解：适配认证是“局部证明”，说明我这款OS能配合好；国测清单是“通用证明”，说明产品通过了国家检测标准；信创产品目录是“采购导引”，是在满足国测的基础上结合本地环境推荐的采购范围。

注意：实际项目里，招标文件如果写“要求提供信创目录内产品”，一定要先跟招标方确认，它指的是国测清单还是本省目录。这两个对产品范围的要求差别很大，漏看一个词可能导致废标。

1.3 谁在编写和更新：权威来源必须搞清楚

清单不是某个商业机构随便发布的，背后是具备国家级检测资质的测评机构和相关标准化组织。测评机构会定期组织送测、复测、抽检，并对外公布通过名单。更新周期上，一般每年会集中发布几个批次，年中偶尔补充新的通过名单。2023年和2024年这两年的变化尤其大，原因是国产基础软硬件的成熟度上了一个台阶，送测数量明显变多，清单的厚度和覆盖范围都比前几年扩张了不少。

为什么反复强调“看权威来源”？因为市面上很多第三方网站、公众号会转载清单，转载过程中容易出两个问题：一是内容滞后，转载的是去年甚至前年的版本；二是信息截取不完整，把某个批次的部分名单当成全部。我的习惯是，任何需要对外使用的清单信息，必须回到官方发布渠道核对一遍，截图存档，标注查询日期。别嫌麻烦，评审专家追问的时候，一张官方截图比十句口头解释都管用。

2. 2023、2024版清单的几大变化

2.1 产品类别明显扩容

对比2022年及之前，2023年、2024年的清单给人最直观的感受就是“厚”了。早期信创清单集中在CPU、操作系统、数据库、中间件、办公软件、整机这些基础类别，而这两年又增加了不少新方向，比如电子公文系统、版式软件、PDF阅读器、电子签章、协同办公平台等应用层产品也被大量纳入。

这个变化背后其实反映了一件事：信创正在从“基础软硬件替换”走向“业务应用适配”。如果底层换国产，上层应用还是老一套，用户实际用起来感受不到变化，落地效果会打折扣。所以清单扩容，本质上是在引导整个生态往全栈国产化走。我接触过的项目里，2023年很多还在纠结操作系统选哪个，2024年已经开始追问“业务系统能不能跑在国产数据库上”，这个趋势和清单变化是同步的。

2.2 CPU与操作系统的格局变化

CPU领域虽然主流还是那几家，但不同架构产品在清单中的分布有明显变化。早期项目里ARM架构（如鲲鹏、飞腾）和x86架构（如海光、兆芯）的入围产品居多，龙芯的LoongArch架构这两年也逐步在党政、金融等领域放量。选CPU架构不能只看清单，更要看背后的生态，如果项目里要跑的是重量级商业软件，就得确认这款软件有没有对应架构的版本。

操作系统这边，麒麟和统信UOS依然是清单里最常见的两个名字，但细心的人会发现，以它们为基础的衍生版本也在增加，比如面向服务器、嵌入式、桌面等不同场景的专门版本。这里有个很实用的提醒：清单里写的是具体版本号，不是笼统的“银河麒麟”四个字。送测或采购的版本必须和清单登记的版本完全一致，激进的新版本或老旧的补丁版本都不行。我们在验收时遇到过这个问题——系统装的是同一系列但小版本号不同，评审差点没通过，最后现场升级回清单登记版本才解决。

2.3 数据库、中间件与办公软件的变化

数据库方面，清单里的国产数据库已经非常丰富，关系型的有达梦、人大金仓、GaussDB、OceanBase、TDSQL等，时序数据库、图数据库也在逐步进入。中间件以东方通、金蝶天燕等品牌为主。办公软件方面，WPS和永中Office是常客，版式软件里数科、福昕等也都在列。

但进入清单只代表起点，真正考验它们的是真实业务负载下的表现。我在项目里经常提醒团队：清单只代表“通过检测”，不代表“能直接替换你现有的Oracle/MySQL”。比如从Oracle迁移到达梦，SQL语法兼容性、存储过程改写、字符集差异、序列和触发器的行为，每一项都要实际测试。清单帮你筛出了候选池，但最终选谁，还是要靠压测和迁移演练来决定。

3. 实操：怎么查清单、怎么验证产品是否在列

3.1 官方查询渠道

目前比较稳妥的查询路径包括几个方向：一是国家级测评机构的官网与公示平台，上面会按批次发布通过测试的产品名单，部分支持按产品类别、厂商名称检索；二是信创相关公共服务平台，个别地方也有自己的查询入口；三是厂商官网，通过测评的厂商一般都会展示证书扫描件，可以要求厂商提供原件核对。

需要注意，不同渠道的数据更新时效不一样。国家级平台最权威，但查询方式可能偏传统；厂商官网更新积极，但存在展示不全或旧证书未下架的情况。我的做法是：官方平台为主，厂商证书为辅，两个口径交叉验证。两者信息冲突时，一律以国家级平台的公示为准。

3.2 查询时的关键字段

查询清单时，别只盯着产品名称看，下面这几个字段每一个都要核对：

• 产品名称与型号：必须精确匹配，型号不能有出入。有的产品名称和商标名接近，但实际不是同一个版本，容易看错。
• 证书编号：记录完整的证书编号，投标文件里要附上。
• 测评结论：注意是“通过”还是“有条件通过”，有条件通过的通常附带整改或限制说明。
• 有效期：证书一般有有效期，过期产品不能作为有效证明。
• 登记版本号：操作系统、数据库这类软件产品尤其要关注版本号，版本不符等于无效。

我个人的习惯是把这些字段整理成一张核对表，每个候选产品一行，后面加上“官方链接”“查询日期”“核对人”，在选型和投标阶段反复使用。这个习惯帮我避免过很多次低级错误——有一回项目里某款产品官网显示在列，跟官方平台一核对，型号差了一个字母，差点出大问题。

3.3 如何判断“适配”是否真实可用

清单查询解决了“合规性”问题，但解决不了“好不好用”的问题。判断一款在列产品是否适合你的项目，至少要补做三件事：

1. 查看该产品是否有与你目标CPU/操作系统组合的适配认证，比如你的环境是飞腾+麒麟，就找有没有对应的互认证证书；
2. 要一份官方或社区的性能基准测试数据，用自己的测试用例跑一遍，别只看厂商宣传的tpmC数字；
3. 确认原厂在本地是否有技术支持或服务渠道。国产软件很多走原厂直服模式，服务半径直接影响问题响应速度。

注意：有些厂商会把“兼容性互认”包装成“通过国测”，这两者完全不是一个量级。兼容性互认只说明两个产品放在一起能跑，国测则是对产品本身的全面检测。投标文件里千万不能拿互认证书冒充国测证书，被评审核查出来，性质就完全不同了。

4. 基于清单做信创适配与落地选型

4.1 选型思路：从业务倒推，不要从清单倒推

很多项目组的做法是打开清单，从第一页开始选，哪个名气大选哪个。这是典型的路径依赖，选出来的方案大概率要返工。正确的思路应该从业务倒推：先梳理信息系统的技术栈，搞清楚现在用的操作系统、数据库、中间件、运行时环境是什么版本，有哪些依赖组件，然后把每个组件的替换候选从清单里捞出来，逐项做兼容性比对。

以一个小型政务系统为例，原技术栈可能是CentOS 7 + Oracle 11g + Tomcat 8，迁移时就要考虑：操作系统换哪款Linux（麒麟服务器版或统信服务器版都行）；数据库换哪款（达梦或人大金仓，同时确认是否兼容Oracle模式）；中间件是否换国产中间件还是继续用Tomcat。如果Tomcat能正常跑在国产操作系统上，也不一定强制换。每一个选择都要做矩阵测试：OS、数据库、中间件，交叉组合是否稳定。

4.2 适配流程的四个阶段

我自己总结的适配落地流程分四步，每一步都有明确产出物：

阶段一：信息收集与评估。整理资产清单，明确每个系统的部署架构、依赖关系、端口协议、外设型号，形成一份迁移评估报告。这一步最耗时，也最关键，评估漏项会直接导致后面测试反复。

阶段二：测试环境搭建与验证。在隔离环境里搭建国产技术栈，按业务场景跑功能测试、兼容性测试、性能压测。这个阶段要特别关注旧版SDK、动态库依赖、加密组件、打印控件这些容易出问题的地方。

阶段三：试点迁移与联调。选一个非核心系统先切过去，和上下游系统做接口联调，验证数据迁移脚本，观察系统日志和监控告警。试点阶段要建立详细的回滚方案，出问题能快速回切。

阶段四：推广上线与运维。把试点经验固化，再复制到其他系统。上线后至少观察一到两个完整业务周期，关注资源使用率、慢查询、内存泄漏这些问题。信创环境下很多监控工具也得跟着换，常见做法是选择支持国产化环境的运维监控平台，或者自研脚本做指标采集。

4.3 常见误区：适配不是“装上能开机”就算完

这里多写几句，因为我确实看到太多团队把适配理解得太浅。

第一个误区是“跑起来就算适配”。MySQL能连上、页面能打开就当结束了，真正上线后才发现定时任务不触发、短信接口乱码、文件预览异常，全是隐患。

第二个误区是“架构不用动”。实际上从x86迁到ARM，或者从CentOS换到国产操作系统，很多隐式依赖会浮出水面，比如某些C扩展模块没有对应架构的预编译包，需要重新编译。

第三个误区是“数据同步过去就行”。数据迁移里最容易翻车的是字符集、时区、自增主键冲突这几件事。

我比较推荐的做法是：在测试阶段就把问题充分暴露出来，故意用极端字符测试、切换时区测试、并发跑批测试，把边界情况都压一遍。适配工作做得越早越细，上线后的救火成本就越低。这一点在信创项目里尤其明显，因为生态还不够成熟，很多问题都是首次遇到，没有现成解法，只能靠测试覆盖来兜底。

5. 清单之外的真实问题与排查技巧

5.1 产品查不到或不在清单里怎么办

项目里最常遇到的尴尬局面是：想用的产品很成熟，但在清单里查不到。这时候先不要急着指责厂商，分情况处理。一种情况是产品其实通过了，只是还没公示或者公示渠道没覆盖到，可以直接联系厂商要证书编号，再到官方平台反查。另一种情况是真的没纳入清单，那就得看项目是否强制要求清单内产品。如果强制要求，只能换产品；如果只是鼓励性要求，可以把适配认证和实际测试报告作为补充材料提交评审。

我遇到过不少项目实际上对清单是“软约束”，但你需要提前跟招标方确认口径，别等开标前才发现理解偏差。另外，有些厂商会提供“产品在送测流程中”的说明，意思是测试还没出结果。这种状态在项目里要谨慎使用，因为投标时评审只看已公示的结果，不看“在路上”的承诺，一切以最终公告为准。

5.2 信创环境里的离线安装问题

信创终端和服务器很多部署在内网隔离环境，没有外网，软件包和依赖库都得离线准备。这里有一个很多人都会踩的坑：原本在CentOS上yum安装挺流畅，切到国产操作系统之后，软件源里很多包没有或者版本对不上，离线包又缺依赖，装到一半提示缺lib。

我的办法是：在测试阶段就搭一个和现场一致的离线环境，提前把所有依赖包用清单方式记录下来，用包管理器下载完整依赖树，包含所有间接依赖，一并拷到现场。同时准备一些通用排查工具的离线包，比如telnet客户端、tcpdump、lsof这些基础命令，因为现场环境经常连基本的网络排查命令都没装。离线环境下装telnet要看操作系统的包管理方式，麒麟、统信这类系统用apt/dpkg或yum/dnf，不能直接拿CentOS的rpm包乱装，架构不对、依赖不对都会失败。

注意：离线安装不只是包的问题，还涉及签名和源配置。有的系统默认不启用本地源签名校验，安装时会提示不安全，需要提前评估是否能接受，或者预先导入对应的公钥。

5.3 信创实时云渲染这类新应用如何与清单配合

2024年之后，很多项目从“办公替代”走向“生产系统替代”，图形渲染、三维设计、视频创作这些重度应用也开始跑在信创环境上，于是出现了“信创实时云渲染”这类需求。简单说就是把GPU渲染能力放到服务器端，终端用瘦客户机或云终端去访问，既满足办公场景对终端算力的要求，又方便统一管控数据。

这种场景下，云渲染平台自身通常需要做国产化适配，包括对国产GPU、国产操作系统的兼容。选型的时候即便云渲染平台不在传统信创目录里，它底座所用的操作系统、数据库等仍然要看是否在清单内，同时要关注平台是否有针对国产GPU的适配优化。我的建议是：把云渲染平台当作“应用软件”对待，要求厂商提供信创环境下的实测报告，尤其是多路并发渲染的稳定性测试，这是它与传统办公应用差异最大的地方。

5.4 目录查询的时效性管理

最后说一个管理层面的经验。信创清单是动态更新的，今天查的结果不代表三个月后还有效，产品可能因版本升级、证书到期、抽检不通过而下架。我所在的团队现在对所有核心产品建了一个“信创合规状态台账”，每月更新一次，内容包括清单状态、证书有效期、版本变化、复测提醒。这个台账在投标响应和项目验收时价值极高，因为评审经常抽查证书的有效性，台账能帮你第一时间发现哪款产品该续测了、哪个版本该升级了。

台账的维护不需要太复杂，一个共享表格就行，关键是固定责任人、固定更新频率，并把台账和采购、研发、售前的流程绑定，让信息真正流转起来，而不是躺在表格里吃灰。

最后再说一个我个人的小习惯：但凡要在项目里引用清单内容，一定是先截官方页面的完整地址栏，再标注查询日期，最后存档。这个习惯看着笨，但在多次评审和答辩中救了我。做信创项目，拼的很多时候不是谁信息多，而是谁的信息更准确、更可回溯。清单本身是死的，怎么用是活的，把这套方法用起来，大概率能少走我这些年走过的弯路。