第一次真正意识到“维修厂还在用纸本子记工单”是我在一家汽修连锁门店现场看到的场景三块落了灰的显示器、一个只装了 Excel 的老电脑、贴在墙上的手写排班表每天流水不少可库存对不上、报价靠嗓子喊、交车时间全凭技师个人经验。从那天起我决定用 Flutter × HarmonyOS 6.0 亲手搭一套智能车辆维修管理系统后来它有了名字叫 CarFix Pro——一个面向多端的企业级维修业务中台。这篇文章不讲 PPT只讲真实落地过程中的技术选型、架构设计、离线同步、智能模块和踩坑复盘适合正在做维修或服务行业数字化的开发者参考。1. 立项抉择为什么是 Flutter为什么现在把鸿蒙押进来1.1 多端不只是“顺便支持”先说业务背景。CarFix Pro 要服务的不是单店而是拥有几十家门店的连锁维修企业坐在前台面对客户的接待员、在地沟里施工的技师、管配件仓库的库管、每天要看报表的店长和总部运营用的终端完全不同。前台往往是 Windows 一体机或安卓收银台技师手里是扛得住油污的平板和手机库管则是扫码枪加手机管理层希望打开浏览器就能看到核心指标。如果按传统做法“电脑 安卓 iOS 网页”四套终端至少要养三套开发团队业务还在验证期这个成本根本扛不住。而 CarFix Pro 立项时的核心诉求正是先用一个团队快速覆盖所有终端把业务流跑通再根据每个终端的真实反馈持续加深。1.2 为什么是 Flutter 而不是 React Native/uni-app/三套原生选择 Flutter 的第一理由并不是“一套代码跑所有端”这种营销话术而是它把业务逻辑、状态管理、UI 描述都集中在 Dart 一侧用自绘引擎保证跨平台观感的一致性。实际做下来跨端的复用率不可能做到 100%真正可行的是让 80% 的代码业务逻辑、路由、状态、数据层只写一遍剩下 20% 的端能力通过平台抽象层适配。如果换成 React Native 或 uni-appJS Bridge 在复杂列表和系统级 API 调用上容易成为瓶颈而且它们的渲染层依赖各端原生组件平台之间的观感差异需要额外工作去抹平。原生三件套就更不用说了双团队成本在中小团队里基本是死路。实现方案跨端一致性性能表现鸿蒙适配成本CarFix Pro 的选择Flutter自绘渲染一致性好AOT 编译列表滚动流畅需适配层桥接成本可控采用React Native依赖原生组件差异需自行修复JS Bridge 在复杂列表有压力需额外适配桥不采用原生三件套最一致最好鸿蒙侧需单独团队不采用1.3 为什么现在把 HarmonyOS 6.0 放进拼图把 HarmonyOS 6.0 拉进来起初不是因为它炫酷而是因为采购侧的实情不少汽修集团给新门店配的一体机、手持终端、看板大屏预装的就是鸿蒙版本的系统。产品如果跑不上这些设备等于直接缺席采购清单。再加上维修行业本身就是一个多设备场景——技师手机拍底盘视频、前台平板录工单、售后回访时可能要在车机屏或座舱入口做轻交互——鸿蒙生态这些年越来越强调设备协同和分布式流转这些能力很适合做成“门店设备之间无缝切换”的体验。我们最终把它当成多端里的一等公民来对待而不是某个实验性的小分支。1.4 代价Dart 生态与鸿蒙适配当然押注 Flutter 有代价。最直观的是 Dart 生态比 JS 生态小一圈很多“装个包就能用”的轮子要自己造其次是 Flutter 引擎对鸿蒙的官方支持不如 Android/iOS 那样成熟需要通过社区维护的渲染适配层和 Platform Channel 做桥接。这是立项时就清楚的风险后面的多端架构设计也一直在为这个风险兜底。选型不是选一个十全十美的方案而是选一个你愿意承担其缺点的方案然后把精力放在把缺点控制住。2. CarFix Pro 的骨架工单状态机与核心数据模型设计2.1 六个业务引擎怎么咬合先不聊代码抽象把 CarFix Pro 到底管哪些事说清楚。整个系统围绕一条主线展开车辆进店、接待检查、报价确认、维修施工、质检交付、结算离店。我们沿这条主线拆了六个引擎工单引擎、客户车辆档案引擎、配件库存引擎、结算引擎、排班引擎、数据看板。引擎之间不互相改表而是通过事件通信。比如工单状态变成“质检中”时系统发布一个 WorkOrderStageChanged 事件库存引擎听到后把该工单占用的配件从“预占”改为“已出库”结算引擎如果发现有旧件回收自动生成一项抵扣金额。这种事件式咬合让每个引擎独立演进而不是被别的模块牵着走。2.2 工单状态机八个状态与一张转移表工单状态机是整个业务链路的心脏。设计时最容易犯的错是把状态当成“按钮上的字”——后台提需求就加一个状态最后状态多到没人看得懂。我们反复删减把工单收敛为八个状态created、inspection、quoted、confirmed、repairing、qualityCheck、delivered、settled外加 cancelled 作为可跳跃进入的终止态。enum WorkOrderStage { created, // 进店创建尚未开始检测 inspection, // 技师检测中生成检测报告 quoted, // 报价已生成等待客户确认 confirmed, // 客户已确认开始安排施工 repairing, // 维修施工中含待料间隙 qualityCheck, // 质量复查 delivered, // 已交车客户签收 settled, // 已结算财务结账 cancelled // 已取消记录取消原因 }当前状态目标状态触发动作允许参与者校验规则createdinspection开始检测接待员/技师已绑定车辆档案inspectionquoted生成报价技师/店长检测报告非空quotedconfirmed客户确认接待员/客户报价单已推送confirmedrepairing开始施工店长/组长已分配技师与工位repairingqualityCheck提交质检技师维修明细完整qualityCheckdelivered确认交车质检员/店长质检记录通过deliveredsettled结算完成财务金额无未结项*cancelled取消工单店长/管理后台需填取消原因所有状态流转都会经过一个状态机引擎由它判断“这次流转是否允许”以及“谁有权限触发”。比如 quoted 不能由技师直接改为 repairing必须等客户确认而 repairing 阶段如果配件没到可以临时进入待料子状态但不改主状态避免状态漂移。把校验逻辑收拢在一个 engine 里比散落在几十个页面的按钮处理里好维护得多。2.3 数据模型围绕工单聚合根去建模接下去是数据模型。整个系统围绕工单聚合根来组织所有对象和工单形成可追溯的关系车辆档案在第一次进店时建好之后每次工单都挂在同一车牌和 VIN 下维修明细是工单与配件之间的桥每一行含配件 SKU、数量、单价、工时同一工单可以多次报价但只有最新一版生效。核心对象关键字段说明工单orderNo, vehicleId, mileage, stage, technicianIds, quotedAmount聚合根跨引擎通行的业务主键车辆档案plateNo, vin, modelId, lastInspectionAt, faultCodeHistory一车一档历史故障可沉淀维修明细orderId, partId, qty, unitPrice, laborMinutes, isInsurance工单与配件的桥影响库存与结算配件sku, categoryId, stockQty, safetyStock, avgMonthlyUsage库存数量与安全库存联动用聚合根而不是一堆散表的好处是维修清单、报价单、结算单始终围着同一个工单号展开任何一个环节出问题都能顺着 orderNo 一路回溯到底。多端产品最怕的就是每个端各存一套维度最后对不上账。2.4 多门店与 RBAC 权限模型门店隔离选了“共享库 tenantId 隔离”的折中所有门店共用一套服务端代码和数据库但每个门店有独立 tenantId资源查询强制拼上租户条件总部账号可以跨租户聚合报表门店账号只能看自己门店的数据。权限上做 RBAC角色包括超级管理员、总部运营、店长、前台接待、维修技师、库管、财务。每个角色的权限按“动作 资源”声明而不是按菜单写死——这样以后接小程序、公众号、车机屏权限模型可以直接复用不用重新设计。3. 一套代码的三种骨相多端工程架构与鸿蒙桥接实战3.1 feature-first 目录与 platform layer代码结构上CarFix Pro 走的是严格的 feature-first 分层顶层拆成 app、core、features、platforms 四个目录。app 只放应用入口、路由表、全局主题core 放与业务无关的基础能力比如网络封装、日志、数据库、事件总线、工具集features 按业务模块垂直拆分模块内部再分成 data、domain、presentation 三层模块之间禁止直接 import只能通过 core 里的公共事件或接口通信platforms 目录是整个工程最不一样的地方专门放端能力抽象与各平台的具体实现。这样做的收益在后期很明显当你想把整个系统从一块屏搬到另一块屏上时搬的是 features 和 core平台相关代码永远被挡在边界外。3.2 端能力适配从蓝牙 OBD 到推送的 Bridge 设计所谓端能力指在 Android、iOS、Web、HarmonyOS 上实现完全不同的系统能力。CarFix Pro 依赖的端能力包括蓝牙 OBD 读取、NFC 识别行驶证、相机拍照、相册选取、文件下载、本地数据库持久化、设备型号、网络状态、系统级推送、定位、震动反馈。我们为每种能力定义一个接口例如 DeviceBridge 负责设备型号BluetoothBridge 负责蓝牙链路PushBridge 负责推送注册。业务层只依赖接口不依赖任何一个平台的具体实现。以蓝牙 OBD 为例Port 接口大致长这样abstract class BluetoothBridge { Futurebool get isAvailable; StreamObdDevice scan(); FutureObdConnection connect(String deviceId); FutureDiagnosticTroubleCodeList readCodes(ObdConnection conn); }Android 端用系统 BLE 实现鸿蒙侧通过 Platform Channel 把 Dart 方法桥接到系统蓝牙服务Web 端直接返回“不支持”由 UI 隐藏相关入口。每一端的实现都藏在 platforms 目录里业务代码永远只看到统一的接口。3.3 编译期平台编排dart-define 与工厂模式多端差异最好在编译期被决定而不是在运行期到处写 if。我们把平台标识通过 --dart-define 注入格式是 PLATFORM_TAGharmony、android、ios、web然后写一个很简单的工厂class BridgeRegistry { static BluetoothBridge createBluetoothBridge() { const tag String.fromEnvironment(PLATFORM_TAG); switch (tag) { case harmony: return HarmonyBluetoothBridge(); case android: return AndroidBluetoothBridge(); case ios: return IosBluetoothBridge(); default: return UnsupportedBluetoothBridge(); } } }为什么不把平台判断写进业务代码因为一旦在几十个页面里出现 if (isAndroid) 这类分支产品经理很快会埋下一颗“只有某个平台生效”的雷。编译期工厂把平台差异限定在 platforms 目录业务代码永远保持干净的布尔逻辑。3.4 响应式 UI 断点与字体安全多端最烦的不是逻辑而是布局。同一张工单详情页在 6 寸手机上适合上下滑列表在 12 寸平板上应该左边表单右边操作面板在 Web 后台则是更宽的数据表格。CarFix Pro 用“断点 栅格”的自研轻量方案以 600px 和 1024px 为分界把常用页面拆成可复用的 Flex 区块窄屏纵向堆叠宽屏自动双栏或三栏。这里有一个值得写进规范的教训所有页面必须先开发窄屏版本再用同一份业务数据验证宽屏重构避免两个布局各写一套导致状态不同步。字体度量方面鸿蒙 6.0 与原生安卓默认字体不同我们统一给带文字按钮设置最小高度和额外安全 padding禁止在业务代码里硬编码 Text 高度否则同一套 UI 在两个平台上会出现截字。4. 让断网的车间继续干活离线缓存、同步引擎与冲突合并4.1 为什么维修车间必须 offline-first做过维修行业的人都懂车间和仓库的信号糟得离谱地沟下经常一格信号都没有仓库里堆满金属货架Wi-Fi 覆盖也是断断续续。如果把“创建工单、扫描配件条码、结束质检”这些高频动作做成强依赖网络技师的第一反应不是等着转圈而是掏出纸质记事本。所以 CarFix Pro 从第一天就定了 offline-first 架构客户端永远是操作入口云端是异步收敛的最终事实层。网络连不上活也得照干。4.2 冷温热三层数据与混合存储离线优先的第一步是决定哪些数据必须本地化。按使用频率分三层冷数据是车型库、配件目录、历史工单按需拉取并缓存过期一周温数据是当日班次、技师列表、当前待办每次启动刷新同时保留上次快照兜底热数据是正在编辑的工单、正在扫码的配件永远只存在本地直到同步确认成功才标记完成。存储上本地关系型数据库负责工单、维修明细这类强关系数据键值缓存放用户偏好和 Token 这类小配置。一句话别把所有东西都塞进同一个存储混合使用才能避免启动时全量加载。4.3 两段式同步引擎与幂等设计同步引擎是离线架构的心脏。设计为两段式客户端写操作先落库生成一条带 requestId 和 parentId 的操作记录入网后按顺序上传服务端收到后做幂等处理同一个 requestId 只生效一次然后返回一个递增游标客户端拉取自游标以来的增量数据。class OutboxRecord { final String requestId; final String aggregateType; // workorder | vehicle | part final String aggregateId; final String operation; // upsert | transition | delete final MapString, dynamic payload; final DateTime createdAt; }为什么不直接同步整张表因为维修工单是典型的“多人连续改一单”场景——前台改客户手机号、技师补施工明细、财务调应收金额三个人可能同一天动同一张单。整表同步的冲突率高得离谱而按操作粒度同步冲突可以控制在字段级。4.4 冲突合并字段级、时间戳级与人工仲裁离线冲突无法完全避免但可以尽量让它可处理。CarFix Pro 用三级策略同一个字段值以“最后写入 服务器时间戳”为准不同字段之间做字段级合并前台改电话、技师补配件互不覆盖一旦真撞在同一个关键字段上比如结算金额被两个人同时改系统自动标记“待仲裁”生成一条审批提示由店长在回连后确认。最开始我也想上一套 CRDT 让它自动合并后来发现维修业务的冲突很多不是数学问题而是管理问题——与其让算法偷偷改掉不如明确标记出来让店长拍板业务上更好交代。同步线程的触发时机也做了控制应用启动、从后台回前台、Wi-Fi 恢复、以及每隔 15 分钟兜底一次。触网后Outbox 里的操作按优先级上传结算类 状态流转 出入库 统计同步进度会实时显示在顶部让技师知道“还有 3 条没传上去”而不是默默失败。5. 智能模块落地AI 诊断、配件推荐与排程算法的边界5.1 智能不智能先看能不能改变业务动作谈“AI 赋能维修”很多方案是拿大模型生成一段“建议”读起来都对落地全废。我们在 CarFix Pro 的智能化上非常克制原则只有一条每个智能模块必须直接改变业务流中的某个决策或动作否则不做。按这个原则上线了三个模块OBD 故障码辅助诊断、拍照识别里程表和配件铭牌、维修工时预测与预约排程。它们都不炫酷但都能减少一次手工操作。5.2 OBD 故障码辅助诊断与本地规则库技师把蓝牙 OBD 盒插到诊断口手机端连上后读取 ECU 故障码和实时数据流。原始数据是一串 P0xxx、U0xxx 编码大多数技师只认识其中常用的一部分遇到冷门码得翻手册或者拍照去搜。CarFix Pro 在本地内置了三千多条故障码规则把故障码映射到故障等级、维修方案、可能涉及的配件和预估工时。读码完成后生成一张“诊断摘要”技师确认或修改后一键转成工单检测报告。难点不在匹配本身而在把维修语境组合起来做筛选同一个故障码在不同品牌、不同车型上的维修方案差异很大规则引擎必须组合 VIN 年份、车系、里程来过滤。5.3 OCR 识别里程表、车牌与配件铭牌拍照识别分两部分一是进店接车时前台拍仪表盘OCR 自动读里程避免手输错二是库管遇到扫码枪扫不出来的旧件或异形件拍照识别铭牌型号。车牌识别也在接车环节顺手做了直接进车辆档案。这些功能单看都不算黑科技但一旦和工单打通价值很实在——把最容易出错的录入环节砍掉了。真实数据里仪表盘、车牌这类规整场景的识别率很稳但模糊铭牌的错误率会明显偏高所以我们坚持“识别 人工确认”绝不全自动提交免得 OCR 读错一个数字后面整个结算都要返工。5.4 配件关联推荐与实时库存联动配件推荐从历史工单里挖关联规则同车型进厂修刹车片有一半概率同时需要刹车盘报修发动机异响的车最后开出的明细往往包含机油滤芯和发动机护板。实现上没有上来就搞协同过滤而是直接在本地跑 Apriori 风格的统计把规则落到建议清单前台录入维修明细时实时提示。一个关键经验是配件推荐必须和实时库存联动关联规则再好仓库没货等于白搭还得判断库存是否被其他在施工的工单预占。推荐接口里直接输出可售库存而不是理论库存。排程方面用的是带约束的贪心加关键工位优先一个工位一次只能停一辆车一个技师同一时段最多绑一个工位等待配件到货的工单自动降级为待料。系统按预约时间和承诺交车时间生成工作日历店长可以拖拽调整调整后依赖该工位的任务全部重算。相比纯学术最优解这套方法牺牲了一点理论最优但换来的是店长看得懂、能干预、敢用。在数字化系统落地里可解释性往往比最优解更重要。6. 被工期反复毒打后我才重视的工程化问题6.1 冷启动从 3.7 秒压到 1.3 秒CarFix Pro 是一个典型“壳轻核重”的应用业务模块多如果启动时全部初始化在低端安卓上首页出现前可以卡三四秒。做完三件事后效果立竿见影入口页只依赖冷缓存和最小依赖树数据库和同步引擎放进后台 isolate 初始化不在首帧阻塞 UI路由表和业务模块按 feature 动态注册启动时只加载首页相关的两个 feature其余在路由命中时才注入。主流千元机上冷启动从约 3.7 秒降到 1.3 秒左右。6.2 图片管道、体积裁剪与低端机内存维修场景里的工单照片动辄十几 MB如果直接用原图解码低端机的内存会被瞬间打爆。图片层强制统一走缩略图管道列表最多渲染 480px 宽的缩略图详情页需要时再加载原图再用一个 LRU 控制内存上限。包体积方面做了平台裁剪和延迟加载——配图、维修手册这类大体积静态资源不打进安装包放到 CDN 首次触网后拉取本地只留占位图。这对多端产品特别重要因为鸿蒙和安卓的应用包都有大小限制装包越瘦用户越愿意升级。6.3 三层自动化测试与 Golden 对比多端最怕的是改一个逻辑某个平台的表单塌了。CarFix Pro 配了三层自动化测试核心状态机引擎用纯 Dart 单元测试覆盖所有状态转移路径关键业务页面写 Widget 测试并截图做 golden 比对核心链路也就是从建单到结算的完整流程写端到端测试至少在安卓和鸿蒙各跑一遍。Golden 在跨平台里特别有价值——它能捕捉到字体度量差异导致的按钮折叠人眼经常漏掉这种问题。数据库迁移也在 CI 上跑一份模拟脏数据的老库测试专门验证升级路径。6.4 CI/CD 多端产物与真机清单发布流程上CI 为四个目标产物分别构建Android 的 APK/AAB、iOS 的 IPA、鸿蒙应用包、Web 产物。每个产物构建完自动跑 smoke test 然后出报告。发布顺序是先内部测试群发一版再按 10% 灰度最后全量。自动化覆盖不了真机兼容性于是把主流机型固化成清单每次发版前真机过一遍鸿蒙设备单独抽了门店实际在用的一台一体机和一台手持终端这两个设备不过就不允许发生产。7. 复盘几个印象深刻的坑从多端适配到数据迁移7.1 channel 注册时序导致的诡异无响应第一次把 CarFix Pro 跑上鸿蒙适配层时遇到奇怪崩溃某页面点蓝牙按钮没有任何反应另一台设备同操作却正常。排查到最后发现Dart 侧发起 Platform Channel 调用的时机早于鸿蒙侧完成 Channel 注册。这类“初始化时序”问题是跨平台 bug 的常客解决方式是把所有 channel 注册收敛到一个入口并在引擎 ready 事件之后再允许业务发起调用。不要依赖系统给的默认时序跨端开发里这种假设迟早会被某个平台打破。7.2 离线大队列下的数据库迁移共享库 门店隔离的模式让每次本地数据库迁移都像拆弹。最疼的一次是给工单表加“保险理赔金额”字段迁移脚本在测试机上全过上线后却在老版本数据上失败——某家门店积压了几千条离线工单迁移时触发了非常慢的 ETL 路径。后来把迁移改成分步执行先迁移 schema再在后台逐批 backfill 数据旧版本期间可以只读打开。所有迁移脚本在 CI 上专门用带异常脏数据的老库验证保证升级在不同门店的数据条件下都走同一条安全路径。7.3 鸿蒙字体度量差异与按钮截字HarmonyOS 6.0 的默认字体度量与 Android 原生不一致导致同一个 Button 在安卓上刚刚好在鸿蒙上文字被截掉半个字。这个问题肉眼很难发现是 golden 对比测试先报出来的后来在真机上复现确认。修复方案就是我们前面说的所有带文字的按钮定最小高度加安全 padding禁止硬编码 Text 高度。如果你也在做跨端建议把“字体度量不可跨端假设”直接写进 UI 规范省得后面挨个页面填坑。7.4 低端安卓真机上的掉帧与慢查询测试时大家手里都是中高端手机到门店现场才发现有技师还在用两三年前的机器。低端机上两类问题最明显页面列表一次性渲染太多卡片滚动掉帧严重本地库查询没走组合索引工单一多就要卡一两秒。后来列表改成懒加载加分页查询全部加组合索引本地库打开 WAL 模式问题才压住。上线前的最后一件事永远是拿一台你能买到的最便宜的安卓真机跑一遍核心流程。最后聊聊我从这个项目里拿走的东西。最大的体会是多端并不仅仅是“用一套代码跑所有设备”的口号而是要把业务逻辑和平台差异在工程结构上彻底分开把复杂度收拢在明确定义的边界里。如果你打算做维修或服务行业的数字化系统我建议不要一上来就把智能模块、离线同步、排程算法全部铺开先跑通“接单-检测-报价-施工-交付-结算”这条主链路再把离线能力加上最后才去碰 AI 和排程。这样每一步都踩在真实使用的反馈上而不是架构师在白板上的想象。踩过的坑和补坑的过程才是这个项目最有价值的部分。 
长河君 · 2026/10/18 3:52:16 · 阅读 1.2k Flutter × HarmonyOS 打造多端车辆维修中台：架构与离线同步实践
第一次真正意识到“维修厂还在用纸本子记工单”是我在一家汽修连锁门店现场看到的场景三块落了灰的显示器、一个只装了 Excel 的老电脑、贴在墙上的手写排班表每天流水不少可库存对不上、报价靠嗓子喊、交车时间全凭技师个人经验。从那天起我决定用 Flutter × HarmonyOS 6.0 亲手搭一套智能车辆维修管理系统后来它有了名字叫 CarFix Pro——一个面向多端的企业级维修业务中台。这篇文章不讲 PPT只讲真实落地过程中的技术选型、架构设计、离线同步、智能模块和踩坑复盘适合正在做维修或服务行业数字化的开发者参考。1. 立项抉择为什么是 Flutter为什么现在把鸿蒙押进来1.1 多端不只是“顺便支持”先说业务背景。CarFix Pro 要服务的不是单店而是拥有几十家门店的连锁维修企业坐在前台面对客户的接待员、在地沟里施工的技师、管配件仓库的库管、每天要看报表的店长和总部运营用的终端完全不同。前台往往是 Windows 一体机或安卓收银台技师手里是扛得住油污的平板和手机库管则是扫码枪加手机管理层希望打开浏览器就能看到核心指标。如果按传统做法“电脑 安卓 iOS 网页”四套终端至少要养三套开发团队业务还在验证期这个成本根本扛不住。而 CarFix Pro 立项时的核心诉求正是先用一个团队快速覆盖所有终端把业务流跑通再根据每个终端的真实反馈持续加深。1.2 为什么是 Flutter 而不是 React Native/uni-app/三套原生选择 Flutter 的第一理由并不是“一套代码跑所有端”这种营销话术而是它把业务逻辑、状态管理、UI 描述都集中在 Dart 一侧用自绘引擎保证跨平台观感的一致性。实际做下来跨端的复用率不可能做到 100%真正可行的是让 80% 的代码业务逻辑、路由、状态、数据层只写一遍剩下 20% 的端能力通过平台抽象层适配。如果换成 React Native 或 uni-appJS Bridge 在复杂列表和系统级 API 调用上容易成为瓶颈而且它们的渲染层依赖各端原生组件平台之间的观感差异需要额外工作去抹平。原生三件套就更不用说了双团队成本在中小团队里基本是死路。实现方案跨端一致性性能表现鸿蒙适配成本CarFix Pro 的选择Flutter自绘渲染一致性好AOT 编译列表滚动流畅需适配层桥接成本可控采用React Native依赖原生组件差异需自行修复JS Bridge 在复杂列表有压力需额外适配桥不采用原生三件套最一致最好鸿蒙侧需单独团队不采用1.3 为什么现在把 HarmonyOS 6.0 放进拼图把 HarmonyOS 6.0 拉进来起初不是因为它炫酷而是因为采购侧的实情不少汽修集团给新门店配的一体机、手持终端、看板大屏预装的就是鸿蒙版本的系统。产品如果跑不上这些设备等于直接缺席采购清单。再加上维修行业本身就是一个多设备场景——技师手机拍底盘视频、前台平板录工单、售后回访时可能要在车机屏或座舱入口做轻交互——鸿蒙生态这些年越来越强调设备协同和分布式流转这些能力很适合做成“门店设备之间无缝切换”的体验。我们最终把它当成多端里的一等公民来对待而不是某个实验性的小分支。1.4 代价Dart 生态与鸿蒙适配当然押注 Flutter 有代价。最直观的是 Dart 生态比 JS 生态小一圈很多“装个包就能用”的轮子要自己造其次是 Flutter 引擎对鸿蒙的官方支持不如 Android/iOS 那样成熟需要通过社区维护的渲染适配层和 Platform Channel 做桥接。这是立项时就清楚的风险后面的多端架构设计也一直在为这个风险兜底。选型不是选一个十全十美的方案而是选一个你愿意承担其缺点的方案然后把精力放在把缺点控制住。2. CarFix Pro 的骨架工单状态机与核心数据模型设计2.1 六个业务引擎怎么咬合先不聊代码抽象把 CarFix Pro 到底管哪些事说清楚。整个系统围绕一条主线展开车辆进店、接待检查、报价确认、维修施工、质检交付、结算离店。我们沿这条主线拆了六个引擎工单引擎、客户车辆档案引擎、配件库存引擎、结算引擎、排班引擎、数据看板。引擎之间不互相改表而是通过事件通信。比如工单状态变成“质检中”时系统发布一个 WorkOrderStageChanged 事件库存引擎听到后把该工单占用的配件从“预占”改为“已出库”结算引擎如果发现有旧件回收自动生成一项抵扣金额。这种事件式咬合让每个引擎独立演进而不是被别的模块牵着走。2.2 工单状态机八个状态与一张转移表工单状态机是整个业务链路的心脏。设计时最容易犯的错是把状态当成“按钮上的字”——后台提需求就加一个状态最后状态多到没人看得懂。我们反复删减把工单收敛为八个状态created、inspection、quoted、confirmed、repairing、qualityCheck、delivered、settled外加 cancelled 作为可跳跃进入的终止态。enum WorkOrderStage { created, // 进店创建尚未开始检测 inspection, // 技师检测中生成检测报告 quoted, // 报价已生成等待客户确认 confirmed, // 客户已确认开始安排施工 repairing, // 维修施工中含待料间隙 qualityCheck, // 质量复查 delivered, // 已交车客户签收 settled, // 已结算财务结账 cancelled // 已取消记录取消原因 }当前状态目标状态触发动作允许参与者校验规则createdinspection开始检测接待员/技师已绑定车辆档案inspectionquoted生成报价技师/店长检测报告非空quotedconfirmed客户确认接待员/客户报价单已推送confirmedrepairing开始施工店长/组长已分配技师与工位repairingqualityCheck提交质检技师维修明细完整qualityCheckdelivered确认交车质检员/店长质检记录通过deliveredsettled结算完成财务金额无未结项*cancelled取消工单店长/管理后台需填取消原因所有状态流转都会经过一个状态机引擎由它判断“这次流转是否允许”以及“谁有权限触发”。比如 quoted 不能由技师直接改为 repairing必须等客户确认而 repairing 阶段如果配件没到可以临时进入待料子状态但不改主状态避免状态漂移。把校验逻辑收拢在一个 engine 里比散落在几十个页面的按钮处理里好维护得多。2.3 数据模型围绕工单聚合根去建模接下去是数据模型。整个系统围绕工单聚合根来组织所有对象和工单形成可追溯的关系车辆档案在第一次进店时建好之后每次工单都挂在同一车牌和 VIN 下维修明细是工单与配件之间的桥每一行含配件 SKU、数量、单价、工时同一工单可以多次报价但只有最新一版生效。核心对象关键字段说明工单orderNo, vehicleId, mileage, stage, technicianIds, quotedAmount聚合根跨引擎通行的业务主键车辆档案plateNo, vin, modelId, lastInspectionAt, faultCodeHistory一车一档历史故障可沉淀维修明细orderId, partId, qty, unitPrice, laborMinutes, isInsurance工单与配件的桥影响库存与结算配件sku, categoryId, stockQty, safetyStock, avgMonthlyUsage库存数量与安全库存联动用聚合根而不是一堆散表的好处是维修清单、报价单、结算单始终围着同一个工单号展开任何一个环节出问题都能顺着 orderNo 一路回溯到底。多端产品最怕的就是每个端各存一套维度最后对不上账。2.4 多门店与 RBAC 权限模型门店隔离选了“共享库 tenantId 隔离”的折中所有门店共用一套服务端代码和数据库但每个门店有独立 tenantId资源查询强制拼上租户条件总部账号可以跨租户聚合报表门店账号只能看自己门店的数据。权限上做 RBAC角色包括超级管理员、总部运营、店长、前台接待、维修技师、库管、财务。每个角色的权限按“动作 资源”声明而不是按菜单写死——这样以后接小程序、公众号、车机屏权限模型可以直接复用不用重新设计。3. 一套代码的三种骨相多端工程架构与鸿蒙桥接实战3.1 feature-first 目录与 platform layer代码结构上CarFix Pro 走的是严格的 feature-first 分层顶层拆成 app、core、features、platforms 四个目录。app 只放应用入口、路由表、全局主题core 放与业务无关的基础能力比如网络封装、日志、数据库、事件总线、工具集features 按业务模块垂直拆分模块内部再分成 data、domain、presentation 三层模块之间禁止直接 import只能通过 core 里的公共事件或接口通信platforms 目录是整个工程最不一样的地方专门放端能力抽象与各平台的具体实现。这样做的收益在后期很明显当你想把整个系统从一块屏搬到另一块屏上时搬的是 features 和 core平台相关代码永远被挡在边界外。3.2 端能力适配从蓝牙 OBD 到推送的 Bridge 设计所谓端能力指在 Android、iOS、Web、HarmonyOS 上实现完全不同的系统能力。CarFix Pro 依赖的端能力包括蓝牙 OBD 读取、NFC 识别行驶证、相机拍照、相册选取、文件下载、本地数据库持久化、设备型号、网络状态、系统级推送、定位、震动反馈。我们为每种能力定义一个接口例如 DeviceBridge 负责设备型号BluetoothBridge 负责蓝牙链路PushBridge 负责推送注册。业务层只依赖接口不依赖任何一个平台的具体实现。以蓝牙 OBD 为例Port 接口大致长这样abstract class BluetoothBridge { Futurebool get isAvailable; StreamObdDevice scan(); FutureObdConnection connect(String deviceId); FutureDiagnosticTroubleCodeList readCodes(ObdConnection conn); }Android 端用系统 BLE 实现鸿蒙侧通过 Platform Channel 把 Dart 方法桥接到系统蓝牙服务Web 端直接返回“不支持”由 UI 隐藏相关入口。每一端的实现都藏在 platforms 目录里业务代码永远只看到统一的接口。3.3 编译期平台编排dart-define 与工厂模式多端差异最好在编译期被决定而不是在运行期到处写 if。我们把平台标识通过 --dart-define 注入格式是 PLATFORM_TAGharmony、android、ios、web然后写一个很简单的工厂class BridgeRegistry { static BluetoothBridge createBluetoothBridge() { const tag String.fromEnvironment(PLATFORM_TAG); switch (tag) { case harmony: return HarmonyBluetoothBridge(); case android: return AndroidBluetoothBridge(); case ios: return IosBluetoothBridge(); default: return UnsupportedBluetoothBridge(); } } }为什么不把平台判断写进业务代码因为一旦在几十个页面里出现 if (isAndroid) 这类分支产品经理很快会埋下一颗“只有某个平台生效”的雷。编译期工厂把平台差异限定在 platforms 目录业务代码永远保持干净的布尔逻辑。3.4 响应式 UI 断点与字体安全多端最烦的不是逻辑而是布局。同一张工单详情页在 6 寸手机上适合上下滑列表在 12 寸平板上应该左边表单右边操作面板在 Web 后台则是更宽的数据表格。CarFix Pro 用“断点 栅格”的自研轻量方案以 600px 和 1024px 为分界把常用页面拆成可复用的 Flex 区块窄屏纵向堆叠宽屏自动双栏或三栏。这里有一个值得写进规范的教训所有页面必须先开发窄屏版本再用同一份业务数据验证宽屏重构避免两个布局各写一套导致状态不同步。字体度量方面鸿蒙 6.0 与原生安卓默认字体不同我们统一给带文字按钮设置最小高度和额外安全 padding禁止在业务代码里硬编码 Text 高度否则同一套 UI 在两个平台上会出现截字。4. 让断网的车间继续干活离线缓存、同步引擎与冲突合并4.1 为什么维修车间必须 offline-first做过维修行业的人都懂车间和仓库的信号糟得离谱地沟下经常一格信号都没有仓库里堆满金属货架Wi-Fi 覆盖也是断断续续。如果把“创建工单、扫描配件条码、结束质检”这些高频动作做成强依赖网络技师的第一反应不是等着转圈而是掏出纸质记事本。所以 CarFix Pro 从第一天就定了 offline-first 架构客户端永远是操作入口云端是异步收敛的最终事实层。网络连不上活也得照干。4.2 冷温热三层数据与混合存储离线优先的第一步是决定哪些数据必须本地化。按使用频率分三层冷数据是车型库、配件目录、历史工单按需拉取并缓存过期一周温数据是当日班次、技师列表、当前待办每次启动刷新同时保留上次快照兜底热数据是正在编辑的工单、正在扫码的配件永远只存在本地直到同步确认成功才标记完成。存储上本地关系型数据库负责工单、维修明细这类强关系数据键值缓存放用户偏好和 Token 这类小配置。一句话别把所有东西都塞进同一个存储混合使用才能避免启动时全量加载。4.3 两段式同步引擎与幂等设计同步引擎是离线架构的心脏。设计为两段式客户端写操作先落库生成一条带 requestId 和 parentId 的操作记录入网后按顺序上传服务端收到后做幂等处理同一个 requestId 只生效一次然后返回一个递增游标客户端拉取自游标以来的增量数据。class OutboxRecord { final String requestId; final String aggregateType; // workorder | vehicle | part final String aggregateId; final String operation; // upsert | transition | delete final MapString, dynamic payload; final DateTime createdAt; }为什么不直接同步整张表因为维修工单是典型的“多人连续改一单”场景——前台改客户手机号、技师补施工明细、财务调应收金额三个人可能同一天动同一张单。整表同步的冲突率高得离谱而按操作粒度同步冲突可以控制在字段级。4.4 冲突合并字段级、时间戳级与人工仲裁离线冲突无法完全避免但可以尽量让它可处理。CarFix Pro 用三级策略同一个字段值以“最后写入 服务器时间戳”为准不同字段之间做字段级合并前台改电话、技师补配件互不覆盖一旦真撞在同一个关键字段上比如结算金额被两个人同时改系统自动标记“待仲裁”生成一条审批提示由店长在回连后确认。最开始我也想上一套 CRDT 让它自动合并后来发现维修业务的冲突很多不是数学问题而是管理问题——与其让算法偷偷改掉不如明确标记出来让店长拍板业务上更好交代。同步线程的触发时机也做了控制应用启动、从后台回前台、Wi-Fi 恢复、以及每隔 15 分钟兜底一次。触网后Outbox 里的操作按优先级上传结算类 状态流转 出入库 统计同步进度会实时显示在顶部让技师知道“还有 3 条没传上去”而不是默默失败。5. 智能模块落地AI 诊断、配件推荐与排程算法的边界5.1 智能不智能先看能不能改变业务动作谈“AI 赋能维修”很多方案是拿大模型生成一段“建议”读起来都对落地全废。我们在 CarFix Pro 的智能化上非常克制原则只有一条每个智能模块必须直接改变业务流中的某个决策或动作否则不做。按这个原则上线了三个模块OBD 故障码辅助诊断、拍照识别里程表和配件铭牌、维修工时预测与预约排程。它们都不炫酷但都能减少一次手工操作。5.2 OBD 故障码辅助诊断与本地规则库技师把蓝牙 OBD 盒插到诊断口手机端连上后读取 ECU 故障码和实时数据流。原始数据是一串 P0xxx、U0xxx 编码大多数技师只认识其中常用的一部分遇到冷门码得翻手册或者拍照去搜。CarFix Pro 在本地内置了三千多条故障码规则把故障码映射到故障等级、维修方案、可能涉及的配件和预估工时。读码完成后生成一张“诊断摘要”技师确认或修改后一键转成工单检测报告。难点不在匹配本身而在把维修语境组合起来做筛选同一个故障码在不同品牌、不同车型上的维修方案差异很大规则引擎必须组合 VIN 年份、车系、里程来过滤。5.3 OCR 识别里程表、车牌与配件铭牌拍照识别分两部分一是进店接车时前台拍仪表盘OCR 自动读里程避免手输错二是库管遇到扫码枪扫不出来的旧件或异形件拍照识别铭牌型号。车牌识别也在接车环节顺手做了直接进车辆档案。这些功能单看都不算黑科技但一旦和工单打通价值很实在——把最容易出错的录入环节砍掉了。真实数据里仪表盘、车牌这类规整场景的识别率很稳但模糊铭牌的错误率会明显偏高所以我们坚持“识别 人工确认”绝不全自动提交免得 OCR 读错一个数字后面整个结算都要返工。5.4 配件关联推荐与实时库存联动配件推荐从历史工单里挖关联规则同车型进厂修刹车片有一半概率同时需要刹车盘报修发动机异响的车最后开出的明细往往包含机油滤芯和发动机护板。实现上没有上来就搞协同过滤而是直接在本地跑 Apriori 风格的统计把规则落到建议清单前台录入维修明细时实时提示。一个关键经验是配件推荐必须和实时库存联动关联规则再好仓库没货等于白搭还得判断库存是否被其他在施工的工单预占。推荐接口里直接输出可售库存而不是理论库存。排程方面用的是带约束的贪心加关键工位优先一个工位一次只能停一辆车一个技师同一时段最多绑一个工位等待配件到货的工单自动降级为待料。系统按预约时间和承诺交车时间生成工作日历店长可以拖拽调整调整后依赖该工位的任务全部重算。相比纯学术最优解这套方法牺牲了一点理论最优但换来的是店长看得懂、能干预、敢用。在数字化系统落地里可解释性往往比最优解更重要。6. 被工期反复毒打后我才重视的工程化问题6.1 冷启动从 3.7 秒压到 1.3 秒CarFix Pro 是一个典型“壳轻核重”的应用业务模块多如果启动时全部初始化在低端安卓上首页出现前可以卡三四秒。做完三件事后效果立竿见影入口页只依赖冷缓存和最小依赖树数据库和同步引擎放进后台 isolate 初始化不在首帧阻塞 UI路由表和业务模块按 feature 动态注册启动时只加载首页相关的两个 feature其余在路由命中时才注入。主流千元机上冷启动从约 3.7 秒降到 1.3 秒左右。6.2 图片管道、体积裁剪与低端机内存维修场景里的工单照片动辄十几 MB如果直接用原图解码低端机的内存会被瞬间打爆。图片层强制统一走缩略图管道列表最多渲染 480px 宽的缩略图详情页需要时再加载原图再用一个 LRU 控制内存上限。包体积方面做了平台裁剪和延迟加载——配图、维修手册这类大体积静态资源不打进安装包放到 CDN 首次触网后拉取本地只留占位图。这对多端产品特别重要因为鸿蒙和安卓的应用包都有大小限制装包越瘦用户越愿意升级。6.3 三层自动化测试与 Golden 对比多端最怕的是改一个逻辑某个平台的表单塌了。CarFix Pro 配了三层自动化测试核心状态机引擎用纯 Dart 单元测试覆盖所有状态转移路径关键业务页面写 Widget 测试并截图做 golden 比对核心链路也就是从建单到结算的完整流程写端到端测试至少在安卓和鸿蒙各跑一遍。Golden 在跨平台里特别有价值——它能捕捉到字体度量差异导致的按钮折叠人眼经常漏掉这种问题。数据库迁移也在 CI 上跑一份模拟脏数据的老库测试专门验证升级路径。6.4 CI/CD 多端产物与真机清单发布流程上CI 为四个目标产物分别构建Android 的 APK/AAB、iOS 的 IPA、鸿蒙应用包、Web 产物。每个产物构建完自动跑 smoke test 然后出报告。发布顺序是先内部测试群发一版再按 10% 灰度最后全量。自动化覆盖不了真机兼容性于是把主流机型固化成清单每次发版前真机过一遍鸿蒙设备单独抽了门店实际在用的一台一体机和一台手持终端这两个设备不过就不允许发生产。7. 复盘几个印象深刻的坑从多端适配到数据迁移7.1 channel 注册时序导致的诡异无响应第一次把 CarFix Pro 跑上鸿蒙适配层时遇到奇怪崩溃某页面点蓝牙按钮没有任何反应另一台设备同操作却正常。排查到最后发现Dart 侧发起 Platform Channel 调用的时机早于鸿蒙侧完成 Channel 注册。这类“初始化时序”问题是跨平台 bug 的常客解决方式是把所有 channel 注册收敛到一个入口并在引擎 ready 事件之后再允许业务发起调用。不要依赖系统给的默认时序跨端开发里这种假设迟早会被某个平台打破。7.2 离线大队列下的数据库迁移共享库 门店隔离的模式让每次本地数据库迁移都像拆弹。最疼的一次是给工单表加“保险理赔金额”字段迁移脚本在测试机上全过上线后却在老版本数据上失败——某家门店积压了几千条离线工单迁移时触发了非常慢的 ETL 路径。后来把迁移改成分步执行先迁移 schema再在后台逐批 backfill 数据旧版本期间可以只读打开。所有迁移脚本在 CI 上专门用带异常脏数据的老库验证保证升级在不同门店的数据条件下都走同一条安全路径。7.3 鸿蒙字体度量差异与按钮截字HarmonyOS 6.0 的默认字体度量与 Android 原生不一致导致同一个 Button 在安卓上刚刚好在鸿蒙上文字被截掉半个字。这个问题肉眼很难发现是 golden 对比测试先报出来的后来在真机上复现确认。修复方案就是我们前面说的所有带文字的按钮定最小高度加安全 padding禁止硬编码 Text 高度。如果你也在做跨端建议把“字体度量不可跨端假设”直接写进 UI 规范省得后面挨个页面填坑。7.4 低端安卓真机上的掉帧与慢查询测试时大家手里都是中高端手机到门店现场才发现有技师还在用两三年前的机器。低端机上两类问题最明显页面列表一次性渲染太多卡片滚动掉帧严重本地库查询没走组合索引工单一多就要卡一两秒。后来列表改成懒加载加分页查询全部加组合索引本地库打开 WAL 模式问题才压住。上线前的最后一件事永远是拿一台你能买到的最便宜的安卓真机跑一遍核心流程。最后聊聊我从这个项目里拿走的东西。最大的体会是多端并不仅仅是“用一套代码跑所有设备”的口号而是要把业务逻辑和平台差异在工程结构上彻底分开把复杂度收拢在明确定义的边界里。如果你打算做维修或服务行业的数字化系统我建议不要一上来就把智能模块、离线同步、排程算法全部铺开先跑通“接单-检测-报价-施工-交付-结算”这条主链路再把离线能力加上最后才去碰 AI 和排程。这样每一步都踩在真实使用的反馈上而不是架构师在白板上的想象。踩过的坑和补坑的过程才是这个项目最有价值的部分。