网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录引言按技术层拆一开始为什么这么舒服项目变大后技术分层会带来的问题问题一代码分散问题二边界模糊问题三协作困难按功能Feature拆解决了什么问题优势一上下文完整优势二天然模块边界优势三更适合团队协作那是不是应该完全放弃“技术分层”推荐结构一个真实场景对比技术分层结构Feature 结构什么时候用哪种方式小项目 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 改 serviceB 改 pageC 改 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 负责 userB 负责 order减少冲突那是不是应该完全放弃“技术分层”很多人看到这里会误解“那是不是就不要分层了”其实不是关键点是分层应该发生在 Feature 内部而不是全局。推荐结构一个更合理的结构是features/ ├─ user/ │ ├─ ui/ │ ├─ model/ │ ├─ service/ │ ├─ state/ │ ├─ order/ │ ├─ ui/ │ ├─ model/ │ ├─ service/Feature 外按业务划分Feature 内按技术分层这样做的好处保留分层优势同时保证业务聚合一个真实场景对比假设你要修改用户头像上传逻辑技术分层结构你需要改pages/user_page.dartservices/upload_service.dartmodels/user_model.dart来回跳 3 个目录Feature 结构你只需要在features/user/内部完成修改所有代码都在一个上下文里什么时候用哪种方式这里给你一个非常实用的判断标准小项目 10 页面技术分层就够了原因简单开发快不需要复杂结构中大型项目10 页面必须 Feature 化否则你会遇到维护困难重构困难团队协作混乱超大型项目Feature 子模块 包拆分甚至可以每个 Feature 独立 package独立发布类似微前端 / 模块化架构总结“按功能拆”还是“按技术拆”其实不是二选一的问题。真正的答案是用 Feature 组织业务用分层管理复杂度。Flutter 项目之所以后期容易失控往往不是因为技术选型错了而是因为代码结构没有随着业务规模一起演进。当你开始从“技术视角”转向“业务视角”组织代码时你会发现代码更容易理解修改成本更低团队协作更顺畅结构设计从来不是一开始就完美的而是随着项目成长不断演进的。
Flutter 应该按功能拆，还是按技术层拆？
网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录引言按技术层拆一开始为什么这么舒服项目变大后技术分层会带来的问题问题一代码分散问题二边界模糊问题三协作困难按功能Feature拆解决了什么问题优势一上下文完整优势二天然模块边界优势三更适合团队协作那是不是应该完全放弃“技术分层”推荐结构一个真实场景对比技术分层结构Feature 结构什么时候用哪种方式小项目 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 改 serviceB 改 pageC 改 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 负责 userB 负责 order减少冲突那是不是应该完全放弃“技术分层”很多人看到这里会误解“那是不是就不要分层了”其实不是关键点是分层应该发生在 Feature 内部而不是全局。推荐结构一个更合理的结构是features/ ├─ user/ │ ├─ ui/ │ ├─ model/ │ ├─ service/ │ ├─ state/ │ ├─ order/ │ ├─ ui/ │ ├─ model/ │ ├─ service/Feature 外按业务划分Feature 内按技术分层这样做的好处保留分层优势同时保证业务聚合一个真实场景对比假设你要修改用户头像上传逻辑技术分层结构你需要改pages/user_page.dartservices/upload_service.dartmodels/user_model.dart来回跳 3 个目录Feature 结构你只需要在features/user/内部完成修改所有代码都在一个上下文里什么时候用哪种方式这里给你一个非常实用的判断标准小项目 10 页面技术分层就够了原因简单开发快不需要复杂结构中大型项目10 页面必须 Feature 化否则你会遇到维护困难重构困难团队协作混乱超大型项目Feature 子模块 包拆分甚至可以每个 Feature 独立 package独立发布类似微前端 / 模块化架构总结“按功能拆”还是“按技术拆”其实不是二选一的问题。真正的答案是用 Feature 组织业务用分层管理复杂度。Flutter 项目之所以后期容易失控往往不是因为技术选型错了而是因为代码结构没有随着业务规模一起演进。当你开始从“技术视角”转向“业务视角”组织代码时你会发现代码更容易理解修改成本更低团队协作更顺畅结构设计从来不是一开始就完美的而是随着项目成长不断演进的。
