Flutter 实战踩坑与架构复盘

Riverpod 在业务项目中的分层实践：从「能跑」到「能养」 当你把 Riverpod 从 Demo 搬进真实业务，最常见的情况不是「不会写 Provider」，而是：Provider 放哪儿都对、

ViewModel 如何写得可测试、可复用 上一篇把 Riverpod 拆成 data / application / presentation。这一篇盯着 application 里那一层：习惯叫

Provider 的 select 与局部刷新：别用错粒度 Riverpod 里最容易产生错觉的一句话是：「我用了 Riverpod，性能就不会差。」 实际上 监听的是哪一层状态、用什么方式监听，比在

异步状态管理：加载、空态、错误态统一处理 列表页、详情页、表单提交，接口一多，页面里很容易出现同一种写法：isLoading、isEmpty、errorMessage 各管一摊，有的地方还要加个 ha

页面一多，最容易长成两种「地狱」：一种是 A 页面直接 ref.read 进 B 模块的 Provider，需求一改全链路跟着抖；另一种是 把导航、弹窗、Navigator、BuildContext

业务架构复盘：我踩过的 5 个反模式 Flutter + Riverpod 做久了，容易有一种错觉：能跑、能发版，就等于架构没问题。真正拖累团队的往往是「当时省事」的写法：改一个入口牵一片、侧滑返回状

我为什么用 Flutter 做中大型业务（选型与边界） 1. 问题背景：业务场景 + 现象 我负责的是一个偏“重交互”的业务项目，核心特征如下： 页面多、模块多（房间、聊天、支付、活动、广告、用户体系

pubspec 依赖管理与版本锁定实践 1. 问题背景：业务场景 + 现象 随着项目变大，依赖会越来越多：网络、状态管理、音视频、支付、广告、埋点、图片、工具链…… 如果 pubspec.yaml 管

日志、埋点、错误收集的统一接入 1. 问题背景：业务场景 + 现象 中大型业务最怕“线上出问题但看不见”： 用户说卡、说崩，但没有上下文 同一个问题在不同模块重复出现 日志分散在 print、debu

Flutter 工程目录如何设计才可长期维护 1. 问题背景：业务场景 + 现象 当项目从 10 个页面增长到 100+ 页面后，最先崩的通常不是功能，而是结构： 找代码靠搜索，不靠约定 页面里堆网络

路由与页面组织：从小项目到复杂业务 1. 问题背景：业务场景 + 现象 小项目里直接 Navigator.push 没问题，但业务变复杂后会出现： 路由字符串散落各处，拼写错误难发现 参数通过 dyn

多环境配置（dev/test/prod）与打包策略 1. 问题背景：业务场景 + 现象 中大型项目里，通常至少有三套环境： dev：联调、快速验证 test：测试回归、提测验收 prod：正式线上 如