1. 为什么“仿探探”才是学 Swift 最该做的项目1.1 待办事项教程和真实开发之间隔着一道巨大的沟写 Swift/iOS 的教程很多但有个尴尬的事实市面上绝大多数入门书和视频讲的都是“做一个待办事项 APP”或者“做一个记账本”。待办事项 APP 的问题在于技术点太简单了你学会的只是 Swift 语法和几个控件一碰到真实项目的复杂交互、复杂状态、网络请求、数据同步就抓瞎。仿探探这个项目之所以好是因为它几乎把 iOS 开发的核心难点全部覆盖了自定义视图、手势识别、拖动动画、分页列表、网络请求、异步刷新、用户匹配逻辑、甚至推送和性能优化。你把这一套完整做下来能力是实实在在能迁移到任何 App 开发上的。另外探探这种卡片流交互在今天的 App 里几乎是一等公民。抖音的上下滑、电商的信息流、社交软件的推荐列表本质都是同类交互模式。学会做一个卡片滑动器就等于掌握了今天主流 App 的交互骨架。这类交互最核心的价值在于它让用户在海量内容里用“极低成本”做决策——左滑右滑的轻重反馈效率远高于传统的列表点赞。你在学习这个项目时写的每一行手势代码都是在为以后做任何内容型产品打地基。1.2 这门课真正适合的三类人我先说结论这门课不是只给零基础新手的它是一条从入门到进阶的完整路线。第一类是纯新手完全没写过代码只是想学一门正规的移动开发技能。我建议你先花一两天把 Swift 基础语法过一遍再进入 UI 部分基本不会卡住。教程里我会尽量把每一步的原理讲清楚让你不是“照着敲”而是“理解后再敲”。第二类是已经会一点其他语言比如 JavaScript、Java、Python想转行 iOS 开发的。这类人学起来最快因为逻辑思维是通用的只是语言和平台 API 不一样。你要重点掌握的是 Swift 的语法习惯和 iOS 的页面生命周期大概一周就能进入状态。第三类是已经能写基本 iOS 页面、但从未完整做过一个“有后端、有缓存、有异常处理、有上架流程”的完整 App 的开发者。这个项目会把你从“会写页面”带到“能独立做完整产品”的层次。因为探探这种项目涉及的不只是 UI而是从网络层、数据层到交互层、发布层的全链路补的正是你以前可能忽略的短板。1.3 先定技术栈SwiftUI 为主、UIKit 为辅、URLSession 打底在正式写代码前先把技术方案定了。Swift 版本我建议用最新的稳定版 Swift 5.9 以上Xcode 15 以上iOS 最低支持版本定为 iOS 16。为什么不全平台支持更老的系统因为新项目没必要背着老系统的包袱iOS 16 以上才支持比较完善的 SwiftUI 新特性你没有必要为了照顾 1% 的旧设备增加开发成本。UI 方面我的选择是 SwiftUI 为主个别复杂交互用 UIViewRepresentable 桥接 UIKit。说白了就是 SwiftUI 处理 90% 的常规页面碰到手势冲突、复杂滚动容器时抠个 UIKit 控件出来用。这是现在 iOS 开发的常规做法比“纯 SwiftUI”和“纯 UIKit”都要省心。数据层用两部分网络层用 URLSession 做封装本地缓存用 UserDefaults 或 CoreData。为什么不直接用 Alamofire不是它不好而是学习阶段我更倾向于让你把系统底层的 API 吃透。你把 URLSession 封装过一遍之后Alamofire 对你来说就是一个可以随时替换的工具而不是一个黑盒。核心组件整体划分如下SwiftUI页面结构、状态管理、动画Combine处理异步数据流URLSession网络请求UserDefaults / CoreData本地存取Mock 数据源 / 轻量后端用户匹配数据2. 环境准备与 Swift 语法极速通关2.1 Xcode 装好之后先处理这三个细节Xcode 的安装很简单App Store 直接搜 Xcode 下载但要注意磁盘空间Xcode 全家桶加模拟器系统差不多要 30GB。装完之后用命令行工具检测一下xcode-select --install xcodebuild -version如果命令行找不到 Xcode 的 SDK 路径执行sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer创建项目的时候选择 iOS App 模板Interface 选择 SwiftUILanguage 选择 Swift。这里有个小坑包名Bundle Identifier一定要想好它会在后面上架时变成你的 App 唯一标识后期改很麻烦。建议用类似com.yourname.cardapp的格式不要用中文也不要用默认的乱码。模拟器配置有一个点值得提一下iOS 16 之后真机调试必须在设置里开启开发者模式模拟器不需要。新手第一步最容易卡在“真机跑不了”多半就是没开这个开关。路径是设置——隐私与安全性——开发者模式打开之后重启手机即可。这个开关的逻辑跟 Android 的“开发者选项”有点像但苹果管得更严默认是关着的。2.2 Swift 核心语法速查表与两个重点概念如果你有编程经验Swift 的语法一天就能掌握核心。我把最重要的部分浓缩成一张速查表语法点示例说明变量与常量var count 0let max 10let不可变var可变可选型var name: String?可能为 nil需要解包数组字典var arr: [Int]var dict: [String: Int]泛型容器结构体struct User { let id: Int }值类型用得多类class UserManager {}引用类型带继承闭包{ (param) in return ... }函数是一等公民枚举enum MatchState { case none }类型安全的枚举异步async / await现代写法比回调舒服这里重点给大家解释两个最容易混淆的概念。第一个是结构体struct和类class的区别。结构体是值类型赋值时会复制一份完整的值类是引用类型赋值只是多了个指向同一内存的引用。在 SwiftUI 里几乎所有 Model 都用 struct因为值语义让状态管理变得可预测不会出现多个页面偷偷改了同一份数据的问题。打个比方struct 像身份证复印件复印多少份都是独立的class 像门禁卡大家拿的是同一张卡一个人刷了门别人手里的卡权限也变了。第二个是可选型。Swift 里任何类型后面加个问号就变成可选型意思是“这个变量有可能不存在”。这其实是 Swift 最优秀的特性之一——它强迫你在编译时就处理“数据不存在”的情况而不是等到运行时崩溃。比如用户头像 URL 可能是空字符串那么avatarURL: String?就比avatarURL: String安全得多。刚开始接触可选型会觉得麻烦但用久了你会发现它替你挡掉了不知道多少因空值导致的崩溃。2.3 SwiftUI 和 UIKit 到底怎么选什么时候用 UIKit新手最爱纠结一个问题SwiftUI 和 UIKit 到底学哪个我的答案很直接以 SwiftUI 为主但必须会 UIKit。SwiftUI 是苹果主推的未来方向写起来快状态管理优雅代码量至少比 UIKit 少一半。但只要你的 App 稍微复杂一点必然会碰到 SwiftUI 搞不定的地方比如某些复杂的滚动嵌套、地图控件、相机手写交互SwiftUI 底层还是要通过 UIViewRepresentable 桥接到 UIKit。我实际项目里有一个典型的例子做卡片堆叠效果的时候SwiftUI 的.gesture和.offset组合起来处理拖动是够用的但一旦要处理“多个卡片同时响应手势”和“松手后的回弹物理动画”纯 SwiftUI 会比较别扭。这时候你把底层那张卡片包成一个 UIViewRepresentable用 UIPanGestureRecognizer 去处理拖动就会流畅得多。判断标准很简单80% 用 SwiftUI20% 用 UIKit哪个写着顺手用哪个不要有洁癖。你不需要在“用 SwiftUI 手写一个无限循环滚动列表”这种事情上死磕换成 UIKit 的 UICollectionView 十分钟就搞定了。3. 探探核心 UI 的完整实现3.1 页面模块拆解探探的 App 结构大概分成 5 个模块推荐页核心的卡片滑动区、匹配成功弹层、消息列表、个人中心、登录模块。我们的教学项目用 TabView 搭一个三 Tab 结构就够了推荐、消息、我的。登录模块前期可以做一个模拟登录页面后期接后端时再替换。在开始写代码前脑子里先过一遍数据流推荐页从网络或者本地 Mock 源拿一批用户数据展示成卡片用户点击喜欢按钮把这条数据标记为“我喜欢”如果对方也喜欢你匹配成功弹层出现同时这条数据进入消息列表。整个流程里的关键在于状态管理——哪些用户已经滑过了、哪些匹配成功了、消息列表怎么更新这些状态如果管理不好代码会越写越乱。我在项目里通常用一个UserStore作为全局状态中枢它负责维护所有用户数据、匹配状态和消息列表。UI 层只跟这个 Store 交互不直接改数据这样逻辑就清晰了。3.2 卡片视图与滑动手势这是整个项目最精彩的部分我详细说一下。首先定义一个 CardView代表一张用户展示卡。其中包括头像、昵称、年龄、距离和一句个人简介。用 SwiftUI 写出来大概是这样的struct CardView: View { let user: UserProfile var body: some View { VStack(alignment: .leading) { AsyncImage(url: URL(string: user.avatarURL)) { image in image.resizable().scaledToFill() } placeholder: { Color.gray } .frame(width: 340, height: 420) .clipped() VStack(alignment: .leading, spacing: 8) { Text(\(user.name), \(user.age)) .font(.title2.bold()) Text(user.distance) .font(.subheadline) .foregroundColor(.secondary) Text(user.bio) .font(.body) .lineLimit(3) } .padding() } .background(Color.white) .clipShape(RoundedRectangle(cornerRadius: 16)) .shadow(radius: 8) } }这里有几个实战细节AsyncImage 是 iOS 15 以后的异步图片加载组件挺好用但它在列表里滚动时会有闪烁问题。如果图片量大建议改用 Nuke 或 SDWebImage 这类第三方库。框架自带的组件总有几个不好用的地方这很正常选型时不要迷信“官方原生”。接下来是核心的滑动手势。State private var offset CGSize.zero var body: some View { CardView(user: users[0]) .offset(offset) .rotationEffect(.degrees(Double(offset.width / 20))) .gesture( DragGesture() .onChanged { value in offset value.translation } .onEnded { value in if abs(value.translation.width) 120 { withAnimation(.spring()) { offset CGSize( width: value.translation.width * 2, height: value.translation.height * 2 ) } removeTopCard(slided: value.translation.width 0) } else { withAnimation(.spring()) { offset .zero } } } ) }这段代码的核心逻辑是拖动时实时更新 offset 让卡片跟随手指移动旋转角度按拖动的水平位移折算当水平位移超过 120pt 时判定为有效滑动否则松手回弹。rotationEffect 这一行很多人会问为什么要除以 20因为我希望让卡片转动角度比较小看起来像真实桌面上翻牌的感觉。120pt 的位移对应 6 度的旋转比较自然。这个数值是经验调出来的你可以自己改成 15 或者 25 试试会发现手感完全不一样。这个就是“调参”的乐趣。removeTopCard 方法负责把当前卡片移出数组显示下一张func removeTopCard(slided: Bool) { if slided { likedUsers.append(users[0]) } users.removeFirst() offset .zero }这里要注意的是滑动方向我用的是value.translation.width 0也就是用户往右滑代表喜欢往左滑代表跳过。这是国内外所有这类 App 的统一设计语言几乎不需要用户学习成本。3.3 层叠卡片与 ZStack 的正确用法真实探探是能看见当前卡片下面还有一两张卡片的。这个用 ZStack 实现非常简单ZStack { if users.count 1 { CardView(user: users[1]) .scaleEffect(0.95) .offset(y: 8) } if users.count 0 { CardView(user: users[0]) .offset(offset) .rotationEffect(.degrees(Double(offset.width / 20))) .gesture( DragGesture() .onChanged { value in offset value.translation } .onEnded { value in // 同上面的判断逻辑 } ) } }第二张卡片固定缩小 5%往下偏移 8pt形成层叠效果。等第一张被滑走后第二张自动变成新的第一张ZStack 层级会自动重排。这里我要多说一句关于动画经验的体会。层叠卡片比较自然的效果是第一张卡片在拖动时第二张卡片应该有一个跟随放大的动画。这个可以用 SwiftUI 的动画绑定来实现第二张卡片的 scaleEffect 值从0.95到1.0和第一张 offset 的绝对值形成联动。你可以在 onChanged 里计算let progress min(abs(offset.width) / 300, 1)然后给第二张卡scaleEffect(0.95 progress * 0.05)。这个小细节能让整个 UI 瞬间生动不少很多教程不会写。3.4 按钮触发滑动的动画技巧除了拖动手势探探还支持点击按钮直接点赞或者跳过。实现方式很巧妙只要把目标位移设成屏幕宽度加一点让卡片飞出屏幕就行了func swipeAnimation(_ isLike: Bool) { withAnimation(.spring(response: 0.5, dampingFraction: 0.7)) { offset CGSize(width: isLike ? 500 : -500, height: 0) } DispatchQueue.main.asyncAfter(deadline: .now() 0.3) { removeTopCard(slided: isLike) } }要注意的是动画结束后要延迟一点再移除卡片否则会在半空中被拿掉视觉上看起来很突兀。我最初写的时候没有加延迟卡片直接原地消失体验很奇怪。后来加了 0.3 秒的延迟让卡片彻底飞出屏幕再移除就自然多了。这个 0.3 秒的数值也不是随便写的。spring 动画的时长通常在 0.4 到 0.6 秒之间我取 0.3 秒是因为卡片位移 500pt 已经超出了屏幕边界用户其实看不到了所以不需要等动画完全跑完就可以把卡片从数据源里移除这样下一张卡片可以更早出现整体节奏更紧凑。3.5 SwiftUI 状态管理实战从 State 到 Observable很多新手写 SwiftUI最头疼的就是状态管理。到底该用 State、Binding、ObservedObject 还是 EnvironmentObject我总结了一个非常实用的判断标准只在当前视图内部使用的状态用 State需要传递给子视图并让子视图能修改的用 Binding全局共享的数据比如用户数据池、登录状态用 Observable 或者 EnvironmentObject从网络层拉数据交给一个单独的 Model 层管理ViewModel 持有它在这个仿探探项目里用户数据池就是一个典型的全局共享数据我建议用 Observable 宏来管理。iOS 17 以后苹果推出了 Observable 宏比原来的 Published 更简洁性能也更好Observable final class UserStore { var users: [UserProfile] [] var likedUsers: [UserProfile] [] var matchedUsers: [UserProfile] [] }在视图中用 State 持有它struct ContentView: View { State private var store UserStore() var body: some View { TabView { RecommendationView() .environment(store) MessageListView() .environment(store) ProfileView() .environment(store) } } }这样做的好处是任何一个子视图通过.environment(store)拿到的是同一个实例改了一处数据所有依赖它的视图都会自动刷新。这就是响应式编程的核心。4. 网络层、数据层与匹配逻辑4.1 URLSession GET 请求的完整封装市面上的课程经常一上来就推荐 Alamofire我觉得作为学习项目先自己用 URLSession 封装一遍更好。原因很简单Alamofire 只是一个封装底层依然是 URLSession你把底层摸透了以后用任何网络库都能秒上手面试的时候也不至于一问三不知。现代 Swift 推荐用 async/await 写网络请求简单清晰struct APIClient { static let shared APIClient() private let baseURL https://api.example.com func fetchUsers(page: Int) async throws - [UserProfile] { var components URLComponents(string: baseURL /users)! components.queryItems [ URLQueryItem(name: page, value: String(page)), URLQueryItem(name: limit, value: 20) ] var request URLRequest(url: components.url!) request.httpMethod GET request.setValue(application/json, forHTTPHeaderField: Accept) let (data, response) try await URLSession.shared.data(for: request) guard let httpResponse response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { throw APIError.badResponse } return try JSONDecoder().decode([UserProfile].self, from: data) } }URLComponents 的那段代码新手容易忽略但它是构建带参 URL 的标准姿势。直接用字符串拼接 URL 最大的坑是参数里有中文或特殊字符时会直接崩溃URLComponents 会帮你做百分比编码稳得多。比如用户搜索关键词是“摄影 旅行”如果直接拼进 URL 就会产生非法字符URLComponents 会自动转成%E6%91%84%E5%BD%B1这种编码形式。JSON 解码这部分Swift 的 Codable 协议很强大但要注意字段映射。如果后端给你的字段是user_name而你的模型是userName需要做一下映射struct UserProfile: Codable, Identifiable { let id: Int let name: String let age: Int let avatarURL: String let distance: String let bio: String private enum CodingKeys: String, CodingKey { case id, name, age case avatarURL avatar_url case distance, bio } }这里我要重点说一个错误处理的心得。很多人写网络层只处理“成功”和“失败”两种状态这是不够的。一个健壮的网络层至少要区分请求超时、服务器返回 4xx客户端错误、服务器返回 5xx服务端错误、网络断开、JSON 解析失败。这五种情况用户的处理方式完全不同。我用一个枚举来定义enum APIError: LocalizedError { case invalidResponse case badRequest case serverError case decodingFailed case networkUnavailable var errorDescription: String? { switch self { case .invalidResponse: return 服务器响应异常 case .badRequest: return 请求参数有误 case .serverError: return 服务器开小差了请稍后重试 case .decodingFailed: return 数据解析失败 case .networkUnavailable: return 网络连接断开请检查网络 } } }把这些错误信息直接展示在 UI 上用户就能很清楚地知道发生了什么而不是一个干巴巴的“网络错误”。这个设计细节既提升用户体验也提升你代码的可维护性。4.2 POST 请求与字段映射点赞、滑过、举报这些行为都是 POST 请求。这类请求需要 body注意 HTTPBody 要转成 JSON Datafunc likeUser(userID: Int) async throws { var request URLRequest(url: URL(string: baseURL /like)!) request.httpMethod POST request.setValue(application/json, forHTTPHeaderField: Content-Type) let body [user_id: userID] request.httpBody try JSONSerialization.data(withJSONObject: body) let (_, response) try await URLSession.shared.data(for: request) guard let httpResponse response as? HTTPURLResponse, httpResponse.statusCode 200 else { throw APIError.serverError } }一个很容易被忽视的细节Content-Type一定要设置成application/json否则后端的 Spring 或者其他框架解析 body 时可能直接报错。类似的任何 POST 请求都要想想“服务端到底需要什么格式”——是 JSON 还是 form 表单这个小点对过不过后端联调起着决定作用。还有一个实战经验POST 请求尽量把用户操作做成“幂等”。也就是说同一个请求发送两次不会产生两条重复数据。比如用户狂点喜欢按钮如果没有幂等保护后端可能收到 10 个完全相同的请求。推荐的做法是客户端在点赞后立刻在本地把该用户标记为“已处理”同一用户不可重复提交服务端也要做去重。4.3 打造一个会“预加载”的用户数据池在实际开发中你不可能翻一页就请求一次网络太慢了。常规做法是本地维护一个用户池每次请求 20 条滑完一批再请求下一批。我自己的做法是写一个UserStore的 ObservableObjectMainActor final class UserStore: ObservableObject { Published var users: [UserProfile] [] Published var likedUsers: [UserProfile] [] private var currentPage 0 func loadMoreIfNeeded() { guard users.count 10 else { return } Task { do { let newUsers try await APIClient.shared.fetchUsers(page: currentPage 1) users.append(contentsOf: newUsers) currentPage 1 } catch { // 失败时保持旧数据显示重试按钮 } } } }用Published标记的数据SwiftUI 会自动监听数据一变页面就刷新这就是响应式编程的核心。这里的guard users.count 10是一个简单的预加载判断当剩余卡片少于 10 张时提前加载下一批让用户体验保持在流畅的状态。关于 MainActor 这里我多说一句。标记了 MainActor 的类所有属性和方法都在主线程执行。为什么这样做因为你看到的 Published 属性最终是要更新 UI 的必须在主线程操作。如果不加 MainActor网络请求完成后还要手动 dispatch 到主线程。加了之后Swift 编译器会在你从后台线程调用时自动提醒甚至报错帮你规避掉大量线程问题。4.4 匹配成功逻辑与通知弹层真实产品的匹配逻辑在后端实现两个用户互相点赞就产生匹配。教学项目没有后端我在本地做一个模拟匹配用户 A 赞了用户 B如果用户 B 的“匹配率”超过某阈值比如 70%就算匹配成功。func checkMatch(user: UserProfile) - Bool { let matchRate user.compatibilityRate ?? Double.random(in: 0...1) return matchRate 0.7 }匹配成功后弹一个庆祝视图同时把匹配到的用户加到会话列表里。在实际 App 里这一步是通过 WebSocket 或者长轮询从服务器收到“对方也赞了你”的消息。弹层的实现我建议用.sheet或者自定义的 overlay。为了做出“两颗心碰撞”的动画效果我用了两种动画叠加一是缩放抖动动画二是背景遮罩渐入。核心代码如下.overlay { if showMatch { MatchView(user: matchedUser) .transition(.scale.combined(with: .opacity)) } }用户看到匹配成功后点的第一个按钮通常是“继续滑动”此时要做一个收起动画。我习惯用withAnimation(.easeOut(duration: 0.25))让弹层整体缩小消失速度宁可慢一点点也不要突然消失那样会显得很突兀。5. 从“能跑”到“好用”性能、并发与上架5.1 卡片列表卡顿的三个优化方向卡片滑动器的性能瓶颈通常在图片加载。AsyncImage 在快速滑动时会产生大量网络请求内存暴涨。三个优化方向第一图片尺寸裁剪。服务端如果不下发缩略图客户端就请求大图然后本地裁剪这个消耗非常大。理想的方案是服务端按请求参数下发不同尺寸的图例如?width400height500。如果没有后端控制权客户端至少要压缩一次再缓存。第二图片缓存。推荐用 Nuke 或者 Kingfisher它们自带内存缓存和磁盘缓存第一次加载后第二次直接读缓存滑动就顺多了。我实测过没有缓存时快速滑动 20 张卡片大概要 200MB 内存加了缓存之后稳定在 80MB 以下差距非常明显。第三控制并发网络请求。一次滑动触发多张卡的加载是很常见的用 URLSession 的httpMaximumConnectionsPerHost可以限制同一主机的连接数避免瞬间请求过多导致全部超时。5.2 Swift 并发与线程安全速成进阶内容里Swift 并发是必考题。async/await让异步代码写得跟同步一样但有一个使用误区在主线程上执行耗时操作。即使是 async 任务如果在主 Actor 上执行依然会卡 UI。正确做法是把耗时操作放到后台let data try await Task.detached { // 耗时计算在后台线程执行 return try await APIClient.shared.fetchUsers(page: 1) }.value还要注意MainActor的传播。SwiftUI 的 View 默认是在主 Actor 上运行的如果你在一个标注了 MainActor 的类里调用一个非并发安全的全局变量编译器会直接报错。这不是麻烦是保护——它让你在编译期就发现数据竞争问题。对新手来说需要记住的核心原则只有三条一是 UI 更新只在主线程二是耗时操作不要挡在主线程三是共享数据要加锁或是直接走 Swift 的 Actor 机制。这三条做到90% 的并发问题都不会找上你。在实际项目中我见过太多新手自己写的数据竞争 bug——两个线程同时修改同一个数组导致崩溃或者数据错乱都是因为没用对并发模型。5.3 上架 App Store 全流程与审核避坑上架这事第一次做会踩无数坑。流程我给你捋一遍第一步在 Apple Developer 网站注册开发者账号个人账号 99 美元一年。这个步骤需要准备一个 D-U-N-S 编码如果是个人开发者可以跳过公司账号必须要。建议注册之后先把协议、税务、银行信息都填好不然后面上传构建的时候会卡住。第二步在 Xcode 里配置好 Bundle Identifier、版本号、构建号用 Xcode 菜单栏的 Product——Archive 打出 Release 包。第三步在 App Store Connect 里创建 App 记录填好各种描述、关键词、审核备注提交审核。审核周期一般是 24 到 48 小时也有快的时候几个小时内就能过。审核被拒的几个常见理由使用私有 API。SwiftUI 和 UIKit 公开的 API 都没问题但千万不要去调用私有框架。功能不完整或者崩溃。审核员会拿真机测任何一步崩溃都会被拒。权限描述不符合实际。比如你申请了相机权限但 App 里根本没有使用相机的功能。虚拟支付不走苹果内购。做社交 App 经常踩这个坑虚拟金币必须走 IAP。我自己的经验是上架前的最后一晚一定要用真机把核心路径完整走一遍。审核员不会像你一样爱惜产品他们会乱点、断网、疯狂切换页面你得保证在任何情况下都不崩。5.4 版权边界与商标注意事项最后说一个非常重要但经常被忽略的点可以学习“探探的交互模式”但不能直接照抄探探的 UI 素材Logo、配色方案、界面截图。苹果审核和版权方对 App 的商标、素材都很敏感。教学项目用自己设计的占位图和中性配色是安全的发布上线前建议改成完全原创的设计。配色也是一样的道理。探探的粉色是它的品牌色你在学习阶段可以随意用但如果是准备上架的正式产品建议还是用自己的品牌色系。尽量规避知识产权风险同时也能早一点建立品牌意识。6. 常见问题排查实录6.1 Xcode 常见报错速查表下面这个表格我在带项目时几乎每个新手都会遇到直接整理成速查报错信息原因解法No such module X没引入依赖或 framework确认 SPM/CocoaPods 配置Cannot find xxx in scope拼写错误或未定义检查变量名与定义Thread 1: Fatal error: Unexpectedly found nil强制解包遇到 nil检查可选型处理Build failed: CocoaPods not installed缺少 pod 命令安装 CocoaPodsProvisioning profile doesnt include device证书和描述文件不匹配重新生成描述文件The app delegate must implement the windowSceneScene 生命周期配置错误确认 Xcode 模板选择正确我最想强调的还是那个Unexpectedly found nil。新手特别喜欢用!强制解包图一时爽快结果运行时直接崩给你看。我的经验是除了IBOutlet这种系统保证非空的场景其他地方一律用if let或者guard let。刚开始可能觉得麻烦但长期来看你写出的代码会稳很多。6.2 SwiftUI 状态不刷新改完数据 UI 不动怎么办新手问得最多的问题是我改了数据为什么 UI 不刷新最常见的原因是用了普通属性而不是State/Published。SwiftUI 的刷新机制是只有被State、Published、Observable等属性包装器标记的变量发生修改时依赖它的 View 才会重新渲染。普通属性改了View 根本感知不到。第二个原因是修改了引用类型但指向没有变化。比如你有一个State var user User()你改了user.name但user本身的地址没变SwiftUI 可能不会刷新。这时候应该给User用 struct 值类型或者用Observable宏。第三个原因是修改发生在非主线程。网络请求返回后如果你在后台线程直接改了Published数组UI 不会每次都刷新甚至可能崩溃。这种问题的表现很诡异——有时刷新有时不刷新。排查思路是给修改代码加MainActor.run或者直接调用DispatchQueue.main.async。6.3 网络请求失败怎么用 Charles 抓包和排查模拟器跑起来流畅真机却卡大概率是网络和图片加载的问题。模拟器走的是 Mac 的网络真机走 Wi-Fi网络差异会导致图片在真机上加载明显变慢。真机调试时建议用 Charles 抓包看一下具体耗时环节把慢的网络请求找出来。Charles 抓包这个工具值得花时间学一下。设置好代理和 SSL 证书后你就能看到 App 发送的每一个请求、状态码、响应耗时。排查网络问题基本离不开它。我平时抓包定位问题的流程是复现问题——打开 Charles 看请求记录——对比正常请求和异常请求的差异——看是参数不对、URL 不对还是响应超时。大部分网络问题80% 都能在 Charles 里一眼看出来。比如我遇到过“App 登录后列表空白”查了半个小时最后发现是请求里少了Authorization请求头服务端返回 401但代码里没有处理 401 的逻辑直接把空数据渲染出来了。这种问题没有抓包工具真的无从下手。6.4 上架前最后一公里的自查清单我想在最后给你一份简洁但非常实用的自查清单。按这个清单过一遍能避免我踩过的大部分坑把 App 里的所有print和调试注释清理一遍真机测试核心流程登录、滑动、匹配弹层、消息列表断网测试确保有统一的错误提示不崩溃反复快速操作按钮看会不会出现重复提交检查所有权限描述文案与实际功能是否一致上传前在 App Store Connect 里补全隐私政策链接使用 TestFlight 邀请两三个朋友做一轮内测最后分享一个对我帮助很大的经验如果你做这个仿探探项目遇到某个问题卡了一下午这是正常的。我当年做卡片滑动手势手势和动画的冲突调了整整一下午最后发现是.gesture和.onTapGesture的优先级问题。这类经验只有踩过坑才能真正记住。第一次做可以跟着教程走第二遍一定要自己从零写一遍卡住再翻答案这个过程比看十遍教程都有效。做完这个项目你拿到的不仅是一个探探仿品而是一套可以迁移到任何内容型产品的完整 iOS 开发能力。