Unity UI自适应布局：Canvas Scaler三种模式深度解析与实战避坑指南

1. 项目概述：为什么你的UI总在“瞎调”？

做Unity UI开发，最让人头疼的莫过于“适配”两个字。你花了一下午，在1920x1080的屏幕上把按钮、面板、文字调得整整齐齐，堪称完美。然后你满怀期待地切到iPhone 13的屏幕尺寸，或者一台老旧的安卓平板，画面瞬间崩坏——按钮叠在了一起，文字跑出了框，整个界面布局乱成一锅粥。这时候，很多人的第一反应就是去“瞎调”：手动拖拽RectTransform的锚点，给不同分辨率写一堆if-else判断，甚至为每个UI元素写位置补偿脚本。结果往往是越调越乱，代码耦合度飙升，维护起来苦不堪言。

问题的根源，在于没有理解Unity UI自适应布局的核心引擎——Canvas Scaler。它绝不是面板上一个简单的缩放滑块，而是一套完整的、基于数学原理的屏幕空间映射系统。很多开发者，包括早期的我，都只是凭感觉在它的三种模式（Constant Pixel Size, Scale With Screen Size, Constant Physical Size）之间切换，或者盲目调整Reference Resolution，却不知道每种模式背后的设计哲学、适用场景以及那些隐藏的“坑”。

这篇教程，就是来终结这种“瞎调”状态的。我会以一个踩过无数坑的过来人身份，带你彻底吃透Canvas Scaler的三种模式。我们不止讲理论，更会通过完全可复现的实战案例，对比它们在横竖屏切换、异形屏、多分辨率设备下的真实表现。最后，我会附上一份凝结了血泪教训的“避坑清单”，里面全是官方文档不会写、但实际开发中一定会遇到的细节问题。无论你是刚接触Unity UI的新手，还是被适配问题困扰已久的老鸟，这篇“保姆级”拆解都能让你建立起一套清晰、可靠、一劳永逸的UI自适应解决方案。

2. Canvas Scaler核心原理深度拆解

在开始对比三种模式之前，我们必须先理解Canvas Scaler到底在做什么。你可以把它想象成一个“空间转换器”，它的核心工作是在Canvas的“设计分辨率空间”和设备的“实际屏幕空间”之间建立一座桥梁。

2.1 核心概念：从设计分辨率到屏幕空间

设计分辨率（Reference Resolution）：这是你在Unity编辑器中布置UI时使用的“画布”尺寸。比如，你设定为1920x1080，那么你所有的UI元素位置、大小都是基于这个1920x1080的虚拟画布来定义的。这是一个逻辑尺寸。

屏幕空间（Screen Space）：这是玩家设备上实际的像素尺寸，比如2340x1080（某安卓手机）、2532x1170（iPhone 14 Pro）等。这是一个物理尺寸。

Canvas Scaler要解决的，就是如何将你在1920x1080画布上精心设计的UI，合理地“映射”到千变万化的实际屏幕上去。这个映射过程，主要涉及两个关键计算：缩放因子（Scale Factor）和参考点（Reference Point）。

缩放因子决定了UI整体放大还是缩小。参考点（通常由Canvas的Render Mode和UI元素的锚点共同决定）决定了以屏幕的哪个位置（中心、左上角、拉伸边缘等）作为映射的基准。Canvas Scaler的三种模式，本质上就是三套不同的“映射算法”。

2.2 三种模式的底层逻辑与设计意图

Constant Pixel Size（恒定像素大小）：这是最简单粗暴的模式。它的逻辑是：“我不管屏幕多大，UI元素就显示我设定的那么多像素”。缩放因子永远为1。一个100x100像素的按钮，在任何屏幕上都是100x100物理像素。它的设计意图是用于像素艺术游戏、复古风格UI或者一些需要绝对精确像素控制的HUD元素。在这种模式下，UI的物理尺寸会随着屏幕PPI（像素密度）的变化而变化，在高PPI的屏幕上看起来会很小。

Scale With Screen Size（随屏幕尺寸缩放）：这是最常用、也最复杂的模式。它的逻辑是：“根据屏幕尺寸与设计分辨率的比例，动态缩放整个UI画布”。它会计算一个缩放因子，让UI在逻辑上“填满”屏幕。其核心在于“填满”的策略，由Screen Match Mode参数控制，这直接决定了宽高比不同时的处理方式，是后续所有坑的源头。

