LESSON 05 / 575 分钟
Swift Package Manager 与工程组织
先用系统框架完成核心功能；当复用边界明确时，再引入包或拆模块。
用你的前端经验理解
SPM 类似包管理器；Package.swift 类似包清单。它管理产品、Target 和依赖，不是直接安装 npm 包。
01 / 理解问题
为什么需要它
包管理解决复用和依赖边界，不负责替你设计架构。对一个阅读 App，网址格式化函数可能只需独立文件；当同一逻辑被 iOS、macOS 和测试共同使用，且不依赖 UI 时，提取为 Swift Package 才开始有收益。过早拆包会增加访问控制、平台配置和构建维护成本。
它是怎样工作的
Swift Package 可以定义多个 Target，再以 product 对外暴露可使用的库。App 依赖某个产品，源码通过 import 访问模块；模块中的类型与成员还必须具有合适的可见性。版本约束表达允许升级的范围，解析记录帮助团队使用一致依赖。引入前还需核对平台、最低系统版本、许可证和传递依赖。
02 / 掌握要点
把关键概念连起来
1
依赖
在 Xcode 中添加 Package Dependency，明确版本约束，并审查维护状态、许可与平台支持。
2
模块
import 引入模块，public 才向模块外公开；internal 默认在同模块内可访问。
3
组织
小项目按 Feature 分目录，页面、模型、服务靠近功能。独立可测试逻辑再提取到 Swift Package。
03 / 案例推演
把阅读时长计算移入共享模块
- 先写一个只接收字数并返回分钟数的纯函数，不让它读取单例、当前窗口或数据库。
- 在包里公开类型、初始化器和方法；仅把 struct 标为 public 而遗漏成员访问级别，App 仍可能无法调用。
- 给零字数、正常文章和异常输入规定结果，并在包测试里验证。随后由两个 App Target 导入同一产品。
这里需要你亲自判断
不要为了一个小工具引入复杂状态框架；依赖的最低系统版本也会影响你的 App。
04 / 动手验证
做一个小练习
把一个纯 Swift 格式化函数放进独立文件；说明它是否值得提取成包。
- 判断网址解析、页面导航、数据库连接中哪些适合共享包，并解释依赖方向。
- 在提交记录里查看新增包带来了哪些间接依赖与平台要求。
展开参考思路与验收标准
共享包应依赖稳定的输入输出，而不是反向依赖具体 App 的 View。一个可以在不启动 UI 的情况下测试的阅读时长函数，是比“所有文件放入 Core 包”更清楚的模块边界。
05 / 检查理解
想让包里的类型被 App 访问，应关注哪个访问级别？
答对理解题后即可标记完成