一、政策与采购背景：目录机制、替代节奏与招标评分拆解

信创（信息技术应用创新）不是一个采购标签，而是一套分层目录 + 分批节奏 + 逐层互认的准入机制。理解它的结构，比记住任何一份平台清单都重要：目录决定「能不能买」，节奏决定「什么时候必须买」，互认决定「买回来能不能过验收」。在 n=76 的政企类项目复盘里，最常见的失败不是技术选错，而是把这三件事混在一起谈——用一张「国产化率清单」去回答「适配到什么程度」的问题，结果在验收阶段被逐条追问。

第二个高频误区是把信创等同于「换硬件」。低代码平台处在应用层，它的适配压力并不主要来自芯片本身，而来自平台在运行期是否隐含了境外依赖：容器镜像仓库、中文字体、时区数据库、地图与短信服务、大模型的默认云端端点、在线许可校验、在线组件市场。这些依赖在演示环境里完全不可见，一旦进入 air-gapped（物理隔离）内网就会集中爆发，表现为启动缓慢、首次加载超时、报表乱码、甚至因许可无法回连而进入降级模式。

1.1 信创目录体系：三层结构各自回答什么问题

把三层目录的职责弄清，可以避免大量无意义的争论：对方说「已在目录里」时，追问一句「哪一层的目录、覆盖哪个型号」，多数分歧当场就能收敛。

口径：目录层级划分依据公开政策文件与行业公告归纳；具体准入以项目所在地主管部门当期公告为准，本报告不构成准入承诺。

1.2 国产化替代节奏与预算立项口径

替代节奏直接决定项目的紧迫度与预算来源。从公开政策脉络看，推进顺序大致是党政先行、关键行业跟进、地方国企跟随，并且「新建系统同步信创」已经成为跨批次的长期要求。这意味着企业很少有「等下一轮再做」的空间——尤其是新建业务系统，一旦错过同步信创的窗口，后续改造的成本通常是新建的 1.5–3 倍。

预算口径上，建议在立项文件里就把两类费用分开列示：一次性建设费用（软硬件、平台许可、实施服务、适配与测评配合）与年度运维费用（许可续费、运维人天、备份介质、等保复测）。经验区间是年度运维约占一次性建设的 15%–25%，信创环境的巡检与补丁配合工作量通常高于通用环境，漏列这一块是验收后预算紧张的主要来源。

1.3 招标评分项拆解：权重区间与证据准备

信创类招标的评分结构总体稳定：技术分通常占大头，价格分被压缩但仍是决胜项。下表给出的是权重区间而非固定值，实际以招标文件为准；列出的价值在于提前把「能拿分的证据」准备到位，而不是在标前一周补材料。

口径：权重区间依据 2024–2026 年公开招标文件样本归纳，仅作准备优先级参考；实际评审规则以招标文件为准。

二、信创适配四层模型：等级定义、判定方法与自测清单

信创适配之所以容易扯皮，是因为「适配」这个词没有统一定义。本节把适配拆成两个正交的维度：纵向的四层（芯片、操作系统、数据库、中间件）与横向的五个等级（L0 到 L4）。任何一句「我们支持信创」，都可以被定位到「哪一层、哪一级、什么证据」这三个坐标上。

先明确一个结论：应用层是适配验收的最终入口。芯片与操作系统层面的互认由基础设施厂商提供，但业务系统是否真的能在该组合上稳定运行、能否备份恢复、能否升级、是否在运行期访问境外地址，只能由应用层用实测证据回答。这也是低代码平台在信创项目中责任最集中的地方。

2.1 适配等级：从 L0 到 L4 的判定证据

等级模型的作用是消灭「都适配」这种无效结论。在项目里，招标文件要求的等级、合同承诺的等级、验收时能拿出证据的等级，三者往往不一致——把这三个数字在启动会上对齐，可以省掉后期大量争论。

口径：等级定义为本报告提出的判定框架，用于统一采购、实施与验收三方的沟通语言；等级结论需以本项目环境实测为准。

2.2 四层适配自测清单

下表共 18 项，覆盖最容易在验收阶段被追问的技术点。建议把它作为 POC 脚本的一部分：每一项都给出「通过标准」与「验证方式」，避免结论停留在「试过了，没问题」。

口径：清单依据 micount.cn 政企类项目 POC 脚本归纳（n=76），按验收阶段被追问频次排序；具体阈值需结合本项目资源规格实测确认。

2.3 六类「假适配」信号与验证方法

「假适配」不是指造假，而是指证据强度不足却下了整体结论。下面六类信号在样本中出现频率最高，它们共同的特点是在投标与演示阶段看起来毫无问题。

三、信创低代码平台能力横评：七维度矩阵与明细对照

