先聊聊选型这件事。移动端跨平台开发走到今天，Flutter 和 uni-app 几乎是开发者绕不开的两个高频选项。不少刚入行的前端或客户端同学，一搜“跨平台方案”就会被这两个名字刷屏，但看了一圈资料，反而更纠结：一个要学 Dart，一个说会 Vue 就能上手；一个号称性能接近原生，一个到处强调一套代码多端发布。到底该学哪个？项目选型到底怎么定？

这篇文章不打算站队，而是把两者从头到尾拆开对比。我会先讲清楚它们各自的底层逻辑，再给出可复现的工程示例，最后结合团队情况聊选型建议。无论你是打算做第一个跨端项目，还是正在为公司技术选型做调研，这篇文章都值得读完。

1. 背景与核心概念

1.1 Flutter 是什么

Flutter 是 Google 开源的一款 UI 工具包，严格来说它不只是跨平台框架，而是一整套渲染体系。开发者使用 Dart 语言编写代码，Flutter 通过自带的 Skia 图形引擎直接绘制每一个像素，不依赖系统原生控件。也就是说，你在 iOS 和 Android 上看到的按钮、列表、动画，都是 Flutter 自己画出来的。

这种设计的最大好处是，UI 在不同平台上的表现高度一致，很难出现“iOS 正常、Android 错位”的兼容性问题。同时因为渲染链路绕过了原生控件，动画和页面切换的流畅度可以做到很高。

1.2 uni-app 是什么

uni-app 是由 DCloud 团队推出的一套跨端开发框架，核心定位是“一套代码，多端运行”。它的语法基础是 Vue.js，开发者用 Vue 的单文件组件写法开发页面，然后通过 uni-app 提供的编译工具，把同一套代码编译成微信小程序、App、H5、百度小程序等不同目标。

注意这里的“编译”和 Flutter 的“绘制”方向完全不同。uni-app 在 App 端可以选择 WebView 渲染，也可以选择使用原生控件渲染（uni-app 的 App 端有 nvue 方案）。但整体而言，它不是自己造一套渲染引擎，而是通过适配层把 Vue 的组件映射到目标端的能力上。

1.3 它们解决的是同一个问题吗

从外观看，两者都在解决“多端复用”问题，但侧重点不一样：

• Flutter 的重点是「自绘渲染 + 高性能」，它希望你用同一种方式构建所有平台的 UI，并且性能尽量接近原生。
• uni-app 的重点是「生态复用 + 低成本上手」，它希望你用前端最熟悉的 Vue 语法，快速发布到多个平台，尤其是微信小程序。

所以，选择哪个方案，本质上不是比谁更“高级”，而是看你的主要目标平台、团队技术背景、性能要求分别是什么。

2. 技术架构对比

这一节需要从底层理解两者的差异。很多同学只停留在“Flutter 性能好，uni-app 上手快”的结论上，这不够。真正影响项目走向的是它们的架构设计。

2.1 渲染引擎：自绘与宿主控件

Flutter 的渲染路径是：

Dart UI 描述（Widget）→ Flutter Engine → Skia/Impeller 渲染 → 屏幕像素

这个链路里没有系统原生控件的参与。Flutter Widget 只是数据结构，最终由 Engine 合成并上屏。这样带来的优势是：

1. UI 一致性极强，同一个 Widget 在不同设备上长得几乎一样。
2. 动画性能稳定，不像原生控件那样容易受系统版本影响。

uni-app 的分端渲染路径是：

Vue 组件 → uni-app 编译器 → 小程序模板 / HTML / 原生控件映射

在小程序端，uni-app 会把 Vue 模板转换成小程序自身的 WXML/WXSS；在 App 端，默认情况是 WebView 渲染，也可以写 nvue 页面走原生渲染（基于 Weex 演进）。但不管是哪种，UI 控件本质上来自宿主环境。

对比结果很明显：Flutter 是“自己画”，uni-app 是“借别人的控件来拼”。这决定了 Flutter 在复杂动画、高频刷新场景下表现更好，也决定了 uni-app 在不同端上会存在样式细节差异。

2.2 语言：Dart 与 JavaScript/Vue

