conti-docs/tech-selection/Flutter-vs-UniApp-Speaker.md

# Flutter vs uni-app x — 27 页内容摘要

配 `Flutter-vs-UniApp-deck.standalone.html`。数据核验 2026-08-25，出处见 `Flutter-vs-UniApp.md` 附录 A。
30 分钟配时写在每页标题后。对表点：**第 12 页 ≈ 12:00 · 第 17 页 ≈ 18:40 · 第 22 页 ≈ 24:40**。

---

## 事实校正

以下六条**在材料里没有依据**，是早期版本里被推翻的说法：

| 错 | 对 |
| --- | --- |
| uni-app x 不支持 iOS / 鸿蒙 / AI 工具 | 三条 2026 年都支持；鸿蒙它更强 |
| uni-app x 只有文档开源 | 组件与 API 是 Apache-2.0 开源；闭的是 Runtime、原生 SDK、HBuilderX |
| 提交量差几十倍 | 8.1 倍（91,171 / 11,216） |
| UVue 是改过的 Weex | nvue 才是 |
| 小组件 / Siri 做不到 | 做得到，代价是开 Xcode 写 Swift + 多绕一层 DCloud 打包规则 |
| 离线打包 = 原生工程完全可定制 | 围着闭源 AAR 的壳工程；壳外可加，壳内不可改 |

三个措辞口径：uni-app x 大厂案例是**「未检索到」不是「没有」**；成本是**「基本持平」不是「Flutter 更便宜」**；ID. UNYX 的依据是**大众安徽官网合规披露那条公开链接**。

---

## 逐页

### 1 · 封面 — 0:30
App 技术栈介绍 · T-Systems · 2026 年 8 月。

### 2 · 目录 — 0:30
五部分：跨端技术路线 / 三框架定位 / 生态与落地 / 产品能力与工程链路 / 结论。

### 3 · 结论摘要 · 推荐 Flutter — 2:00
**落点**：四条理由，且明确不做优劣评判。

- **界面两端完全一致** — 自绘引擎，不用系统控件、不依赖各机型浏览器内核。对本项目 = 六套来源不同的小程序整合后，同一业务概念在各页面长得一样
- **系统能力无额外限制** — 原生侧就是标准 Xcode / Android Studio 工程；小组件、Siri、系统推送按常规原生做，不必学第二套插件规则
- **大型 App 先例充分** — BMW、大众安徽、字节、阿里、腾讯、美团、京东、贝壳、携程；引擎到框架全部开源
- **技术栈稳定** — Flutter 2015 至今同一主线；uni-app 系同期换过两代 App 方案（5+ App、nvue），两代已于 2024 年停止官方维护
- 页脚原文：不做优劣评判，只对照与本项目形态的匹配度；uni-app x 更优三项在第 24 页

### 4 · 三个框架核心对照 — 1:30
10 行表。**前 7 行 Flutter 占优，后 3 行 uni-app x 占优**（鸿蒙 / 包体内存 / 成本）。

值得停的四行：
- **嵌 F6 网页** — Flutter 侧 F6 零改动；uni-app x 侧需 F6 引入 `uni.webview.1.5.5.js`
- **原生能力开发** — Flutter 支持命令行；uni-app x 插件只能经 HBuilderX
- **开源程度** — 差别在开到哪一层，见第 13 页
- **成本** — ±10% 以内，基本持平

### 5 · 分隔 01 — 0:10
跨端开发的技术路线。

### 6 · 市面方案按原理只有四类 — 1:20
11 个方案归四类：① 原生双端 ② 网页套壳（uni-app、Cordova、Capacitor、Taro）③ 编译到系统控件（uni-app x、RN、Kuikly、MAUI）④ 自绘引擎（**只有 Flutter**）。

- `5+ App`、`nvue` 标灰 = DCloud 上一代方案，已停止维护
- 未展开的：RN 前提是团队已有 React 栈；Taro / Cordova / Capacitor 重心仍是网页路线；KMP 只共享逻辑层；Kuikly 2025 年开源，对外生态尚早

### 7 · 四条路线，从代码到屏幕 — 2:00
四根柱子的分层图。落点在页脚：**路线 ② ③ 的界面最终交给别人画**（一个交给浏览器内核，一个交给系统控件），**路线 ④ 把这层拿回框架自己手里**——是控制权归属，不是好坏。

