在传统 web 项目中，开发者会对项目中的公共物料做抽离复用，代码片段如：组件、接口、CSS 样式、类型（TypeScript 项目），资源如图片、icon 等。对于公共页面，更倾向于采用公共组件的形式来维护，因为页面是 web 项目中的最高级也是最重的容器，使用公共组件可以减少页面的部署次数、降低调用成本。而对于轻中量级的 Flutter 项目来说，页面是基础容器，扁平化的页面管理方式会随着页面的增多愈加难以维护，因此建议基于项目实际的业务架构进行目录结构设计，提升项目代码的可读性。
以 Apple Music 为例，它是长这样的：
我们从界面设计中可以拆出如下业务模块：
| 页面入口 | 页面内容 | 涉及的页面或模块 | | :---: | :---: | | :---:| | 探索页 | 给用户推荐一些个性化的曲库 | 专辑详情页、歌手详情页、播放页等 | 排行榜 | 不同维度统计下的热歌 | 专辑详情页、歌手详情页、播放页等 | 搜索页 | 个性化曲库内搜索 | 搜索结果页 | 乐曲库 | 分类乐曲库 | 歌单详情页、会员页 | 设置页 | 用户设置页，如歌曲偏好等 | 登录页、用户信息设置页、会员页
四个页面入口相对独立，本身并没有很重的业务逻辑，更多的是展示公共模块的信息。以【探索页】为例，展示用户个性化的专辑、歌手是页面的核心逻辑，登录页是完成该流程的前置条件，专辑模块、歌手模块、播放器模块是实现逻辑的必需物料。再以【设置页】为例，设置页只是不同页面的集合入口和信息的集中展示（这些子页面也可能相互跳转）。
综上，我们可以设计如下业务结构图：
对上图中的四个模块的概念给出如下定义： | 模块 | 模块定义 | 文件夹缩写 | | :---: | :---: | | :---:| | 基础模块 | 基础物料，自身不具备任何逻辑 | base | 通用模块 | 自身带有业务逻辑的可复用模块，且保证独立 | common | 通用页面 | 可复用的页面，如登录页、搜索页。或通过【多链路】展示的页面 | public | 业务页面 | 一级页面，用户不需要进行交互操作即可查看的页面 | 业务名
目录结构如下：
| 一 images // 图片资源
| 一 assets // 其他资源，如 icon/svg/音频文件
| 一 test // 测试目录
| 一 lib // 资源目录
| 一一 config // 环境变量等配置
| 一一 router // 路由管理
| 一一 common // 通用模块
└── network // 网络库
└── api // 接口集合
└── components // 组件库
| 一一 public // 通用页面
└── login // 登录模块
└── login_page // 登录页
└── login.dart
| 一一 pages // 业务页面
└── Explore
└── Setting
└── Trending
└── trending.dart
└── Trending_list.dart
└── Trending_list_search.dart // 同一业务下二级文件命名采用继承的方式，使用’_’连接
└── Libarary
└── Search
| 一一 helper // 工具文件夹集合
└── format.dart // 各类工具函数
目录解析：
- 目录根据业务进行拆分为四个支线，开发者只需要关心当前支线下的业务逻辑；
- 在上述开发场景下，一旦涉及到公共页面修改，开发者需要进入
public文件修改，提高修改的谨慎性； - 什么是【多链路】？如果一个页面只有唯一路径可以打开，那么该页面需要放在
pages对应业务页面下；如果某页面有大于或等于二条的路径来打开查看，即为多链路，此时需要将该页面移动到public文件夹内；
综上，该目录可以较好地满足一个中型项目的初始化。
