聊聊最近帮团队做 iOS 技术岗位初筛的经历。几轮面试下来我发现 SwiftUI 的考察已经彻底从“了解层面”进入“实战层面”了——前几年问“你用没用过 SwiftUI”现在直接问“State 和 ObservedObject 的区别是什么什么时候用错会导致数据不刷新”。这套面试题整理就是基于面试官视角和被面试者视角双重复盘出来的按高频知识点分类每题都给了参考回答和核心考点。无论是准备面试、还是想系统补一遍 SwiftUI 基础都有参考价值尤其适合有 1-3 年 iOS 开发经验、正在从 UIKit 过渡到 SwiftUI 的从业者。1. 状态管理与数据流面试必问答错了基本没戏SwiftUI 面试里数据流和状态管理是开场就会聊的话题。几乎每个候选人都会被问到属性包装器之间的区别这一章基本覆盖了面试中出现频率最高的四个问题。1.1 从 State 到 Binding把小状态管明白面试官最常见的问法“你在 SwiftUI 里怎么管理一个局部状态”答案的核心是 State。这个属性包装器专门用于视图内部的、值类型的小状态比如一个弹窗的显示开关、一个输入框的文本内容。关键点在于State 的底层存储由 SwiftUI 框架接管当值发生变化时框架自动让依赖该状态的视图刷新。很多候选人忽略的细节是State 适合管理的是视图私有状态它不负责跨视图共享也不适合持有引用类型数据。一旦把一个大对象塞进 State状态更新的控制粒度就会失控。紧接着面试官一定会问“子组件要修改这个状态怎么办”这就是 Binding 的考点。Binding 本身不拥有数据它只是提供了一套“读写通道”让子视图可以修改父视图持有的 State。理解这一点特别重要Binding 的 get 和 set 背后联动的是源状态的 storage所以修改会直接反应到源头。常见的 trick 是问“子视图里用 State 重新拷贝一份行不行”——答案是不行因为拷贝出来的状态是独立的父视图的变更不会同步修改也无法回传。即便面试官不追问自己在画组件边界时也要记住这个原则子组件只管消费和回调数据真正的主人永远只有一个。补充一个考点Binding 可以配合自定义封装来拦截或调整写入值。比如限制输入长度可以在 Binding 的 set 里做截断处理再写回源状态。这种写法在面试中属于加分项体现的不只是会用而是理解读写通道的原理。1.2 StateObject 与 ObservedObject 的边界“StateObject 和 ObservedObject 有什么区别”这是我想从项目实战角度考察人时必问的一道题。很多背过定义的人能说出一句“前者负责创建后者引用外部”但问到“为什么用错会导致数据闪烁或重新初始化”就答不上来了。核心区别在于对象的所有权。StateObject 持有一个可观察对象的生命周期视图出现时创建一次视图销毁时才释放即使父视图重建只要这个视图本身没有被销毁StateObject 就不会被重新初始化。而 ObservedObject 不拥有对象它只是观察外部传入对象的属性变化。用 ObservedObject 来持有自己创建的 Model隐患在于父视图发生 body 重算时子视图可能被重新初始化导致观察对象被重建数据状态丢失。这种问题非常隐蔽常见表征是界面偶尔“闪一下”或输入框内容莫名清空。实际写代码时怎么区分我的经验是问自己一句这个数据对象是谁创建的如果是在本视图的初始化或默认值里创建的那使用 StateObject如果数据对象来自父视图、全局单例或环境注入那一律用 ObservedObject或者干脆用 EnvironmentObject。还有一个容易混淆的点ObservedObject 观察的触发依赖对象内部被 Published 标记的属性。如果属性没加 Published值变化了视图也不会重新渲染。面试时把这个说出来基本碾压背定义型选手。1.3 EnvironmentObject 与依赖注入EnvironmentObject 的考点从来不是“怎么用”而是“它的优势和风险”。优势很明确它可以在不层层传递的情况下让任意层级的视图读取同一个可观察对象。适合的东西有用户会话、主题配置、全局设置等。面试的回答逻辑通常走一条线从依赖注入讲到响应式更新再讲到环境传递。风险是更值得展开的。EnvironmentObject 一旦在环境中缺失视图在运行时直接崩溃——注意是崩溃不是报个警告。崩溃原因从控制台看是找不到 key 对应的 object很多新手上线后遇到闪退往回查才发现某个提前预览的视图没有注入环境对象。基于这种风险有几个更稳的方案值得写在简历和面试答案里一是为环境对象提供默认值比如在根视图初始化时统一注入二是使用自定义 EnvironmentKey 配合 .environment 修饰符为视图注入更加细粒度的配置项三是在 SwiftUI 新版本里用 Observable 宏清洗数据模型替代传统的 ObservableObject 组合。1.4 属性包装器底层原理与高频追问面试官一旦确认候选人熟用属性包装器往往就会往下追问一层“这些关键字底层到底是什么”这里的高频考点是“为什么给属性加一个 State修改时视图就会刷新”。往深了说State 底层把值包装到一个内部 storage 中通过 nonmutating setter 修改修改的同时向依赖图发送更新消息。Published 发布属性变化内部用到 Combine 的 Publisher 机制EnvironmentObject 则通过环境查找对应的 ObservableObject。追问里常出现的还有 AppStorage 和 SceneStorage。前者是对 UserDefaults 的包装——本质是“写入 UserDefaults 的响应式状态”后者是场景级数据存储适合 iPad 多窗口场景两者存储范围不同。有人说 AppStorage 底层是 UserDefaults这是对的但注意它和 UserDefaults 共享存储空间时值类型必须保持一致否则可能取到奇怪的结果。综合看状态管理这块的面试难度集中在“所有权”和“作用域”两个概念上。只要把谁拥有数据、谁观察数据、谁读写数据这三个问题理清了大多数相关追问都能应对。2. 布局与响应式界面嘴上说简单笔下见真章SwiftUI 的布局系统是声明式框架最直观的体现。但正因为代码写起来像搭积木很多候选人对底层逻辑反而不清楚——这恰恰是面试官喜欢挖坑的地方。2.1 容器、对齐与 Spacer为什么 HStack 会“填满”一道非常基础但高频的题“HStack 里面放了两个 Text为什么右边会出现一大块空白”原因是 HStack 默认不会“填满”父容器它只会根据自己的内容计算理想宽度。但如果在 HStack 里放了一个 SpacerSpacer 就会占用剩余空间把 Text 推到两端。很多人在项目里遇到过类似情况但说不清 Spacer 到底是“占位元件”还是“弹性空间”。深入一点说SwiftUI 的布局遵循三个步骤父视图提议尺寸、子视图确定尺寸、父视图按对齐方式摆放子视图。HStack 和 VStack 会根据子视图的内容自适应大小如果希望某个方向的容器填满可用宽度可以显式添加 frame(maxWidth: .infinity) 或调整容器自身的布局优先级。围绕这个布局原理面试官还会问 LayoutPriority。给一个视图设置更高的布局优先级意味着当空间不足时它优先获得空间其他视图则被压缩甚至裁剪。比如登录页面上一行放了标题和按钮屏幕宽度小的时候按钮被挤出屏幕外这时候给按钮加 .layoutPriority(1) 就能保住按钮不被压缩。2.2 GeometryReader 是“空间查询器”不是万能布局工具GeometryReader 是个高频考点也是很多人用错的点。它的作用是拿到父视图为它提供的尺寸和位置信息这些信息放到 closure 里的 GeometryProxy 中。最典型场景是构建随容器宽度变化的自适应布局比如根据宽度决定展示一行还是两行。但注意GeometryReader 的行为和 HStack 这类容器完全不同。它会尽量占据父视图提供的全部空间而不是根据内容自适应。这导致把它包在小容器里时尺寸会突然撑大初学者经常一脸懵。理解了这个特性就能解释为什么在 List 行内直接用 GeometryReader 会撑满整行。另一个高频追问是 GeometryReader 里 CoordinateSpace 的用法。用 GeometryReader 获取某个视图相对于全局坐标、父视图坐标或自定义坐标系的 frame常用于做滚动偏移动画、悬浮按钮等。这个点能答出 .global、.local 和自定义 coordinateSpace 命名这三类基本就过关了。我个人的建议是能用常规容器解决的布局不要上 GeometryReader因为它会让 body 的重新计算范围变大对性能有一点影响。善用它但别滥用它。2.3 ViewThatFits 与自适应布局iOS 16 引入的 ViewThatFits 是近几年 SwiftUI 布局里比较受关注的新 API也是一个典型的面试加分题。考察方向是“如何在做多尺寸适配时减少条件判断代码”。回答思路是ViewThatFits 会按顺序尝试多个候选视图选择第一个能够适应当前可用空间的视图。它替代了以前用“GeometryReader if 宽度判断”写切换逻辑的笨办法。举个例子做一个辅助说明文案区域小屏显示精简版大屏显示完整版。写法大概是ViewThatFits { Text(完整的长文本说明这里有很多内容需要完整展示……) Text(精简说明) }ViewThatFits 的候选规则是“第一个放得下的”所以完整版放不下时自动回退到精简版。这个 API 结合 AnyLayout 和自定义 Layout 协议可以构建真正响应式的界面回答时可以从这三个层面展开展示自己对新版本特性的关注度。老项目里还在用 iOS 15 以下系统的话这个 API 就用不了需要回退到 GeometryReader 手动判断这也是扩展回答时的一个好话题。2.4 Lazy 容器与列表性能陷阱面试题里常出现这类问题“长列表用 VStack 还是 LazyVStack有什么区别”VStack 是一次性创建所有子视图无论可见不可见。LazyVStack 是按需创建滚动范围内可见的视图。对于超大列表用 VStack 会导致一次性计算所有 cell 的布局滚动起来卡顿明显。更常见的坑藏在 LazyVStack 和 List 的选择里。List 是 SwiftUI 封装的原生列表容器它内部做了更多优化比如滚动复用、编辑支持、滑动删除等而 ScrollView LazyVStack 只是“能滚动的懒加载栈”没有系统级复用。要求实现分组、侧滑操作这类功能时直接上 List 通常更合适。不过 List 的视图构建方式对自定义布局有诸多限制有时候反而 ScrollView 更灵活。说到列表还有一个高频考点是 ForEach 的 id。ForEach 要求数据类型是 Identifiable 或者显式传入 id 路径。id 的作用是让 SwiftUI 追踪视图的身份从而在数据变化时准确 diff 出哪个视图需要更新、移动、删除。如果用了不稳定的 id比如数组 index列表更新时会出现 UI 错乱、动画异常。这个问题在面试中被反复问起因为它直接关系到列表的稳定性和性能。3. 生命周期与异步任务SwiftUI 里没有 viewDidLoad生命周期问题最能暴露候选人对 SwiftUI 框架模型的理解深度。很多 UIKit 出身的人带着旧思维来写第一步就错了。3.1 onAppear、onDisappear 与任务启动时机SwiftUI 没有 viewDidLoad这是一个经常拿来开场的判断题。视图的加载和出现不是同一个概念在 SwiftUI 中通常使用 onAppear 来感知“视图即将出现在界面中”使用 onDisappear 感知“视图即将退出界面”。这里容易踩的坑是onAppear 不一定只在初次创建时调用。当视图从导航栈返回、tab 切换回来时它也可能再次触发。所以不能把一次性初始化逻辑盲目塞进 onAppear否则会出现重复执行。替代方案是配合 State 记录是否已经执行过或者把初始化动作放到 init 或 task 里。还有一点onAppear 的触发时机是“视图被插入到视图树”即使在屏幕外但被保留在层级中也可能触发。复杂场景下光靠 onAppear/onDisappear 不足以准确判断“用户真正看到了什么”要结合 scenePhase 一起处理前后台切换逻辑。3.2 task 修饰符与异步任务管理task 修饰符是 iOS 15 引入的重点 API也是面试里和 Swift 并发结合最紧密的题目。常见问法“在 SwiftUI 里怎么发起网络请求”“视图消失后任务还在跑怎么解决”官方推荐的写法是.task { await fetchData() }task 的生命周期和视图绑定视图出现时自动启动任务视图消失时 SwiftUI 自动尝试取消任务。前提是任务内部使用了支持协作取消的 API比如 URLSession 的 async 方法。如果内部调用的是同步阻塞方法或没有监听取消信号的任务取消并不会真正中断执行。一些面试官会追问 “task 和 onAppear 里调用 Task {} 的区别”。核心区别在于结构化并发。.task 修饰符创建的异步任务与视图生命周期关联并遵循结构化取消语义用 Task {} 手动创建的异步任务是“游离”的需要自己管理生命周期。从代码维护和内存安全角度看能用 task 尽量用 task。3.3 MainActor 与主线程更新SwiftUI 的 UI 更新必须发生在主线程这本身没有争议。真正有争议的是“怎么保证代码一定在主线程执行”。SwiftUI 视图本身默认被视为 MainActor 运行所以直接在 body 里修改 UI 状态没问题。但 ViewModel 层和网络层未必在主线程。使用 Published 属性时如果在后台线程给属性赋值在开启 Swift 并发检查后会触发编译警告或运行时检测问题。这是因为 ObservableObject 的 objectWillChange 需要保证在主线程发出更新否则视图更新不一致。解决办法是给 ViewModel 的类标注 MainActor。这样类的所有属性和方法都默认在主线程执行网络层结果回来后在主线程更新状态。还有一种常规写法是使用 MainActor.assumeIsolated 或 Task { MainActor in ... } 来切换上下文。面试中对这个细节有清晰认知通常能获得不错的评价。3.4 状态恢复与 SceneStorage关于生命周期还常被提到的是状态保存和恢复。iPad 分屏、后台被杀、iOS 的场景重建都会影响 SwiftUI 应用。SceneStorage 就是针对场景状态保存的轻量方案。和 AppStorage 不同SceneStorage 只作用于当前场景同一个应用在分屏时会有多个独立场景各自拥有独立的存储空间。适合保存每个窗口独立的页面位置、导航状态等。但要记住它是类似 UserDefaults 的轻量存储不适合保存大数据量或者敏感数据。回答状态恢复问题时可以结合场景委托中的 scenePhase 变化做状态保存配合 SceneStorage 在视图重新出现时恢复。这个组合回答在高级岗位面试里很具说服力。4. 动画与交互反馈加分题都在这里动画部分在面试里不是必考但一旦考到能区分出谁只是“会用动画 API”、谁真正理解“动画背后的机制”。4.1 withAnimation 与事务机制先梳理基础的隐式动画用 .animation 修饰符显式动画用 withAnimation 包裹状态变更。面试题常见的考察是“为什么 withAnimation 里的状态变化带动画外面就不带动画”——因为 withAnimation 会为状态变更关联一个事务Transaction事务里带上了动画参数。更进阶的追问是 Transaction 的自定义。用 withTransaction 可以修改动画参数之外的内容比如关闭某个动画、改变动画持续时间。另一个容易忽略的点是withAnimation 只影响被修改状态所关联的视图更新不保证一定触发动画。如果视图层没有变化动画自然不执行如果状态变化没有引起依赖视图重建动画同样无效。动画面试题答到这里基本能自圆其说了。如果再被问到“如何让动画可交互打断”答案方向是使用插值型动画或手势联动控制进度比如 DragGesture 里根据拖动比例设置动画进度而不是简单套用 timing 函数。4.2 matchedGeometryEffect 的玩法与坑matchedGeometryEffect 是动画高频题里最有含金量的一个。原理是让两个视图共享同一个几何标识SwiftUI 自动为它们的位置和尺寸变化创建过渡动画效果是元素在视图间“平滑变形”。经典使用场景是列表卡片点击后展开为详情页Tab 切换时图标从一个位置飞到另一个位置购物车加入商品时的飞入动画。核心参数有两个id 和 namespace。namespace 用 Namespace 声明给不同来源的视图标记同一个 idSwiftUI 就能在前后两个视图层级变化时计算对应的几何差异并生成动画。坑也很真实如果两个相关视图没有同时存在于视图树中比如列表项消失、详情页才出现动画可能失效。解决思路是让源视图和目标视图在 transition 期间同时存在于层级中比如用 ZStack 叠放。另一个常见问题是地图控件、摄像头预览这类不支持原生插值的视图matchedGeometryEffect 只能做位置缩放内容本身并不会“平滑变形”。4.3 给动画选择合适的“值”面试时还有一个高频考察点SwiftUI 中并不是所有属性都可以直接做动画插值。比如颜色是可以插值的透明度和位移也可以但有条件计算的属性或者自定义 View 的非动画参数SwiftUI 可能会直接跳变。怎么把“值变化”变成“可动画变化”通常用 Animatable 协议或者对 AnimatablePair 做自定义插值。这个进阶概念出现的频率不算高但一旦出现基本都是高级岗位。我实际项目里用得最多的反而是简化优先使用系统提供的 spring、easeInOut避免过度自定义曲线导致动画之间不协调。要引入弹性效果时重点调 spring 的响应度和阻尼比而不是套一个固定 duration。5. 与 UIKit 共存每个真实项目都逃不掉虽然越来越多新项目用 SwiftUI 起步但现实是大量成熟项目仍是 UIKit 为主、SwiftUI 为局部模块。桥接是必修课面试自然也爱考。5.1 UIViewRepresentable 桥接三步走题目很直接“怎么把一个 UIKit 控件放到 SwiftUI 里”标准回答是使用 UIViewRepresentable需要实现两个核心方法makeUIView 负责创建并初始化控件updateUIView 负责在 SwiftUI 状态变化时同步数据到 UIKit 控件。考细节时面试官会追问makeUIView 什么时候调用答案是仅当 SwiftUI 需要创建对应 UIKit 视图时调用一次。updateUIView 则会在每次依赖状态变化时调用所以不要在这里做控件初始化只做数据同步。另外要注意如果控件的某个属性和 UIKit 代理回调互相联动更新属性时还要避免陷入“更新-回调-再更新”的循环。UIKit 控件持有权也常被问。SwiftUI 视图是值类型而 UIViewRepresentable 包装的是引用类型所以底层桥接需要借助 Coordinator 或者让 makeUIView 创建真实视图并让 SwiftUI 持有引用。这里必须保持引用的一致性否则可能出现“SwiftUI 拿到的是旧视图”这类诡异情况。5.2 CoordinatorUIKit 代理到 SwiftUI 的桥很多 UIKit 交互都需要代理回调比如 UIScrollViewDelegate、UITextFieldDelegate。SwiftUI 里怎么接收这些事件答案就是 Coordinator。Coordinator 是 UIViewRepresentable 内部的一个类通常用 objc 方法或 delegate 方法接收 UIKit 事件然后通过绑定把数据反应到 SwiftUI 状态。makeCoordinator 方法创建它然后在 makeUIView 中把 coordinator 赋值给 UIKit 控件的 delegate。一个常见追问是“Coordinator 的生命周期由谁管理”。Coordinator 的生命周期和 UIViewRepresentable 实例绑定由 SwiftUI 管理。因此不要在 Coordinator 里持有循环引用的强引用也不要在 execute 里保存过长的临时状态。典型写法是 Coordinator 持有 Binding而 Binding 再映射回父视图状态。这个题目答好了说明候选人有实际桥接经验因为只有真正处理过代理回调的人才知道 Coordinator 的作用不是“存放业务逻辑”而是“转换事件通道”。5.3 桥接时容易踩的内存与更新坑桥接部分的面试题通常不只是“会写”还包括“坑怎么避”。最常考的是循环引用。如果 UIViewRepresentable 的 makeUIView 里让 UIKit 控件持有 Coordinator 强引用而 Coordinator 又持有视图强引用容易形成循环。标准解法是让 Coordinator 对视图或 Binding 的持有保持弱引用或者通过闭包回调向上层传递。另一个问题是布局尺寸。UIKit 控件内部往往有内容尺寸intrinsicContentSize桥接后 SwiftUI 计算布局时不一定能正确读取它。遇到布局异常时优先检查是桥接后有自定义约束冲突还是 intrinsicContentSize 没正确返回。内存问题的最后一个高发点是 updateUIView 频繁调用导致资源重复创建。处理思路是使用 Diffing 思路只有数据真的变化时才更新 UIKit 控件而不是每个更新周期都重建子视图。6. 架构设计与性能优化拉开差距的关键最后这部分是高级岗位和普通岗位的分水岭。基础题大家都能答上来但“把 SwiftUI 写出高性能、可维护的架构”才是真正拉开差距的地方。6.1 MVVM 在 SwiftUI 中的正确打开方式SwiftUI 天然适合做 MVVM这一点几乎所有候选人都能说出来。但往深里问“ViewModel 里放什么View 里放什么Model 放哪里”很多人就开始含糊了。我的理解是View 的职责是描述 UI它不持有业务逻辑ViewModel 负责把业务状态转换为视图可以直接渲染的状态Model 是纯数据层与 UI 无关。在 SwiftUI 里ViewModel 通常是一个 ObservableObject 或使用了新观察框架的类View 通过 StateObject 或环境持有它。这里有个面试要准备的点MVVM 中数据流是“单向”的。View 不能直接改 Model而是调 ViewModel 的方法ViewModel 更新自己的可观察属性View 再基于新状态刷新。单向数据流的优点是可以快速定位数据变化的源头也方便做单元测试。新的 Observable 宏是近期的加分项。相比 ObservableObject 配合 PublishedObservable 用宏自动生成观察逻辑代码更简洁性能也更好但它要求 iOS 17 以上的系统版本。面试时主动提这个通常能展示对新技术方向的敏感度。6.2 减少 body 计算的几种手段性能优化在面试里越来越常被考察。问题常以这种形式出现“列表滚动卡顿怎么定位和解决”首先明确 SwiftUI 的性能模型View 是一个轻量结构体body 是一个计算属性。系统需要渲染时会调用 body 来计算新的视图树然后和旧视图树做 diff。body 计算次数越少、单次计算越轻界面就越流畅。几种常用手段拆分视图把大视图拆成小视图减少单次 body 计算的范围。子视图的局部状态变化不会引起父视图整体刷新。精准控制状态范围不要把不相关的数据放到同一个 ObservableObject 里。一个对象的任何 Published 属性变化都会通知所有观察者粒度太粗会导致无关视图一起刷新。用 EquatableView 或自定义 Equatable 降低 diff 成本当视图内容没有实际变化时避免重复计算。避免在 body 里做重计算比如直接对数组做 filter、排序最好在 ViewModel 中提前计算降低视图渲染路径的负担。正确使用常量把不变的内容定义成常量减少可变状态的引用范围。面试题里经常问 ViewBuilder 是不是影响性能。其实 ViewBuilder 只是结果构建器编译期生成的是构建视图树的代码它本身不直接造成运行时性能问题。性能瓶颈通常来自不合理的状态设计和过大的视图计算范围。6.3 列表性能与 diffing 的深入理解列表是 SwiftUI 应用最常见的场景也是性能问题高发区。常见问题有“为什么 LazyVStack 里几百行数据滑动还是卡”“为什么给行视图加动画会闪”。这些问题的回答都指向 diffing 机制。SwiftUI 通过视图的结构和 id 来识别视图身份。在使用 ForEach 时id 的稳定性非常关键使用 index 做 id 只是临时方案当数据排序或删除时视图的重用逻辑会错乱动画和状态都会出问题。正确做法是用数据的唯一标识比如数据库主键。列表行内做了复杂布局时也要注意行视图的“体重”。尽量把固定不变的内容放到视图外行内只保留依赖状态的部分。需要做大量计算的行可以把计算结果放到 ViewModel 里预计算。面试中如果能主动提到 Instruments 里的 SwiftUI 模板比如查看 body 计算次数、视图更新范围会是很好的加分点。说明你不是只会写界面而是会用工具去定位性能瓶颈。面试官还会问大列表的数据分页。这块的回答方向是使用 LazyVStack 或 List 配合数据源的分页加载在滚动接近底部时触发下一页请求同时维护好加载状态和错误状态。注意分页加载的状态也要放到 ViewModel 中管理试图层只负责触发。6.4 组件设计与可测试性架构面试的压轴题通常围绕“如何设计可复用的 SwiftUI 组件”和“怎么给 SwiftUI 代码做单元测试”。组件设计的核心不是“把 UI 拆得多细”而是“把状态边界划清楚”。一个复用组件只通过参数接收要展示的数据通过回调或 Binding 上报用户操作。组件内部允许有私有状态但私有状态的边界必须明确不能让内部状态漂移污染外部数据流。可测试性方面ViewModel 是主要测试对象。因为它不依赖于具体视图可以独立验证业务逻辑。这也是为什么 MVVM 在 SwiftUI 里受欢迎View 层很薄逻辑集中在 ViewModel测试起来非常舒服。面试里提到测试时可以顺带说一句视图层的测试用 ViewInspector 这类第三方库可以做到但核心价值还是业务逻辑的测试。能清晰表达“哪部分值得测、哪部分不值得测”比空谈覆盖率更有说服力。7. 一些实操体会带了几轮新人、面了不少候选人之后我越来越觉得 SwiftUI 面试题考察的不只是 API 记忆而是“状态模型”和“生命周期”这两个底层思维模型有没有建立起来。很多人卡在背 API 上换个问法就露馅。比如把 State 的问法改成“页面上的计数器自增但视图不刷新可能是什么原因”考察的就是对状态归属和刷新机制的真正理解。如果想扎实掌握这些高频考点我自己的建议是不要停留在读题和背答案而是把这几个问题写成小 Demo 逐一验证。比如故意把 ObservedObject 用在自创建的 Model 上跑一遍看看会不会出现意外重初始化故意在 onAppear 里放一个打印日志看看导航返回时会不会重复执行。踩过这些坑之后再回答面试题就是“经验之谈”而不是“背诵之作”。这份整理覆盖了数据流、布局、生命周期、动画、UIKit 桥接和架构设计六个方向。对准备面试的人来说建议把每个章节里的问题当作自测题先遮住答案自己回答一遍遇到卡壳的地方再回来翻对应的解析。写代码这件事从来都是动手过一遍才真正属于自己。