装修类比（md 1.2 已有）：② 贴壁纸，墙有多平壁纸就有多平 · ③ 翻译图纸，词典没有的词做不出来、得自己补 · ④ 自带施工队，进哪套房子装出来都一样。

### 8 · 「界面由谁绘制」影响三件事 — 1:10
三行：两端一致性 / 做设计稿上的特殊效果 / 用一个新的系统能力。

落点在右下两张卡：本项目要嵌 F6 网页、要用扫码定位推送相机等一批系统能力、两端要保持一致品牌体验 → **一致性和系统能力两列同时重要，而路线 ④ 在这两列都不受第三方约束。**

### 9 · 分隔 02 — 0:10
三个框架的定位。

### 10 · 三者各走哪条路线 — 1:10
- **Flutter** — Dart 编译成机器码，无 JS 解释器，引擎自绘
- **uni-app** — Vue 代码，App 端跑在 WebView 里
- **uni-app x** — UTS 编译成 Kotlin / Swift，界面用系统控件；柱子第三层标着 **DCloud Runtime（闭源）**

页脚：**uni-app x 与 uni-app 是两套独立技术栈，不是版本升级关系**。佐证——uni-app x 不支持传统 uni-app 的原生插件，旧插件已停止新增上架，自家体系内迁移插件也要重写。

### 11 · 三个框架各自为谁设计 — 1:20
四行表，重点是「最初要解决的问题」这行：Flutter = 一套代码做体验接近原生的独立 App；uni-app = 一套 Vue 同时发小程序 / H5 / App；uni-app x = 让 Vue 团队产出真正的原生 App。

落点在两张卡：**首版只发 iOS / Android，不发小程序也不要 H5，且目标之一就是关停现有六套小程序** → uni-app 系最值钱的多端复用能力在本项目没有买家，要承担它的架构代价却收不到最大那份好处。

> ⚠️ 屏幕上能力清单列了「蓝牙」，但 `Flutter-vs-UniApp.md` 的原生能力表没有这一项。

### 12 · 分隔 03 — 0:10 📍 ≈ 12:00
生态与落地规模。

### 13 · 开源到哪一层，社区多大 — 1:30
**上半（重点）**：Flutter 三层全开——业务框架层 / 渲染引擎 / CLI 与构建工具。uni-app x 业务框架层开源（Apache-2.0），**下两层闭源**——Runtime 与原生 SDK、HBuilderX 与打包服务。
含义：渲染层或运行时的 bug，Flutter 侧可读源码定位、必要时自改；uni-app x 侧只能提工单等厂商。

**下半（快过）**：提交数 91,171 / 11,216（8.1 倍），star 178,643 / 41,600（4.3 倍）。
两条口径要自己先说破：① star 反映全球开源关注度，**不等于国内商业落地量**，uni-app 在国内企业与政企项目落地量很大，数据体现不出来；② 但 Flutter 那 9 万次**含渲染引擎**，DCloud 那 1 万次是框架层的，Runtime 与 SDK 闭源无任何公开提交历史。

### 14 · 谁在主力 App 上用 Flutter — 1:30
证据分档：**甲 = 框架方官方收录，乙 = 使用方公开披露，丙 = 第三方扫包统计**。丙档只看趋势不下结论。

表中：字节 90+ 款、BMW、大众安徽、闲鱼、腾讯、美团商家端、京东、贝壳、携程。

落点在左下卡：**这些团队没有一个是把整个 App 用跨端框架重写的，全是原生工程为主体 + Flutter 承载业务页面 + 系统能力走原生** —— 和本项目规划完全一致，不是要自己趟的新形态。

右下丙档卡：新上架应用 Flutter 11.07% / RN 6.75%（2024 年 1–10 月，2022 年为 10.15% / 4.73%）。该口径扫不到 uni-app 系（主要落地在小程序和 H5，不经应用商店分发），不可比。

### 15 · 案例 A · BMW — 2:00
挑这类的原因：远程车控、实时车况回传、找车、充电桩地图全落到系统 API 和车联网长连接上，**是「原生能力密集」的极端形态**，还要在多品牌多市场维持同一套体验。

