Flutter从入门到实战-03-综合案例实战

Flutter 从入门到实战（三）：综合案例实战与多端适配

完整业务应用从 0 到 1 跑起来：路由、首页模块化、接口封装、登录态、上拉下拉、状态共享，以及 Android/iOS/HarmonyOS 适配。

一、先看项目目标：做一个可运行的商城 Demo

综合案例的核心页面：

1. 首页
2. 分类
3. 购物车
4. 我的
5. 登录页

课程建议先完成 Web 端，再逐步扩到 Android、iOS、鸿蒙。这个顺序非常实用，因为它把"业务问题"和"平台问题"分层处理了。

二、项目初始化与目录规划

1. 创建项目（先 Web）

flutter create --platforms web hm_shop
cd hm_shop
git init

2. 建立基础目录

建议按功能拆分：

1. api/：接口层
2. models/：数据模型
3. views/：页面
4. components/：通用组件
5. utils/：工具层（请求、token、toast 等）
6. routes/：路由配置

这一层结构在后续多端适配时会明显降低改造成本。

三、先把"应用骨架"跑起来

1. 基础路由

在 main.dart 配置首页与登录页路由，先保证可跳转。

2. 底部 Tab 主框架

讲义的主推荐方案：

1. BottomNavigationBar 负责切换
2. IndexedStack 保持各 Tab 状态
3. SafeArea 处理安全区域

这套组合很适合"首页/分类/购物车/我的"这类稳定主框架。

四、首页模块化：用组件拼业务，而不是把代码写成一坨

首页最终由多个模块组成：

1. 轮播图（HmSlider）
2. 分类入口（HmCategory）
3. 特惠推荐（HmSuggestion）
4. 爆款推荐（HmHot）
5. 商品列表与无限滚动（HmMoreList）

讲义建议用 CustomScrollView 把这些模块组合起来，这样后面做吸顶、懒加载、复杂滚动都更自然。

五、轮播图模块：UI + 数据打通

1. UI 结构

轮播图常用 carousel_slider：

flutter pub add carousel_slider

同时通过 Stack + Positioned 叠加搜索框与导航条，实现"图上叠层"的电商首页效果。

2. 数据接入

讲义里轮播模块重点不是控件本身，而是数据流程：

1. 定义轮播模型
2. 封装轮播接口
3. 初始化请求数据
4. 父传子渲染

这套流程后面在分类、推荐、商品列表会反复复用。

六、接口工程化：Dio 不是调用一次 get() 就结束

案例里把请求层拆得比较完整，建议直接沿用：

1. 常量层：baseUrl、超时、业务状态码、接口路径
2. 请求层：Dio 实例、拦截器、统一错误处理
3. API 层：按业务模块导出方法
4. 模型层：factory 构造函数把 JSON 转对象

推荐统一思路：

1. 页面只关心"拿什么数据"
2. 业务状态码和异常处理在请求层统一处理
3. 模型层保证页面拿到的是强类型数据

七、AI 辅助开发：快，但要保留人工校验

讲义里大量使用 Trae 的 Tab/协作模式生成模型和 API。

很实用，但有个前提：复杂结构一定要人工复核字段与空值处理。

适合 AI 自动生成的部分：

1. JSON 转模型类
2. 标准 CRUD API 方法
3. 重复模板代码

必须人工接管的部分：

1. 复杂 UI 结构
2. 交互细节与边界态
3. 业务规则与异常分支

八、列表体验：上拉加载 + 下拉刷新

讲义把"列表可用性"做得比较完整，核心点如下：

1. 上拉加载

需要同时维护：

1. 当前页码 page
2. 是否正在加载 loading
3. 是否还有下一页 hasMore

避免两个常见问题：

1. 滚动到底部重复并发请求
2. 没有下一页还继续请求

2. 下拉刷新

通常用 RefreshIndicator 包裹列表，刷新逻辑要做"重置 + 重新拉首屏"：

1. 清空列表
2. 重置页码和状态
3. 重新请求第一页

3. 提示与过渡

讲义还加入了轻提示与过渡动画，这些细节会显著提升"体感完成度"。

九、我的页面：复用已有能力

"我的"页面不是从头再做一套，而是复用已有组件和请求能力：