Flutter 使用 Dart。Dart 是 Google 维护的面向对象语言，语法融合了 Java 和 JavaScript 的特点，支持 JIT 和 AOT 编译。开发阶段用 JIT 实现热重载，发布前用 AOT 编译成高效机器码。

uni-app 的核心语言是 JavaScript。它依赖 Vue 2 / Vue 3 的语法，你写的依然是 template + script + style 三段式单文件组件。对于前端团队来说，这个学习成本很低，基本上“会 Vue 就会 uni-app”。

但低学习成本也有一些隐性代价：

• JavaScript 是动态语言，大型项目中的类型约束需要靠 TypeScript 或 JSDoc 补充。
• Vue 的抽象会带来一层模板解析和运行时适配的损耗，性能上限不如 Dart AOT 编译后的代码。

2.3 编译与运行机制

Flutter 编译产物分平台：

• Android 可编译成机器码（AOT），也可在开发时用 JIT
• iOS 使用 AOT 编译
• Web 使用 CanvasKit 或 DOM 渲染方案
• 桌面端走各平台的窗口嵌入

uni-app 更像一个“转译器”：

• 开发时通过 webpack/vite 构建
• 发布到小程序时生成对应平台的原生代码包
• 发布到 H5 时生成普通 Web 应用
• App 端默认生成基于 WebView 的混合应用，或生成 nvue 页面

所以 uni-app 的运行性能极大依赖宿主环境，尤其是小程序的性能和微信运行时的 JavaScript 引擎绑在一起。

2.4 UI 组件与样式体系

Flutter 里一切皆 Widget。没有 CSS 的全局选择器、层叠规则，而是通过 Widget 嵌套来构建界面。所有样式数据都写在 Dart 代码中，或者用主题（Theme）统一管理。

// Flutter 中按钮和文字的写法 ElevatedButton( onPressed: () {}, style: ElevatedButton.styleFrom( backgroundColor: Colors.blue, foregroundColor: Colors.white, ), child: const Text('确认'), )

uni-app 基本沿用 CSS 体系和轻量级组件：

<template> <button class="confirm-btn" @click="onConfirm">确认</button> </template> <style scoped> .confirm-btn { background-color: #2196F3; color: #fff; border-radius: 8rpx; } </style>

这里能看出，uni-app 的样式写法更接近传统 Web，而 Flutter 的样式完全符合“状态驱动 UI”的理念。这两者没有绝对的谁好谁坏，关键看你的团队习惯哪种思维方式。

3. 环境准备与项目创建

不管选哪个，先要把工具链跑通。下面分别介绍两种方案的开发环境，然后演示如何创建项目。

3.1 Flutter 开发环境准备

Flutter 官方支持 Windows、macOS、Linux 上的开发环境搭建。以常见的 Android + iOS 场景为例，你需要安装：

1. Flutter SDK
2. Android Studio（至少安装 Android SDK、命令行工具）
3. 如果要构建 iOS，需要 macOS + Xcode
4. 可选安装 Visual Studio Code + Flutter 插件

安装后，运行诊断命令验证环境：

flutter doctor

正常情况下会看到类似输出：

Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, 3.x.x, on macOS ...) [✓] Android toolchain - develop for Android devices (Android SDK version ...) [✓] Xcode - develop for iOS and macOS (Xcode ...) [✓] Chrome - develop for the web [✓] Android Studio [✓] VS Code

如果某一项打叉，按照提示安装缺失的组件就行。我遇到过最常见的问题是 Android SDK 路径没配置好，需要在flutter doctor -v里查看具体路径，然后在 IDE 的 SDK Manager 中补装。

创建 Flutter 项目：

flutter create my_demo_app

项目结构大致如下：

my_demo_app/ ├── android/ ├── ios/ ├── lib/ │ └── main.dart ├── test/ ├── pubspec.yaml └── ...

需要说明的是，Flutter 项目本身的跨端代码主要集中在lib/目录，android、ios等目录是平台工程。日常开发通常不需要频繁修改这些目录。

3.2 uni-app 开发环境准备

uni-app 最常用的开发工具是 HBuilderX，同样可以使用 Vue CLI 或 Vite 手动创建项目。如果你已经习惯了 VS Code，我更推荐使用 CLI 方式，这样可以统一前端工具链。