横评的目的不是给出一个「最好的平台」，而是给出一套可复用的判定语言，让采购方能够在 POC 中把候选平台的差距定位到具体维度上。本节刻意不按厂商排名，而按平台形态做横向比较——因为同一形态的产品往往有一致的长板与短板，而具体厂商的版本与授权差异，必须以本项目 POC 实测与官方材料为准。

3.1 七个维度与评分锚点

评分要能复现，锚点就必须写成「看到什么算 3 分」。下表把每个维度的领先、可用、受限三种状态落到具体可观察的现象上，避免评审时因理解差异产生分歧。

口径：评分锚点为本报告提出的定性判定标准，「领先 / 可用 / 受限」对应该维度 3/2/1 分；具体厂商评分不在本报告结论范围内。

3.2 能力明细对照表

以下是 POC 中真正需要逐项验证的 14 个能力项。建议把它直接做成 POC 记录表，每项填写「结论 / 证据 / 遗留问题」三列，作为适配报告的原始数据来源。

3.3 部署形态选型判定

同一个平台产品往往提供多种部署形态，而形态的选择直接决定成本、可用性与运维负担。把这张表贴在选型会现场，通常比逐条讨论功能更能收敛意见。

四、私有化部署拓扑与高可用：单机、主备与双活

私有化部署的关键不是「把软件装到内网」，而是在网络分区、组件清单、端口策略、切换目标四个层面都留下可验收的痕迹。本节给出可直接抄入实施方案的组件与端口清单，并给出三种拓扑的 RTO/RPO 目标区间。需要强调的是：所有 RTO/RPO 数字都必须经过演练验证，未经演练的目标值只能视为设计意图，不能作为验收依据。

4.1 三种拓扑的适用边界与最小组件清单

口径：可用性目标为设计参考区间，受数据库复制方式、存储类型与中间件能力影响，必须以本项目切换演练实测结果为准。

4.2 端口与网络策略清单

端口清单是等保测评与运维移交都要用到的材料，也是「最小化暴露面」的落点。建议在方案阶段就形成下表，并由网络团队确认后再进入实施，避免实施期反复申请策略导致工期被动。

4.3 Kubernetes 与虚拟机两种承载方式对比

容器化在通用环境里几乎是默认选择，但在信创环境中需要额外确认两件事：容器运行时与国产内核的兼容性、以及镜像离线分发能力。如果这两点无法在 POC 中验证，虚拟机承载往往是更稳妥的起步方式。

4.4 高可用目标：RTO / RPO 与演练方式

RTO 与 RPO 是运维移交材料中最常被抽查的数字，也是最容易「写了没测」的数字。建议把下表作为演练计划表使用：每一项都约定触发条件、目标值、验证方式与演练频次。

口径：目标值区间为设计参考，实测值受复制方式、网络质量、运维流程影响；建议在合同附件中明确「以演练实测值作为验收基准」。

五、等保三级技术对标：控制项逐条对照与整改工作量

等保三级（GB/T 22239-2019）的测评对象是整个信息系统，而不是某个软件。这决定了一个关键事实：低代码平台只承担其中一部分控制项，另一部分由机房、网络、安全设备与甲方管理制度承担。把责任边界划清楚，是控制整改工作量的前提。

实践中常见两种极端：一是把全部等保责任写进平台采购合同，二是把平台说成「与等保无关」。前者会引发无休止的争议，后者会在测评时暴露计算环境层的空白。本节的对照表按控制类 → 承担方 → 平台需具备的能力三层组织，可以直接转成差距分析模板。

5.1 五大类控制项的责任划分

5.2 控制项逐条对照表

下表 19 条覆盖计算环境与边界的核心控制项，每一条都给出「验收方式」与「常见缺口」。建议在项目实施初期用它做一次差距自评，把需要平台配合、需要甲方配合、需要第三方设备配合的条目分开标注，再据此排整改计划。

依据：GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》与 GB/T 25070-2019《网络安全等级保护安全设计技术要求》公开文本；对照关系为本报告归纳，测评结论以具备资质的测评机构判定为准。

5.3 低代码平台需自证的八个控制点

在计算环境层，有八个控制点几乎完全落在平台能力上。它们也是测评机构最常要求现场演示的部分。建议在实施阶段就准备好对应的材料，而不是等测评通知后再临时拼凑。

5.4 常见整改项与工作量估算

整改工作量直接影响上线节奏。下表的「人日」为经验区间，用于排期与预算参考；其中影响节奏最大的两项通常是国密传输改造与字段级权限重构，前者涉及全链路，后者会触发用例全面回归。

六、数据库与中间件适配要点：迁移差异与兼容性坑位

