Chapter 01 / Executive Summary
面向五年周期的
独立 App 技术路线选择。
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 自己绘制像素，原生能力通过标准插件直接对接，边界由工程能力决定。
Kuikly 的位置：腾讯于 2025 年开源、内部落地规模可观，但对外生态仅一年多，且更贴合 Kotlin/KMP 团队与动态化需求。本项目不具备这两个前提，应在未来三年后重新评估。
| 维度 | uni-app | uni-app x | Flutter |
|---|---|---|---|
| 路线 | 网页套壳 | 系统控件编译 | 自绘引擎 |
| 界面一致性 | 受 WebView 影响 | 两端系统控件存在差异 | 逐像素一致 |
| 能力天花板 | 插件生态 | 词典 + 插件生态 | 自己的工程能力 |
Chapter 03 / Product Fit
原生能力密度，才是本项目的决定性变量。
Flutter F6 网页零改动
App 在页面加载后注入胶水代码，单一双向 JavaScript Channel 承担请求与回调。F6 无需引入额外脚本。
uni-app x 需要外部厂商配合
网页须引入 DCloud 的 uni.webview.js；网页到 App 与 App 到网页是两条不对称单向通道，需自行封装协议。
扫码 / VIN 识别
相机 / 相册多选
弱网离线与重传
带进度的大文件上传
定位与运行时权限
Bugly 崩溃上报
神策埋点 SDK
物理返回键拦截
WebView 文件选择
iOS 隐私清单
结论：这些能力无论选择哪条路线都需要实现与双端验证。Flutter 的原生实现可同时服务原生页面和 F6 网页通道；uni-app x 则需在 UTS 插件与 HBuilderX 约束下处理。
Chapter 04 / Ecosystem & Governance
生态的价值，在规模化交付与问题发生时才真正显现。
Flutter 主仓库公开提交数，包含渲染引擎到框架层。
Flutter fork 数。公开协作与问题排查的广度。
相对 uni-app 主仓库提交数与 fork 数的量级差异。
开源的层次不同。
Flutter 从渲染引擎到框架均以 BSD 协议开源。uni-app x 的组件与 API 开源，但 Runtime、SDK 和 HBuilderX 为 DCloud 自有闭源能力。
这不是偏好问题。
当问题落在渲染层或运行时，Flutter 可以阅读源码、提交修复或自行维护；uni-app x 需要依赖厂商支持。对于五年周期的核心业务系统，这是不同的风险敞口。
BMW / 甲档案例
96 个变体，自动化交付
My BMW App 覆盖 47 国。其 Mobile 2.0 Platform 可在每次构建中自动生成、测试并部署 96 个变体。
ID. UNYX / 乙档案例
主干页面承载车控场景
大众安徽的法定 SDK 披露将 Flutter 列为 App 全部 L1、L2、L3 页面开发语言，展示真实混合架构的主干选择。
落地证据：字节 90+ 款、闲鱼、美团商家端、京东、携程、BMW 与 ID. UNYX 的公开材料，指向“原生 / 混合底座 + Flutter 承载业务主干”的成熟形态，正是本项目规划的路径。AI 工具链方面，Flutter / Dart 的 skills 和 MCP 服务也是独立开源资产，可接入多种 agent 工具。
Chapter 05 / Delivery & Extensibility
自动化交付，不能依赖某台机器上的一个 IDE。
既定链路包含 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
首版成本持平，五年后的主动权不一样。
- 架构适配：项目是独立 App，无法获得多端小程序复用收益。
- 业务风险：F6 集成和十余项原生能力需要更直接、可控的通道。
- 长期治理：开放生态与完整原生工程为问题处置保留主动权。
- 交付能力：Flutter 更匹配现有 GitLab CI/CD 与标准原生扩展方式。