先安装 Vue CLI（如果是用 Vue CLI 版 uni-app）：

npm install -g @vue/cli

创建 uni-app 项目：

vue create -p dcloudio/uni-preset-vue my-uni-app

如果网络受限，也可以直接从 HBuilderX 可视化创建，内置了多个模板，但 HBuilderX 有自己的插件体系，部分开源插件在 VS Code 中不通用。

创建完成后项目结构类似：

my-uni-app/ ├── src/ │ ├── pages/ │ │ └── index/ │ │ ├── index.vue │ │ └── index.scss │ ├── static/ │ ├── App.vue │ ├── main.js │ ├── manifest.json │ └── pages.json ├── package.json └── vite.config.js

这里面的pages.json是 uni-app 的路由和页面配置，和微信小程序的app.json有点类似。大部分页面级配置都在这个文件中完成。

3.3 运行项目的差异

Flutter 运行起来是直接起一个原生应用进程：

cd my_demo_app flutter run

运行时会自动连接设备或模拟器，使用R键热重载，使用Shift+R热重启。

uni-app 开发时通常需要选择目标平台：

npm run dev:mp-weixin # 微信小程序 npm run dev:h5 # H5 npm run dev:app # App 平台

这里的差别很明显：Flutter 的“一次开发”主要面向 iOS/Android/Web/桌面，而 uni-app 的“一次开发”面向小程序生态更灵活。

4. 核心开发体验对比

4.1 页面编写方式

先看 Flutter 的页面示例。

// 文件路径：lib/main.dart import 'package:flutter/material.dart'; void main() { runApp(const MyApp()); } class MyApp extends StatelessWidget { const MyApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( title: 'Flutter Demo', theme: ThemeData( colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue), ), home: const HomePage(), ); } } class HomePage extends StatelessWidget { const HomePage({super.key}); @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: const Text('Flutter 页面')), body: Center( child: Column( mainAxisAlignment: MainAxisAlignment.center, children: const [ Text('你好，Flutter'), SizedBox(height: 8), Text('这是 Dart 构建的 UI'), ], ), ), ); } }

Flutter 的写法有一个特点：UI 结构、样式、状态处理都在 Dart 代码中。刚开始可能不习惯，但熟悉后会发现组合性很强，非常方便抽组件。

再看 uni-app 的页面示例：