从开源数据库迁移到国产数据库，真正的风险不在「能不能建表」，而在语法细节与语义差异引发的中长期故障：分页结果不稳定、中文写入乱码、并发下死锁概率上升、批量任务执行时间翻倍。这些问题的共同特点是在功能测试阶段不会暴露，只会在数据量增长或并发上升后出现。因此本章的清单必须在 POC 阶段逐条实测，并把结论写入适配报告。

需要先确认一个前提：低代码平台的元数据引擎会自动生成 DDL 与 DML。这意味着数据库差异不只是开发人员的问题——即使业务开发者不写一行 SQL，平台内部的元数据操作仍然会触发方言差异。所以在选型时，「平台是否针对国产库做过元数据层适配」比「平台是否支持自定义 SQL」更关键。

6.1 国产数据库关键差异点对照

口径：差异点依据达梦、人大金仓、openGauss、OceanBase 等官方技术文档与 micount.cn 迁移项目记录归纳；具体版本行为请以目标数据库官方文档与本项目实测为准。

6.2 SQL 兼容性坑位与改写方法

6.3 字符集与排序规则：三级一致性检查

中文乱码在生产环境中极其顽固，原因是它可能发生在四个不同的位置：服务端、库表、连接、以及客户端程序。只检查其中一处，往往会出现「数据库里看着正常、页面上却是问号」的情况。

6.4 中间件替换注意事项

七、性能与容量规划：估算模型、压测阈值与数据量治理

信创环境下的性能往往低于同规格的通用环境，原因包括指令集差异、国密算法的软件实现开销、以及平台在国产库上未充分优化的查询路径。因此容量规划不能直接沿用通用环境的经验值，必须以本项目目标环境上的压测结论为准。本节给出估算模型与阈值区间，用于确定压测规模与预算量级，而不是替代压测。

7.1 从并发用户数到资源规格的估算模型

估算的关键是先区分三个数字：注册用户数、在线用户数、并发请求数。采购与立项文件通常按注册用户报价，而资源规格取决于并发请求数。经验换算关系为：峰值并发 ≈ 在线用户数 × 业务活跃系数（0.08–0.20）× 时间集中度系数（1.5–3.0）；表单填报类业务的活跃系数偏低（0.08–0.12），审批与查询类偏高（0.12–0.20），集中度系数在上班后与交班前 30 分钟取上限。

口径：规格区间为经验参考值，受平台实现、业务复杂度、报表数量与集成调用量影响显著；信创环境建议在估算基础上预留 20%–40% 余量。

7.2 压测场景与验收阈值

压测的常见失败是「只测登录页」。真正需要验证的是数据量最大、逻辑最重、并发最集中的几个场景。下表给出八类场景与建议阈值，阈值应写入合同附件作为性能验收依据。

7.3 慢查询与表单数据量增长治理

信创项目的性能问题往往不是上线时出现，而是运行 6–12 个月后随数据量增长逐渐显现。因此治理动作要前置到设计与运维规范里，而不是等问题出现再优化。

八、迁移与上线实施路线：五阶段、90 天与割接回退

信创项目的实施路线与通用项目最大的区别，在于适配工作必须前置且独立成阶段。把适配混在开发阶段里做，结果是问题在最贵的时点集中爆发。本节的五阶段路线中，「适配」与「试点」各自独立成阶段，每个阶段都有可单独验收的交付物。

8.1 五阶段工作内容、周期与交付物

口径：周期以 90 天为基准，实际周期受适配遗留问题数量、等保测评排期与数据迁移规模影响；样本中适配阶段延期最集中（平均 5 个工作日）。

8.2 割接窗口与回退检查表

割接是风险最集中的时点，而多数事故并非来自技术，而是来自「没有约定什么情况下必须回退」。下表建议作为割接方案的核心部分，并由业务、IT、实施三方签字。

8.3 项目角色与最低投入

九、验收材料模板与清单：七类材料的编制要点

信创项目的验收材料有一个共同特点：它们记录的是过程，而不是结果。适配报告需要对应用例记录，等保备案需要测评机构出具结论，性能报告需要压测原始数据，安全加固需要变更记录。这些材料无法在验收前两周补出来——因为它们依赖的是项目过程中真实做过的动作。因此本章最实用的建议只有一句：把材料编制当作项目计划的一部分，从第 1 周开始收集原始记录。

9.1 验收材料清单

口径：材料清单依据政企类项目验收实践归纳（n=76），具体清单以项目所在地主管部门与甲方要求为准。

9.2 适配报告模板章节要点

适配报告是整个材料包里最容易被要求返工的一份，因为它同时被技术评审、等保测评与审计三方查阅。建议按下表结构编写，特别注意「遗留问题」一章——把已知问题写清楚，比声称一切正常更容易通过评审。

9.3 运维手册目录结构

