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
+