<!-- 文件路径：src/pages/index/index.vue --> <template> <view class="container"> <text class="title">你好，uni-app</text> <text class="desc">这是 Vue 构建的 UI</text> </view> </template> <script> export default { data() { return {} }, onLoad() { console.log('页面加载') } } </script> <style lang="scss"> .container { padding: 32rpx; text-align: center; } .title { font-size: 40rpx; font-weight: bold; } .desc { margin-top: 8px; font-size: 28rpx; color: #666; } </style>

uni-app 的页面写法对前端开发者非常友好，几乎就是 Vue 单文件组件。模板、脚本、样式三者分离，编辑器也有完整的智能提示。

4.2 状态管理

Flutter 官方推荐的状态管理方式经历了从 StatefulWidget 到 Provider、Riverpod、Bloc 的演变。目前社区最流行的是 Riverpod 和 Bloc。最基础的 setState 仍然有效：

class CounterPage extends StatefulWidget { @override State<CounterPage> createState() => _CounterPageState(); } class _CounterPageState extends State<CounterPage> { int _count = 0; void _increment() { setState(() { _count++; }); } @override Widget build(BuildContext context) { return Scaffold( body: Center( child: Text('当前数值：$_count'), ), floatingActionButton: FloatingActionButton( onPressed: _increment, child: const Icon(Icons.add), ), ); } }

uni-app 因为基于 Vue，所以天然支持 Vuex 和 Pinia。在 Vue 3 项目中更推荐 Pinia：

// 文件路径：src/stores/counter.js import { defineStore } from 'pinia' export const useCounterStore = defineStore('counter', { state: () => ({ count: 0 }), actions: { increment() { this.count++ } } })

页面中直接使用：

<script setup> import { useCounterStore } from '@/stores/counter' const counter = useCounterStore() </script> <template> <view> <text>{{ counter.count }}</text> <button @click="counter.increment">加一</button> </view> </template>

如果你熟悉 Vue 全家桶，Pinia 的迁移成本很低。而 Flutter 的状态管理更强调不可变状态和依赖注入，学习曲线要陡一些。

4.3 路由与页面跳转

Flutter 有两种主流路由方式：

1. 命名路由：提前注册路由表
2. 声明式路由：直接使用Navigator.push

Navigator.push( context, MaterialPageRoute(builder: (context) => const DetailPage()), );

uni-app 的路由则保留了小程序风格：

uni.navigateTo({ url: '/pages/detail/detail?id=1' })

可以看到，uni-app 的路由写法更“配置化”，而 Flutter 的路由是纯代码的方式。如果是从小程序转过来的开发者，uni-app 明显更顺。

4.4 原生能力与插件生态

Flutter 的官方插件生态集中在 pub.dev，常用能力大多有官方或社区支持。比如摄像头、相册、定位、文件分享等。

使用插件：

flutter pub add camera flutter pub add geolocator

uni-app 的插件市场是 DCloud 插件市场，同时兼容部分微信小程序插件。在 App 端，很多原生功能需要通过 uni-app 的原生插件机制或离线打包来集成。

如果你需要一个“扫码”功能，在 uni-app 中可以这样用：

uni.scanCode({ success: (res) => { console.log('扫码结果：', res.result) } })

这类 API 在 uni-app 中内置了很多，覆盖了常用业务场景，这比 Flutter 还需要找插件、配置权限更省事。

5. 完整实战：同一个计数页面，两种实现

光聊理论没有体感，下面用同一个非常简单但完整的例子——计数器页面，分别在 Flutter 和 uni-app 中实现，并说明运行结果。

5.1 Flutter 计数页面

在lib/main.dart中写入以下代码：

// 文件路径：lib/main.dart import 'package:flutter/material.dart'; void main() { runApp(const CounterApp()); } class CounterApp extends StatelessWidget { const CounterApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( title: '计数器示例', theme: ThemeData( useMaterial3: true, primarySwatch: Colors.blue, ), home: const CounterPage(), ); } } class CounterPage extends StatefulWidget { const CounterPage({super.key}); @override State<CounterPage> createState() => _CounterPageState(); } class _CounterPageState extends State<CounterPage> { int _count = 0; void _increment() { setState(() { _count++; }); } void _reset() { setState(() { _count = 0; }); } @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: const Text('Flutter 计数器'), ), body: Center( child: Column( mainAxisAlignment: MainAxisAlignment.center, children: [ Text( '$_count', style: const TextStyle( fontSize: 72, fontWeight: FontWeight.bold, ), ), const SizedBox(height: 16), Text( '已点击 $_count 次', style: const TextStyle(fontSize: 20), ), const SizedBox(height: 24), Row( mainAxisAlignment: MainAxisAlignment.center, children: [ ElevatedButton( onPressed: _increment, child: const Text('加一'), ), const SizedBox(width: 12), OutlinedButton( onPressed: _reset, child: const Text('重置'), ), ], ), ], ), ), ); } }

运行：

flutter run

你会在模拟器或真机上看到一个带 AppBar 的页面，点击“加一”按钮，中间的数值递增；点击“重置”，数值归零。整个过程非常流畅，动画也由 Flutter 自己完成。

5.2 uni-app 计数页面

在src/pages/index/index.vue中实现同样功能：

<!-- 文件路径：src/pages/index/index.vue --> <template> <view class="container"> <text class="count">{{ count }}</text> <text class="tips">已点击 {{ count }} 次</text> <view class="btn-group"> <button class="btn-primary" @click="increment">加一</button> <button class="btn-reset" @click="reset">重置</button> </view> </view> </template> <script setup> import { ref } from 'vue' const count = ref(0) function increment() { count.value++ } function reset() { count.value = 0 } </script> <style scoped> .container { padding-top: 200rpx; display: flex; flex-direction: column; align-items: center; } .count { font-size: 120rpx; font-weight: bold; } .tips { margin-top: 24rpx; font-size: 28rpx; color: #666; } .btn-group { margin-top: 48rpx; display: flex; gap: 24rpx; } .btn-primary { background-color: #2196F3; color: #fff; } .btn-reset { background-color: #eee; color: #333; } </style>

在 HBuilderX 中运行到微信开发者工具：

运行 -> 运行到小程序模拟器 -> 微信开发者工具

或者用命令：

npm run dev:mp-weixin

然后打开微信开发者工具，导入项目生成的dist/dev/mp-weixin目录。页面同样展示计数和两个按钮。区别在于，这里的按钮、文本、布局最终被编译成了微信小程序的 WXML 组件，样式由小程序平台接管。

5.3 对比结论

从这个小例子能直观看出：

• Flutter 的代码更“程序化”，一个页面就是一个 Widget 树。
• uni-app 的代码更“模板化”，内容和样式分离。
• 两者都能快速完成简单页面，真正的差距在复杂动画、深度性能调优以及多端细粒度适配时才会放大。

6. 性能与包体积

6.1 运行时性能

在移动端，性能的关键指标包括：

• UI 渲染流畅度
• 启动速度
• 首帧时间
• 内存占用

Flutter 因为绕过原生控件，渲染链路短，且 Dart AOT 编译后直接执行机器码，所以在高频刷新场景下表现稳定。尤其是列表滚动、动画切换、复杂页面布局，Flutter 的帧率一致性通常优于 WebView 方案。

uni-app 的 App 端如果使用 Vue 页面（WebView 渲染），性能上限受 WebView 影响。简单页面刷起来问题不大，但长列表、复杂数据更新、大量动画时容易卡顿。如果使用 nvue 原生渲染，性能有提升，但 nvue 的组件覆盖和样式支持有限制，很多 Web 端 CSS 效果在 nvue 中不支持，需要为原生端单独写兼容。

从工程角度看，Flutter 的性能表现更可预测，因为它不依赖宿主端对 Web 技术的实现；uni-app 的性能调试链路更复杂，问题可能出在 Vue 运行时、WebView、小程序基础库等不同层面。

6.2 包体积

Flutter 生成的 Android APK 体积通常比 uni-app 的 WebView 方案更大，因为 Flutter 需要把引擎和框架代码打进去。官方默认的空项目 APK 体积在 8MB 到 12MB 左右，具体版本和二进制目标不同会有差异。你可以通过flutter build apk --split-per-abi生成按 CPU 架构拆分的包，以减少单一 APK 体积。

uni-app 的 App 安装包，如果只打包一个较空的 WebView 应用，体积相对小；但要是集成了大量原生插件和资源，体积也会上涨。在小程序端，uni-app 有包大小限制，需要借助分包加载。

这里没有绝对的“谁更小”，只能根据业务目标平台和资源要求来优化。对于小团队来说，uni-app 的包体积管理门槛可能更低，因为不像 Flutter 那样需要理解 Android 的 ABI 拆分和 iOS 的符号裁剪。

6.3 内存表现

Flutter 自绘引擎的内存管理是 Dart 的 GC 机制，配合系统内存压力调整，整体可控。但如果你在 Widget 中持有大量图片、动画控制器，也需要关注资源释放问题。

uni-app 的 WebView 方案每个页面都可能单独持有 WebView 实例，多个页面叠加时内存占用偏高，尤其在不同安卓设备的 WebView 实现不一致时，会偶发白屏或崩溃。

因此，如果你的业务是纯展示型、工具型，两者差距没那么大；如果是信息流、直播、地图、音视频编辑器这类强交互应用，Flutter 的综合性能优势会更明显。

7. 发布与多端支持范围

7.1 支持的平台对比

Flutter 官方支持：

• Android
• iOS
• Web
• Windows
• macOS
• Linux

不过要注意，Flutter 对 Windows、macOS、Linux 的支持更偏向桌面应用，部分插件只支持移动端。发布到 Web 端时，CanvasKit 渲染模式较重，在低端设备上加载可能偏慢。

uni-app 官方支持的端包括：

• 微信小程序
• 支付宝小程序
• 百度小程序
• 字节跳动小程序
• QQ 小程序
• 快手小程序
• H5
• iOS App
• Android App

uni-app 在小程序端的覆盖确实广，这也是它的一大优势。如果你的业务目标就是“全小程序铺开”，uni-app 的编译体系能节省大量重复工作。

7.2 发布流程

Flutter 发布 iOS/Android 应用时，主要依赖原生工具链：

• Android 用 Gradle 构建签名 APK/AAB
• iOS 用 Xcode 构建并上传 App Store Connect

命令示例：

flutter build apk --release flutter build ios --release

uni-app 发布 App 时，可以选择云打包或本地离线打包。云打包是把项目上传到 DCloud 的打包服务，生成原生安装包；本地打包则需要下载对应的 Android/iOS 工程，配置原生环境，再把 uni-app 的产物集成进去。对于没有原生开发经验的小团队，云打包确实方便，但也要注意云打包服务的排队和额度限制。

发布小程序时，uni-app 的做法是先在命令行生成小程序产物，再用微信开发者工具上传。这意味着你把“多端发布”的复杂度转成了“构建脚本 + 各平台工具上传”的流程。

7.3 生态与社区

• Flutter 的社区主要在 pub.dev、GitHub、Stack Overflow，Google 官方维护力度大，第三方库更新快，问题有长期积累。
• uni-app 的社区主要围绕 DCloud 插件市场、官方问答区，中文资料多，形成了一套国内小程序开发者的使用习惯。

如果你的产品面向国内，团队也用 Vue，那 uni-app 的社区资源更有针对性；如果团队主要面向海外 App 市场，或者对 GitHub 生态依赖大，Flutter 更合适。

8. 选型建议：什么项目该用 Flutter，什么项目该用 uni-app

很多同学问“到底选哪个”，实际上应该拆成几个问题来看。

8.1 优先选择 Flutter 的情况

• 核心产品是独立的移动 App，对 UI 一致性、流畅度要求高，比如社交 App、内容消费 App、工具类 App。
• 团队不排斥学习 Dart，愿意接受 Widget 编程模型。
• 需要同时在移动端之外支持 Web / 桌面端，并且希望用一套 UI 逻辑覆盖。
• 项目风格偏“重客户端”，比如复杂的动画、自定义视频播放器、画板、音视频编辑等。

8.2 优先选择 uni-app 的情况

• 业务主要以微信小程序为主，同时需要 H5 和 App 覆盖。
• 团队是前端背景，已经熟练使用 Vue，不想引入新的语言体系。
• 产品是业务型、界面相对常规，比如商城、管理后台、社区内容、企业展示。
• 开发周期紧，需要快速上线多端，尤其要覆盖大量小程序平台。

8.3 团队成本与长期维护

选型还要考虑维护成本。Flutter 过了初学阶段后，Dart 代码并不难，但组件化思维、状态管理、原生插件编译这些门槛需要时间消化。如果团队是纯前端，刚上 Flutter 的头两到三个迭代可能会比较难受。

uni-app 的优势是“拿起来就能用”，但项目变大后，由于目标端太多，一些条件编译和平台兼容逻辑会分散在各处，维护时容易“改一处，坏三端”。这需要团队建立自己的平台适配约定，比如统一用条件编译注释管理差异代码。

// #ifdef H5 console.log('只在 H5 生效') // #endif // #ifdef MP-WEIXIN console.log('只在微信小程序生效') // #endif

如果你确定后续很长一段时间只做两三个平台，那么集中精力维护一套 Flutter 代码更省心；如果要上大量小程序平台，uni-app 的编译体系效率更高。

9. 常见问题与排查思路

9.1 Flutter 常见问题

9.2 uni-app 常见问题

9.3 通用排查步骤

无论是哪套框架，遇到编译或运行时问题，先按这个顺序排查：

1. 看控制台完整报错，不要只看第一行。
2. 确认当前工具链版本，比如 Flutter SDK、Node.js、Vue CLI 是否匹配。
3. 最小化复现：删除业务代码，只保留框架自建页面，看问题是否消失。
4. 搜索官方 issue 和社区帖子，优先看最近一年内的内容。
5. 检查插件版本锁定，避免升级后出现 breaking change。

这套流程在实际项目中帮我解决过很多“莫名奇妙的 bug”，比直接搜错误码更可靠。

10. 最佳实践与工程建议

10.1 Flutter 工程建议

代码组织上，不要把所有页面写进一个main.dart。推荐按 feature 分层：

lib/ ├── core/ │ ├── theme/ │ ├── network/ │ └── utils/ ├── features/ │ ├── auth/ │ ├── home/ │ └── profile/ └── shared/ └── widgets/

这样做的目的是隔离业务边界，后期扩展或重构更安全。

状态管理不要一上来就选最复杂的方案。一个小工具类应用用setState完全没问题；中型项目用 Riverpod 或 Provider；大型多模块项目再考虑 Bloc。过度设计往往是团队新手犯的最大问题。

性能优化上，优先注意：

• 避免在build中执行耗时操作。
• 大图用cacheWidth/cacheHeight或图片库做缩放。
• 列表用ListView.builder做懒加载，不要一次性加载所有 Widget。
• 动画使用AnimatedBuilder时把重建范围控制在最小子树。

10.2 uni-app 工程建议

在 pages.json 中维护好页面路由，并使用分包结构：

{ "pages": [ { "path": "pages/home/index" } ], "subPackages": [ { "root": "pagesA", "pages": [ { "path": "list/index" } ] } ] }

这样设计的好处是让小程序的包体更紧凑，也能缓解微信平台对包大小的限制。

开发中尽量使用 API 封装。因为 uni-app 需要运行在不同端，各端的网络、存储、登录逻辑有细微区别。建议在utils/request.js中统一封装请求方法，避免每个页面直接调用uni.request，方便后续统一处理 token、错误码和重复请求。

// 文件路径：src/utils/request.js export function request(options) { return new Promise((resolve, reject) => { uni.request({ url: options.url, method: options.method || 'GET', data: options.data || {}, header: { 'Authorization': uni.getStorageSync('token'), ...options.header }, success: (res) => { if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data) } else { reject(res) } }, fail: (err) => reject(err) }) }) }

10.3 跨端代码管理规范

如果你使用 uni-app，条件编译是必然要掌握的技能。但条件编译如果乱用，代码可读性会急剧下降。建议：

• 把平台差异化逻辑集中在独立模块中，不在页面里到处写条件编译。
• 用环境变量声明平台标识，方便构建脚本注入。
• 每周做一次全平台回归，避免某次改动只测了微信端。

用 Flutter 时，如果也有 Web 端需求，要留意网络库和文件读取的差异，比如dart:io在 Web 端不可用，需改用HttpClient的跨端实现或dart:html的兼容层。

10.4 安全与权限

移动应用开发还要注意权限的最小化申请：

• Flutter 使用 permission_handler 插件时，只申请当前业务真正需要的权限。
• uni-app 在 manifest.json 中配置权限说明，不要为了省事把权限列表全部勾上。
• 涉及用户隐私数据时，无论如何都要先做合规授权，比如用户协议、隐私政策弹窗。

这一点容易被小团队忽略，但应用上架审核时经常被驳回。

11. 总结与下一步学习路线

这篇对比其实回答了三层问题：

第一个层面是原理。Flutter 使用自绘引擎，Dart 语言，性能上限高；uni-app 基于 Vue 生态，编译到多端，重点是方便快捷。第二个层面是工程体验。Flutter 适合对性能、UI 一致性要求高的应用，uni-app 适合小程序优先、快速铺量的业务。第三个层面是团队选型。没有标准答案，只有“当前项目最适合的方案”。

如果你决定深入 Flutter，下一步可以重点学习 Widget 布局原理、状态管理方案、原生插件编写，以及动画体系。如果决定走 uni-app，则优先把 Vue 3 语法、小程序的运行机制、平台差异处理练熟，再去研究原生插件和离线打包流程。

最后想说的是，选型只是开始，真正的考验是坚持把项目做完。多写代码，多跑真机，多处理兼容问题，经验会告诉你哪个方案更适合你的业务。希望这篇文章能帮你少走一点弯路，也欢迎留言聊聊你项目里的跨端经历。