我是如何用 SwiftUI 做产品的：一些真实经验

很多人问我，SwiftUI 到底好不好用？值不值得投入？

如果只回答一句话：SwiftUI 不是更简单，而是更“纯粹”。

它迫使你理解“状态”与“结构”。

如果你不理解，你会很痛苦；

如果你理解了，它会非常强。

这篇文章不讲基础语法，而是讲我在真实产品开发中踩过的坑，以及后来形成的一些原则。

一、SwiftUI 的本质不是 UI，而是状态

很多人把 SwiftUI 当成“更简单的 UIKit”。

这是第一层误解。

SwiftUI 的核心不是“视图”，而是：

状态变化 → 视图重新计算

一切问题都围绕这件事。

当你发现界面莫名刷新、列表乱跳、动画卡顿、导航异常，本质都是：

状态管理失控。

我早期写代码时，经常把所有状态塞进 View 里。

结果是：

body 超过 300 行
任何修改都会引发连锁刷新

后来我开始强制自己做一件事：

让 View 只负责展示，让状态集中管理。

二、不要把业务逻辑写在 View 里

SwiftUI 很容易诱导你这样写：

Button("Save") {
    if input.count > 5 {
        model.save()
    }
}

这看起来很方便，但随着项目变大，逻辑会迅速失控。

我的经验是：

View 只做触发
判断逻辑放进 ViewModel
数据处理放进 Service

分层之后，整个项目稳定性会明显提升。

SwiftUI 的“轻松感”会让人放弃结构，但产品一定需要结构。

三、NavigationStack 是第二个大坑

如果你做过复杂应用，一定遇到：

返回层级异常
深层页面 pop 失败
路径状态丢失

SwiftUI 的导航是状态驱动的，而不是控制器驱动的。

我的经验：

永远用 NavigationPath 管理路由
不要在子页面直接 push
所有跳转集中在一个 Router

当你把导航当成“数据”，问题就会少很多。

四、动画和性能不是免费的

SwiftUI 的动画非常好用，但也非常危险。

一开始我几乎所有状态都加 .animation()，后来发现：

列表卡顿
滚动掉帧
复杂视图反复重绘

SwiftUI 每次状态变化都会重新计算 body。

如果层级深、依赖多，代价非常大。

后来我形成了一个习惯：

大视图拆小
只给必要状态加动画
用 EquatableView 控制刷新

SwiftUI 性能问题，90% 来自“过度状态依赖”。

五、设计系统是救命工具

当产品开始多模块时，如果没有统一设计系统，你会非常痛苦。

我后来建立了：

统一间距系统
统一字体层级
统一颜色 Token
统一阴影和圆角

这样做的好处是：

UI 一致
改主题容易
不会到处写 magic number

SwiftUI 的声明式写法非常适合设计系统化。

六、SwiftUI 最大的优点：迭代速度

真正让我坚持 SwiftUI 的原因只有一个：

迭代快到不可思议。

在 UIKit 时代，一个交互改动可能涉及：

控制器
约束
代理
数据刷新

在 SwiftUI 里，改一个状态，UI 自动响应。

对于独立开发者来说，这种速度就是竞争力。

七、不要神化 SwiftUI

它不是完美的。

你会遇到：

奇怪的布局 bug
版本兼容问题
macOS 和 iOS 差异
某些 API 不完整

有些时候，UIKit 仍然更稳定。

真正成熟的做法是：

SwiftUI 为主，必要时桥接 UIKit。

而不是极端选择。

八、我对 SwiftUI 的理解

写了一段时间之后，我意识到：

SwiftUI 不是一个 UI 框架。

它是一种“结构表达方式”。

你写的不是界面，而是：

数据关系
状态流向
依赖结构

如果结构清晰，SwiftUI 会非常优雅。

如果结构混乱，SwiftUI 会让你痛苦。

九、给新手的建议

不要一上来就做复杂项目
学会状态流，而不是学 modifier
早点建立分层结构
不要让 body 超过 150 行
永远控制状态数量

最重要的一点：

SwiftUI 是长期主义的框架。

它奖励结构化思维，而不是技巧。

结语

如果让我重新选择，我仍然会用 SwiftUI 做产品。

不是因为它简单，而是因为它让产品和结构天然绑定。

当你理解“状态即驱动”之后，

你会发现：

SwiftUI 写的不是 UI，

而是一个活着的系统。

SwiftUI 开发指南