SwiftUI 系列 15｜我会怎样从零搭一个可维护的 SwiftUI 项目

如果让我从零搭一个 SwiftUI 项目，我最先考虑的不会是目录长什么样，也不会先纠结：

• 是不是要上很完整的架构模板
• 是不是要先抽很多基础层

我更先想的是这几件事：

• 状态怎么流动
• 页面职责怎么切
• 组件何时抽、抽到什么程度
• 项目三个月后会不会开始难改

因为很多 SwiftUI 项目最初都挺轻，真正的分水岭往往出现在两三个月后：

• 页面越来越多
• 状态越来越散
• 组件复用越来越随意
• View 里开始堆业务逻辑

所以“可维护”真正要解决的是增长后的稳定性，而不是第一周的开发速度。

一、我不会一开始就搭很重的架构壳，而是先把职责立清

从零起项目时，最常见的误区之一就是：

• 业务还没展开
• 先把一整套看起来很完整的架构铺满

这并不一定错，但风险是：

• 抽象过早
• 结构和真实业务不贴
• 团队后面会不断绕过它

所以我更倾向于：

• 先让职责边界清楚
• 再随着复杂度逐步加层

比起“第一天就大而全”，我更看重“第一个月都还顺手”。

二、我最先明确的通常是三层：页面层、状态层、能力层

1. 页面层

负责：

• 结构
• 组件组合
• 页面状态映射

2. 状态层

负责：

• 业务状态
• 异步流程
• 页面语义状态切换

3. 能力层

负责：

• 网络
• 存储
• 领域服务
• 通用组件与样式能力

这三层未必一开始就要拆得非常细，但意识必须先有。
否则 SwiftUI 项目很容易滑向“所有东西都直接写在 View 里”。

三、我会非常警惕“巨型 View”

SwiftUI 写 UI 很顺手，所以最容易出现的坏味道之一就是：

• 结构写在 View
• 请求写在 View
• 状态判断写在 View
• 文案拼装也写在 View

早期看当然很快，但项目一复杂，View 会迅速变成：

• 难读
• 难改
• 难测

这时问题不是 SwiftUI 不行，而是你让 View 承担了过多非展示职责。

四、组件复用我会故意慢半拍，而不是一开始就抽得很狠

很多团队一开始很容易追求“通用组件库”。
但真实项目里，过早抽象往往比稍晚抽象更危险：

• 接口会被设计得过宽
• 为了未来可能的场景预埋很多选项
• 组件看起来复用，实际上谁用谁难受

所以我更愿意让组件在一两个真实页面里先长出来，等模式足够稳定后再抽。
这样抽出来的组件通常更贴近真实使用，而不是抽象体操。

五、状态边界通常比目录结构更重要

很多项目一开始会花很多时间争论：

• Feature-first 还是 Layer-first
• 文件夹该怎么分

这些当然重要，但我更在意的是：

• 哪些状态归页面自己管
• 哪些状态归外部业务对象管
• 哪些状态该共享，哪些不该共享

因为真正决定维护成本的，往往不是目录名字，而是状态有没有到处乱跑。

六、可维护性的核心，其实是让每一层都“说得清自己负责什么”

如果一个项目后期越来越难改，通常都有这些信号：

• 页面结构看不出主次
• 状态归属越来越模糊
• 组件边界越来越抽象
• 一改需求就要横跨很多层补逻辑

所以一个可维护的 SwiftUI 项目，我最看重的通常不是“高级感”，而是：

• 页面一眼能读
• 状态一眼能分
• 组件边界自然
• 业务逻辑不堆在 View 里

这四件事都很朴素，但长期特别值钱。

七、结论：从零搭 SwiftUI 项目，真正要先摆对的是边界，不是模板

如果只用一句话总结，我会说：

从零搭一个可维护的 SwiftUI 项目，最重要的不是先选一个多完整的模板，而是先把状态边界、页面职责和组件抽象时机摆对。

这些边界一旦立住，项目会越长越稳；
边界没立住，再高级的模板也很容易被真实业务一点点冲散。