先弄清几个概念（像在讲给朋友听）
很多人遇到适配问题，往往是因为把“设备方向”当作唯一维度。其实更重要的是“可用画布大小”和“上下文”（比如是否在分屏、是否弹出键盘）。把问题拆成三件事来想，会更简单：
- 尺寸类（Size Classes）和TraitCollection：告诉你当前界面是“宽”还是“窄”、是“高”还是“矮”，相比单纯看设备型号更可靠。
- Auto Layout 与自适应约束：让控件根据可用空间流动，而不是写死坐标。
- 多任务与系统容器：Split View、Slide Over 会改变视图宽度，甚至在横竖屏中出现紧凑宽度，应当优雅应对。
为什么不建议直接读 UIDevice.orientation？
因为设备物理朝向不一定等于界面最终展现的方向，尤其在 iPad 的多任务场景里。推荐通过 UIViewController 的 traitCollection 和 viewWillTransition(to:with:) 来判断和处理布局变化。
整体策略：把布局设计成“响应式”的三步法
- 基础约束优先：先保证 UI 在最小可用宽度下也能呈现（比如 Slide Over 的 320pt 左右），再在更宽的情况下扩展。
- 分层适配：全局布局 → 容器内布局 → 组件微调。每一层都尽量使用约束和自适应规则，而不是硬编码宽高。
- 渐进增强：为更大屏幕和横屏提供增强版布局（多栏、侧边栏），而非在窄屏上强行显示所有信息。
UIKit 实战指南（工程师会喜欢的步骤）
Info.plist 设置和全局方向控制
在 Info.plist 的 Supported interface orientations (iPad) 中声明支持的方向。注意：即便 Info.plist 支持横竖，系统在 Split View 下仍会以容器大小为主，不能强制设备旋转。
ViewController 层的常用回调
- viewWillTransition(to:with:)：在尺寸将要变更时收到回调，通常用于触发动画或调整布局相关状态。
- traitCollectionDidChange(_ previousTraitCollection:)：当尺寸类或界面环境（例如多任务、分辨率变化）改变时调用，适合切换布局模式或样式。
- override var supportedInterfaceOrientations 与 preferredInterfaceOrientationForPresentation：用于单个 VC 的方向偏好，但在 iPad 多任务下有限制。
Auto Layout 的实际技巧
- 使用 UILayoutGuide（safeAreaLayoutGuide、layoutMarginsGuide）来保证边缘安全。
- 优先用相对约束（比例、间距）而非固定宽高。用 priority 来在紧凑空间中有所退让。
- 对于“横屏显示更多信息”的场景，可以用两套约束组（activated = true/false）切换，或通过 StackView 动态调整排列方向。
- 使用 UIContentSizeCategory 考虑动态字体尺寸，避免在大屏上字体过小或布局崩溃。
示例：用 viewWillTransition 切换布局（伪代码）
这里就用文字描述思路：在 viewWillTransition 中，根据新大小判断是否进入“宽视图模式”，然后激活对应约束组并在协调器内执行动画，让转场平滑。
SwiftUI 的实现要点（稍微不一样）
SwiftUI 本身会根据容器尺寸自动布局，但有些场景需要手动干预：
- 使用 GeometryReader 获取父容器的实际尺寸，做条件布局（比如一列或两列）
- 借助 horizontalSizeClass 和 verticalSizeClass（通过 Environment）做适配
- 若需强控屏幕方向，可以把 UIKit 的 HostingController 包裹起来，重写 supportedInterfaceOrientations
SwiftUI 示例思路
在顶层 View 用 GeometryReader 判断宽度阈值（例如 600pt），小于则单列，大于则两列或侧栏。对复杂场景（如分栏拖拽）考虑把内容拆成独立子 View。
iPad 多任务（Split View / Slide Over）的特殊考虑
- 永远不能依赖固定的屏幕宽度，应用应该在任意中间宽度下都能工作。
- Split View 会触发多次 traitCollection 变化，注意去抖（debounce）某些昂贵重布局操作。
- Slide Over 宽度通常更窄，优先保证核心交互可用，次要内容隐藏或折叠。
交互逻辑如何调整
当进入窄屏模式，把某些多列控件降级为分页或可折叠面板。注意触摸目标最小尺寸（Apple 建议 44pt）和可视反馈。
图片与资源管理（别忽视这一块）
iPad 型号多、分辨率也不一，处理图片时建议：
- 优先使用矢量 PDF（在 Asset Catalog 中设置为 Single Scale）或 SF Symbols（适用的地方）。
- 为位图提供 @2x/@3x，注意 iPad Retina 常见为 @2x，但特定大型 iPad 依然是 @2x。
- 对横屏大图使用按需加载（lazy load）与占位图，避免瞬间占用大量内存。
键盘与外设（键盘、分屏键盘、外接显示器）
键盘出现会改变 safeAreaInsets，尤其在横屏下会把输入框遮住。监听 keyboardWillShow / keyboardWillHide（或使用 UIView 的 keyboardLayoutGuide）来调整底部约束。
动画与转场（追求自然感）
在旋转或尺寸变化时尽量在系统动画协调器中执行：在 viewWillTransition 的 coordinator.animate(alongsideTransition:) 里更新约束，这样系统会帮你平滑过渡。避免在动画中做大量布局计算或同步网络请求。
Web 与混合 App（WebView / PWA）的适配要点
- 在 Web 端使用响应式设计（媒体查询、flexbox、grid），并在 meta viewport 中设置合适缩放策略。
- 监听 orientationchange 与 resize 事件，以便调整 canvas、地图或富媒体播放器尺寸。
- 注意 PWA 在 iPad 上可能会被固定为某种方向或尺寸，测试真实环境非常重要。
常见坑与对应做法（实用清单）
- 坑：用 UIDevice.orientation 判断布局——修复：用 traitCollection 或 view.bounds。
- 坑：在动画外修改约束导致闪烁——修复：在 transitionCoordinator 中修改并调用 layoutIfNeeded。
- 坑：忽略 Split View 导致布局在窄宽度崩掉——修复：在设计阶段就有窄宽度的最低可视化样式。
- 坑：图片太大占内存——修复：使用按需加载、图像压缩与图块化（tiling）策略。
调试与测试建议（确保覆盖面）
- 在 Xcode 的 Simulator 中测试多种 iPad 型号和分屏比例（25/50/75%）。
- 在真机上实际操作 Slide Over、Split View、弹出键盘、外接键盘、旋转，观察所有边界情况。
- 使用 Xcode 的 View Debugger 检查约束冲突与层级问题。
- 通过 Accessibility inspector 检查动态字体与对比度，保证可访问性在不同方向下也可用。
性能与可维护性小贴士
- 避免每次尺寸变化都完全重建 View 层次；尽量复用子视图，更新内容而不销毁整个树。
- 对复杂布局使用差分更新或局部刷新，避免在主线程做昂贵计算。
- 对可配置布局使用清晰的状态模型（例如枚举描述当前布局模式：compact/regular/multi-column），把布局逻辑集中化，便于测试与维护。
一张速查表（常用 API 与用途）
| 用途 | UIKit API | 备注 |
| 布局变化通知 | viewWillTransition(to:with:) | 在 coordinator 中做动画 |
| 环境变化 | traitCollectionDidChange(_) | 检查 horizontalSizeClass 等 |
| 安全区 | view.safeAreaLayoutGuide | 处理刘海与系统条 |
| 键盘适配 | keyboardLayoutGuide（iOS 15+） | 更可靠地绑定底部约束 |
| SwiftUI 环境 | Environment(\.horizontalSizeClass) | 配合 GeometryReader |
实战小案例思路（把上面的东西串起来）
假设你要做一个商品详情页，横屏要两栏（图片与信息并列），竖屏为单列。实现思路：
- 总体：采用 Auto Layout / SwiftUI 的弹性布局。
- 在小于 600pt 时采用单列，图片在上；大于等于 600pt 时切换为两列布局。
- 在 traitCollectionDidChange 中切换约束组或在 SwiftUI 中基于 GeometryReader 改变 HStack/VStack。
- 图片使用矢量或高效的按需位图，横屏下懒加载更高分辨率版本。
- 测试点：Slide Over、分屏 50/50、外接键盘弹出、旋转后的过渡动画。
最后提几句实用的心态建议
别想着一次把所有设备都“完美”适配，那样会卡死设计。先把核心交互在最小宽度下可用，再逐步增强。多任务场景是 iPad 的常态，设计时反过来把“可变宽度”当作第一公设，你会少踩很多坑。测试要在真机上做，模拟器只能覆盖部分情况。顺手把常见的布局模式封装成组件，团队会更省力。
好了，说到这儿我忽然想起上次调试一个 split view 的 bug，原来是某条约束 priority 写错了，导致在窄屏时某些控件被压扁——改成可折叠的隐藏策略后问题就没了。你在实践中会遇到类似的小意外，慢慢就有套路了。