数值模拟仿真软件桌面前端技术选型与自主可控方案对比报告

版本：v2.0（选型评审稿）
编制日期：2026-08-16
适用范围：Linux 原生桌面 CAE 前后处理软件（非 Web）

一句话结论： 在“CentOS 7 起步、后续适配银河麒麟、百万级流畅/千万级可开”的约束下，首选 Qt Widgets + VTK + Qwt + HDF5：CentOS 7 以 Qt 5.15.19 + VTK 9.4.x 作为待验证组合，银河麒麟另建 Qt 6 + 对应 VTK 构建线；所有第三方软件都要留存源码、许可证和构建记录。严格国产方案应作为独立路线保留，不能用“国产外壳仍依赖 Qt/VTK”冒充全栈国产。

重要边界： 本报告中的“自主可控率”是项目内部决策模型，不是测评机构结果。当前尚未取得客户或测评方的正式评分表，任何方案均不能据此承诺“必然过审”。正式投标前必须让评审方书面确认：国产框架是只看直接依赖，还是穿透到底层 Qt、VTK、Mesa、GCC、HDF5。

0. 一页纸结论摘要

0.1 选型结论

0.2 推荐技术基线

0.3 许可证与缩写说明

许可证决定“别人的代码能不能放进我们的闭源产品、需要履行什么义务”。它不直接决定软件是不是国产，也不等于软件安全等级。

下表覆盖本项目候选组件直接涉及的许可证，以及评审中常见的对照类型；它不是全部开源许可证目录。

“第三方软件清单”不是许可证，而是记录产品所用外部软件名称、版本、来源、许可证和处理方式的审计材料。

以上是工程选型解释，不代替正式法律意见。最终发布前仍需按实际使用模块和链接方式复核。

0.4 双口径结果

分数是基于第 5 章公开公式得到的内部评估值。严格分低不代表软件不安全，也不代表无法进入信创市场；它只表示在“穿透审查原始权利主体”的定义下，国外开源底层不会被算作国产。

0.5 立即决策

1. 立项采用方案 A，V1 统一使用 C++17。
2. CentOS 7 以 Qt 5.15.19 + VTK 9.4.x 作为候选组合，目标机验证通过后再定版；银河麒麟版本明确后另建 Qt 6 + 对应 VTK 构建线。
3. 必须取得一台海光 x86-64 和一台飞腾/鲲鹏 aarch64 实机；没有实机，不宣称已适配。
4. FastCAE 只做代码和架构审计，不作为 V1 运行时底座；若招标明确要求国产 CAE 底座，再启动精简改造评估。
5. 将“框架国产”与“源码可控”分别作答，不用一个模糊百分比掩盖底层依赖。

1. 需求边界与验收基线

1.1 产品边界

• Linux 原生桌面应用，非 Web。
• 交互形态：菜单/工具栏、特征树、属性面板、Dock 多窗口、中心三维视口、XY 曲线窗口。
• 只做 CAE 前后处理：打开网格、云图、等值面、切平面、旋转/缩放、拾取/查值、残差曲线。
• 不做 B 样条造型、草图/特征建模、布尔运算、UG/NX 二次开发或完整网格生成器。
• 附件中的参数化造型软件仅作为行业背景和既有 Qt 经验依据；新工作台通过文件/进程接口接入其输出，不合并其几何建模职责。

1.2 运行与数据基线

1.3 建议验收指标

以下是立项指标，不是当前已实测数据：

2. “开源 ≠ 自主可控”的判定边界

2.1 官方信息能支持什么

中国信息安全测评中心 2026-06 发布的《安全可靠测评工作指南 V4.0》当前主要面向 CPU、AI 芯片、操作系统、数据库和打印机主控芯片，并强调研发环境、代码数据、知识产权、开源许可履行、供应链持续性和可追溯性。该公开范围不直接等同于本桌面应用的采购评分表。官方指南

因此：

• 不能把本报告分数宣传为国家测评成绩。
• 也不能推导“应用软件使用 Qt 一定可以/一定不可以”。
• 可借鉴其方法：证明境内研发、核心代码、许可履行、供应链和持续维护能力。
• 最终准入仍取决于客户招标文件、兼容认证和测评方对依赖穿透层级的解释。

2.2 两套项目口径

严格口径并不自动等于更安全。一个名义国产但停止维护、无法重复构建的项目，实际可控性可能低于一个许可清晰、源码完整且可由内部继续维护的国外开源项目。