- 起点：iOS / Android 各一套 BMW Connected + MINI Connected，两端功能与设计逐渐分叉，2018 年大到必须收敛
- 选型时**为体验明确排除了基于浏览器的方案**
- 2019-10 慕尼黑定案 → 2020-07 My BMW App 上线，不到一年
- 覆盖 **47 个国家、五大洲**，双端合一，同时服务 BMW 与 MINI

**这页真正的落点是那个 96**：内部 Mobile 2.0 平台每天出多个构建，**每个构建自动生成、测试并部署 96 个变体**；到 2021-10 每个变体累计构建超 10,000 个版本 → 证明 Flutter 产物在 CI 里可批量、可自动化、可长期滚动，直接接第 20 页。

### 16 · 案例 B · 大众汽车（安徽）ID. UNYX — 1:30
购车定制 / 车联车控 / 社区 / 商城。

证据类型与 BMW 不同：**大众安徽官网《第三方个人信息共享清单》**列明 Flutter SDK、供应方 Google LLC，使用情形写作**「App 所有的 L1、L2、L3 页面开发语言」**（即全部主干界面）。合规披露是法定义务、内容须与实际一致，可信度高于任何技术文章转述。

同站另一份 SDK 说明另列有 React Native SDK → 混合形态，材料里主动注明了。这不削弱结论，反而印证第 14 页：**问题不是能不能只用一个框架写完，是主干页面交给谁。**

本章收口回答三个疑问：重原生能力是不是禁区（不是，车控密度更高）· 多变体长周期扛不扛得住（那个 96 是上限参考）· 是否必须整个重写（不是，两例都是混合底座）。

### 17 · 分隔 04 — 0:10 📍 ≈ 18:40
产品能力与工程链路。

### 18 · App 的形态不止「页面 + 接口」 — 1:20
迟早会碰到：桌面/锁屏小组件、系统语音助手、系统级进度通知、各类 App Extension（如门店当日待办、库存预警上桌面）。

表中两行：
- **改一次要重来多少** — Flutter 一次增量编译；uni-app x 按官方教程**每次修改这些文件后须重制自定义基座**
- **取资源 ID 的方式** — uni-app x 侧不能直接引用 `R` 类，须运行时按字符串查找，**编译期类型检查失效**

页脚原文：**两条路线都做得到，区别在做的方式**——Flutter 侧就是开 Xcode / Android Studio 写原生；uni-app x 侧同样写原生，还要额外走一遍 DCloud 的插件与打包规则。
来源等级：uni-app x 栏出自官方文档，仅安卓小组件那份清单取自 2026-05 社区实战教程（已标注）。

### 19 · 两项官方限制，同时满足不了 — 2:30
**全场最硬的单点。** 两条均出自 DCloud 官方文档：

- **情形 A** 要用插件市场加密付费插件 → 原文「uts 加密插件只支持云端传统打包，不支持离线打包，也不支持安心打包」→ **只能云端打包**
- **情形 B** 要做 Siri 快捷指令类扩展 → 官方路径是在**离线打包**的原生工程里实现 `AppShortcutsProvider`，再用 UTS 插件衔接 → **要求离线打包**

**两个要求互斥。** 同时需要时无解，只剩三个选择：放弃扩展能力 / 重新购买非加密授权（若厂商提供）/ 整体迁走。

下半澄清「离线打包 = 原生工程完全可控」这个误解：拿到的是 Android Studio 工程，但核心是 DCloud 已编译好的闭源 AAR（`lib.5plus.base-release.aar`、`uniapp-v8-release.aar`、`utsplugin-release.aar`），无源码。
**能改**：包名、版本号、图标、Gradle 依赖、权限清单，以及在壳外加自己的原生模块。**改不了**：页面怎么渲染、页面容器与生命周期、UTS 与原生的通信机制、运行时任何行为。
连壳本身也被规定死：**自定义 `Application` 必须继承 `DCloudApplication`**，默认 `MainActivity` 节点须移除 → 宿主工程入口不归你。**不是把 uni-app 集成进自己的 App，是在它的 App 里放自己的东西。**

