缘起：账单上那笔想不起来的15块
去年年底翻信用卡账单，发现一笔15块的扣费怎么都想不起来是什么。折腾半天才查到——某个App试用期过了自动续费，而我甚至没打开过第二次。
相信不少人有过类似经历。当时我就想，为什么不做一个工具，把所有订阅服务集中管理起来，哪些该续、哪些该砍，一目了然？
于是就有了「订阅斩」这个项目。从去年底开始做，到现在上架App Store大概三个多月，中间踩了不少坑，这篇文章做个技术复盘。
技术选型
项目一开始就选了 SwiftData + SwiftUI + Swift 6 这套纯新技术栈。SwiftData当时刚出来不久，确实有风险，但我觉得个人项目就是拿来试新东西的，而且它跟SwiftUI的数据流集成确实比CoreData那套NSFetchedResultsController样板代码清爽太多。
核心数据模型大致长这样：
@Model
final class Subscription {var id: UUIDvar name: Stringvar price: Doublevar cycle: Int // 0=月付, 1=季付, 2=年付var isTrial: Boolvar nextBillingDate: Datevar status: Int // 活跃 / 已斩var killedDate: Date?var isShared: Boolvar membersCount: Intvar categoryStorage: String?
}
这里有个设计取舍：cycle和status存的是Int rawValue而不是直接存枚举。原因是SwiftData对枚举类型的lightweight migration支持当时还不稳定，用Int更保险，上层再包一个计算属性转回枚举就行。虽然丑，但稳。
周期换算：一个低级Bug让我排查了半小时
仪表盘需要展示「每月总支出」，但用户录入时可以选月付、季付、年付，所以需要统一折算。逻辑本身很简单——季付除以3，年付除以12。
但我一开始把季付的换算系数写成了3.0 / 1.0（对，写反了），导致仪表盘金额离谱地高。当时还以为是SwiftUI的刷新问题，用Instruments看了半天才发现是纯粹的算术错误。教训：越简单的逻辑越容易犯低级错误，单元测试不能省。
风险检测：抓出「订阅刺客」
这是我比较满意的功能设计。App会根据几个维度给订阅打风险标签：
- 高危：试用期订阅且距离下次扣费不到3天
- 中危：超过60天没有手动确认仍需要的订阅
实现思路是每条订阅详情页有个「我仍需要」按钮，点击后重置lastConfirmedDate时间戳，App拿当前日期做diff判定。共享订阅会降低风险权重（分摊了成本）。
逻辑不复杂，但实测确实管用。我自己用了两个月，砍掉了4个订阅，每月省了大概80块。
踩坑记录
1. SwiftData的@Attribute(originalName:)是救命的
我中途改过好几次字段名，如果没有这个注解做映射，用户数据就丢了。更坑的是改字段类型后migration会静默失败——不报错，数据直接清空。最后靠originalName绕过去的，目前没找到更优雅的解法。
2. 本地通知的64条限制
iOS对pending的本地通知有64条上限。如果用户订阅多且三档提醒全开（7天/3天/1天），很容易超限。我的做法是按紧急程度排序，优先注册最近的扣费提醒，超出部分下次打开App时再补注册。
3. 预设库的模糊匹配
为了降低录入成本，我内置了常见订阅服务的预设库（Netflix、Spotify、iCloud+、爱奇艺、B站大会员等）。最初匹配用的是简单的contains，结果"Apple TV+"会匹配到所有带"apple"的条目，误报太多，后来改成了加权评分才解决。
产品设计上的一点小心得
「斩」这个交互隐喻是有意为之的。停用订阅不是「删除记录」，而是「斩断一笔持续失血的开支」，停用后进入「已斩」Tab，有种完成任务的成就感。加了「已斩」计数器之后，我自己都会有冲动多砍几个——游戏化设计比预想的有效。
当前状态
App已上架App Store，搜索「订阅斩」可以找到，当前版本1.2。说实话下载量很少，独立开发最难的不是写代码，是让别人知道你做了这东西。
最后想问问同样在用SwiftData的朋友：你们遇到过改字段类型后migration静默失败的情况吗？除了@Attribute(originalName:)还有什么更好的处理方式？欢迎评论区交流。