Chapter 01 / Executive Summary
-Continental Retail APP 将整合并关停六套小程序。首版只面向 Android 与 iOS；在十一种候选技术栈中，核心挑战仍是系统级能力、第三方网页集成与长期工程可控性。
- -首版投入与 uni-app x 基本持平；真正的差异将出现在未来五年新增系统能力、自动化交付和底层问题的处置能力上。
Chapter 02 / Architecture
-Kotlin 与 Swift 分别开发。能力没有上限，但维护两套代码与团队。
uni-app 的路径。系统能力依赖插件，受 WebView 内核与插件生态制约。
uni-app x、React Native、Kuikly、.NET MAUI 的路径。能力上限取决于“翻译词典”和插件覆盖度。
Flutter 自己绘制像素，原生能力通过标准插件直接对接，边界由工程能力决定。
| 维度 | uni-app | uni-app x | Flutter |
|---|---|---|---|
| 路线 | 网页套壳 | 系统控件编译 | 自绘引擎 |
| 界面一致性 | 受 WebView 影响 | 两端系统控件存在差异 | 逐像素一致 |
| 能力天花板 | 插件生态 | 词典 + 插件生态 | 自己的工程能力 |
Chapter 03 / Product Fit
-App 在页面加载后注入胶水代码，单一双向 JavaScript Channel 承担请求与回调。F6 无需引入额外脚本。
网页须引入 DCloud 的 uni.webview.js；网页到 App 与 App 到网页是两条不对称单向通道，需自行封装协议。
Chapter 04 / Ecosystem & Governance
-Flutter 主仓库公开提交数，包含渲染引擎到框架层。
Flutter fork 数。公开协作与问题排查的广度。
相对 uni-app 主仓库提交数与 fork 数的量级差异。
开源的层次不同。
Flutter 从渲染引擎到框架均以 BSD 协议开源。uni-app x 的组件与 API 开源，但 Runtime、SDK 和 HBuilderX 为 DCloud 自有闭源能力。
这不是偏好问题。
当问题落在渲染层或运行时，Flutter 可以阅读源码、提交修复或自行维护；uni-app x 需要依赖厂商支持。对于五年周期的核心业务系统，这是不同的风险敞口。
My BMW App 覆盖 47 国。其 Mobile 2.0 Platform 可在每次构建中自动生成、测试并部署 96 个变体。
大众安徽的法定 SDK 披露将 Flutter 列为 App 全部 L1、L2、L3 页面开发语言，展示真实混合架构的主干选择。
Chapter 05 / Delivery & Extensibility
-既定链路包含 GitLab CI/CD、三套环境、远程 Mac 构建节点、Android OTA 与 iOS TestFlight。目标是每次发布都可追溯、可复现。
-代码提交后触发 lint、格式化与测试卡点。
Android / iOS 在自有流水线和构建节点中出包。
官方限制：UTS 插件只能经 HBuilderX 创建和使用，不支持 CLI。
加密付费插件仅支持云端打包；部分系统扩展官方建议离线打包，形成取舍。
离线打包不是完整原生工程。
拿到的是围绕闭源 Runtime / AAR 搭建的壳工程：可在外层添加模块，不能修改运行时内部行为。
扩展能力会回到原生。
小组件、Siri 快捷指令、分享扩展等最终仍需要 Xcode / Android Studio 与 Swift / Kotlin；Flutter 侧可直接遵循标准原生工程规则。
Chapter 06 / Recommendation
-0.1 / Executive Summary
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 开发 |
1.2 / Four Architectural Routes
系统给什么就能用什么；代价是两份 UI 和两组工程协作。
一套 Web 代码覆盖多端；系统能力必须借插件从网页环境打洞。
由语言和词典翻译到 Kotlin / Swift；词典外的能力需要自行补齐。
Flutter 自己绘制像素，系统能力通过标准原生插件直接连接。
Kotlin Multiplatform 是例外：它默认只共享逻辑层；配上 Compose Multiplatform 才进入 UI 跨端路线。
1.3 / Capability Ceiling
没有人提供或持续维护的能力，就会成为业务路线的阻塞点。
既受平台映射能力影响，也受插件和 IDE 工具链制约。
原生工程、渲染框架和桥接协议都在项目可掌控范围内。
2.1 / uni-app
它是什么。
使用 Vue / JavaScript 开发，App 端运行在系统 WebView。它的目标是让小程序团队顺便发布 App 与 H5。
它适合什么。
小程序是主要入口、App 只是辅助触点的商城或业务工具。此时同一套页面复用有明确回报。
2.2 / uni-app x
它使用 UTS / UVue，编译到 Android Kotlin、iOS Swift、鸿蒙 ArkTS，并使用系统原生控件渲染。设计方向值得肯定，但其能力边界仍由映射层、插件和工具链共同决定。
直接编译目标端语言，相比字符串式方法调用更具类型表达力。
传统 uni-app 原生插件不兼容，旧市场也已停止接受新增上架。
可完成 App，但无法消除本项目中原生集成与自动化交付的复杂度。
2.3 / Flutter
一致性。
Dart 提前编译；界面由自带引擎逐像素绘制，不依赖 Android 与 iOS 控件的默认差异。
连接原生。
每项系统能力可封装为独立插件。Pigeon 从一份定义生成 Dart、Kotlin、Swift 三端强类型接口，接口失配在编译期暴露。
3.1 / F6 Web Integration
报价开单、施工查车、结算收银和提醒模块都依赖嵌入的 F6 页面。网页需要调用扫码、拍照、上传、拨号、登录态和门店上下文等 13 项能力、15 个方法，App 也必须反向通知网页。
在页面加载完成后由 App 自动注入胶水代码。请求与回调共用协议，例如 { id, method, params }，F6 无需修改。
网页须引入 uni.webview.js；网页到 App 用 postMessage，App 到网页用 evalJS，需自行补齐协议与异常处理。
3.2 / Native Capability Density
3.3 / Module Boundaries
近三百条需求，长期多人并行开发。
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
My BMW App 覆盖 47 国。Mobile 2.0 Platform 每次构建可自动生成、测试并部署 96 个变体。
大众安徽法定 SDK 披露将 Flutter 列为 App 全部 L1、L2、L3 页面开发语言。
4.3 / AI Toolchain
| 维度 | 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 |
5.3 / Extensions
iOS 需要 Xcode、SwiftUI 与 WidgetKit 的 .appex；Android 同样需要 Kotlin、Manifest 和 XML。
官方建议离线打包后在原生工程实现 AppShortcutsProvider，再通过 UTS 衔接业务。
加密 UTS 插件仅支持云端传统打包，和部分扩展所需的离线路径互斥。
做得到不等于低成本：两端仍需写 Swift / Kotlin，并额外承受一层厂商打包与基座规则。
6.1 / First Release Cost
6.2 / Fair Comparison
这些优势不应被回避；它们只是没有改变本项目在 F6 集成、原生能力密度和 CI 可控性上的关键判断。
6.3 / Final Recommendation