子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人第一次做 Flutter 项目，都会有一种“开发效率爆炸”的感觉：
页面很好写，组件复用也顺手，热重载几乎让开发变成“所见即所得”。

甚至一个人就能在几天内，把一个完整的业务流程跑通。

但问题往往出现在项目进入第二阶段之后：

• 页面越来越多
• 需求越来越碎
• 改一个地方开始牵一发而动全身

这时候你会发现—— 项目并没有变复杂，但却越来越难维护了。

初期的“简单”，来自于低耦合假象

在项目刚开始时，大多数 Flutter 代码结构是这样的：

lib/
 ├─ pages/
 ├─ widgets/
 ├─ services/
 └─ models/

这个结构的问题不在于“错”，而在于：

它只在“功能少”的时候成立。

比如一个登录流程：

• page 负责 UI
• service 负责请求
• model 负责数据

路径非常清晰，几乎没有交叉。但随着业务增长，你会慢慢发现：

• 一个 service 被多个页面复用
• 一个 widget 被不同业务“稍微改一下”
• model 开始变得越来越通用

表面上是复用，实际上是耦合在悄悄增加。

失控的第一步：依赖开始无边界扩散

Flutter 最大的“隐性问题”之一是：

import 几乎没有限制。

你可以在任何地方直接引用任何文件：

import '../../services/user_service.dart';

短期看非常方便，但长期会带来一个很典型的问题：依赖方向彻底失控。 常见现象包括：

• UI 直接调用 service
• service 反向依赖 UI（比如 callback）
• utils 变成“万能工具箱”

这时候如果你画一张依赖图，会发现已经不是分层结构，而是一张网。一旦某个核心类改动：

很难判断影响范围。

失控的第二步：复用变成“隐性共享”

很多团队在项目发展到中期时，会开始强调“组件复用”。

于是会出现这样的代码：

CommonButton(
  text: '提交',
  isLoading: true,
  type: ButtonType.primary,
  enableShadow: false,
  customPadding: EdgeInsets(...)
)

参数越来越多，看起来越来越“通用”。但本质上，这类组件在做一件危险的事情：

把不同业务的需求，硬塞进一个组件。

结果是：

• 修改一个参数，影响多个页面
• 新需求越来越难兼容
• 谁都不敢动这个组件

复用没有减少复杂度，只是把复杂度集中到了一个地方。

失控的第三步：状态开始失去归属

Flutter 的状态管理灵活，但也因此容易“失控”。常见情况：

• 页面里有 setState
• 局部用了 Provider
• 某些地方直接用全局变量

短期看问题不大，但当多个页面依赖同一份数据时：

• 更新时机不一致
• 状态来源不清晰
• bug 很难复现

最终会出现一个典型问题：

不知道该改哪里。

这其实不是状态管理工具的问题，而是状态边界没有设计清楚。

失控的第四步：接口变化直接冲击 UI

很多 Flutter 项目会直接在页面里写：

final name = response['name'];

或者：

User.fromJson(res.data)

问题在于：

UI 直接依赖接口结构。

当接口发生变化：

• 字段改名
• 嵌套层级变化
• 数据格式调整

就会变成：

多页面同时修改。

如果项目大一点，这种修改成本会非常高。

为什么这些问题在中后期集中爆发

因为前期有三个“掩护”：

功能少 → 看不出结构问题

改动频率低 → 感觉一切可控

开发人数少 → 没有协作冲突

一旦进入中后期：

• 多人协作
• 高频迭代
• 历史代码堆积

所有“结构问题”都会被放大。

一个更稳定的演进方向

如果你观察那些能长期维护的 Flutter 项目，通常会做三件事：

按业务拆，而不是按目录拆

features/
 ├─ user/
 ├─ order/
 └─ home/

每个 feature 内部自成体系：

• UI
• data
• logic

这样可以做到：

删除一个功能，不影响其他模块。

控制依赖方向

明确一条规则：

• UI → logic → data
• 不能反向依赖

哪怕不做强约束，也要在代码评审中坚持。

隔离“变化”

包括两类变化：

接口变化 → 用 DTO 隔离
UI 变化 → 避免过度复用组件

核心思想是：

不要让“变化”扩散。

本质问题：不是 Flutter，而是工程思维

很多人会把这些问题归结为：

Flutter 不适合大型项目。

但实际上，同样的问题在：

• 前端（React / Vue）
• iOS
• Android

都出现过，区别只是：

有的生态已经踩过坑，并形成了共识。

而 Flutter 还在快速发展阶段，很多团队还没走到“结构反思”这一步。

写在最后

Flutter 项目“前期简单，后期失控”，本质不是代码变多了，而是：

结构没有随着业务一起演进。

如果只关注“怎么写页面”，而忽略：

• 模块边界
• 依赖方向
• 数据流设计

那项目迟早会进入一个阶段：

功能还能加，但没人敢改。

而真正好的结构，不是让你写得更快，而是让你在一年之后，依然能从容地改动今天的代码。