右卡：Flutter 侧没有这个分支，只有一种构建方式，`ios/` `android/` 就是两个完整原生工程，加不加插件、上不上 Siri 都不影响出包方式。

> 若被问云端打包费用：每次 2 元、最高档几十元，相对项目总投入可忽略——**这页的问题不是钱，是构建方式被约束后的连锁限制。**

### 20 · 发版链路能不能全自动 — 1:10
已定链路：GitLab CI/CD（lint、格式化、测试卡点）· dev/uat/prod 三套环境 · iOS 由远程 Mac 出包 · 内测分发安卓走托管 OTA 页、iOS 走 TestFlight。核心诉求是**全自动、可追溯、可复现**——任一版本能从一次 git 提交自动构建，不依赖任何人本机环境。

关键第二行：uni-app x 的原生插件与 UTS 插件编译需经 HBuilderX，**图形化 IDE 无法在流水线中自动执行**——与全自动流水线是结构性错配。本项目原生插件是十几个，不是一两个。

页脚口径：**比的不是「能不能出包」（两者都能），是出包能否放进自动化流水线。** 对照第 15 页 BMW 的 96 变体 / 上万次构建。

### 21 · AI 编程工具 — 0:50
**两边都有官方 AI 工具**，uni-app x 有 `uni-agent`、`uni-app-x-mcp`。真实差别两条：

- **开放 vs 内置** — Flutter 的 skills 是独立开源仓库（`flutter/agent-plugins`、`dart-lang/skills`），一行命令装进任意 AI 编程工具，可 fork 可加自有 skill；uni-app x 的 AI 能力主要绑在官方助手和自家 IDE
- **公开语料** — Dart / Flutter 是近十年全球公开代码；UTS / UVue 是新语言，语料以中文官方文档为主，且**插件市场付费插件加密分发，不会进入任何公开语料**

### 22 · 分隔 05 — 0:10 📍 ≈ 24:40
结论。

### 23 · 首版投入构成 — 1:50
**先给结论：两条路线基本持平，±10% 以内。成本不是推荐 Flutter 的理由。**

| 构成 | 占比 | uni-app x |
| --- | --- | --- |
| 业务逻辑与外围系统集成、联调 | 45–55% | 无差异（与框架无关） |
| UI 实现 | 20–25% | **略省**（Vue 熟悉度） |
| 原生能力与桥接 | 10–15% | 明显更贵 |
| 工程、CI、发布、可观测 | 10–15% | 明显更贵 |

**它的效率优势作用在占比第二小的那块，额外成本作用在另外两块，一加一减基本持平。**
边界：占比区间基于本项目形态估算，不同团队有出入但量级关系稳定；不含后续运维迭代。

### 24 · uni-app x 强于 Flutter 的三项 — 1:30
**不要快讲。** 讲完对方优势是下一页结论可信的前提。

**① 鸿蒙** — uni-app x 官方直接支持，一等公民；Google 明确**不在 Flutter 主线支持鸿蒙**（issue #150536，Closed as not planned，不是「还没做」是「不打算做」）。
但：鸿蒙适配由 OpenHarmony-SIG 社区分支承接，**2026-01 成立 Flutter SIG 做治理**，按季度跟进主线，3.41 鸿蒙版已发布、**3.44 鸿蒙版预计 2026-09**，不是无人维护的野生 fork。而本项目基线正是 **3.44.9**，鸿蒙不在首版范围，停在 3.44.9 不追新本就是为接鸿蒙留窗口 → 本项目时间线内可控，**但若鸿蒙变硬需求，这项它确实更省事，应如实计入。**

**② 包体与内存更小** — DCloud 官方实测 8.5M vs 18M、103MB vs 138MB。**这两个数可信**——自绘引擎必须把渲染引擎打进包，是路线本身的代价。

**③ 热更新** — uni-app 系方案成熟，线上问题不等商店审核直接下发。

页脚原文：**这三项是真实的技术差异，是否构成决定性因素取决于产品对鸿蒙、包体和热更新的实际要求。**

时间够可补：鸿蒙首版不在范围、基线已留窗口 · 门店内部业务 App，企业分发/商店安装，**无包体 KPI**，35MB 内存差在现代机型无可感知影响 · 发版链路已定为 OTA 页 + TestFlight + App Store，**热更新这条优势在已定发版模式下用不上**，发版策略变了应重新计入。