2.3 五项判据

1. 许可权利：可否闭源分发、静态/动态链接条件、修改公开义务、专利和商标限制。
2. 源码与构建：是否能获得完整源码、依赖、构建脚本、补丁和哈希；是否能在断网环境复现。
3. 治理归属：主要版权与维护决策由谁掌握，是否存在单一境外商业主体改变节奏的风险。
4. 内部接管能力：是否真正具备读懂、修改、测试和维护自有分支的能力；“源码可下载”不等于“能接管”。
5. 可替代性：是否存在稳定边界、数据标准和第二实现；替换范围是否可控制。

2.4 Qt 的合规边界

Qt 同时提供商业许可和开源许可。首选方案使用的是开源许可：大多数核心模块允许闭源应用以动态库方式使用，但必须让用户能够替换 Qt 动态库，并提供许可证文本、所用 Qt 库的对应源码或受控获取方式。如果某个模块只有 GPL 许可，则闭源产品不能直接采用，除非另购商业许可。Qt 的大部分版权与控制权仍由芬兰 The Qt Company 掌握。Qt 开源义务 · Qt 许可总览 · Qt 控制主体说明

项目落地要求：

• 只使用已列入第三方软件白名单的 Qt 模块；Widgets/Core/Gui/OpenGL/PrintSupport 等逐项核验。
• 使用动态库，不把 Qt 开源库直接静态合并进闭源主程序。
• “关于”页面显示第三方软件清单；安装介质附 LGPLv3 许可证文本。
• 归档实际使用的 Qt 5.15.19 源码、补丁、构建命令、编译器和校验值；不能只给上游网页链接。
• 允许客户替换兼容 Qt 动态库；最终 EULA 不得禁止为调试库修改而进行的逆向工程。
• 不使用开源侧只有 GPLv3 的 Qt Charts，因为直接链接会给闭源发布带来开源义务；改用 Qwt。Qt Charts 许可
• 许可证判断交由专业法律顾问复核，本报告不构成法律意见。

2.5 行业先例如何正确使用

答辩时建议使用“公开证据表明存在兼容和国产项目实践”，不要使用“某软件已经过信创，所以同技术栈自动过审”的跳跃推理。

3. GUI 与控件候选矩阵

3.1 GUI 框架

wxWidgets 的官方许可允许基于库生成的二进制按自己的条款分发；Qt 路线的合规义务更多，但工程生态明显更成熟。wxWidgets 许可

3.2 Dock、树、属性与图表

Qwt 的许可证允许应用按规定链接而不要求公开应用源码，但仍需在产品中标明使用了 Qwt。Qwt 许可

3.3 属性面板自研边界

自研的是业务控件，不是重新造 GUI 框架。建议结构：

• PropertyDefinition：ID、名称、类型、单位、范围、枚举、只读条件、校验器。
• PropertyModel：与业务对象和 Undo/Redo 交互，不依赖具体编辑器。
• EditorFactory：布尔、整数、浮点、枚举、颜色、文件、向量等编辑器。
• PropertyDelegate：只管理视图编辑生命周期。
• Command/Action：所有修改进入命令层，GUI、CLI 和未来 Python 共用。
• 复杂材料、边界条件作为独立编辑页，不把所有表单都塞进属性网格。

4. 三维渲染方案对比

VTK 官方将其定位为跨平台科学可视化、3D 图形和图像处理工具包，采用宽松的 BSD 风格许可：可以商业使用、修改和闭源发布，但要保留版权、许可文本和免责声明。Qt 支持模块属于 VTK 官方模块。VTK 概览与许可 · VTK Qt 支持模块

4.1 推荐 VTK 数据/渲染路径

1. HDF5 Reader 只读取当前工况、字段和时间步需要的数据块。
2. 将拓扑和字段转换为 vtkUnstructuredGrid；明确所有权，避免多次深拷贝。
3. 表面显示使用 Geometry/Surface Filter，不把全部体单元直接送入边线渲染。
4. 云图使用 Mapper + LookupTable；等值面使用 Contour Filter；切平面使用 Cutter/Plane。
5. 拾取先走屏幕/包围盒粗选，再用 Cell Locator 精确查值。
6. 交互中切换到降采样/低质量 representation，停止交互后恢复目标精度。
7. 千万级数据按区域/块维护缓存，并设置可配置的内存高水位。

