伟星啊最近在折腾一个跨端车辆维修管理系统，技术栈锁定在 Flutter 和 OpenHarmony 这条线上。说实话，真正动手之后才发现，跨端 UI 的实现难度并不在“跑起来”，而在于让同一套 Flutter 代码在 OpenHarmony 设备上既要稳定运行，UI 又要达到能交付给客户看的水平。尤其是欢迎区域这种进门第一屏，既要撑起品牌调性，又要兼顾维修工单、车辆状态、登录入口这些高频操作，做不好非常掉价。
这篇文章我打算从实际项目出发，把“基于 Flutter × OpenHarmony 的跨端车辆维修管理系统”中欢迎区域 UI 的设计思路和工程化落地完整梳理一遍。覆盖技术选型、组件拆解、主题工程化、原生能力桥接、常见踩坑记录这些方面，适合正在做 Flutter 跨端项目、或者准备把现有 Flutter 工程往 OpenHarmony 设备上迁移的开发者参考。
1. 项目背景与跨端技术选型思考
1.1 为什么是 Flutter 加 OpenHarmony 的组合
这个车辆维修管理系统的使用场景很典型：门店前台有固定的工位终端，修车师傅手里有移动端，管理层偶尔要在平板上看经营数据。过去这类系统一般做一套 Android 应用就够了，但这两年 OpenHarmony 设备在商业终端领域铺得很快，尤其是工位一体机、收银设备、带触控屏的维修终端，越来越多开始跑 OpenHarmony 标准系统。客户的需求也很直接——同一套 UI，能不能同时在原来的 Android 设备和新的 OpenHarmony 设备上跑，尽量别维护两套代码。
Flutter 的优势在于它把渲染引擎自己带上了，UI 层不依赖系统控件，天然具备跨端基础。OpenHarmony 社区也一直在推进 Flutter 适配，官方有 flutter_flutter 的分支，各路厂商也在不断合入设备适配代码。实际测下来，Flutter 应用在 OpenHarmony 设备上做标准 UI 展示、列表滚动、基本动画这些场景，性能是够用的。而 ArkUI 虽然是 OpenHarmony 的亲儿子，但它的能力边界在复杂布局和自定义绘制上还有不少限制，做工具类、管理类系统时，很多现成的 Flutter 组件生态可以直接搬过来用，这是比 ArkUI 顺手的地方。
选这套组合还有个现实原因：团队里大部分人本来就会 Flutter，学习 OpenHarmony 的 ArkTS 和声明式开发需要成本，而 Flutter 侧的技能积累能直接复用。Dart 语言上手快，Flutter 组件体系成熟，热重载对调试效率的提升也是实打实的。对我们这种小团队来说，用最少的人同时覆盖两个平台，是必须算的账。
1.2 整体架构：共享 UI 层与平台能力桥接
确定了 Flutter 作为 UI 主框架之后，架构上要解决的核心问题是：Flutter 层如何调用 OpenHarmony 的原生能力？比如调用系统图库选车辆照片、拉起微信登录、触发应用内支付、读取设备信息做保修登记。这些能力 Flutter 本身没有，必须通过平台通道（Platform Channel）桥接到 OpenHarmony 侧的原生代码。
我的做法是分三层：
- UI 层：全部用 Flutter 实现，包括欢迎页、工单列表、车辆档案、维修记录等所有界面。
- 业务逻辑层：Dart 侧维护状态管理和数据请求，与 UI 解耦。
- 能力桥接层：封装一组统一的 Channel 接口，上层只调 Dart 方法，底层分别在 Android 和 OpenHarmony 侧做原生实现。
这样设计的好处很直接——如果后续要再扩展其他平台，UI 层和业务逻辑层完全不用动，只要在桥接层补一个实现就行。欢迎区域 UI 在整个体系里属于 UI 层的一部分，但它不只是静态展示，还承载了登录状态判断、工单提醒、快捷入口跳转等交互逻辑，所以不能只当“一张图”来做。
架构边界划分清楚之后，后面的工作才能并行推进。原生侧的同事可以专心处理桥接，UI 侧的同事专心做组件和页面，不用互相等。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 欢迎区域 UI 需求分析与设计拆解
2.1 欢迎区到底要承载什么
很多开发者在做欢迎页的时候，习惯把它做成一整张漂亮的背景图加一个“进入系统”的按钮，看着大气，实际上对维修管理系统来说并不实用。我梳理了一下门店实际使用场景，欢迎区域必须在一屏之内完成这几件事：
- 展示当前用户登录状态：已登录显示工号、姓名、所属门店；未登录提供快速登录入口。
- 展示当日待处理事项：待接车的预约单数、待完工的维修工单数、待回访的客户数。
- 提供高频操作入口：新建工单、车辆登记、配件查询、客户档案，这四个功能在维修门店的使用频次最高。
- 展示系统品牌与门店信息：Logo、门店名称、当前日期和星期、天气这种环境信息可以提升使用温度。
如果欢迎区只是好看，师傅每天早上开单要多点好几下，用不了两天就会被吐槽。所以我把欢迎区设计成“信息聚合 + 快捷操作”的复合区域，而不是单纯的品牌曝光