余时行很长一段时间里，我以为“App 尺寸适配与多屏幕支持”只是切几套图、改几个 dp 的事。直到有一次临上线前，测试机列表里一台老款 Android 把底部按钮挤出屏幕，我才意识到：屏幕碎片化不是单个控件的尺寸问题，而是单位、布局、资源、安全区这些层面叠加出来的系统性工程。
这篇文章我会用实际开发视角，把 App 尺寸适配的完整链路拆开讲：先从物理像素和逻辑像素的区别聊起，再说布局容器和资源目录怎么做，最后给到刘海屏、折叠屏、多窗口这些容易被忽略的适配细节。无论你做的是原生 Android、iOS，还是 Flutter、React Native，底层的判断逻辑基本一致，差别只在 API 名称上。
1. 崩溃的表象是屏幕不统一，深层其实是三套换算规则相互打架
1.1 同一个“一英寸”，在不同设备上对应了完全不一样的物理像素
很多新人在做尺寸适配时，第一反应是把设计稿里的 px 数字直接搬进代码。今天看起来“差不多”，换一台密度更高的真机就全乱了，这是因为屏幕并没有你想象中那么标准。
Android 定义了一套以 160dpi 为基准的换算方式：在 160dpi 的屏幕上，1dp 等于 1px；在 320dpi 的屏幕上，1dp 等于 2px。这里的 dpi 代表每英寸像素数，而 density 就是实际 dpi 除以 160 得到的缩放系数。iOS 的 pt 逻辑类似，它的基准设备和换算规则虽然不一样，但抽象意图一致：让布局尺寸不随硬件像素密度疯狂变化。
拿两台宽度相近的手机举例：一台物理宽度 1080px、density=2.75，一台物理宽度 1260px、density=3.0。你给图片设了 360px 的固定宽度，前一台能完整显示，后一台可能超框；但如果统一写成 360dp，系统会自动换算成不同物理像素，结果看起来反而是一致的。
1.2 逻辑像素是给布局用的，物理像素是给位图用的
我把适配规则总结成一句话：代码布局里能不用物理像素就不用物理像素，位图资源才需要关心物理像素。 因为布局关心的是“元素在屏幕上占多大视觉区域”，而不是“占了多少个发光点”。
Android 使用 dp 作为长度单位，sp 用于字号，React Native 的默认数字单位、Flutter 里的逻辑像素，本质上都扮演了同一个角色——屏蔽密度差异的逻辑尺寸。只要你把所有控件尺寸、间距、内边距都写在逻辑单位上，布局就能在不同 density 下得到一致的视觉效果。
问题是很多页面并不只用逻辑单位。拿到设计稿后，有人会在内容宽度里写死 1080 的一半、在实际服务端下发的排版节点里直接塞 px，或者用 Canvas 画图时把 dp 当成任意缩放数值。这些都会让布局在特定设备上突然错位。如果你在项目里搜索宽度，能在某个第三方组件里看到“px”字样，就需要警惕：它要么是图片尺寸，要么很可能是适配隐患。
1.3 真正决定成败的是“可用区”，不是整块玻璃
一块屏幕在运行 App 时，并不是所有区域都能自由摆放内容。状态栏、导航栏、底部手势条、刘海区域、系统分屏边界，都会不断压缩内容区。很多适配问题，用逻辑像素算是对的，却在真机上被系统栏挡住，就是因为只考虑了屏幕总宽，没有考虑可用区。
做多屏幕支持时，“适配目标”应该写成：可用宽度从 320dp 到 1000dp、可用高度从 500dp 到 1400dp，内容都能完整展示、可读、可点击。搞清楚这份边界，后续的工作才不是盲目补丁。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 我把尺寸方案拆成宽度档位和边界值，才不再每台新手机都“看一眼适配”
2.1 让产品一起确定 320/360/600/840 这几个档位
一份视觉稿通常只按 iPhone 或某一台主流 Android 机型的宽度画，但如果开发只按这条线写死，新机型一多，马上失控。与其等线上反馈，我建议先和产品、设计拉一个“支持的宽度档位”清单，做适配前就把标准定下来。
Android 按逻辑宽度统计，比较常见的是 320dp（老款小屏）、360dp（很长一段时间的主流）、411dp/412dp（新全面屏）、600dp（小平板/折叠屏展开）、840dp（大平板）。iOS 则以 pt 为维度，iPhone 常见 320pt（老 SE）、375pt（经典尺寸）、390pt、414pt、430pt，iPad 通常从 768pt 起步，分屏后也可能出现 320pt 左右的窄布局。
这组数据不要只在开发脑子中放一份。把档位写进需求模板、让设计在每个档位出关键节点或至少出约束图，能省掉大量后期返工。更高效的做法是直接使用断点：宽度小于 600dp 走手机布局，600dp 到 840dp 之间走双列或侧栏过渡，840dp 以上走真正的大屏多栏布局。这个思路几乎适用于所有平台。
| 宽度档位 | 常见设备 | 布局策略 |
|---|---|---|
| 320–414dp | 手机 | 单列为主，容器宽度不超过屏宽，严格控制边距 |
| 600–800dp | 平板小窗/折叠屏展开 | 双列或侧栏，避免内容被拉成过宽的长行 |
| 840dp 以上 | 平板或大屏 | 内容区限制最大宽度，使用多列、Master-Detail 结构 |
2.2 用 smallestWidth 与断点区分手机、折叠屏和平板的通用结构
Android 的 sw 资源修饰符是适配大屏最实用的工具之一。sw600dp 表示“设备最小宽度不小于 600dp”，这里的“最小宽度”指的是不考虑横竖屏时，屏幕短边对应的逻辑宽度。竖握一台 7 寸平板，宽度可能只有 600dp；横屏后短边可能是 800dp，但你希望在这两种状态下都使用平板布局，sw600dp 就能保证一致命中。
代码里可以这样让资源目录自动加载不同布局：
text复制res/layout/mian_activity.xml // 手机默认
res/layout-sw600dp/mian_activity.xml // 平板/大屏通用
res/layout-land/mian_activity.xml // 手机横屏专用
res/layout-sw600dp-land/mian_activity.xml // 平板横屏专用
目录名里的 sw 是设备属性，不随旋转改变，因此非常适合做“手机 vs 平板”的结构切换。而 w600dp 这样的宽度修饰符则会随可用宽度实时变化，适合做分屏。如果你维护的是老旧项目，早期还可以用 layout-xlarge 之类的大小桶判断，但最小宽度是更有确定性的标志。
2.3 横屏不是“旋转90度”，而是布局策略的第二套轨道
竖屏和横屏对内容空间的感受完全不同。竖屏时宽度有限，适合卡片流；横屏时高度有限，顶部 bar 浪费一截，应该把导航搬到侧边或采用双层结构。
如果手机布局只是把宽度放大、高度变窄，长列表会显得很可笑。比较好的做法是：横屏手机不能按竖屏同等策略放更多列，而应该放宽内容容器、降低上下留白；平板横屏则可以同时显示主从页面，比如邮件列表点击后右边展示详情。iOS 里的 Regular width/Compact width、Android 里的 screenWidthDp，都能在遇到横屏时告诉布局层“这里的空间变了，请重新组织”。
判断小屏横屏最怕的是一切按比例拉伸。比例拉伸只能处理容器，处理不了文本可读性，比如横屏把一张图表横向拉高，看起来占满了屏，却丢失了浏览节奏。
3. 布局容器必须同时支持拉伸、压缩和限宽，才能承担多屏幕兼容
3.1 ConstraintLayout 里优先用 Guideline 和比例宽度
我一直建议团队少用嵌套的 LinearLayout 去做复杂页面，因为它的 width=0dp + weight 虽然能解决“等分”，却很难表达“左边固定、右边自适应、整块内容不超过最大宽度”这类需求。ConstraintLayout 的 Guideline 可以按百分比分割屏幕，例如把关键内容限制在左右 8% 到 92% 之间。
比例宽度的典型用法：
xml复制<androidx.constraintlayout.widget.ConstraintLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<Button
android:id="@+id/btnPrimary"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:text="主操作"
app:layout_constraintWidth_percent="0.6"
app:layout_constraintWidth_max="480dp"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toEndOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>
百分比宽度解决的是“容器自身大小”，但仅靠百分比远远不够。你还需要设置最大和最小宽度，否则在超宽平板上按钮会无限拉宽，最终变得不可点击、难以阅读。layout_constraintWidth_max 和 layout_constraintWidth_min 就是给你做边界控制的。
iOS 里 Autolayout 同样支持 multiplier，等价于比例约束；如果你用 SwiftUI，则可以借助 GeometryReader 根据父容器宽度做比例计算。布局的底层逻辑并不神秘：优先让外壳跟随父容器变化，内部细节保持合理边界。
3.2 页面级的外层容器，要保留 maxWidth/maxHeight 的余量
大屏适配最常见的问题是内容区无脑拉满。竖屏 320dp 到平板 1000dp，如果一行评论列表横跨整屏，人的视线从左侧扫到右侧会非常吃力。因此页面级容器最好保留一个“最大阅读宽度”，超出后居中即可。
比如在 Android 中常用这样一段结构：
xml复制<FrameLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<LinearLayout
android:id="@+id/contentContainer"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
android:maxWidth="840dp"
android:layout_gravity="center_horizontal">
...
</LinearLayout>
</FrameLayout>
这种结构没有用复杂的自定义控件，就能在平板上让内容不铺满全屏。需要注意 maxWidth 只对“match_parent 上限”生效，最好配合左侧和右侧为 0 或居中处理，避免出现紧贴一边的怪异效果。类似 iOS 使用 readableContentGuide 是一个更成熟的做法，它直接按排版可读性给出安全宽度。
真正高级的适配，是让布局系统在空间富余时“扩张”，在拥挤时“收缩”，在极端场景下“不失能”。而不是把所有元素铺满，也不是把所有元素都固定成某一个“安全”尺寸。
3.3 空间不足时应让内容折叠，而不是整体缩放
“把整个页面按比例缩小”看起来是个一劳永逸的适配方案，手机上铺不下、缩放一下不就行了吗？做过一轮就会发现，文本超过一定缩放比例后，阅读成本暴涨；按钮区域缩小后，触控准确率直线下降。违背可达性和交互直觉的整体缩放，应该是最后手段。
正确的思路是把内容分层：横向空间不够时，把一部分纵向排布；侧边栏放不下就收进抽屉；表格列太多就让部分列折叠进详情。这也解释了为什么大屏适配往往涉及组件结构，而不是只调一个尺寸。折叠、展开、拖拽、分栏，本身就是响应式布局的组成部分。
任何元素的最终尺寸都不能由单一公式算出。 你要先让宽度“可流动”，再用最大最小宽度限制边界。这样才能兼顾 4 寸小屏和 12 寸平板的体验。
4. 资源和切图跟着密度走，不是跟着宽度走，也不是越多越好
4.1 Android 的密度 resource bucket，适合位图但不适合拿来造业务 UI
Android 工程里有 drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi 等目录，它们和屏幕密度桶一一对应，系统会自动选择最合适的一套。很多初接触 Android 的人以为适配就是“把所有图片都丢到这些目录里”，结果图片资源体积迅速膨胀，APK 大得吓人。
实际上，位图资源才需要按密度切多套；纯色背景、图标、按钮背景尽量使用 shape 或矢量图。如果一张背景图本身是设计稿中的大图，提供 xxhdpi 与 xxxhdpi 两种已够一大部分设备覆盖。密度桶并不是“按手机品牌精确匹配”，它只会匹配到最接近的系统密度档位，所以没必要为每个 dpi 都放大一套。
iOS 端同样如此。普通需求一般提供 @1x、@2x、@3x 三套；现在主流 iPhone 基本用 @3x，iPad 多数是 @2x。如果你维护一个跨平台设计系统，图片切图我建议直接让设计师按 Android 的 xxhdpi 与 iOS 的 @2x/@3x 导出，既保证清晰度，又不会把资源搞到失控。
4.2 图标和按钮尽量上矢量图，复杂的图片只保留缩放上限
图标是尺寸适配中最适合向量化的部分。Android 的 VectorDrawable、iOS 的 PDF 矢量资源或 SwiftUI 的 Shape，Windows 系统的字体图标，都能在不同尺寸下无损缩放。只要不是摄影类图片、复杂渐变插画，一个图标几十个 vector 指令远比一堆位图资源可靠。
位图问题集中的另一处是布局缩放后失真的情况。比如服务器下发了一张宽度 1080px 的图，屏幕宽度只有 360dp，又要求撑满容器。如果你不区分 density，直接用 ImageView 按 fitCenter 缩放，图片会在高密度手机上产生硬件压缩或模糊。如果要高质量显示，正确的做法是对不同网络环境下发不同尺寸的资源；静态资源则用 resize 和 centerCrop/centerInside 配合容器边界，而不是依赖 ImageView 无限缩放。
要知道系统对位图的内存占用是按物理像素计算的。一张 1920px 宽的图放进 density=3 的屏幕容器，假设高度 1080，占用内存约 1920×1080×4≈8.3MB。在大图列表里随意放大缩小，内存会被瞬间打满。图片资源更适合有清晰的分辨率上限；布局则更依赖容器约束。
4.3 字号用 sp，行高不用固定死，必要时给 TextView 开启自动缩放兜底
字体适配里，单位选择最容易出问题。Android 上用 dp 标字号，关闭系统字体缩放后没有问题，但一旦用户在系统设置里调大字体，文本会不跟随变化，视觉就会显得很“拧巴”。正确的字号单位是 sp，它是基于 dp 再叠加用户字体缩放比例的一种逻辑单位。
但我们不能因此把所有行高和容器高度都写成 wrap_content 了事。文本内容变长后，如果行高仍是固定值，文字会被裁切；如果按钮高度固定，大字号文案会把按钮撑爆。最好的策略是：文字高度交给 wrap_content，行高通过 lineSpacing 设置为相对值；关键操作按钮不要完全依赖固定高度，而是配合内边距伸缩。
如果列表标题必须单行截断，可以给 TextView 设置 autoSizeTextType="uniform"，让它在一段区间内自动缩小字号：
xml复制<TextView
android:id="@+id/title"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:textSize="16sp"
android:autoSizeTextType="uniform"
android:autoSizeMinTextSize="12sp"
android:autoSizeMaxTextSize="16sp"
android:maxLines="1"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toStartOf="@id/icon" />
自动缩放是“兜底”，不是唯一方案。如果所有文案都靠降低字号适配，阅读体验会明显受损。用它处理超长标题、卡片操作栏这类边界，比硬撑到下一行更好。
5. 安全区、刘海和系统手势被很多人忽略，却是多窗口场景里最先顶出来的硬伤
5.1 用 WindowInsets 取代自己算状态栏高度
很多老项目适配刘海屏的方法是：读取状态栏高度，然后给顶部容器加一个 padding。在一台手机上看着没事，到了另一台可折叠设备上，statusBar 高度可能横竖屏不一致、切换手势导航后底部 inset 变化，手写算法立刻失效。
从 Android 11（API 30）开始，官方推荐用 WindowInsets 获取系统栏和刘海区域。ViewCompat.setOnApplyWindowInsetsListener 会在 insets 变化时被回调，应用只需要根据 insets 调整自己的 padding 或 margin：
kotlin复制ViewCompat.setOnApplyWindowInsetsListener(view) { v, insets ->
val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
val cutout = insets.getInsets(WindowInsetsCompat.Type.displayCutout())
v.updatePadding(
top = systemBars.top,
left = maxOf(systemBars.left, cutout.left),
right = maxOf(systemBars.right, cutout.right),
bottom = maxOf(systemBars.bottom, cutout.bottom)
)
insets
}
iOS 里则主要通过 Safe Area 这个抽象层处理：UIView 的 safeAreaInsets 和 SwiftUI 的 safeAreaInset 会自动告诉子视图哪些区域被圆角、刘海或 home indicator 盖住。核心原则都是：不要自己把某个系统高度当成常量写死，而要监听一个“安全区域边界”事件，让界面在边界改变时主动响应。
5.2 分屏和窗口大小变化要响应，而不是只适配“App 全屏”
多窗口支持是“多屏幕适配”最容易被测试遗漏的形态。Android 进入分屏后，Activity 的宽度可能从 800dp 直接降到 400dp；iOS 的 iPad Split View 同样会把布局压到类似手机宽度，这时固定宽度布局必然错乱。
应用需要在窗口大小变化时重新评估布局策略。Android 中监听 onConfigurationChanged，判断 newConfig.screenWidthDp；如果 Activity 不是全屏模式，还要结合 WindowMetrics 拿到真实的可用显示区。在 Compose 中，BoxWithConstraints 会把可用的 maxWidth 暴露出来，让布局在不同宽度状态下自动切换：
kotlin复制@Composable
fun AdaptiveContent() {
BoxWithConstraints {
val maxWidth = maxWidth
if (maxWidth >= 600.dp) {
TabletLayout()
} else {
PhoneLayout()
}
}
}
分屏是最典型的“可用宽度变化”场景，但很多人默认只处理横竖屏。一个更全面的测试方案是：把应用切到分屏下半区、把 iPad 页面拖成第三栏、调用 Android 的 freeform 窗口随机缩放。这些操作会暴露比旋转更复杂的状态组合。
5.3 刘海旋转后区域会变，要用区域读取而不是常量偏移
刘海是安全区中比较特别的“不可用区域”，但它不是固定位于顶部。设备旋转后，刘海可能出现在屏幕左侧或右侧，如果你的适配逻辑写的是“顶部固定下移一个状态栏高度”，横屏时刘海就会盖住内容。
正确的做法是把刘海当做“物理切口区域”而不是“方向区域”。Android 的 DisplayCutout 对象里有 getSafeInsetLeft/getSafeInsetTop/getSafeInsetRight/getSafeInsetBottom，你可以根据当前窗口方向选择合适的 inset；iOS 上则靠 safeAreaInsets 自动处理。设计上如果横屏有内容栏，应给内容留出不小于切口区域的安全边距，避免关键按钮落在切口附近。
这类问题纯靠真机很难查全，因为刘海设备只占一部分。建议在团队内部规范里列出一个“危险区域清单”：顶部两个角落、底部手势条、屏幕圆角、前置摄像头挖孔。开发时不要硬编码边距，让可交互重要元素主动避开这些区域。
6. 真机不够也能回归：用模拟矩阵和预览把适配问题固定在前置阶段
6.1 用可配置虚机与开发者选项模拟不同宽高和 density
大多数小团队没有几十台真机的条件，但 Android Studio 的 Device Manager 可以创建不同尺寸、不同版本的虚拟机。你不需要覆盖所有型号，聚焦三台足够：一台 320dp 左右的小屏、一台主流 360dp 全面屏、一台 800dp 左右的平板。
比虚拟机更轻量的是开发者选项里的“Smallest width”调试入口（不同系统叫法不同）。把它改成 350 或 600，系统会重新按目标宽度渲染布局，你在同一台真机上就能快速确认当前页面在“小屏”或“平板”宽度下的表现。这个方式极适合开发期自测，也能在白板演示时快速展示响应式结果。
iPad 侧也可以用 Xcode 模拟器选择不同设备，甚至有 iPad 无刘海和分屏布局的区别。注意模拟器消耗大，测试流畅性可能不如真机，但它对宽度适配的验证精度已经足够高。真机矩阵主要用来验证性能、相机、传感器、刷新率这类硬件相关功能。
6.2 把多尺寸预览写进组件，让开发者在写代码时就能看见失真
现代 UI 开发都支持多尺寸预览，这个特性被我当作适配第一道关卡。Compose 中可以用多个 @Preview 注解同时展示小屏和大屏状态；SwiftUI 的 PreviewDevice 可以模拟不同机型；Android XML 中也可以用 layout inspector 结合多个虚拟设备，但自动化程度不如 Compose 方便。
我分享一个简单有效的 Compose 预览写法：
kotlin复制@Preview(name = "Phone", widthDp = 360, heightDp = 800)
@Preview(name = "Tablet", widthDp = 800, heightDp = 1280)
@Composable
fun OrderDetailPreview() {
OrderDetailScreen(...)
}
这样在编码阶段，你的集成开发环境会在左侧直接显示两套效果图。发现卡片被拉变形，或按钮宽度异常，换行处理得不够聪明，你会很早在 IDE 里看到，而不是等设计师截图骂生产环境。此类预览可以覆盖绝大多数基础布局问题，剩下的是交互层面的细微差异。
6.3 用固定清单在发版前做一轮人工检查，比随机找设备更高效
自动化能挡掉一部分问题，但真正决定用户体感的往往是一系列很小的状态组合：超大字体、蓝牙键盘让屏幕高度变化、分屏、横屏、后台切换、导航模式切换。这些不是每台真机都会出现的情况，靠人力逐个检查也浪费时间。
因此，我建议团队沉淀一份“多尺寸回归清单”，大致可以包括：
- 首页、详情页、购物车、设置页在 320dp、360dp、600dp、840dp 下的显示
- 同一页面横竖屏各看一轮
- 全局 font scale 调到 1.3、1.5 之后是否出现截断或重叠
- 长标题、超长用户名、多语言文本是否有溢出
- 底部操作栏是否被手势条遮挡
- 界面从竖屏转横屏再转回竖屏，控件是否回到原状
这份清单不需要天天跑，但建议每个迭代上线前至少花二十分钟过一遍。适配问题的本质不是某个尺寸没写对，而是当多种环境变量叠加时，布局是否依旧有“余量”。
7. Flutter 和 React Native 的适配抽象，终归要回到这套逻辑上
7.1 Flutter 的逻辑像素是统一层，但仍要用 MediaQuery 切换布局
Flutter 的逻辑像素和原生 dp、pt 类似，所以你在 Flutter 中写 width: 100，系统会把它当作逻辑单位而非物理像素。这只是适配的第一步，真正的多屏幕支持依然依赖 MediaQuery.of(context).size 或 LayoutBuilder。
dart复制final size = MediaQuery.of(context).size;
final isLarge = size.width >= 600;
我见过很多 Flutter 新手用 MediaQuery.of(context).size 拿到的全屏宽高，直接除以一个常量来缩放每一个子组件。这个方法在细节层面看似可行，一旦系统字体缩放或 TextScale 改变，容易全面失控。推荐优先使用布局容器自适应的能力，让 Flexible、Expanded、Stack 结合 BoxConstraits 处理空间分配，仅用 MediaQuery 做断点判断。
Flutter 的 SafeArea 组件自带 top/bottom padding，它其实也在帮你在最外层处理刚才提到的安全区问题。如果你用自定义 Scaffold 包了沉浸式页面，务必保留对应的 SafeArea 或手动读取 MediaQuery padding。
7.2 React Native 的 Dimensions 和 useWindowDimensions 各有适用场景
React Native 使用逻辑像素单位进行布局，同时提供 Dimensions.get('window') 获取窗口宽高。最容易犯的错误是直接在模块顶层用常量缓存宽高，然后在页面中当成“永远不会变”的数值来用。横竖屏切换后，Dimensions 数值不会自动重新触发渲染，这就会导致界面错乱。
更好的做法是用 useWindowDimensions hook 监听窗口变化，确保旋转或分屏后能重新渲染。RN 中做多栏布局依然需要条件判断，例如：
javascript复制const { width } = useWindowDimensions();
const isTablet = width >= 768;
React Native 和 Flutter 在高阶抽象上做了很多跨平台工作，但并没有绕过“布局结构需要随窗口宽度变化”这个现实。跨端框架的价值是让你用一套代码写多个平台，而不是让你忽略多屏幕支持的复杂度。
7.3 跨端导航容器和底部操作栏，需要额外留安全区
RN 和 Flutter 因为绕过了传统系统控件，顶部导航、底部 TabBar、扫码页面通常由开发者自己渲染，所以最容易产生安全区错位。原生系统不会主动帮你把一个全屏背景拉伸到刘海后面，然后让按钮避开刘海。
跨端框架一般都会区分“全屏渲染区域”和“可触摸操作区域”。如果你把页面背景延伸出去，做沉浸式效果，这没问题；但按钮、表单、回到顶部、关闭按钮这类可交互元素，必须保留安全边距。不要相信“在 iPhone 14 上好了就等于全部好了”的经验，iPad、多任务分屏后安全区起点会变。
经验法则是把安全区相关的公共组件封装一遍，比如全局导航条、底部 TabBar、弹窗容器。它们统一读取设备安全区信息，避免每个页面单独处理两套接口，导致后期无穷无尽的特判。
适配不是一个可以一劳永逸的固定动作，更像是一套需要不断维护的运行规则。核心思路始终是：用逻辑单位定义尺寸、让容器具有伸缩能力、资源按需提供、安全区动态读取、断点放在组件结构层面。把这个循环沉淀进项目模板和预览配置，每次迭代需要修的适配问题会明显变少。至少我在整理完这套方案后的几个版本里，再没因为“某台新手机显示异常”而在上线的晚上熬夜。