4.2 硬件与 CPU 软件渲染降级策略

llvmpipe 是 Mesa 提供的 CPU 软件渲染器：没有可用显卡驱动时，可用 CPU 完成基本三维绘制。官方公开目标只列 x86、x86-64 和 ppc64le，未列 aarch64。因此海光 x86-64 可进入实测，飞腾/鲲鹏必须核验目标系统实际提供的软件渲染器，并准备受限模式；不能预先承诺同等功能和性能。Mesa llvmpipe 文档 · Mesa Systems

启动时记录：

• GL_VENDOR、GL_RENDERER、GL_VERSION、核心扩展和最大纹理/缓冲限制。
• 是否显示 llvmpipe、softpipe 等 CPU 软件渲染标识。
• GPU/系统内存、CPU 核数和当前数据规模。

进入软件渲染后，自动关闭抗锯齿、阴影、高级透明、全量边线和大量箭头/符号；限制同时显示区域，必要时只显示外表面与选中区域。若 aarch64 上无法获得满足 OpenGL 3.3 的软件驱动，则进入受限模式并明确提示。禁止把“能启动”写成“千万级可流畅使用”。

5. 六条方案的双口径评分

5.1 评分方法

严格国产来源分（100）：自研业务 25、GUI 框架 20、Dock/属性/树控件 10、三维可视化 20、数据/IO 10、工具链 5、国产 OS/CPU/GPU 10。国外开源组件即使许可宽松，也不计为国产来源；国产外壳包装国外底层只获部分分。

宽松自主可控分（100）：许可权利 25、源码与离线构建 20、治理分散/可接管 20、替代边界 15、国产平台证据 10、持续维护能力 10。

工程综合分（100）：自主可控 35%、功能覆盖 20%、性能 15%、实施复杂度 15%、维护生态 10%、跨平台 5%。

5.2 评分明细

5.3 严格门槛解释

• 如果评审只看直接 GUI 框架权利主体：FastCAE 或 DTK 可被列为“条件式国产框架方案”，但必须公开其 Qt/VTK 传递依赖。
• 如果评审穿透到 GUI 和渲染底层：FastCAE、DTK 和 UKUI 路线都不能去除 Qt/VTK，不通过。
• 如果评审穿透整个工具链和运行时：即便全自研 GUI/渲染，GCC、CMake、Linux、Mesa、LLVM、HDF5 等仍需逐项认定；在现有边界内无法诚实宣称 100% 国产全栈。

项目建议使用“国产自研代码占比”“国产直接依赖占比”“宽松可控分”“严格来源分”四个独立指标，禁止把它们合并成一个没有公式的“国产率”。

6. FastCAE 专项结论

2026-08-16 对 FastCAE 官方 Gitee 主仓进行只读审计，得到：

• FastCAE 官方仓库标明许可证为 BSD-3-Clause；对应义务见 BSD-3-Clause 正文（OSI）。项目版本为 2.5.0。
• 主 CMake 固定 C++11，并默认寻找 Qt 5.14.2。
• 必需依赖包括 VTK、OpenCASCADE、Qwt、HDF5、CGNS、TecIO、QuaZIP、Gmsh 和 Python；显著超出本项目 V1。
• 主仓 HEAD 2ac80e3... 的提交时间为 2024-05-16；未发现正式 Git tag。GitHub Linux 仓库也明确说明已迁移到 Gitee且不再更新。FastCAE Gitee · FastCAE GitHub 迁移说明

6.1 两种口径

6.2 如果必须选 FastCAE

只保留必需模块：MainWindow/Plugin 基础、结果显示和少量公共设施；彻底移除 Gmsh、OCCT、TecIO、Python 等 V1 非必要组件；将自动联网下载依赖改为离线依赖仓；补齐测试、第三方软件清单和正式版本标记。先完成“可删除性/可升级性技术验证”，验证通过后再决定是否采用。

本报告最终建议仍是：把 FastCAE 当作国产架构参考和条件式备选，不作为方案 A 的运行时依赖。

7. 推荐架构

