0.1 / Executive Summary
面向五年周期的
独立 App 技术路线选择。
Continental Retail APP 将整合并关停六套小程序。首版只面向 Android 与 iOS；评估重点不在“画页面快不快”，而在系统能力、第三方网页集成与长期工程主动权。
首版投入与 uni-app x 基本持平。真正拉开差距的是后续系统级需求、自动化交付和运行时问题的处置空间。
面向五年周期的
0.2 / Decision Logic
四条可核验的推荐理由。
项目正在关停小程序，不获得 uni-app 系最核心的多端复用收益。
扫码、OCR、上传、定位、离线、权限和 SDK 集成不会因更换框架而消失。
Flutter 的边界是自身工程能力；uni-app x 的关键边界仍受 Runtime、插件和打包体系影响。
关键判断：这不是“哪种技术更流行”的偏好选择，而是当前项目是否愿意为不使用的多端复用能力，承担工具链和运行时上的约束。
0.3 / Comparison At A Glance
优势与代价，都应放到同一张桌子上。
| 维度 | Flutter | uni-app x |
|---|---|---|
| 架构路线 | 自绘引擎 | 编译到系统控件 |
| F6 网页 | App 侧建立通道，F6 零改动 | F6 需引入 DCloud JS 文件 |
| 原生能力 | Pigeon 强类型生成，支持 CLI | UTS 插件，工具链绑定 HBuilderX |
| 工程归属 | 完整自有 Android / iOS 工程 | 围绕闭源 Runtime 的壳工程 |
| 客观优势 | 生态、开放性与界面一致性 | 鸿蒙、一套代码复用、包体与内存 |
包体、内存与鸿蒙是 uni-app x 的真实优势，但均不在本项目首版的敏感维度。
1.1 / Market Landscape
十一种候选技术栈，先完整摆上台面。
| 路线 | 代表方案 | 适用前提 |
|---|---|---|
| 原生双端 | Kotlin / Swift | 能力上限优先，接受双端团队 |
| 网页套壳 | uni-app、Taro、Cordova、Capacitor | 小程序 / H5 为主，App 为补充 |
| 编译到系统控件 | uni-app x、React Native、Kuikly、MAUI | 翻译层与插件覆盖需求范围 |
| 自绘引擎 | Flutter | 需要跨端一致且长期演进的独立 App |
| 逻辑层共享 | Kotlin Multiplatform | 愿意保留两端 UI 开发 |
本轮不展开的方案：React Native 的核心前提是已有 React 人力；Taro、Cordova、Capacitor 的重心仍是网页路线；KMP 只共享逻辑；Kuikly 则对外生态仍处早期。
1.2 / Four Architectural Routes
品牌不同，能力上限来自同一套底层规律。
原生双端
系统给什么就能用什么；代价是两份 UI 和两组工程协作。
网页套壳
一套 Web 代码覆盖多端；系统能力必须借插件从网页环境打洞。
编译到控件
由语言和词典翻译到 Kotlin / Swift；词典外的能力需要自行补齐。
自绘引擎
Flutter 自己绘制像素，系统能力通过标准原生插件直接连接。
Kotlin Multiplatform 是例外：它默认只共享逻辑层；配上 Compose Multiplatform 才进入 UI 跨端路线。
1.3 / Capability Ceiling
五年后真正要问的：天花板在谁手里？
没有人提供或持续维护的能力，就会成为业务路线的阻塞点。
既受平台映射能力影响，也受插件和 IDE 工具链制约。
原生工程、渲染框架和桥接协议都在项目可掌控范围内。
本项目的结论：需求只会增加，能力上限归属不是技术偏好，而是五年周期的风险管理问题。
2.1 / uni-app
uni-app 的价值，在小程序主导的多端复用。
它是什么。
使用 Vue / JavaScript 开发，App 端运行在系统 WebView。它的目标是让小程序团队顺便发布 App 与 H5。
它适合什么。
小程序是主要入口、App 只是辅助触点的商城或业务工具。此时同一套页面复用有明确回报。
项目不匹配点当前项目正在整合并关闭六套小程序，首版也不发布 H5。
直接后果界面本质仍是网页，重原生能力需要反复通过插件打通。
2.2 / uni-app x
uni-app x 不是传统 uni-app 的简单升级。
它使用 UTS / UVue，编译到 Android Kotlin、iOS Swift、鸿蒙 ArkTS，并使用系统原生控件渲染。设计方向值得肯定，但其能力边界仍由映射层、插件和工具链共同决定。
直接编译目标端语言，相比字符串式方法调用更具类型表达力。
传统 uni-app 原生插件不兼容，旧市场也已停止接受新增上架。
可完成 App，但无法消除本项目中原生集成与自动化交付的复杂度。
2.3 / Flutter
Flutter 的出发点，就是构建独立 App。
一致性。
Dart 提前编译；界面由自带引擎逐像素绘制，不依赖 Android 与 iOS 控件的默认差异。
连接原生。
每项系统能力可封装为独立插件。Pigeon 从一份定义生成 Dart、Kotlin、Swift 三端强类型接口，接口失配在编译期暴露。
架构判断：本项目要做的是一个独立 App，而不是一个小程序附属品。仅从架构选型，Flutter 已满足最直接的适配条件。
3.1 / F6 Web Integration
嵌入 F6 网页，是项目最高风险项。
报价开单、施工查车、结算收银和提醒模块都依赖嵌入的 F6 页面。网页需要调用扫码、拍照、上传、拨号、登录态和门店上下文等 13 项能力、15 个方法，App 也必须反向通知网页。
Flutter 单一双向通道
在页面加载完成后由 App 自动注入胶水代码。请求与回调共用协议，例如 { id, method, params }，F6 无需修改。
uni-app x 两条单向通道
网页须引入 uni.webview.js；网页到 App 用 postMessage，App 到网页用 evalJS，需自行补齐协议与异常处理。
3.2 / Native Capability Density
真正的工作重心，不是页面，而是系统集成。
扫码 / VIN OCR
相机 / 相册多选
文件上传进度
弱网离线与重传
图片压缩
定位与权限
Bugly 崩溃桥
神策 SDK
返回键拦截
WebView 文件选择
成本含义：上述能力无论选择哪条路线都需要实现、维护、双端验证。框架对 UI 的效率影响，只覆盖整体工作中较小的一部分。
3.3 / Module Boundaries
十九个模块并行开发，边界必须能被强制执行。
19 模块
近三百条需求，长期多人并行开发。
21 包
Flutter 以 Melos 组织基础设施、业务模块与原生能力层。
编译期
包依赖机制可阻止业务模块直接引用彼此内部实现。
第二年
边界约束的价值，会在重构、替换和新增能力时放大。
uni-app x 也可以组织工程化目录，但模块边界更多依赖团队自觉和评审纪律，缺少同等强度的物理阻断。
4.1 / Openness & Continuity
关键不是“是否开源”，而是开到哪一层。
Flutter 主仓库公开提交数，包含渲染引擎到框架层。
Flutter Fork 数，体现公开协作与问题排查广度。
相对 uni-app 主仓库提交数与 Fork 数的量级差异。
Flutter。
引擎和框架均以 BSD 开源，原生工程由项目自身掌握。
uni-app x。
组件与 API 开源；Runtime、SDK 与 HBuilderX 为 DCloud 自有闭源能力。
4.2 / Production Evidence
大型 App 的真实形态，是混合底座加跨端业务主干。
BMW / 甲档案例
96 个变体，自动化交付
My BMW App 覆盖 47 国。Mobile 2.0 Platform 每次构建可自动生成、测试并部署 96 个变体。
ID. UNYX / 乙档案例
主干页面承载车控场景
大众安徽法定 SDK 披露将 Flutter 列为 App 全部 L1、L2、L3 页面开发语言。
同一形态的公开案例：字节 90+ 款应用、闲鱼主链路、美团商家端、京东、携程、BMW 与 ID. UNYX 都证明：原生能力仍在原生侧，业务页面可以稳定由 Flutter 承担。
4.3 / AI Toolchain
AI 辅助效率，来自开放生态与公开代码沉淀。
| 维度 | Flutter / Dart | uni-app x |
|---|---|---|
| 官方 Skills | 独立开源仓库，可 Fork / PR | 主要内置于 uni-agent |
| MCP | Dart & Flutter MCP Server | uni-app-x-mcp |
| 工具适配 | 可接入多种 AI 编程工具 | 以自家生态和少数工具为主 |
| 公开语料 | 近十年全球 Dart / Flutter 项目 | UTS / UVue 较新，公开沉淀有限 |
实际影响：当开发者需要生成、调试、重构或验证原生桥接与业务组件时，公开生态的深度会直接反映在生成质量和返工率上。
5.1 / Delivery Pipeline
目标是每个版本都能从一次提交中重建。
既定工程链路：GitLab CI/CD，lint / 格式化 / 测试卡点，dev / uat / prod 三环境，远程 Mac 出 iOS 包，Android OTA 与 iOS TestFlight 分发。
提交触发静态检查、格式化和测试。
Android / iOS 在自有节点完成可追溯构建。
UTS 插件创建和使用绑定 HBuilderX，官方不支持 CLI。
云打包、离线打包和加密插件之间存在结构性取舍。
5.2 / Packaging Boundaries
“离线打包”给的是壳，不是完全可控的原生工程。
| 范围 | 可以修改 | 不能修改 |
|---|---|---|
| 工程外层 | 包名、图标、权限、ABI、原生模块 | 运行时页面容器和生命周期 |
| Android | Manifest 与 Gradle 配置 | 闭源 AAR 内部实现与 UTS 通信机制 |
| 应用入口 | 可在约束下定制 | Application 必须继承 DCloudApplication |
| 语言选择 | Flutter 标准 Kotlin / Swift | 传统离线 SDK 官方声明不支持 Kotlin |
核心区别：Flutter 以模块挂入自己的标准 Android / iOS 工程；uni-app x 离线 / 嵌入路径则是把自定义内容放入围绕闭源运行时构成的宿主壳中。
5.3 / Extensions
桌面小组件、Siri 和分享扩展，最终都会回到原生。
iOS 需要 Xcode、SwiftUI 与 WidgetKit 的 .appex；Android 同样需要 Kotlin、Manifest 和 XML。
官方建议离线打包后在原生工程实现 AppShortcutsProvider，再通过 UTS 衔接业务。
加密 UTS 插件仅支持云端传统打包，和部分扩展所需的离线路径互斥。
做得到不等于低成本：两端仍需写 Swift / Kotlin，并额外承受一层厂商打包与基座规则。
6.1 / First Release Cost
首版成本基本持平，差异在 ±10% 内。
成本不是决策理由。 UI 熟悉度带来的节省被原生桥接、插件工具链与 CI / 发布成本抵消，首版不应以工时差异作为主导依据。
6.2 / Fair Comparison
uni-app x 的三项真实优势，应当被正面计入。
鸿蒙支持更完整UTS 可直接编译 ArkTS；Flutter 主线不支持鸿蒙，社区分支正在跟进。
小程序与 H5 复用若未来需要 App、小程序、H5 同时发布，价值会立即显现。
UTS 的语言方向正确直接编译 Kotlin / Swift 的桥接方式比传统字符串式调用更干净。
包体、内存与热更新uni-app x 在这些方面有实际优势，但本项目没有包体 KPI，发版也采用正规分发链路。
这些优势不应被回避；它们只是没有改变本项目在 F6 集成、原生能力密度和 CI 可控性上的关键判断。
6.3 / Final Recommendation
推荐 Flutter，把能力上限留在自己的工程里。
- 架构适配：项目是独立 App，无法获得多端小程序复用收益。
- 业务风险：F6 集成和十余项原生能力需要直接、可控的通道。
- 长期治理：开放生态与完整原生工程为问题处置保留主动权。
- 交付能力：Flutter 匹配既有 GitLab CI/CD 与标准原生扩展方式。