### 25 · 推荐方案 — 1:20
标题原文：**技术栈采用 Flutter，原生工程为主体，业务页面由 Flutter 承载，系统能力走原生。**
—— 推荐的不是「整个 App 用 Flutter 重写」，是第 14 页那批团队验证了五六年的形态。

四行：**界面一致性**（自绘，不依赖系统控件与浏览器内核）· **系统能力**（原生工程完全开放，没有第二套规则要学）· **工程链路**（CLI 完整，可接 CI 无人值守，与已定 GitLab 流水线天然契合）· **先例充分**（BMW、大众安徽同类形态长期运行）。
基线 **Flutter 3.44.9**，首版 iOS + Android。

### 26 · 数据与事实来源 — 0:20
完整清单在书面材料附录 A，37 条。**除三处已就地标注的非官方来源外，其余全部来自厂商官方文档**，可自行复核。

### 27 · 收口 — 0:50
两句：**成本基本持平；真正差异在五年周期里能力天花板归谁**——Flutter 的天花板是自己的工程能力，uni-app x 的天花板是厂商的插件市场与打包体系。

若仍倾向 uni-app x，md 6.6 的六项前提（前四项任一落不实即应重新评估）：
1. **F6 书面同意**在其页面引入 `uni.webview.js`，并承诺配合联调排期
2. **神策提供**与我方后端版本匹配的 uni-app x SDK，明确后续支持与升级责任
3. **Bugly 的 UTS 封装完成并验证**，含 iOS 侧崩溃符号化
4. **DCloud 明确 CLI / CI 可行路径**；若无，须接受构建链路存在人工用 HBuilderX 出包的环节并据此调整发布流程
5. 确认云端 / 离线打包取舍（是否用加密付费插件、是否有需离线打包的扩展需求，互斥时以哪个为准），并知悉离线工程仍是围着闭源二进制的壳
6. 接受首版拿不到多端复用收益——那六个小程序正被这个项目关掉

---

## 超时取舍（30 → 20 分钟）

按序砍。**▲ 不可砍：3 / 4 / 7 / 15 / 16 / 19 / 23 / 24 / 25。**

| 砍 | 省 |
| --- | --- |
| 26 页附录 | 0:20 |
| 21 页 AI | 0:50 |
| 8 页并进 7 页 | 1:10 |
| 10 页并进 11 页 | 1:10 |
| 14 页只念字节 / BMW / 大众安徽 | 0:45 |
| 6 页只讲第 ④ 行 | 0:40 |
| 13 页只讲开源层次图 | 0:40 |
| 20 页并进 19 页尾 | 1:10 |

砍满 ≈ 6:45 → 23:45；再并 18 页进 19 页 → 22:25。

---

## 数字速查

| 数 | 含义 |
| --- | --- |
| 91,171 / 11,216 | 主仓库提交数，**8.1 倍**；前者含渲染引擎，后者仅框架层 |
| 178,643 / 41,600 | star，4.3 倍 |
| 31,002 / 3,709 | fork |
| 18M / 8.5M | 安装包（DCloud 官方实测） |
| 138MB / 103MB | 运行内存（同上） |
| 8.7MB / 8.1MB | uni-app x 离线或嵌入的包体增量，iOS / Android arm64-v8a |
| 47 / 96 / 10,000 | BMW：国家数 / 每构建变体数 / 每变体累计构建版本 |
| 90+ / 800+ | 字节：线上 Flutter 应用数 / Flutter 开发者数 |
| 11.07% / 6.75% | 2024 年 1–10 月新上架应用 Flutter / RN（2022 年 10.15% / 4.73%），**丙档** |
| 1,350 / 1,184 | Top 10,000 非游戏 iOS 应用中 RN / Flutter 检出数（2025-12），**存量口径，RN 早三年开源** |
| 853 / 3,413 / 300 | Kuikly 仓库提交 / star / fork，建于 2025-04-24 |
| 45–55 / 20–25 / 10–15 / 10–15 | 成本四块占比 |
| ±10% | 首版总投入差异 |
| 3.44.9 | Flutter 版本基线 |
| 2 元 | uni-app x 云打包单次计费，60MB 以下不额外收费 |