运维手册的质量直接决定系统一年后是否还在用。好的运维手册不是功能说明书，而是「出了问题该怎么办」的行动手册。建议按下表目录编写，每个流程都写清楚判断条件、操作步骤、预期结果与联系责任人。

十、运维、升级与备份：环境一致性、灰度与告警阈值

信创环境的一个显著特点是补丁与升级节奏更慢、联动影响更大：操作系统升级可能需要重新验证中间件，数据库打补丁可能需要重新验证驱动与连接池参数。因此升级计划不能只列「平台升级」，而要列出四层组件的联动验证清单。

10.1 环境一致性与升级路径

10.2 备份策略与恢复目标

备份方案要能回答三个问题：多久备一次、备到哪里、怎么恢复。只回答前两个的备份方案，在真正需要恢复时会暴露问题。建议把下表作为备份策略附件，并在验收前完成至少一次完整恢复演练。

口径：保留周期与 RPO 为常见实践区间，具体以行业监管要求与甲方制度为准；未完成恢复演练的备份方案不应视为有效。

10.3 监控指标与告警阈值

十一、案例：某省政务 72 小时上线（公开报道整理）

本章案例来自公开报道与厂商公开材料的整理，并对省份名称、项目名称与具体经办单位做了脱敏处理。整理的目的不是复述「72 小时上线」这个结果，而是拆出哪些前置条件让 72 小时成为可能。需要强调的是：72 小时上线的是一个范围明确的新增场景，而不是从零建设整个系统。把这一点忽略掉，就会得出「信创项目可以三天上线」的错误结论。

以下时间轴与动作整理自公开报道的表述，具体技术细节在公开材料中并未全部披露，涉及内部安排的部分已在表中标注为「公开材料未披露」。

11.1 72 小时时间轴与关键动作

来源：公开报道与厂商公开材料整理（含信创全栈环境下的政务场景案例）；时间轴为公开表述的归纳，部分内部安排未在公开材料中披露，引用时请注意区分事实与推断。

11.2 踩坑记录与化解方式

11.3 三条可复用的经验

1. 把「范围」写死再谈速度：能在 72 小时内交付的场景，一定是范围被严格限定的场景。范围模糊时，任何工期承诺都不可信。
2. 前置条件的完成度决定上线速度：环境、基础平台、组件库、接口四项就绪后，新增场景的配置与验证才是真正的短周期工作。排期时应先核算前置条件的完成度。
3. 回退能力是「敢上」的前提：案例中的快速上线建立在设计态与运行态分离、可单独发布运行包、且有回退包的基础上。没有回退能力时，速度承诺会变成风险承诺。

十二、不宜私有化与不宜信创的场景判定与替代方案

本章是全篇最重要的「减法」章节。在样本中，有些项目失败的原因不是做得不好，而是一开始就不该做私有化：数据敏感度不高、用户规模很小、没有专职运维人员、业务变化极快。对这些场景，「替代方案 + 边界说明」比勉强私有化更能保护业务。

12.1 五类不宜私有化的场景与替代方案

12.2 三年总拥有成本临界点判定

私有化与托管的成本结构完全不同：私有化是前期投入高、边际成本低，托管是前期投入低、随规模线性增长。决策的可比口径是三年总拥有成本，并且要把「运维人力」折算进去——这是最常被漏掉的一块。

口径：成本结构为定性对照，具体金额受平台定价、规模、服务范围影响显著，建议结合自身报价单与运维人力成本做三年期对比。

十三、常见问题（FAQ）

数据来源与免责声明

数据来源：本报告数据来自三类可交叉验证来源——① 公开机构与厂商披露材料（IDC / Gartner / 艾瑞及平台官方文档，按引用处标注）；② 算数科技自有交付台账（累计 6000+ 个项目、服务 5000+ 企业客户，按行业与规模分层抽样，样本量与口径在每章末尾注明）；③ 面向企业 IT 负责人的定向访谈与问卷（n 值随章标注）。
引用规范：引用本报告请注明「算数科技（上海思扬信息科技有限公司）· micount.cn」，许可协议 CC BY 4.0。
免责说明：报告中的成熟度等级、试点区间与成本区间为基于样本的经验区间，用于决策起点而非承诺值；任何厂商报价、交付周期以最终商务合同为准。涉及渠道与合伙人经营结果的内容均为个别结果，不构成收益承诺，不保证任何特定收益。

本报告引用口径：企业客户 5000+、交付项目 6000+；口径提示：算数科技为 16+ 家平台官方授权一级服务商、19+ 条可售渠道，网络覆盖 320+ 城市（伙伴协作），可调配顾问 800+（外部伙伴协作网络，非自有员工）。渠道采购通常省 15%–30%，最高可达 55%（视平台与规模）。