┌───────────────────────────────────────────────────────────┐
│ Application Shell：菜单 / 工具栏 / Dock / 布局持久化       │
├───────────────────────────────────────────────────────────┤
│ 自研业务层：Project / Case / Region / Field / Selection    │
│ ActionRegistry / Command / Undo / Batch CLI                │
├───────────────────┬───────────────────┬───────────────────┤
│ Tree & Property   │ 2D Curve Service  │ View/Selection    │
│ 自研模型与编辑器   │ Qwt Adapter       │ VTK Adapter       │
├───────────────────┴───────────────────┴───────────────────┤
│ Visualization Core：VTK filters / mapper / LOD / picking  │
├───────────────────────────────────────────────────────────┤
│ Data Core：HDF5 Schema / Cache / Unit / Result Repository  │
├──────────────────────┬────────────────────────────────────┤
│ Solver Gateway       │ Platform Services                  │
│ process/file/UDS     │ path/process/GL probe/package       │
├──────────────────────┴────────────────────────────────────┤
│ CentOS 7 / 银河麒麟；x86-64 / aarch64；OpenGL / llvmpipe  │
└───────────────────────────────────────────────────────────┘

7.1 不建议做“万能 GUI 抽象层”

Qt 和 wxWidgets 的对象模型、事件、布局、Model/View 与 OpenGL 上下文差异很大。把每个控件抽成统一接口会制造一个新的不成熟 GUI 框架。正确的可替换边界是：

• 业务领域、动作/命令、数据访问、求解器协议完全不依赖 GUI。
• Tree/Property/Curve/3D 各有语义级接口和独立适配器。
• 平台相关路径、进程、窗口上下文和 GPU 探测集中管理。
• UI 组合层允许重写；核心数据与用例不重写。

7.2 HDF5 Schema 建议

/meta/schema_version
/meta/producer
/mesh/points              float64[N,3]
/mesh/cells/connectivity   int64[M]
/mesh/cells/offsets        int64[C+1]
/mesh/cells/types          uint8[C]
/mesh/regions/<id>/...
/results/<case>/<step>/point_fields/<name>
/results/<case>/<step>/cell_fields/<name>
/history/residuals/<name>

要求：字段带单位、分量名、位置（node/cell）、时间/工况索引；大数组 chunked；Schema 有主版本和兼容迁移器；Reader 独立于 GUI/VTK，转换层负责构造 VTK 对象。

7.3 求解器集成

• V1 用 job.json/清单描述输入、输出、工作目录和资源限制。
• 大结果只经 HDF5 文件交换；进度、日志和取消使用本地进程间通信或子进程信号。
• 前端不得假定求解器同进程，崩溃后可以恢复项目并重新挂接结果。
• Action 层同时服务菜单、工具栏、CLI，未来 CPython 只绑定 Action/API，不操作 QWidget。

8. 版本、构建与发布策略

8.1 CentOS 7 兼容线

CentOS 官方已于 2024-06-30 结束 CentOS Linux 7 生命周期；这意味着系统基线本身不再获得正常维护。CentOS 官方生命周期

推荐固定：

• Qt 5.15.19 开源源码。Qt Project 于 2026-05-19 发布，属于 Qt 5 最终开源版本。发布公告
• VTK 9.4.x 的锁定补丁版本。9.4.2 构建文档仍兼容较老环境，而 VTK 9.5 发布说明明确不再保留 CentOS 7 的最低依赖构建；因此 9.4.x 更适合作为 CentOS 7 候选，但仍须实机验证。VTK 9.4.2 构建要求 · VTK 9.5 发布说明
• Qwt 6.3.0、HDF5 1.14.6。
• GCC 8 或更高的锁定工具链；以 CentOS 7 自带的 Linux 基础运行库版本作为二进制兼容下限。
• C++17；禁止公共核心无条件使用 C++20 库特性。

不能把“源码可编译”当作既成事实：Qt 6.8 官方支持列表从 RHEL 8 等现代系统起步，Linux 二进制最低基于 glibc 2.28；CentOS 7 不在支持表内。因此方案 A 在立项第 0 阶段必须先完成源码构建与测试。Qt 6.8 支持平台

8.2 银河麒麟与 aarch64

在版本未知前只制定流程，不承诺兼容：

1. 确认桌面/服务器版、版本号、X11/Wayland、glibc、GCC、包格式、GPU 驱动。
2. 海光 x86-64 与飞腾/鲲鹏 aarch64 各选一台验收整机。
3. 共用领域层、动作层、HDF5 Schema 与可视化抽象；新系统优先建立 Qt 6 + 对应 VTK 构建线。
4. 同时测试硬件 OpenGL 3.3 和目标系统实际可用的软件驱动；aarch64 不预设 llvmpipe 已可用。
5. 获取 OS/CPU 厂商兼容认证需要的真实材料清单。

