Flutter 应该按功能拆，还是按技术层拆？

网罗开发 （小红书、快手、视频号同名）

大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

📣 公众号"Swift社区"，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 3 月 17 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

• • 引言
  • 按技术层拆，一开始为什么这么舒服
  • 项目变大后，技术分层会带来的问题
  • • 问题一：代码分散
    • 问题二：边界模糊
    • 问题三：协作困难
  • 按功能（Feature）拆，解决了什么问题
  • • 优势一：上下文完整
    • 优势二：天然模块边界
    • 优势三：更适合团队协作
  • 那是不是应该完全放弃"技术分层"？
  • 推荐结构
  • 一个真实场景对比
  • • 技术分层结构
    • [Feature 结构](#Feature 结构)
  • 什么时候用哪种方式？
  • • [小项目（< 10 页面）](#小项目（< 10 页面）)
    • [中大型项目（10+ 页面）](#中大型项目（10+ 页面）)
    • 超大型项目
  • 总结

引言

很多 Flutter 项目在初期都会有一个"看起来很合理"的目录结构：

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

刚开始的时候，这种结构确实很好用：

• 找代码很直观
• 新人容易理解
• 开发速度很快

但项目一旦变大，你大概率会遇到这种情况：

"我改一个页面，要改 5 个目录里的代码？"

这时候问题就来了：到底应该按"功能拆"，还是按"技术层拆"？

这个问题，本质上不是 Flutter 的问题，而是工程规模的问题。

按技术层拆，一开始为什么这么舒服

先说"按技术层拆"，这种结构其实来源很早，很多 Web、Android 项目都用过。例如：

pages/
models/
services/

优点很明显：

• 分层清晰
• 职责明确
• 符合"架构设计"的直觉

比如一个接口请求：

• model 定义数据
• service 负责请求
• page 负责展示

看起来非常"标准"，但问题在于：

它是从"技术实现"角度组织代码，而不是从"业务"角度。

当业务变复杂时，这种结构会逐渐失控。

项目变大后，技术分层会带来的问题

当你有 20+ 页面时，问题开始出现：

问题一：代码分散

一个"用户模块"的代码，可能分布在：

pages/user_page.dart
models/user_model.dart
services/user_service.dart

当你要修改"用户逻辑"时，你需要跨多个目录跳转。

上下文被打断

问题二：边界模糊

随着时间推移，你会发现：

• service 里开始写业务逻辑
• page 里也有数据处理
• utils 变成"垃圾桶"

例如：

// utils 里突然出现业务方法
formatUserLevel(user)

代码开始"漂移"，没有清晰归属

问题三：协作困难

多人开发时：

• A 改 service
• B 改 page
• C 改 model

冲突频繁出现， 因为大家都在改"同一块业务"的不同技术层

按功能（Feature）拆，解决了什么问题

再看另一种方式：按功能拆。例如：

features/
 ├─ user/
 │   ├─ user_page.dart
 │   ├─ user_model.dart
 │   ├─ user_service.dart
 │
 ├─ order/
 │   ├─ order_page.dart
 │   ├─ order_model.dart
 │   ├─ order_service.dart

这时候你会发现一个明显变化：

所有"用户相关"的代码都在一个目录里。

优势一：上下文完整

当你在改"用户模块"时：

• 不需要跨目录
• 不需要全局搜索
• 思路不会被打断

开发效率明显提升

优势二：天然模块边界

每个 feature 都像一个"小项目"：

• 有自己的数据
• 有自己的 UI
• 有自己的逻辑

更容易做模块隔离

优势三：更适合团队协作

可以按功能分工：

• A 负责 user
• B 负责 order

减少冲突

那是不是应该完全放弃"技术分层"？

很多人看到这里会误解：

"那是不是就不要分层了？"

其实不是，关键点是：

分层应该发生在 Feature 内部，而不是全局。

推荐结构

一个更合理的结构是：

features/
 ├─ user/
 │   ├─ ui/
 │   ├─ model/
 │   ├─ service/
 │   ├─ state/
 │
 ├─ order/
 │   ├─ ui/
 │   ├─ model/
 │   ├─ service/

Feature 外按业务划分，Feature 内按技术分层

这样做的好处：

• 保留分层优势
• 同时保证业务聚合

一个真实场景对比

假设你要修改：

用户头像上传逻辑

技术分层结构

你需要改：

• pages/user_page.dart
• services/upload_service.dart
• models/user_model.dart

来回跳 3 个目录

Feature 结构

你只需要在：

features/user/

内部完成修改

所有代码都在一个上下文里

什么时候用哪种方式？

这里给你一个非常实用的判断标准：

小项目（< 10 页面）

技术分层就够了，原因：

• 简单
• 开发快
• 不需要复杂结构

中大型项目（10+ 页面）

必须 Feature 化，否则你会遇到：

• 维护困难
• 重构困难
• 团队协作混乱

超大型项目

Feature + 子模块 + 包拆分，甚至可以：

• 每个 Feature 独立 package
• 独立发布

类似微前端 / 模块化架构

总结

"按功能拆"还是"按技术拆"，其实不是二选一的问题。真正的答案是：

用 Feature 组织业务，用分层管理复杂度。

Flutter 项目之所以后期容易失控，往往不是因为技术选型错了，而是因为：

代码结构没有随着业务规模一起演进。

当你开始从"技术视角"转向"业务视角"组织代码时，你会发现：

• 代码更容易理解
• 修改成本更低
• 团队协作更顺畅

结构设计，从来不是一开始就完美的，而是随着项目成长不断演进的。