肥白白1. 项目背景：为什么选 Flutter 做鸿蒙维修管理系统
先说结论：车维通不是那种“为了跨平台而跨平台”的 Demo 项目，而是一个真实跑在维修厂工位上的生产工具。我当时接这个项目时，客户方的需求很直接——他们手里有二十多家连锁门店的汽修业务，前台接待、车间调度、配件出库、结算开单全靠在 PC 上操作老旧的 Web 系统，工位上的师傅们常年抱着手写单据跑来跑去。他们想要一套能装在平板和手机上的移动端系统，让师傅在车边上就能完成接车、体检、派工、领料、完工上报这些操作，同时后台还得跟原有系统打通。硬件选型也基本定了：门店配的是华为平板，系统版本已经能升到 HarmonyOS。
这个背景下，摆在面前的技术选项其实有三个方向：纯原生 HarmonyOS 开发、uni-app 之类的跨端方案、Flutter。纯原生的问题很简单——团队里没人写过 ArkTS，短时间内要交付一套业务复杂度不低的维修管理系统，学习成本压不住工期。uni-app 虽然上手快，但客户对界面交互的要求偏高，尤其在平板上的复杂表单和多列表联动场景，uni-app 的渲染性能和历史包袱经常会在细节上卡你一下。最后敲定 Flutter，理由很实际：其一，Flutter 的渲染引擎是自绘的，不依赖系统 WebView，在鸿蒙上的表现一致性有保障；其二，Dart 语言的类型系统和组件化思维，用来做这种“表单密集型 + 列表密集型”的管理系统，代码组织起来比 JS 那套舒服得多；其三，社区里已经有比较成熟的 Flutter 适配鸿蒙方案，不是从零趟坑。
我要重点说的“快速操作功能”，其实是从原 Web 系统里最常用的几个高频动作里提炼出来的——快速接车、快捷体检项录入、一键派工、快速领料、完工确认。这些操作在 PC 上也就是点几个下拉框的事，但换到手机和平板上，如果照搬 PC 的交互逻辑，师傅们能骂死你。所以整个项目的核心设计原则就一条：把高频操作做到三步以内完成，让师傅在车旁边站着也能单手操作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构设计：模块拆分与选型背后的考量
2.1 三层架构与状态管理方案的选择
车维通的项目结构我拆成了三层：UI 表现层、业务逻辑层、数据服务层。UI 层全部用 Flutter Widget 构建，业务逻辑层用 ChangeNotifier + Provider 做状态管理，数据服务层封装了 REST API 客户端和本地 SQLite 缓存。
选 Provider 而不是 Bloc 或 GetX，是一个偏保守的决策。这个项目的业务逻辑不算特别复杂，但涉及的状态流转很多，比如接车单从“待体检”到“体检中”再到“待派工”，每一步都要刷新多个页面的数据。Provider 的 ChangeNotifier 机制对这种场景的侵入性最小——你不需要像 Bloc 那样为每个页面写一堆 Event 和 State 类，也不用担心 GetX 那种“万物皆可全局”带来的隐式依赖问题。团队里如果有人没接触过状态管理库，Provider 的学习成本也是最低的。
数据层我做了两层缓存。第一层是 API 层面的内存缓存，用简单的 Map 存最近请求的列表数据，Key 是接口路径加参数拼接；第二层是 SQLite，存车辆档案、客户信息、配件目录这类基础数据。这么做是因为维修厂的网络环境其实挺差的，很多老店的 Wi-Fi 是能用的程度，但车间里金属货架一多，信号就是玄学。师傅点一下“查询车辆档案”，如果每次都走网络，转圈圈的时间足够他们掏出手机打电话骂你了。
2.2 快速操作模块的独立设计
设计“快速操作”这个模块时，我特意没把它做成几个孤立页面的集合，而是从用户角色和操作场景出发，重新梳理了整个系统的功能树。调查了维修厂的实际流程后，我发现高频操作集中在四个角色上：前台接待、车间调度、仓库管理员、维修技师。接待员 80% 的时间在做“接车建档”和“开维修单”；调度员一直在“派工”和“调整工位”；仓管的核心动作是“查配件”“出库”；技师则是“领任务”“报完工”“申请追加项目”。这些高频动作在原来的 Web 系统里分散在不同菜单里，而现在我要把它们全部聚合到一个统一的“快速操作面板”上。
面板的入口放在 App 首页最显眼的位置，一个悬浮的加号按钮，点开后是一个半屏高度的 Action Sheet 式面板，按角色动态显示可用的快捷操作。这个面板还有个小心机：它会根据系统时间做简单推荐，早上开门时把“接车建档”排在第一位，下午五六点把“完工结算”顶上去。看起来是个微不足道的细节，但实际用下来，确实有店长反馈说“这个推荐还挺懂我们”。
2.3 耗时任务与 UI 反馈的取舍
维修管理系统的操作大多是小表单提交，但有两个场景比较特殊：一是接车时拍摄车辆照片，二是批量导入配件目录。拍照上传如果按常规做法，点完快门等上传完成再返回，体验会非常僵硬。我用了“先本地保存、后台上传、失败重试”的策略——照片先压缩存入本地缓存目录，页面立即返回，上传任务丢给一个全局的后台队列去处理。这样可以保证师傅连续拍十几张车辆外观照片时，手不用停下来等网络。
批量导入配件这里踩过一个坑，后面在问题章节会详细说。简单来说就是，如果你在主线程里解析一个几千行的 Excel 文件，鸿蒙平板都会卡到让你怀疑人生。解决方案是用 isolate 做后台解析，每次只往 UI 线程丢一批解析结果。
3. 快速操作面板的实现细节与界面调优
3.1 主面板布局：从用户习惯反推 UI 结构
快速操作面板我最终做成了