A
Air官方
Qt5.15 LTS 是大量 KDE 与行业软件的长期支撑版本，评估它上鸿蒙的可行性，是 Air 系列路线选型时绕不开的一题。结论先行：可行，但 Air 系列最终统一收敛到 Qt6 线，Qt5 只在特定条件下值得投入。
▍Qt5 路线的构成
Qt 上位的抽象层是 QPA（Qt Platform Abstraction），平台插件负责窗口、输入、屏幕与主题。Qt5 上鸿蒙就是写一个 ohos QPA 插件，把 QWindow 映射到原生窗口，把触摸事件翻译成 QTouchEvent。这套机制 Qt5 与 Qt6 是同构的，工作可以互相借鉴。
▍评估要点
一看模块面：Qt5.15 的 qtbase 加上应用用到的模块（Widgets、Quick、Network 等），交叉编译量与 Qt6 相当；二看依赖差异：Qt5 时代不少应用还挂着 Qt4 遗留接口或 X11 调用，要先审计；三看维护窗口：5.15 开源版的安全维护已进入尾声，长期项目押上去意味着将来还要再迁一次 Qt6。
▍Air 系列的拍板
Air 系列早期短暂用过 Qt 6.2.4 统一构建栈，后来整体迁移到 6.11.1 模块族，Qt5 没有进入正式生产线。原因就是上面第三条：与其花双份力气维护两个大版本的 QPA 与补丁族，不如把资源集中到一条线上，让所有 Qt 工程共享同一栈的红利。
▍什么时候仍选 Qt5
只有当目标应用锁定 Qt5 且无 Qt6 迁移路线（比如深度绑定 Qt5 私有 API 的行业软件），或者 Qt6 下行为回归明确无解时，Qt5 路线才是正解。此时建议直接从 Air 系列的 ohos QPA 经验起步，QPA 层的窗口时序、触摸双投递这些坑在 Qt5 上同样存在。
▍给评估者的三步
先在 Linux 上确认应用对 QPA 的依赖程度（有无裸调 X11）；再交叉编译 qtbase 跑通一个纯 Widgets 演示；最后接目标应用验证核心窗口流程。三步都绿再立项。
有疑问欢迎在本板块直接发帖，我们会逐条回复。
▍Qt5 路线的构成
Qt 上位的抽象层是 QPA（Qt Platform Abstraction），平台插件负责窗口、输入、屏幕与主题。Qt5 上鸿蒙就是写一个 ohos QPA 插件，把 QWindow 映射到原生窗口，把触摸事件翻译成 QTouchEvent。这套机制 Qt5 与 Qt6 是同构的，工作可以互相借鉴。
▍评估要点
一看模块面：Qt5.15 的 qtbase 加上应用用到的模块（Widgets、Quick、Network 等），交叉编译量与 Qt6 相当；二看依赖差异：Qt5 时代不少应用还挂着 Qt4 遗留接口或 X11 调用，要先审计；三看维护窗口：5.15 开源版的安全维护已进入尾声，长期项目押上去意味着将来还要再迁一次 Qt6。
▍Air 系列的拍板
Air 系列早期短暂用过 Qt 6.2.4 统一构建栈，后来整体迁移到 6.11.1 模块族，Qt5 没有进入正式生产线。原因就是上面第三条：与其花双份力气维护两个大版本的 QPA 与补丁族，不如把资源集中到一条线上，让所有 Qt 工程共享同一栈的红利。
▍什么时候仍选 Qt5
只有当目标应用锁定 Qt5 且无 Qt6 迁移路线（比如深度绑定 Qt5 私有 API 的行业软件），或者 Qt6 下行为回归明确无解时，Qt5 路线才是正解。此时建议直接从 Air 系列的 ohos QPA 经验起步，QPA 层的窗口时序、触摸双投递这些坑在 Qt5 上同样存在。
▍给评估者的三步
先在 Linux 上确认应用对 QPA 的依赖程度（有无裸调 X11）；再交叉编译 qtbase 跑通一个纯 Widgets 演示；最后接目标应用验证核心窗口流程。三步都绿再立项。
有疑问欢迎在本板块直接发帖，我们会逐条回复。
楼主
7 天前