企业官网建设流程全解析

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 选择 SwiftUI，Language 选择 Swift。这里有个小坑：包名（Bundle Identifier）一定要想好，它会在后面上架时变成你的 App 唯一标识，后期改很麻烦。建议用类似com.yourname.cardapp的格式，不要用中文，也不要用默认的乱码。

模拟器配置有一个点值得提一下：iOS 16 之后，真机调试必须在设置里开启开发者模式，模拟器不需要。新手第一步最容易卡在“真机跑不了”，多半就是没开这个开关。路径是：设置——隐私与安全性——开发者模式，打开之后重启手机即可。这个开关的逻辑跟 Android 的“开发者选项”有点像，但苹果管得更严，默认是关着的。

2.2 Swift 核心语法速查表与两个重点概念

如果你有编程经验，Swift 的语法一天就能掌握核心。我把最重要的部分浓缩成一张速查表：

这里重点给大家解释两个最容易混淆的概念。

第一个是结构体（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% 用 SwiftUI，20% 用 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 Data：

func 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的 ObservableObject：

@MainActor 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 在快速滑动时会产生大量网络请求，内存暴涨。三个优化方向：

第一，图片尺寸裁剪。服务端如果不下发缩略图，客户端就请求大图然后本地裁剪，这个消耗非常大。理想的方案是服务端按请求参数下发不同尺寸的图，例如?width=400&height=500。如果没有后端控制权，客户端至少要压缩一次再缓存。

第二，图片缓存。推荐用 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 常见报错速查表

下面这个表格，我在带项目时几乎每个新手都会遇到，直接整理成速查：

我最想强调的还是那个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 开发能力。