---

## 问答速查

**限制会不会随版本解决** — 小的会（CLI、SDK 覆盖）。三条不会：Runtime 与原生 SDK 闭源是商业模式；多端复用在本项目没有买家是项目形态；能力天花板取决于厂商生态是路线 ③ 的结构。

**UTS 编译成 Kotlin/Swift，不是比 Dart 更接近原生** — 承认，方向正确，比传统「字符串方法名 + 弱类型参数」的桥接干净得多。保留意见在外面那层工具链和打包体系，不在语言。

**自绘在低端安卓机卡不卡** — 表单/列表/报表为主的业务 App，两边都够用。**性能在材料里标为非决定项，不作论据。**

**不用系统控件会不会不像原生** — Flutter 有 Material 与 Cupertino 两套。更重要的是本项目要的是「整个 App 看起来是一个东西」，不是「在苹果上像苹果」。

**为什么不选 RN** — 与 uni-app x 同属路线 ③，路线分析同样适用；选它最大理由是复用已有 React 人力，本项目无此前提。用 RN 的多是 2015–2018 就大规模投入的存量团队。

**Kuikly 更新更好** — 三条，均非「它不好」：① 对外开源仅一年多，853 提交 / 3,413 star，体系外生产案例、第三方组件、招聘、AI 语料都没起来；② License 非标准开源，加了「未经腾讯书面同意不得为增加或启用动态代码下发能力制作衍生作品」；③ 面向 Kotlin/KMP 团队，与我方人力结构不匹配。

**Flutter 会不会被 Google 砍** — 风险存在，不说「绝对不会」。区别在退路：BSD-3-Clause，引擎到框架全开源，社区可 fork 接手；uni-app x 的 Runtime 与原生 SDK 闭源，**没有第二个可接手的主体**。

**uni-app 几百万开发者，生态怎么会小** — 先认：国内企业应用、政企落地量很大，star 数体现不出来，材料已主动写明口径。比的是两件不同的事：可见工程投入（含引擎 vs 仅框架层），以及同等形态的落地先例。

**招人：Vue 遍地、Dart 没人** — Dart 对有 Java/Kotlin/TS 背景的人一两周进入正常产出；项目最大一块成本（45–55%）与框架无关；真正稀缺的是写原生桥接的人，换 uni-app x 一件不少还要多学 UTS 和 DCloud 插件规则；字节一家 800+ Flutter 开发者。

**以后又要小程序怎么办** — 承认这是 uni-app 系客观长处。但本项目方向相反，目标之一是关停六套小程序；真到那天 H5 或小程序端可单独做，不必反过来约束主力 App 底座。

**DCloud 官网那页对比 Flutter** — 已逐条核验，结论在附录 C。安装包 18M/8.5M **属实**；内存 138/103MB **属实**；「dart 与原生 API 通信损耗非常明显」未附实测数据与测试条件，定性表述；「原生渲染与自渲染并存问题很多」未附数据，但混排确是业界已知难点，提醒成立；「dart 生态」与公开数据相反，**但「嵌套写法」这条是真实体验问题，不辩解**，不影响能力上限；热更新属实。

**通信损耗对我们有影响吗** — 扫码/拍照/上传是用户触发的低频调用，不在渲染热路径；接口由 Pigeon 从一份定义生成三端强类型代码。真正吃紧的是嵌 F6 那条链路，而那恰是 uni-app x 更弱处。

**BMW 那 96 跟我们什么关系** — 我们要的是 dev/uat/prod 三套环境 + 多渠道包 + 每次提交自动出包。96 证明的是产物可完全无人值守、长期规模化地跑。对照 uni-app x 的云端打包与「改一次原生文件重制基座」。

**BMW 是大公司，跟我们不一样** — 不是比资源。它在原生密度、可靠性、变体数、周期四个维度都比本项目极端，那种条件下成立则本项目风险可控。另一个信号：选型时明确排除了浏览器方案。

**怎么确认 ID. UNYX 是 Flutter** — 只指大众安徽官网《第三方个人信息共享清单》那条链接（`www.id.unyx.com/subp-YH20240626002`），使用情形写「App 所有的 L1、L2、L3 页面开发语言」。**依据是使用方的法定披露，不是任何其他来源。**

