刚接触Unity3D那会儿，我干过一件特别蠢的事：想在屏幕正上方摆一个按钮，直接用transform.position = new Vector3(0, 200, 0)，结果按钮飞到了屏幕外面，怎么调都回不来。后来翻了RectTransform的文档才明白，UI位置的世界跟3D物体的世界根本不是一套坐标系。这个坑估计大半做过UI的同学都踩过，区别只是有些人后来绕明白了，有些人还在用改localScale、搬来搬去这类土办法硬撑。
这篇文章专门聊UI位置设置的底层逻辑和实操套路，覆盖RectTransform坐标体系、四种设置位置的写法、屏幕坐标和UI坐标的互转、以及设置位置时最容易踩的五个大坑，最后用一个工具提示框跟随鼠标的完整案例把所有知识点串起来。适合刚开始写UI、或者写过一阵子但一直被坐标问题折腾的开发者。
1. RectTransform坐标体系：设置任何UI位置前必须搞懂的概念
1.1 为什么UI的Transform和普通GameObject不一样
在Unity3D里，所有UI元素挂的都不是Transform，而是RectTransform。RectTransform继承自Transform，所以它保留了位置、旋转、缩放这些能力，但额外多了一套矩形坐标描述。你可以简单这么理解：普通Transform管的是"一个点在哪"，RectTransform管的是"一个矩形区域怎么摆"。
这个区别非常关键。普通3D物体可以只关心中心点坐标，因为它的碰撞体积、贴图基准都围绕这个点。但UI不一样，UI的显示范围是一块矩形，矩形有四个边、有中心点、有锚点，你得先明确"这个矩形相对于谁、以哪个点为基准来摆放"，才能把位置设对。
1.2 anchor（锚点）和pivot（轴心点）到底在控制什么
锚点和轴心点是RectTransform里最绕、也最容易被忽略的两个概念。
锚点（anchorMin/anchorMax）描述的是UI元素和父节点之间的绑定位关系。它的取值是0到1之间的比例，表示父节点矩形内部的某个相对位置。比如anchorMin = (0, 0), anchorMax = (0, 0)表示锚点在父节点的左下角；anchorMin = (0.5, 0.5), anchorMax = (0.5, 0.5)表示锚点在父节点的正中心。
锚点聚合成一个点的时候，我们叫"点锚"。点锚下anchoredPosition的含义就是：UI元素的pivot点相对这个锚点偏移了多少。锚点不聚合、拉开成一个区域的时候，叫"拉伸锚"，这种状态下UI会在锚点区域内自动拉伸，anchoredPosition表示的是pivot相对这个锚点区域中心（或特定点）的偏移。
轴心点（pivot）是UI元素自己的参照点，取值范围同样是0到1，(0.5, 0.5)代表矩形中心。旋转、缩放、以及位置计算都以pivot为基准。你说不清pivot是什么，位置设置就是一笔糊涂账。
1.3 position、localPosition、anchoredPosition三者的本质区别
这是设置UI位置时最基础、也最容易混淆的一组概念。我给了一张对比表：
| 属性 | 参照系 | 含义 | UI中能否直接使用 |
|---|---|---|---|
transform.position | 世界坐标系 | 在世界空间中的绝对位置 | 不推荐。UI坐标会被Canvas的缩放和渲染模式影响，设置结果不可控 |
transform.localPosition | 父节点坐标系 | 相对父节点的偏移 | 有条件使用。锚点为0时会退化成localPosition，否则两者数值会有偏差 |
rectTransform.anchoredPosition | 锚点坐标系 | 相对锚点的偏移 | 推荐。这是UI位置设置的正确入口 |
很多新手直接改transform.position，是把普通3D物体的操作习惯带到UI里了。UI元素在世界坐标系里的"绝对位置"很大程度取决于Canvas的摆放。你手动设置一个世界坐标，Canvas一缩放，显示位置立刻对不上预期，这就是最典型的翻车现场。
2. 设置UI位置的四类实操方式与适用场景
2.1 直接修改anchoredPosition：最日常的写法
日常开发中，设置UI位置最高频的写法就是改anchoredPosition。它表示UI元素的pivot点相对锚点的偏移，单位是像素（严格来说是Unity单位，但在UI体系里等同于像素逻辑单位）。
RectTransform rt = GetComponent<RectTransform>(); rt.anchoredPosition = new Vector2(100, -50);这行代码的意思是：让UI元素的pivot点，相对锚点向右100个单位、向下50个单位。前提是当前锚点是点锚。如果锚点在父节点中心，(100, -50)就表示在父节点中心偏右、偏下的位置。
有一点要注意：anchoredPosition的单位不受CanvasScaler的"参考分辨率"影响，它始终是本地逻辑单位。实际屏幕上表现出的物理像素值，要乘以Canvas的scaleFactor。所以你在1920x1080设计分辨率下写的(960, 540)，放到手机上因为scaleFactor不同，实际像素不同，但相对位置是对的。这也是为什么UI位置设置最好都走anchoredPosition而不是硬编码屏幕像素。
2.2 通过offsetMin和offsetMax撑开UI区域
锚点是拉伸锚（锚点是一个区域）时，offsetMin和offsetMax才是控制位置的正确入口。
offsetMin表示UI矩形左下角相对锚点区域左下角的偏移，offsetMax表示UI矩形右上角相对锚点区域右上角的偏移。手动设置这两个值的效果，等价于在Inspector的RectTransform面板里调整Left、Right、Top、Bottom四个字段。
RectTransform rt = GetComponent<RectTransform>(); // 让UI四边距离父节点边缘始终为20像素 rt.offsetMin = new Vector2(20, 20); rt.offsetMax = new Vector2(-20, -20);offsetMax取负值是因为右上角的偏移方向是向内收缩。这种设置方式特别适合做自适应面板：不管父节点多大，面板永远保持四边间距。如果你只是用点锚，offsetMin和offsetMax的意义会发生变化，它们会把锚点撑开，同样能达到拉伸效果，但这个操作比较绕，日常开发里点锚场景直接用anchoredPosition就够了。
2.3 用position或localPosition设置：什么时候能这么做
这里必须说实话：直接改localPosition和position在UI里不是绝对不行，但你要搞清楚自己设的是什么。
localPosition是相对父节点的偏移。当UI的锚点位于父节点左下角（(0,0)）时，anchoredPosition和localPosition在数值上是相等的。其他锚点设置下，两者会产生一个固定的差值，这个差值由pivot、锚点位置和自身尺寸共同决定。
position是世界坐标，UI中直接用的风险最高。Canvas在Screen Space - Overlay模式下，UI元素的世界坐标是混乱且没有直觉意义的，同一个UI在不同分辨率下世界坐标完全不一样。
如果你确定自己理解当前UI的锚点、pivot、以及Canvas的渲染模式，可以用localPosition做相对移动。一般建议还是老老实实走anchoredPosition，代码可读性和可控性都更好。
2.4 SetParent时的worldPositionStays参数：UI开发中的隐藏陷阱
这是个高频坑。很多人做UI弹窗、面板迁移时都会用SetParent，但第二个参数传true还是false，影响天差地别。
// 保持世界坐标（3D物体常用） child.SetParent(newParent, true); // 保持本地坐标（UI面板迁移推荐） child.SetParent(newParent, false);3D物体用SetParent(parent, true)是希望换父物体后仍待在原地。但UI场景完全不同，Canvas的缩放和锚点计算会让"保持世界坐标"变成一个不可控的行为——尤其当新旧父节点的RectTransform大小不一致时，UI会瞬移到一个莫名其妙的位置。
UI操作里我习惯传false，然后再手动设置anchoredPosition。这样每次迁移后的位置都是可预期的，不会出现"换了个父对象，位置飞了"的灵异事件。
3. 屏幕坐标、世界坐标与UI坐标的互转：让UI跟随鼠标的完整方案
3.1 RectTransformUtility是唯一的官方桥梁
UI坐标和屏幕坐标之间的互转，本质上绕不开RectTransformUtility这个静态工具类。它里面封装了各种坐标空间的转换方法，其中最常用的是ScreenPointToLocalPointInRectangle。
这个方法的签名是：
public static bool ScreenPointToLocalPointInRectangle( RectTransform rect, // UI元素，通常是你要设置位置的父节点 Vector2 screenPoint, // 屏幕坐标 Camera eventCamera, // Canvas对应相机，Overlay模式传null out Vector2 localPoint // 转换后得到的UI局部坐标 )它返回的localPoint是相对于rect这个UI元素的局部坐标，像素单位。拿到这个值之后，可以直接赋给子UI的anchoredPosition，前提是子UI的锚点固定在rect的某个点上（比如中心）。
3.2 从屏幕坐标转到UI局部坐标的完整案例
这里我给一个UI跟随鼠标的经典写法。比如做一个Tooltip，鼠标在哪个位置，提示框就跟着出现在哪个位置：
public class TooltipFollow : MonoBehaviour { public RectTransform canvasRect; // Canvas的RectTransform public Camera uiCamera; // Overlay模式传null即可 void Update() { Vector2 uiLocalPos; bool success = RectTransformUtility.ScreenPointToLocalPointInRectangle( canvasRect, Input.mousePosition, uiCamera, out uiLocalPos ); if (success) { // canvasRect的pivot通常在中心，直接用这个值设置anchoredPosition GetComponent<RectTransform>().anchoredPosition = uiLocalPos; } } }这段代码能跑通的关键在于：ScreenPointToLocalPointInRectangle给出的局部坐标，已经经过了CanvasScaler的缩放换算。也就是说不管适配模式怎么设置，你拿到的localPoint都是可以直接用于anchoredPosition的UI坐标系数值。
3.3 Canvas的三种渲染模式对坐标转换的影响
坐标转换里最容易出错的点是Canvas的Render Mode。三种模式下，eventCamera参数和转换逻辑都有区别：
| Canvas渲染模式 | UI所在空间 | eventCamera传入 | 典型场景 |
|---|---|---|---|
| Screen Space - Overlay | 屏幕空间（无相机） | null | 常规UI、HUD界面 |
| Screen Space - Camera | 指定UI相机前平面 | UI相机 | 模型上叠加UI、特效UI |
| World Space | 3D世界空间 | 场景主相机 | 血条、名字漂浮框 |
World Space模式下，UI本质上是3D世界里的一个平面物体，RectTransformUtility转换时需要使用能渲染这个Canvas的相机。传错相机类型或者传null，转换结果就会出现整体偏移。
我见过一个很典型的案例：World Space血条UI，坐标转换总是差几百个像素，最后排查下来是Canvas挂在了Screen Space - Camera模式下，代码里eventCamera却传了场景主相机。两个相机的视口角度不同，算出来的平面位置自然对不上。
3.4 实战补充：把UI元素转到世界坐标做放置
反向需求也经常出现：我根据UI位置放置一个3D物体，或者把UI位置对应到世界坐标。这时用RectTransformUtility.ScreenPointToWorldPointInRectangle会更顺手：
Vector3 worldPos; RectTransformUtility.ScreenPointToWorldPointInRectangle( targetRect, screenPoint, camera, out worldPos );这里返回的worldPos是投射到targetRect所在平面上的世界坐标点。做AR、或者需要把3D特效对齐到UI位置时特别有用。比如在UI按钮上播放一个粒子特效，先把按钮中心转成世界坐标，再设置特效的transform.position，就对齐了。
4. 设置UI位置时绕不开的五大坑
4.1 坑一：锚点不一致，同样的anchoredPosition显示位置完全不同
你写anchoredPosition = new Vector2(100, 100)，在不同锚点下含义不一样。锚点固定在中心时，它表示相对父节点中心向右上偏移；锚点固定在左上角时，它表示相对左上角向右下偏移。两处UI的代码一样，但显示出来一个在中间、一个在角落。
这个问题难排查的地方在于：代码看起来完全一致，Inspector里数值也是一样的，但预览效果天差地别。我建议先看Inspector的RectTransform面板，把锚点预设统一。团队协作时，UI预制体最好固定锚点风格，否则别人改个锚点，你的代码逻辑就全偏了。
4.2 坑二：CanvasScaler分辨率适配导致的位置偏移
CanvasScaler是Unity UI适配的核心组件，它根据屏幕实际分辨率和参考分辨率计算一个scaleFactor，用来缩放整个Canvas。
如果你写死了anchoredPosition = new Vector2(1920, 1080)，这是在设计分辨率下写的。实际设备如果分辨率比1920x1080窄，scaleFactor变化后，UI位置可能超出屏幕边缘。解决办法是：尽量用锚点比例来布局，而不是写死像素偏移。确实需要像素值时，要用当前屏幕尺寸参与计算：
float screenWidth = Screen.width; float rightMargin = 100f; rectTransform.anchoredPosition = new Vector2(screenWidth / 2f - rightMargin, 0);注意Screen.width是物理像素，如果Canvas的scaleFactor不等于1，anchoredPosition里还要除以scaleFactor。最稳妥的方式还是用RectTransformUtility做坐标转换，让Unity替你把缩放问题处理掉。
4.3 坑三：UI动画和代码同时改位置导致互相覆盖
这个坑特别隐蔽。你写了一段代码在Update里持续修改UI位置，但发现位置纹丝不动，或是一帧对一帧乱跳，大概率是Animator在作祟。
Unity的Animation系统每一帧都会对动画轨道上涉及的属性做采样并写回。如果你的AnimationClip里恰好有Position相关的动画曲线，它的优先级会覆盖代码里赋的值。更坑的是，你自己在Inspector里点了"Add Property"误加了RectTransform的m_AnchorMin或m_AnchoredPosition，动画播放时你就彻底失去了控制权。
排查方法也简单：查看UI元素上有没有Animator组件，有的话检查Animator窗口当前播放的Clip里有没有Position曲线。如果只是想临时动画一下，直接用代码做插值（比如Vector2.Lerp），别走Animator。
4.4 坑四：父节点缩放导致子UI位置计算异常
RectTransform的anchoredPosition是相对锚点的偏移，但如果父节点有缩放，这个偏移会被连带缩放。举个例子：父节点scale是(2, 2, 1)，子节点anchoredPosition设(100, 0)，实际显示在世界空间是偏移200像素。
这个问题在CanvasScaler的动态缩放下会更隐蔽，因为你很难感知父节点当前的scale是多少。排查时可以检查所有中间父层级是否有非1的scale值。在UI体系中，我自己有一条经验原则：布局层的节点尽量保持scale为1，缩放动画作用在叶子节点上。这样坐标计算始终是1:1的，不容易出幺蛾子。
4.5 坑五：LayoutGroup接管后，手动设置位置全部白费
UI里用了HorizontalLayoutGroup、VerticalLayoutGroup、GridLayoutGroup，或者ContentSizeFitter，那恭喜你，你手动设置的anchoredPosition会在下一帧布局重建时被全部冲掉。
LayoutGroup的原理是统一管理所有子节点的位置和尺寸，它的优先级高于手动赋值。这不是bug，是设计如此。如果有元素需要特殊位置，要么把它移出布局组，要么给布局组件配置padding、spacing这类参数来达到效果。
如果你想在布局组件生效后再做微调，可以调用LayoutRebuilder.ForceRebuildLayoutImmediate(rectTransform)强制刷新布局，紧接着再修改位置。但要注意，这是临时方案，任何导致布局重新计算的操作都会再次冲掉你的修改。长期维护的代码不建议这么写。
5. 一个完整范例：自定悬浮提示框的实时位置跟随
5.1 需求分析与坐标转换选型
我把前面提到的所有知识点串起来，做一个实际项目里高频出现的功能：自定义Tooltip悬浮提示框。鼠标悬停在某个按钮上时，提示框跟随鼠标出现在其右下角；鼠标接近屏幕边缘时，自动翻转到另一侧，避免超出边界。
这里需要用到三个关键能力：
- 屏幕坐标转UI局部坐标（用
ScreenPointToLocalPointInRectangle） - 动态设置
anchoredPosition - 界边界判断，通过
canvasRect.rect.size和UI自身的rect.width/height计算
完整代码如下：
using UnityEngine; using UnityEngine.UI; public class CustomTooltip : MonoBehaviour { [SerializeField] private RectTransform tooltipRect; [SerializeField] private CanvasGroup tooltipCanvasGroup; [SerializeField] private Text contentText; [SerializeField] private RectTransform canvasRect; [SerializeField] private Camera uiCamera; // Overlay模式传null private Vector2 offset = new Vector2(15, -15); void Awake() { // 缓存RectTransform和CanvasGroup，避免运行时频繁GetComponent if (tooltipRect == null) tooltipRect = GetComponent<RectTransform>(); if (tooltipCanvasGroup == null) tooltipCanvasGroup = GetComponent<CanvasGroup>(); Hide(); } public void Show(string content, Vector2 screenPos) { contentText.text = content; tooltipCanvasGroup.alpha = 1f; tooltipCanvasGroup.blocksRaycasts = false; // 想尽办法拿到父Canvas的RectTransform作为转换基准 if (canvasRect == null) { canvasRect = GetComponentInParent<Canvas>().GetComponent<RectTransform>(); } Vector2 localPos; if (RectTransformUtility.ScreenPointToLocalPointInRectangle( canvasRect, screenPos, uiCamera, out localPos)) { SetTooltipPosition(localPos); } } public void Hide() { tooltipCanvasGroup.alpha = 0f; } private void SetTooltipPosition(Vector2 localPos) { // 默认显示在鼠标右下角 Vector2 desiredPos = localPos + offset; tooltipRect.anchoredPosition = desiredPos; // 边界检测：先强制布局更新，拿到正确的矩形尺寸 LayoutRebuilder.ForceRebuildLayoutImmediate(tooltipRect); float tooltipHalfWidth = tooltipRect.rect.width * 0.5f; float tooltipHalfHeight = tooltipRect.rect.height * 0.5f; // canvasRect的pivot应该在中心，坐标为(-width/2, -height/2)到(width/2, height/2) Vector2 canvasSize = canvasRect.rect.size; float leftBound = tooltipRect.anchoredPosition.x - tooltipHalfWidth; float rightBound = tooltipRect.anchoredPosition.x + tooltipHalfWidth; float topBound = tooltipRect.anchoredPosition.y + tooltipHalfHeight; float bottomBound = tooltipRect.anchoredPosition.y - tooltipHalfHeight; Vector2 finalPos = tooltipRect.anchoredPosition; if (rightBound > canvasSize.x * 0.5f) { // 超出右边界，翻转到鼠标左边 finalPos.x = localPos.x - tooltipHalfWidth - offset.x; } if (topBound > canvasSize.y * 0.5f) { // 超出上边界，翻转到鼠标下方 finalPos.y = localPos.y - tooltipHalfHeight - offset.y; } if (bottomBound < -canvasSize.y * 0.5f) { finalPos.y = localPos.y + tooltipHalfHeight + offset.y; } tooltipRect.anchoredPosition = finalPos; } }5.2 为什么我用CanvasGroup而不是SetActive
这个案例里我没有用SetActive来控制显隐，而是用CanvasGroup的alpha。原因很简单：Tooltip这类UI是高频呼出和关闭的，频繁SetActive(true/false)会持续触发Canvas重建，造成"UI界面卡顿"——这个现象在低端设备上特别明显。
SetActive(false)后，UI不再参与渲染和布局，但激活/失活是有开销的。CanvasGroup.alpha = 0时，UI仍然渲染，但开销小，切换速度快，而且可以配合DOTween做淡入淡出。blocksRaycasts = false确保隐藏的Tooltip不拦截鼠标事件。
5.3 实测心得：反射位置与边界检测的顺序问题
第一次写这个功能时，我把边界检测放到了设置位置之前，结果提示框内容变化后，rect.width还是旧的，翻转判断永远不准。
后来我在边界检测前加了一行LayoutRebuilder.ForceRebuildLayoutImmediate(tooltipRect)，强制让布局系统立即重算内容尺寸。这个调用放在主流程会有一点性能开销，但对于Tooltip这种低频更新的UI来说，完全可以接受。
另外，这个功能里有一个小细节值得注意：canvasRect.rect.size是Canvas的实际尺寸，如果在CanvasScaler的匹配模式不是"宽高比匹配"的情况下，它的宽高并不等于参考分辨率。我一开始拿ReferenceResolution的1920x1080来做边界判断，结果在宽屏设备上提示框被判定为越界，直接翻了方向。改用canvasRect.rect.size后一切正常，因为这是运行时Canvas的实际逻辑尺寸。
最后再分享一个我自己摸索出来的习惯：所有需要动态设置位置的UI元素，我都把锚点固定在父节点的中心（0.5, 0.5），pivot保持在（0.5, 0.5）。这样anchoredPosition始终表示"UI中心相对父节点中心的偏移"，坐标系直观、代码可读性强，边界计算也能统一用canvasRect尺寸配合rect.width/height来做。这个小小的一致性约定，帮我省掉了大量排查位置偏移的时间。