Constant Physical Size（恒定物理大小）：这个模式关注的是现实世界的物理尺寸。它的逻辑是：“我希望这个按钮在每台设备上看起来都是1厘米见方”。它需要依赖设备报告的正确DPI（每英寸点数）信息。缩放因子根据物理DPI / 预设DPI来计算。设计意图是用于涉及真实测量、AR/VR或者需要跨设备保持绝对物理尺寸的应用。但请注意，移动设备报告的DPI常常不可靠。

重要提示：选择哪种模式，绝不是拍脑袋决定的。它取决于你的项目类型（是2D像素风还是3D大世界？）、目标平台（是PC单分辨率还是碎片化的移动端？）以及UI的设计风格（是扁平化矢量元素还是精细的位图？）。选错了模式，后续所有“优化”都是事倍功半。

3. 模式一：Constant Pixel Size 实战与陷阱

让我们先从这个最“单纯”的模式开始，把它摸透。

3.1 配置详解与适用场景

在Canvas Scaler组件中选中此模式后，你会发现只有两个参数：Scale Factor和Reference Pixels Per Unit。Scale Factor在这里是手动控制的全局乘数，而Reference Pixels Per Unit是Sprite的像素与Unity单位（米）的换算关系，通常保持100（即100像素对应1米）。

什么情况下该用它？

1. 像素完美（Pixel Perfect）游戏：你的美术资源是精心绘制的像素图，每个像素都不能模糊。比如《星露谷物语》、《蔚蓝》这类游戏。使用此模式可以确保精灵图以整数倍缩放，避免亚像素渲染导致的模糊。
2. 复古风格UI：UI元素本身是低分辨率的像素画，需要保持那种“锯齿感”。
3. 屏幕空间 - Camera渲染模式下的HUD：当你的Canvas渲染模式设为Screen Space - Camera，并需要UI严格跟随某个摄像机、且不受屏幕分辨率影响时（例如，在3D场景中始终固定大小的任务指示图标）。

3.2 实战演示：创建一个像素风血条

我们来做一个经典案例：一个固定在屏幕顶部的像素风血条。

1. 新建Canvas，设置Render Mode为Screen Space - Overlay，Canvas Scaler选Constant Pixel Size，Scale Factor设为1。
2. 创建两个Image作为血条背景（红色）和前景（绿色）。将它们的锚点（Anchor）都设置为Top/Stretch，这样它们的顶部会对齐屏幕顶端，宽度会拉伸。
3. 将背景的宽度设为200像素，前景的初始宽度也设为200。通过脚本控制前景Image的rectTransform.sizeDelta.x来改变血量。

此时运行，无论你如何改变Game窗口的分辨率，这个血条的像素宽度永远是200。在宽屏上，它看起来很短；在窄屏上，它可能显得很长。它的物理尺寸取决于屏幕的DPI。

3.3 致命缺陷与避坑指南

这个模式最大的坑就是完全无视屏幕尺寸和比例。这会导致：

• 布局错乱：你基于1080p设计的UI，在4K屏上会挤在中间一小块区域，周围大片留白。在超宽屏上，所有元素都堆在中间。
• 可读性灾难：在高PPI的手机屏上，文字和按钮可能小到无法点击和阅读。

避坑清单（Constant Pixel Size）：

• 绝不用于主流移动端或PC端自适应UI：除非项目有明确的像素艺术需求，否则请直接跳过此模式。
• 结合Pixel Perfect组件使用：如果确实要用，为Canvas添加Pixel Perfect组件（需要2D Pixel Perfect包），它能强制渲染为整数像素，消除抖动和模糊。
• 注意锚点的作用：在此模式下，锚点依然是有效的。一个锚定在右下角的元素，会一直待在右下角，只是它的大小不会随屏幕缩放。布局可以依靠锚点，但整体留白问题无法解决。
• 测试多分辨率：务必在极端分辨率（如超宽21:9、老旧的4:3）下测试，评估这种“固定”布局是否可接受。

4. 模式二：Scale With Screen Size 全面剖析

这是Unity UI自适应的主力军，也是复杂度最高、最容易出错的模式。理解它，就掌握了UI适配的八成功力。

4.1 核心参数：Reference Resolution与Screen Match Mode

