SpringBoot信创项目怎么验收？从数据库迁移到交付证据
信创项目交付时，最容易出现的分歧，是双方说的“支持”不是一回事。开发团队已经导入数据库、启动应用；采购方以为所有模块、目标服务器和办公终端都已验证。
解决这个问题，需要把环境、版本、操作和结果一起写进验收范围。一句“兼容国产数据库”，无法代替这些信息。
下面以RuoYi Office在2026年9月的信创实验记录为例，说明一套SpringBoot企业系统怎样形成可追溯的交付证据。达梦、openGauss和PostgreSQL走到了不同的验证深度，这些差异本身就应该成为交付材料的一部分。
从转换到交付，每一级需要不同的证据；上一级成功不能自动覆盖下一级。
第一次对齐，先问“在哪套环境、哪个版本上通过”
本轮实验采用openEuler 24.03 LTS SP2，CPU架构为x86_64，配合毕昇JDK 17、Tengine、Redis和Podman。应用采用SpringBoot单体形态，再分别切换数据库Profile。
这个环境选择有一个实际好处：先固定应用和基础设施，观察数据库切换带来的变化。若每次同时更换操作系统、JDK、网关和数据库，遇到登录失败时，很难判断应该先查哪一层。
但实验室通过不等于客户环境已经通过。客户如果指定ARM服务器、不同数据库介质或商业应用服务器，就需要新建一条目标环境记录，而不是把原报告的数据库名称复制过去。
一份可以交接的环境清单，至少把下面四组信息写全。
| 记录对象 | 应记录的内容 | 缺失会造成什么问题 |
|---|---|---|
| 软件输入 | 源码基线、构建包、schema与数据文件 | 无法知道报告对应哪次交付 |
| 基础环境 | CPU架构、OS、JDK、接入层、缓存 | 现场与实验室差异被隐藏 |
| 数据库路径 | 数据库及驱动版本、兼容模式、Profile | 同名数据库可能走不同方言 |
| 验证对象 | 模块、账号角色、操作步骤、结果 | “通过”没有可重复的含义 |
特别需要检查时间：本轮PostgreSQL记录沿用8月31日的数据基线，9月仅补了审批必需字段。因此，这份实验结果不能自动覆盖之后所有新增业务，也不能直接作为10月最新版本的全量验收结论。
交付时可以采用一个简单原则：环境没变但应用变了，要看受影响模块；应用没变但环境变了，要重新验证运行路径。两边都变了，更不能只沿用旧结论。
SQL转换验收：文件生成了，还要证明什么
项目把转换工具封装成统一流水线，输出目标SQL、manifest.json及转换警告。这样，接手人不必凭一个文件名猜测它从哪里来。
manifest记录产物哈希、额外处理、兜底表和流程仓库审计。校验脚本中有这样一段实际检查，位置是ruoyi-office-db/tools/xinchuang/verify_manifest.py：
output=payload.get("outputs",{}).get(db_type,{})ifnotoutput.get("sha256"):errors.append(f"{db_type}: missing output sha256")ifoutput.get("converter_warnings",{}).get("line_count",0)andnotoutput.get("converter_warnings",{}).get("path"):errors.append(f"{db_type}: warning count exists without warning path")fallback=payload.get("fallback_tables",{}).get(db_type)iffallbackisNone:errors.append(f"{db_type}: fallback_tables was not recorded")这段代码检查的是审计材料有没有缺项。它没有连接目标数据库，也不负责证明SQL执行成功。当前实现对产物要求哈希字段存在，不是在这里重新计算文件并逐字节比对；现场交接仍应核对实际文件与记录是否一致。
为什么警告和兜底表值得单独留下？本轮转换需要为遗漏的6张ERP表补充处理，归档明确要求继续比对字段、索引和默认值。如果只交一份“最终SQL”，后续团队可能根本不知道这些表有不同的转换路径。
还有一个更隐蔽的修复：原先较宽的ENGINE.*清洗规则会误伤Flowable插入数据里的ENGINE_VERSION_，导致部署与流程定义数据被截断。包装层改为只匹配建表选项，相关实现位于converter_adapter.py：
r"(?im)^(\)\s*)ENGINE[^;\r\n]*COMMENT"r"(?im)^(\)\s*)ENGINE[^;\r\n]*;"这里展示的是两条限定匹配范围的正则，不是让读者直接执行一个独立转换脚本。它们把“ENGINE选项”限制在建表结束括号之后，避免把同名列当成表选项清洗。
因此，表数量接近源库只能作为初查。流程定义、二进制内容、默认值、索引和主键策略都可能在“表已经建好”以后继续出问题。
实库导入和应用启动，要分别验收
达梦这条路径没有把命令行导入的完成提示作为最终依据。实验记录发现，超长INSERT、BLOB与JSON会受到导入工具物理行处理的影响，改用官方JDBC逐条执行，大BLOB通过PreparedStatement.setBytes处理。
这意味着，交付材料不仅要说明“导入哪个SQL”，还要说明“用什么方式导入、哪些错误允许忽略”。若换回另一个导入器，相同SQL未必得到相同结果。
应用启动则是另一组工作。项目按数据库使用不同Profile，同时处理Flowable数据库识别和Quartz持久化委托：
| 目标库 | Flowable适配 | Quartz委托 |
|---|---|---|
| 达梦 | JDBC产品名映射为oracle | StdJDBCDelegate |
| openGauss | 产品名映射为postgres | PostgreSQLDelegate |
| PostgreSQL | 原生数据库识别路径 | PostgreSQLDelegate |
这是应用组件内部的方言选择，不代表达梦变成了Oracle，也不代表openGauss与PostgreSQL所有行为都相同。
PostgreSQL记录就包含一个具体反例：为导入0/1，转换阶段先把相关bit字段处理为int2；Flowable的标志列再改回需要的布尔类型，否则运行查询会遇到smallint = boolean类型比较错误。
这类问题只能沿运行链路检查。DDL语法合法、数据成功导入，与框架参数绑定后能否执行查询，是不同的验收项。
代表业务闭环，要留住同一张单据
应用健康检查为UP、管理员能登录，说明了基础启动结果。要判断审批业务是否真正可用，还需要让一张单据经过发起、办理和回查。
本轮达梦记录保留了单号OA103-2026090300004，流程结果为completed，业务PROCESS_STATUS=2。PostgreSQL在9月7日完成首轮闭环后，还保留了第二张复测单据OA103-2026090700004。
这些标识的作用，是让界面结果、业务记录和流程实例能够互相对应。否则可能出现：截图来自第一次申请，数据库查的是第二张单，最终报告却写成一次完整成功。
下面这张矩阵来自历史归档，读法比一个统一的绿色勾更明确。
依据2026年9月实验记录整理的验证矩阵，不是终端截图，也不是厂商认证。
openGauss完成了导入、启动、登录和表单填写到提交前，但没有将审批闭环作为最终证据。它应该保持这个状态，而不是因为另一个PostgreSQL兼容路径成功，就顺手标成审批通过。
现场可把每个验收项拆为五个字段：环境编号、执行步骤、预期结果、实际结果、证据位置。结果用“通过、失败、未执行”分别记录；对失败项写修正和复测，不用一个含糊的“基本支持”收尾。
到客户现场，还缺哪几张验收单
本轮已验证基础设施中包含Tengine与Redis，但没有把TongWeb、BES的WAR部署、数据库高可用、全模块冒烟、文件上传和性能作为通过项。金仓、瀚高实库与国产CPU整机认证也不在已完成范围内。
这些范围不是报告的小字附注，而是现场工作计划的输入。例如合同要求带附件的审批，需要另加上传、预览、下载和权限检查；要求故障切换，需要指定故障条件、恢复目标和业务一致性检查。
下面是一份可直接拿去开交付会议的责任划分建议。它是由本轮经验整理的工作安排，不是已经完成的额外测试。
| 交付问题 | 需要的产物 | 谁一起确认 |
|---|---|---|
| 本次安装的到底是哪一版 | 构建包、SQL、配置模板及哈希清单 | 研发与实施 |
| 现场环境是否偏离实验室 | 环境差异清单和新增验证项 | 实施与客户运维 |
| 哪些业务可签收 | 模块范围、测试用例、实际证据 | 业务负责人及测试 |
| 未通过项如何处理 | 问题记录、修复版本、复测结果 | 研发及交付负责人 |
| 升级失败如何恢复 | 备份、回退步骤与演练记录 | 运维及交付负责人 |
尤其要避免把实验室的宽权限原样带进生产。达梦归档记录过实验阶段使用的宽查询权限，并明确客户环境应收敛到所需系统对象的最小权限。这类变更要由现场验证确认，不能在说明书里写一句“按需授权”就算交接完成。
宇擎建议：先把验收做小、做实，再扩大支持范围
对于准备落地SpringBoot信创项目的团队，第一步是固定一个目标环境与一个业务基线，把转换、导入、启动、代表流程和回查完整串起来。每一步保留输入和结果，出现错误后能找到对应文件与实例。
对采购和实施团队，优先索取具体版本及验证矩阵，区分“框架已有适配”“指定环境已验证”和“现场待验证”。不要把驱动存在、兼容协议、实验室结果以及正式认证混写成同一种支持。
如果项目要求的是全模块、高可用或指定国产整机，而目前只有登录和一张审批单的证据，就不适合直接按整体验收通过处理。应先把差额转成明确的测试任务，安排责任人和复测方式。
最终值得交付的，不只是能启动的应用包，而是一条能够复查的证据链：这套输入，在这个环境，执行了这些步骤，得到这些结果；其余范围另有计划。这样，研发完成的工作能被客户理解，客户提出的新要求也有清楚的起点。
信创体验
RuoyiOffice 是一套面向中小企业的企业管理一体化平台，思路是「一个平台管好整个企业」：不用再分别采购 OA、人事、客户管理、进销存好几套系统，数据在一个平台里打通。它的核心特性有这几块：
- 业务全覆盖，按需启用：OA 协同、流程审批、人力资源、客户管理（CRM）、进销存（ERP）、资产管理、仓储管理、企业商城、数据报表、物联网等十余个子系统，模块化组合，用到哪个开哪个。
- 可视化流程引擎：仿钉钉、飞书的流程设计器，同时支持 BPMN；会签、或签、依次审批，抄送、转办、委派、加减签，父子流程和超时提醒都有，请假、入职、转正、调动、离职这类单据都能走线上审批。
- PC 端加移动端：PC 端基于 Vue 3，移动端基于 UniApp，审批、打卡、待办、公告、企业云盘在手机上也能处理。
- 微服务架构：后端基于 Spring Boot 和 Spring Cloud Alibaba，网关、注册配置中心、消息队列齐全，各模块可以独立部署、按需扩展。
- 内置 AI 能力：可对接 DeepSeek、通义千问等大模型，提供 AI 对话、写作、绘图、知识库问答和思维导图。
- 企业级底座：多租户、细粒度的角色和数据权限、单点登录，还有代码生成器，二次开发省事。