**清单里还有 RN，算不算 Flutter 案例** — 是混合形态，材料主动注明了。大型 App 几乎都是混合的；问题是主干页面交给谁，那份披露写的是「所有 L1、L2、L3 页面」。

**字节省 1/3，选 Flutter 是不是也省 1/3** — 不能这么推。**原话对照组是「原生双端开发」，不是 uni-app。** 成本结论仍是基本持平。引它只说明：有能力自研全套基建的团队，做过 90+ 个 App 后仍继续投入 Flutter。deck 上没放这个数。

**携程为什么用 RN** — 存量投入，2015–2018 已大规模投 RN。现在是原生 + RN + Flutter 混合，Flutter 用在火车票、酒店等十多个核心业务的列表页与主流程，他们自己文章标题就是「Native/RN 内嵌 Flutter UI 混合开发实践」。

**uni-app x 有没有大厂案例** — **未检索到**大厂主力 App 上的公开落地案例。DCloud 公布的是 uni-app 全系开发者与应用总量，统计主体是小程序和 H5，无法拆出「用 uni-app x 做的独立 App」，口径不可比。

**包体大 10MB、内存多 35MB 有影响吗** — 数字属实且认，是路线代价。门店员工内部业务 App，企业分发/商店安装，**无包体 KPI**；设备是门店配发的作业终端。且 uni-app x 走离线/嵌入同样有增量（iOS 8.7MB、Android arm64-v8a 8.1MB）。

**鸿蒙** — 三层，见第 24 页。

**没有热更新，线上出 bug 怎么办** — 先认这是它的真优势。三点补充：苹果对「绕过商店下发可执行逻辑」长期处于灰色地带，规模化使用有下架风险敞口；本项目发版链路已定为 OTA 页 + TestFlight + App Store；企业安全与合规评审通常也不倾向接受可绕开商店下发代码的能力。**准确说法是这条优势客观存在，但在已定发版模式下用不上。**

**F6 到底要不要改** — Flutter 侧通道由 App 在页面加载完成时自动注入，单一双向通道，**F6 零改动**。uni-app x 侧按官方 `web-view` 文档，网页向 App 发消息**需引入 `uni.webview.1.5.5.js`**，App 向网页走 `evalJS()`（执行 JS 字符串），是两条不对称的单向通道 → **需要 F6 这家第三方改他们的页面**，是排期风险。不要说它做不出 JSBridge——做得出，但要在两条单向通道上自己封装请求 ID、超时、就绪信号、错误处理、方法白名单。

**CI 和那台远程 Mac 靠谱吗** — 现阶段先手工跑仓库内脚本，后续注册成带 `macos` tag 的 GitLab Runner 变成流水线节点。核心诉求是任一版本能从一次 git 提交自动构建、不依赖任何人本机环境——这也正是判断 HBuilderX 依赖的标准。

**神策和 Bugly 接得上吗** — 神策：Flutter 侧有官方插件，在公开包管理平台、有认证发布者与版本号；uni-app x 侧**不在插件市场**（官方说明因缺 UTS 压缩混淆方案暂未提供市场包），需联系技术顾问索取 zip 源码包，另有后端版本下限。Bugly：只有原生 SDK，Flutter 侧自建原生桥（几十行 Kotlin/Swift），uni-app x 侧未见官方支持，需完全自行用 UTS 封装。落点：两边都有工作量，但一边可版本化追溯，另一边脱离公开分发渠道，升级与责任归属只能靠人对人沟通。

**扫码/车牌/VIN/蓝牙有现成的吗** — 十几项原生能力（扫码、VIN、车牌、相机、相册多选、带进度上传、图片压缩、拨号、定位、运行时权限、弱网离线暂存、崩溃桥、埋点 SDK、安卓返回键拦截、WebView 文件选择器、iOS 隐私清单）**两条路线都要自己实现并两端验证**。Flutter 侧两个具体优势：Pigeon 从一份定义生成三端强类型代码，改接口忘同步实现编译期就报错；扫码一份原生实现同时服务 App 内扫码页与嵌入网页的通道调用。车牌 OCR 拍照上传走云端、**客户端不直连由后端代理**，VIN 在端上解。**蓝牙不在材料的能力清单里，被追问具体用途不要现编。**