Reference Resolution（参考分辨率）：这是你的“设计稿”尺寸。通常选择你的目标主流设备分辨率，或者一个折中的比例，如1920x1080（16:9）、1334x750（iPhone 8比例）。所有UI元素的布局和相对关系都基于这个分辨率来设计。

Screen Match Mode（屏幕匹配模式）：这是本模式的灵魂，决定了当实际屏幕宽高比与参考分辨率不同时，如何计算最终的缩放因子。它有三个选项：

1. Match Width or Height（匹配宽或高）：最常用、最灵活的模式。它引入了一个从0到1的滑块Match。

   • Match = 0：完全匹配宽度。缩放因子 =屏幕宽度 / 参考分辨率宽度。保证宽度方向填满，高度方向可能留黑边或溢出。
   • Match = 1：完全匹配高度。缩放因子 =屏幕高度 / 参考分辨率高度。保证高度方向填满，宽度方向可能留黑边或溢出。
   • Match = 0.5：折中。同时考虑宽高比，在宽度和高度因子之间进行加权平均。这是处理多种宽高比的推荐起点。

2. Expand（扩展）：缩放因子取屏幕宽度/参考宽度和屏幕高度/参考高度中的较小值。这保证了整个UI画布一定能被完整地塞进屏幕，不会超出，但屏幕四周可能会留下黑边。适合内容绝对不能裁切的应用，如电子书阅读器。

3. Shrink（收缩）：缩放因子取屏幕宽度/参考宽度和屏幕高度/参考高度中的较大值。这保证了UI画布一定会填满屏幕的至少一个方向，另一个方向的内容可能会被裁切掉。适合背景可以牺牲一部分内容的游戏，如一些横版卷轴游戏。

4.2 实战对比：三种Match Mode在不同屏幕下的表现

我们以参考分辨率1920x1080（16:9）为例，设计一个简单的UI：一个居中标题，底部左右各一个按钮。

场景1：在2340x1080（19.5:9，更长的手机屏）上运行

• Match Width or Height (Match=0)：以宽度为基准。缩放因子 = 2340/1920 ≈ 1.218。UI整体被拉宽了21.8%。底部按钮水平间距变大，但垂直方向上，屏幕顶部和底部会出现大片空白区域。
• Match Width or Height (Match=1)：以高度为基准。缩放因子 = 1080/1080 = 1。UI保持原样。因为高度一致，宽度不足，屏幕左右两侧会出现巨大的黑边。
• Match Width or Height (Match=0.5)：取折中。缩放因子介于1和1.218之间。UI整体适度放大，宽高方向都有拉伸，黑边相对较小，是比较均衡的选择。
• Expand：取较小因子（此处是高度因子1）。结果同Match=1，左右黑边。
• Shrink：取较大因子（此处是宽度因子1.218）。结果同Match=0，上下留白。

场景2：在1024x768（4:3，iPad经典比例）上运行

• Match=0：因子=1024/1920≈0.533。UI变得非常小，上下留白很多。
• Match=1：因子=768/1080≈0.711。UI较小，左右留白。
• Match=0.5：因子介于0.533和0.711之间，UI大小适中，是相对较好的选择。
• Expand：取较小因子0.533，同Match=0。
• Shrink：取较大因子0.711，同Match=1。

通过对比可以看出，Match Width or Height (Match=0.5)在应对宽高比变化时，提供了最好的折中效果和可控性，因此成为绝大多数项目的首选。

4.3 高级技巧：动态匹配与锚点布局系统

仅仅设置好Canvas Scaler是不够的，必须配合强大的锚点（Anchors）系统，才能实现真正的自适应。

锚点的本质：它定义了UI元素RectTransform的四个边，相对于父物体RectTransform四条边的相对位置。百分比是核心。

实战布局原则：

• 需要保持与屏幕边缘相对位置的元素：如底部的操作栏、侧边的菜单。应将锚点直接预设到对应的父物体（通常是Canvas）边缘。例如，一个全屏宽的底部栏，应设置锚点为Bottom/Stretch和Left/Right，然后将其Pos Y设为0，Height设为固定值。这样无论屏幕多宽，它都会紧贴底部并横向拉伸。
• 需要保持宽高比的元素：如头像、图标。应使用Center锚点，并通过Size Delta或Width/Height设置固定像素大小。Canvas Scaler会整体缩放它。
• 需要按比例缩放并保持相对位置的元素：如一个位于屏幕中央偏右30%位置的按钮。应将锚点设置为父物体的中心，然后通过Pos X设置为父物体宽度的某个百分比（这需要代码或更复杂的布局组件如Aspect Ratio Fitter辅助）。