Qt 6.8 官方已经列出 Linux arm64 参考平台，但国产 CPU/麒麟组合不在其明确测试矩阵中，因此仍属项目实测责任。Qt 6.8 支持平台

8.3 离线与可复现

• 保存源码包、Git commit、补丁、许可证、哈希、构建容器/脚本和编译日志。
• 建立内部只读依赖镜像，不在客户构建时访问 GitHub/Gitee。
• 生成标准格式的第三方软件清单，记录组件名称、版本、来源、许可证和处理方式；Qt 6.8 起官方也提供可直接参考的标准清单。Qt 第三方软件清单说明
• 每个平台生成独立 RPM/DEB 和自包含包；使用 RPATH/qt.conf 控制私有动态库搜索路径。
• 运行包附“第三方软件与源代码获取说明”，并做 ldd/许可证扫描/恶意代码扫描。

9. 风险与对策

10. 待测评方确认表

在最终方案冻结前，请客户/测评方书面回答：

1. “国产框架”是否只检查直接 GUI 框架，还是穿透 Qt/VTK/Mesa/HDF5/GCC？
2. 国外组织主导、采用 BSD/MIT/LGPL 等开源许可、可在内部离线维护的组件是否允许？
3. Qt 采用 LGPLv3 开源许可并动态链接是否允许；需要提交哪些许可证与源码材料？
4. 国产化评价是组件数量、代码行、权重还是关键链路门槛？
5. 目标银河麒麟的产品名称、版本、CPU、GPU、桌面环境和包格式是什么？
6. 是否要求取得 OS/CPU/GPU 兼容认证证书，还是项目验收测试即可？
7. “软件渲染可用”的数据规模、帧率和功能降级接受标准是什么？
8. 是否允许同一源码针对不同平台分别构建和签名？

11. 第三方软件与许可证清单

11.1 首选方案第三方软件清单

11.2 一手来源

• 安全可靠测评工作指南 V4.0
• Qt 开源 LGPL/GPL 义务
• Qt 6 许可与第三方软件清单说明
• Qt 5.15.19 开源发布公告
• Qt 6.8 支持平台与 glibc 说明
• Qt Widgets / QDockWidget
• BSD-3-Clause 许可证正文（OSI）
• MIT 许可证正文（OSI）
• Apache-2.0 许可证正文（Apache）
• GNU LGPLv3 许可证正文
• GNU GPLv3 许可证正文
• MPL-2.0 许可证正文（Mozilla）
• Qt Charts 许可
• GNU GPL 常见问题
• GCC 运行库许可证与例外
• VTK 官方许可说明
• VTK 9.4.2 构建要求
• VTK 9.5 发布说明（移除 EL7 最低依赖构建）
• VTK Qt 支持模块
• Mesa llvmpipe 官方文档
• Mesa Systems / 软件驱动
• wxWidgets 官方许可
• GTK 官方架构
• Qwt 官方许可
• HDF5 许可证正文
• HDF5 1.14.6 官方发布
• CMake 官方许可说明
• Mesa 官方许可说明
• LLVM 官方许可政策
• Gmsh 官方许可说明
• Open CASCADE Technology 官方许可说明
• DTK 官方仓库
• UKUI 官方仓库
• FastCAE 官方 Gitee 仓库
• FastCAE GitHub 迁移说明
• WPS 第三方软件法律声明
• WPS Linux 官方页
• WPS 企业版兼容环境
• 麒麟政务解决方案
• CentOS Linux 7 生命周期

11.3 证据等级

• A：许可证原文、官方标准/指南、官方源代码或构建文件直接明示。
• B：官方文档能支持相邻事实，但需要有限工程推断。
• C：基于公开资料的项目判断，必须经目标实机或测评方确认。

本报告没有直接引用附件中的单位、人员、叶片模型图片和项目细节。附件只用于确认团队已有 C++/Qt 经验，以及本项目应与上游参数化造型职责解耦。

最终建议

现在选 A，架构上保留 B，审计 D，明确拒绝用 E 冒充全栈严格国产；F 只作为预算充足后的长期专项。

方案 A 的真正“自主可控”不是一句“Qt 是开源的”，而是：实际使用版本与补丁全部归档、构建可在断网环境复现、许可证义务可审计、业务和数据模型不被 GUI 锁死、目标国产整机有实测记录，并且团队有能力维护自己的长期分支。