1. 复用商品列表组件
2. 新增"猜你喜欢"接口与模型
3. 继续沿用滚动监听与加载策略
4. 增加吸顶交互

这一节本质上是在练"可复用架构"是否成立。

十、登录页：从 UI 到鉴权链路

1. 表单校验

登录流程至少要覆盖：

1. 手机号格式校验
2. 验证码/密码校验
3. 勾选协议校验
4. 提交按钮可用态控制

2. 登录请求

请求侧补齐 POST 能力后，登录链路就是：

1. 调用登录 API
2. 成功后写入 token
3. 失败时捕获异常并提示

十一、状态共享：用 GetX 统一用户态

讲义采用 GetX 共享用户数据，主线很清晰：

1. 定义 GetxController
2. 用 .obs 声明响应式状态
3. 页面 put/find 控制器
4. 登录后更新全局用户信息

这种方式对中小项目的"登录态联动"非常高效。

十二、Token 持久化：登录闭环的关键一环

持久化采用 shared_preferences：

flutter pub add shared_preferences

建议封装 TokenManager，提供：

1. init
2. setToken
3. getToken
4. clearToken

并在 Dio 请求拦截器中自动注入 token。

这样页面层不需要每次手动拼接鉴权头。

十三、退出登录与弹窗体验

退出流程建议固定成：

1. 弹确认框
2. 确认后清理 GetX 用户态
3. 清理 token 持久化
4. 关闭弹窗并回到未登录态

此外可封装 Loading 弹层，统一处理请求中的等待反馈。

十四、多端适配：从 Web 走向 Android / iOS / HarmonyOS

1. Android 适配重点

讲义给出的主流程：

1. 安装 JDK 17
2. 安装 Android Studio + SDK
3. 完成 flutter doctor -v 检查
4. 接受 Android licenses
5. 补全平台代码：flutter create .
6. 配置 Gradle/Maven 镜像
7. 配置网络权限
8. 修复 UI 溢出
9. 打包 APK

常用打包命令：

flutter build apk --debug
flutter build apk --release

2. iOS 适配重点

iOS 端只在 macOS 环境下进行，核心是：

1. Xcode 工具链正确
2. 模拟器可启动
3. 运行后逐页修复样式溢出和平台差异

3. HarmonyOS 适配重点

讲义重点提到：

1. 使用鸿蒙版 Flutter
2. 安装 DevEco Studio 与模拟器
3. 配置鸿蒙环境变量
4. 处理依赖兼容（例如部分插件替换来源）
5. 签名后运行

这部分是"工具链适配 + 依赖兼容"双重挑战，建议单独留出排障时间。

十五、完结阶段的版本回调

综合案例最后还有一个很实用的提醒：

在 Flutter SDK 或平台链路发生降级/切换后，Android Gradle Plugin、Kotlin 等版本可能需要回调到匹配组合。

换句话说，多端项目里"版本矩阵"本身就是一项工程工作。

十六、从这份案例真正能学到什么

这套综合案例的价值，不在于"做出一个商城界面"，而在于把这几件事一次走通：

1. 结构化目录与模块化组件
2. 请求层工程化封装
3. 列表体验（上拉、下拉、提示、动画）
4. 登录态（GetX + token 持久化 + 拦截器）
5. 多平台工具链与兼容性处理

如果你把这条链路做完整，后续做自己的业务 App 时，基本已经具备"从需求到可上线原型"的能力。

十七、建议你复盘的 7 个关键点

1. 首页为什么用 CustomScrollView 而不是单纯 ListView
2. 请求层为什么要抽离、而不是散在页面里
3. 上拉加载为什么必须有 loading 和 hasMore
4. 登录态为什么要有"内存态 + 持久化态"双层设计
5. 页面通信何时用父子回调、何时上升到全局状态
6. 多端适配中，哪些是业务问题，哪些是工具链问题
7. 出现 UI 溢出时，如何系统定位而不是局部打补丁

结语

这份综合案例的意义是把"会写组件"升级成"会做项目"。

当你能稳定完成这套流程，你的 Flutter 能力就不再停留在 Demo 层，而是开始具备真实业务交付能力。

下一步最推荐的练习是：

把这个商城案例做一次"你自己的业务改版"，比如改成课程系统、图书系统或内容社区。

当你能在同一套骨架上快速替换业务，说明你真的掌握了这套工程方法。