动态匹配策略：你甚至可以根据当前屏幕宽高比，在运行时动态调整Canvas Scaler的Match值。例如，检测到屏幕非常宽（如21:9），可以将Match偏向0（更多匹配宽度），以避免UI在水平方向上被过度挤压。

// 示例：根据宽高比动态调整Match值 CanvasScaler scaler = GetComponent<CanvasScaler>(); float aspectRatio = (float)Screen.width / Screen.height; float referenceAspect = 1920f / 1080f; // 参考宽高比 if (Mathf.Abs(aspectRatio - referenceAspect) > 0.2f) // 宽高比差异较大时 { if (aspectRatio > referenceAspect) // 屏幕更宽 { scaler.matchWidthOrHeight = 0; // 更多匹配宽度 } else // 屏幕更高 { scaler.matchWidthOrHeight = 1; // 更多匹配高度 } } else { scaler.matchWidthOrHeight = 0.5f; // 差异不大，使用折中 }

5. 模式三：Constant Physical Size 的特定用途与局限

这个模式听起来很美好——“让UI在不同设备上拥有相同的物理尺寸”，但现实很骨感。

5.1 工作原理与依赖条件

在此模式下，Canvas Scaler根据物理DPI / 预设DPI来计算缩放因子。预设DPI是你指定的一个值（默认为96，这是Windows桌面系统的标准DPI）。如果一台手机报告它的物理DPI是440，那么缩放因子就是 440/96 ≈ 4.58。

关键问题：这个模式完全依赖于操作系统和设备报告DPI的准确性。在移动平台，尤其是安卓的碎片化生态中，设备报告的DPI常常是错误的，或者是为了兼容性而虚拟化的值。这就导致计算出的物理尺寸完全不可靠。

5.2 实战场景：何时可以考虑使用？

尽管有局限，但在特定场景下它仍有价值：

1. 测量类或AR应用：如果你的应用需要显示一个标尺，或者AR中需要将一个虚拟物体以真实尺寸（如1米长）叠加到现实世界，那么恒定物理尺寸是必要的。你需要进行大量的设备校准和测试。
2. 跨平台桌面应用：在Windows、macOS桌面端，系统DPI设置相对可靠。如果你的应用需要在高DPI（4K）屏幕和普通屏幕上保持UI元素的物理大小一致（比如一个1厘米宽的按钮），可以使用此模式，并配合系统的DPI感知设置。
3. 与Scale With Screen Size混合使用：一种高级技巧是，将Canvas Scaler设为Scale With Screen Size，但对于某些需要绝对物理尺寸的子Canvas（例如一个AR测量框），将其设置为Constant Physical Size，并嵌套在主Canvas下。

5.3 重大限制与避坑指南

最大的坑就是DPI信息不可信。在安卓设备上，你可能会发现同一款手机，不同厂商的ROM报告出不同的DPI。这会导致你的UI尺寸飘忽不定。

避坑清单（Constant Physical Size）：

• 移动端慎用，安卓端尤其避免：除非你有极强的设备测试能力和校准方案，否则不要在移动端项目中将此作为主要适配模式。
• 始终提供备选方案：在代码中检测DPI的可靠性，如果发现异常值（例如DPI低于100或高于600），应自动回退到Scale With Screen Size模式。
• 理解“Fallback Screen DPI”：Canvas Scaler组件中有一个Fallback Screen DPI参数。当系统无法提供DPI时（例如在编辑器或某些平台上），将使用此值。确保它设置得合理。
• 测试，测试，再测试：必须在大量真实设备上测试物理尺寸是否符合预期。用一把真实的尺子放在屏幕旁对比。

6. 复合策略与进阶实战：应对异形屏与安全区

现代移动设备充满了“刘海”、“水滴”、“挖孔”和圆角，这些统称为“异形屏”或“安全区（Safe Area）”。UI适配必须考虑这些区域，避免关键内容被遮挡。

6.1 安全区（Safe Area）适配实战