**弱网怎么办** — 地下车库、仓库、施工区网络差，而恰是这些场景要传大文件（检测报告、装车视频、鉴定证据）。硬要求：上传前压缩、断网本地暂存恢复后幂等重传、上传带进度。两条路线都要自己实现，区别只在实现方式。

**AI 工具对哪个更友好** — 见第 21 页。**不能说 uni-app x 没有 AI 工具。**

**成本差多少** — 见第 23 页。**不暗示 Flutter 更便宜**，说完持平就引到五年天花板。

**哪个更快出第一版** — 差不多。瓶颈在外围系统集成（F6、后台、神策、Bugly、云端 OCR）与十几项原生能力的实现与两端验证，都与框架无关（原生那块 uni-app x 还更贵）。真要说风险，uni-app x 那条路上有一个我方控制不了的排期项：需 F6 配合改造页面。

**你们会 Flutter 吗** — 答能力与学习曲线，**不举己方具体项目名**。

**做到一半能不能换** — 退出成本不对称。Flutter 侧原生工程、原生能力、F6 通道都是标准原生实现，换掉的只是业务页面层，原生资产留得下。uni-app x 侧宿主入口归 DCloud（`Application` 须继承 `DCloudApplication`）、运行时闭源、插件是 UTS 写的，要换就是整体迁移、原生插件全部重写；且 uni-app x 不支持传统 uni-app 原生插件，自家体系内迁移也要重写。

**五年后谁维护** — 技术栈层：Flutter BSD 开源可自行 fork，uni-app x 无第二个可接手主体。工程层：Melos monorepo 21 个包，依赖规则由 Dart 包机制**在编译期物理强制**，业务模块 A 根本 import 不到 B 的符号，不靠规范约束——19 个业务模块多人长期并行，模块边界是最容易烂的地方。人力层：可招聘面与 AI 辅助成熟度。

**是不是被 Google 绑死** — 对 Flutter 诚实：确实依赖其路线决策，鸿蒙就是具体例子。但依赖性质不同：Flutter 代码在手、社区可接手；uni-app x 是三重绑定——Runtime 闭源不可改、插件工具链绑 HBuilderX、云打包在厂商服务器。另有商务侧：付费插件授权绑定唯一 appid 和包名，换其一需重新购买。

**开源协议有无法律风险** — BSD-3-Clause / Apache-2.0 均为宽松协议，不要求开源自身代码，商业使用无附加义务。对比：Kuikly 的 License 非标准开源，附加条款在合规评审时要单走流程。

**代码要上传第三方云编译吗** — Flutter 不需要，`flutter build` 命令行完整，构建全在自有构建机、产物可完整留档。uni-app x 的**云端打包由 DCloud 服务完成**，且加密付费插件只支持云端打包。对有正式安全评审流程的企业是需要走流程回答的问题。（陈述事实，不引申成「有安全风险」。）

**我们需要做什么** — 定 Flutter 则基线 3.44.9、首版双端，架构决策已就绪可直接排期；倾向 uni-app x 则先落实第 27 页那六项前提。

**你们是不是就想用自己熟的** — 熟悉度确实是因素，不回避。但材料写法是为了可被独立验证：每条负面判断都给了 DCloud 官方文档链接，事实与推论分行写。两点佐证非单边论证：主动列出 uni-app x 更优三项（第 24 页）；把 DCloud 官网对比页逐条核验、属实的直接认下。且成本结论给的是「基本持平」不是「Flutter 更省钱」。

---

## 三条不进书面材料

只在被追问时口头用，进任何书面材料都会失去溯源。

1. **DCloud 问答区开发者原话**（「坑无敌多 / 暂时放弃 uvue 转 nvue」）—— 单条匿名发言，被追问「谁、什么项目、什么版本」答不上，会连累全文溯源可信度。
2. **插件数量对比**（DCloud 近千款 / 插件市场约 290 / pub.dev 76,378）—— 三个口径互不可比，会被当场拆掉。用提交数和开源层次说，不用插件数说。
3. **字节「省 1/3 工时」** —— 对照组是原生双端，不能用于成本论证；只能作社会证明。