Unity提供了Screen.safeAreaAPI，它返回一个Rect，表示屏幕上不被刘海、圆角等遮挡的安全矩形区域。

实战步骤：

1. 创建一个全屏的背景Canvas或Panel，用于填充整个屏幕。
2. 创建另一个用于放置核心交互内容（如按钮、文字）的Canvas或Panel。我们称之为“安全内容容器”。
3. 编写一个脚本，挂载在“安全内容容器”上，根据Screen.safeArea来动态调整它的RectTransform。

using UnityEngine; [RequireComponent(typeof(RectTransform))] public class SafeAreaAdapter : MonoBehaviour { private RectTransform _rectTransform; private Rect _lastSafeArea; void Awake() { _rectTransform = GetComponent<RectTransform>(); ApplySafeArea(); } void Update() { // 通常只在屏幕方向改变时检查，这里简化为每帧检查 if (_lastSafeArea != Screen.safeArea) { ApplySafeArea(); } } void ApplySafeArea() { Rect safeArea = Screen.safeArea; _lastSafeArea = safeArea; // 将屏幕像素坐标的安全区，转换为本地归一化坐标（0-1） Vector2 anchorMin = safeArea.position; Vector2 anchorMax = safeArea.position + safeArea.size; anchorMin.x /= Screen.width; anchorMin.y /= Screen.height; anchorMax.x /= Screen.width; anchorMax.y /= Screen.height; _rectTransform.anchorMin = anchorMin; _rectTransform.anchorMax = anchorMax; // 重置偏移，让RectTransform完全贴合锚点定义的范围 _rectTransform.offsetMin = Vector2.zero; _rectTransform.offsetMax = Vector2.zero; } }

这个脚本的核心逻辑是：将Screen.safeArea的屏幕像素坐标，转换为相对于父物体（通常是全屏Canvas）的归一化锚点坐标（0到1），然后直接设置给目标UI面板的anchorMin和anchorMax。这样，该面板就会自动缩放到安全区域内。

6.2 横竖屏切换的动态适配

横竖屏切换意味着屏幕宽高比发生了剧变，从“高屏”变成了“宽屏”或反之。这要求我们的UI布局和Canvas Scaler设置能动态响应。

策略：

1. 动态修改Reference Resolution：监听屏幕方向变化，当切换到横屏时，将Canvas Scaler的Reference Resolution从1080x1920切换为1920x1080。这需要你事先准备好两套布局逻辑，或者使用一个能自动重新布局的UI系统（如Unity的Layout Group）。
2. 使用两套不同的UI预设：分别为横屏和竖屏设计两套不同的UI界面，在方向切换时启用/禁用或替换它们。这是最直观但资源消耗较大的方法。
3. 依赖锚点和布局组：这是最优雅的方式。通过精心设置锚点和使用Horizontal/Vertical Layout Group、Grid Layout Group，让UI元素在父容器大小变化时自动重新排列。结合Canvas Scaler的Scale With Screen Size模式，可以很好地应对宽高比变化。

关键点：在横竖屏切换时，不仅要考虑Canvas Scaler的缩放，更要考虑布局的重构。一个在竖屏下从上到下排列的列表，在横屏下可能需要变成从左到右排列。

6.3 多分辨率资产管理与优化技巧

UI自适应不仅仅是布局和缩放，还涉及到美术资源。一个为1080p设计的按钮贴图，直接放到4K屏幕上缩放4倍，必然会模糊。

多分辨率资产策略：

• 使用矢量图（SVG）：通过Asset Store的插件（如SVG Importer）导入SVG资源。矢量图可以无限缩放而不失真，是UI资源的最佳选择，但可能带来更高的运行时性能开销（网格化）。
• 提供多套位图资源：这是传统但有效的方法。Unity的Sprite Atlas支持Variant（变体）。你可以创建同一个图集的不同分辨率变体（如@1x, @2x, @4x）。在脚本中根据当前Canvas的缩放因子或设备DPI，动态加载不同倍数的图集变体。
• 使用九宫格（Sliced）精灵：对于按钮、面板等需要拉伸的UI元素，务必使用九宫格精灵。它只拉伸边缘部分，而保持四个角不变形，在任何分辨率下都能保持美观。
• 字体与TextMeshPro：对于文字，使用TextMeshPro是必须的。它是矢量字体，渲染清晰。确保为TMP字体资产生成足够大的Atlas Resolution，以覆盖高缩放倍数下可能需要的所有字符大小，避免运行时动态生成导致的卡顿和模糊。

7. 终极避坑清单与性能调优

最后，我把这些年积累的、散落在各处的坑点和优化建议，整理成这份终极清单。每一条都可能让你少熬一个通宵。

7.1 Canvas Scaler配置与布局的常见陷阱

1. 嵌套Canvas的Scaler冲突：如果一个子Canvas有自己的Canvas Scaler，它会覆盖父Canvas的缩放设置。通常，一个场景应该只有一个“根Canvas”设置Scaler，其他UI元素作为其子物体。除非有特殊需求（如3D UI、浮动提示框需要独立缩放），否则避免嵌套Scaler。
2. World Space Canvas的缩放：当Canvas渲染模式为World Space时，Canvas Scaler的Scale With Screen Size模式将失效。此时缩放需要通过调整Canvas的Transform.Scale或Reference Pixels Per Unit来实现。
3. RectTransform的Width/Height vs Size Delta：在锚点非拉伸状态下，Width/Height和Size Delta效果相同。但在锚点拉伸状态下（如Left/Right），Width/Height不可用，必须通过Size Delta来调整大小。理解这两者的区别至关重要。
4. 忽略Canvas的“Pixel Perfect”选项：在Screen Space - Overlay模式下，Canvas组件自身的Pixel Perfect选项会强制UI元素对齐像素网格，可以消除亚像素渲染带来的轻微模糊或抖动。对于像素风或需要锐利边缘的UI，建议勾选。但它可能与Canvas Scaler的缩放产生微小冲突，需测试。
5. Reference Resolution选择不当：不要盲目选择最高的分辨率（如4K）作为参考分辨率。过高的参考分辨率会导致在低分辨率设备上，UI缩放因子小于1，变得非常小。应选择目标用户的主流分辨率或一个中间值。通常，移动端选择1334x750或1080x1920，PC端选择1920x1080是一个安全的起点。

7.2 性能优化要点

1. 合批（Batching）破坏者：Canvas的更新和重建（Rebuild）是UI性能的主要瓶颈。频繁改变UI元素的位置、大小、颜色或文本，会导致其所在的Canvas批次（Batch）被破坏并重建。
   • 优化建议：将动态变化的UI元素（如血条、计时器）放在单独的Canvas或Sub-Canvas中，与静态UI隔离。这样重建只会影响这个小Canvas，而不是整个界面。
2. 过多的Mask与RectMask2D：Mask组件（特别是使用图片做遮罩）和RectMask2D会显著增加绘制调用（Draw Call）。RectMask2D性能优于Mask，但都应节制使用。
3. 过度使用Layout Group：Layout Group（水平、垂直、网格布局组）非常方便，但它们在每一帧（如果子物体有变化）或布局变化时都会触发耗时的布局计算。对于静态UI，在布局完成后可以考虑禁用或移除Layout Group组件。对于动态列表，使用对象池并尽量减少布局变化的频率。
4. TextMeshPro的字体图集：确保TMP字体图集足够大，包含所有需要的字符和字号。运行时动态添加字体会导致图集重建和卡顿。对于多语言项目，要预生成所有可能字符的图集。
5. Canvas的“Override Sorting”与“Additional Shader Channels”：除非必要，不要随意勾选这些选项。它们会影响渲染顺序和向Shader传递的数据，不当使用可能影响性能或产生渲染错误。

7.3 调试与测试方法论

1. 使用Unity的Device Simulator：在Unity编辑器的Window -> General -> Device Simulator中，可以模拟各种手机型号、分辨率和安全区，是前期快速测试的利器。
2. 构建简单的多分辨率测试工具：在编辑器中创建一个下拉菜单或输入框，可以快速切换Game视图的分辨率，模拟不同设备。
3. 真机测试是王道：编辑器测试无法完全模拟所有情况，尤其是安全区和特定设备的DPI问题。必须在最低、最高、以及最常见的主流真机上进行测试。
4. 关注UI的Draw Call和Batches：在Stats面板或使用Frame Debugger工具，检查UI渲染的Draw Call数量。一个优化良好的UI，其Draw Call应该尽可能少且稳定。