企业官网建设流程全解析

UGUI 的 Image 组件，表面上看就是"拖一张图上去显示"，但这几年我调 UI、查性能、改动效，反复跟它打交道之后，越觉得它值得专门拆开讲。系列第一篇把 Image 的属性、Sprite 的九宫格概念、Inspector 上那些选项都过了一遍，这篇第二篇就聚焦"为什么它有时候不听话"和"实际项目里到底怎么用"。比如同一张图放进不同 RectTransform 尺寸下变形、Filled 做进度条、Tiled 平铺的尺寸坑、Image 的网格生成机制，以及它作为 MaskableGraphic 在 Canvas 重绘里的位置——这些都属于一踩一个准的硬核细节。这篇适合刚写完第一个 UI Demo 的初级开发，也适合做了几个项目但"知其然不知其所以然"的客户端同学，把 Image 的显式行为、隐式代价、常见误用一次说透。

1. 为什么 Image 值得单独拆一篇讲

1.1 Image 组件远不止一个"图片显示框"

先从组件关系说起。Image 继承自 MaskableGraphic，MaskableGraphic 又继承 Graphic，Graphic 再往上就是 UIBehaviour 和 CanvasRenderer 这套链路。这意味着 Image 不是一个简单的"图片控件"，它本质上是一套"Mesh 生成 + CanvasRenderer 提交渲染"的完整管线。你改一个 color 属性、换一张 sprite、调整 Image Type，背后都会触发 Canvas 的 Rebuild——重新生成网格、重新提交渲染数据。这是理解后续所有性能问题和异常表现的基础。

很多同学刚接触 UGUI 时，会觉得 Image 不就是个显示图片的容器吗？拖一个 Sprite 进去，设置 RectTransform 的宽高，图片就出来了。这句话没毛病，但它只描述了"最顺滑的路径"。一旦你开始做动态换图、自适应布局、不同分辨率下的拉伸、遮罩裁剪、动效中的尺寸变化，就会发现 Image 的行为并不是无脑的"图片缩放"，而是由一系列内部规则决定的：Sprite 的 Border 是否有效、Image Type 的退化逻辑、RectTransform 的 anchor 和 pivot 怎么参与驱动、Canvas 的 batch 如何受它影响。这些东西在官方文档里是零散记录的，实际排查时只能靠经验串起来。

所以这篇文章我不打算按 API 手册顺序念一遍，而是按"你实际会遇到什么问题"来组织。每个问题背后都对应 Image 内部的一条机制，清楚了机制，问题自然就解决了。

1.2 从 UGUI 的渲染模型看 Image 的定位

UGUI 整个系统的渲染依赖 Canvas 下的 CanvasRenderer。每个 UI 元素（Text、Image、RawImage）会把自己生成的 Mesh 交给 CanvasRenderer，Canvas 负责把所有 Renderer 的 Mesh 合批并送交 GPU。Image 在这里的角色是：根据 Sprite 的像素数据和 Image Type 的规则，生成一个矩形或扇形的 Vertex 网格，再配上 UI/Default 之类的 shader 和一个材质实例。

这个模型解释了三个常见现象：

• Image 尺寸变化时，网格会重新生成，但移动位置不会。因为 RectTransform 的位置变化是在 Canvas 世界坐标层面解决的，不触发顶点重建；而宽高变化直接改变顶点坐标，必然触发 Rebuild。
• Image 的透明度实现是改变顶点颜色里的 alpha 通道，而不是改 Shader 的透明度。所以 Image.color 的 alpha 值调整成本很低，不像某些原生 UI 引擎需要重新上传纹理。
• Image 的批次合并跟它上面的 Sprite 纹理关系很大。同一图集、相同材质、紧邻的 UI 元素才有机会合批；中间插一个不同纹理的 Image，就会打断批次。

在你真正去动 Image 的源码或者做自定义 UI 组件之前，先把这个模型刻在脑子里，后面所有排查都是围绕它展开的。

2. 四种 Image Type 的完全拆解

2.1 Simple：默认却有细节

Image Type 默认是 Simple，听名字以为它最简单，但它内部也有两个容易忽略的细节。第一个是 SetNative Size 按钮，它会根据 Sprite 的原始像素尺寸去设置 RectTransform 的宽高。很多新手以为这个操作是"让图片自适应显示"，其实它是把 UI 矩形直接改成图片的实际像素大小。放在不同屏幕密度下，这个尺寸不会自动缩放，所以如果项目有动态分辨率适配，别指望 SetNative Size 一劳永逸。

第二个细节是 Simple 模式对 Pivot 的处理。Image 的缩放中心受 RectTransform 的 Pivot 影响，如果你准备做一个"从中心放大"的动效，RectTransform 的 anchor 和 pivot 都得检查一次，不然图片会从左上角或右下角"长出来"。我见过好几个同事在 Simple 模式下做打开弹窗的缩放动画，位置到处飘，最后发现是 Pivot 设置问题。

Simple 模式还有一个很少人注意的退化行为：当你把 Sprite 的 Pixels Per Unit 调得很大，或者把 Image 的尺寸缩得比原始像素小很多时，UGUI 会直接按纹理采样来缩放，不会做额外的过滤处理。结果就是图片缩小后出现摩尔纹或锯齿，这时候你以为是图的问题，其实是缩放方式过于粗暴。要解决，要么把纹理先生成 mipmap，要么在放缩比例巨大时改用 Sliced 或其他策略。

2.2 Sliced：九宫格才是 UI 切图的灵魂

Sliced 的原理是把 Sprite 按照 Border（边框）切分成九块：四个角保持原始像素比例，上下左右四条边沿各自方向拉伸，中间部分拉伸填充。这样我们在做按钮背景、对话框底板、血条外框时，可以做到任意尺寸不变形。但这里有几个边界条件，处理不好它会悄悄退化成 Simple 模式。

首先，Sprite 的导入设置里必须把 Texture Type 设为 Sprite，并且切好 Border。很多美术给的图没有设置 border，你就算在 Image 上选了 Sliced 也不会生效，图片整体被拉伸，看起来还是"变形的简单模式"。其次，当 Image 的 RectTransform 宽高小于 border 对应的四角尺寸总和时，UGUI 会触发退化：一个小尺寸下强制用拉伸，具体表现是新版本会"扩展角"保证圆角不挤变形，旧版本则可能直接退化成简单拉伸。这个情况在做小尺寸徽章、小红点时特别容易出现，所以你看到一个小圆点被拉成椭圆，先别怀疑素材，先检查尺寸是否小于 border 总和。

Sliced 模式下还有一个 Fill Center 开关，默认是勾选的。它可以控制是否生成中间的填充网格。如果某个九宫格背景中间是空的，比如一个相框、一个对话框边框，把 Fill Center 关掉，可以减少中间大块无谓的透明三角形网格，对减少 Overdraw 有一点点帮助。但要注意，这不是省 draw call 的关键，真正的收益在填充率上，移动端设备有限制时才有明显体感。

另外，当你把 Sprite 打进图集时，建议保持足够的内边距（Padding）。如果切图时裁得太狠，border 附近的多余像素被裁掉，九宫格拉伸后边缘会出现颜色溢出或白边，这类问题通常要逐像素看纹理才能发现。

2.3 Tiled：平铺的尺寸敏感问题

Tiled 模式适合做地板纹理、聊天背景这类需要重复填充的内容。它的平铺规则实际上是"基于九宫格进行重复"：四个角出现一次，四条边按方向平铺，中心区域按纹理平铺。也就是说，如果你想用 Tiled，Sprite 也必须先设置好 Border，否则没有边框来约束平铺的起始位置，Tiled 会退化成 Simple。

Tiled 最常见的坑有两个。第一个是平铺大小跟预期不符。你在编辑器里看着很舒服，但运行到不同分辨率或者调整 PPU（Pixels Per Unit）后，平铺的格子忽大忽小。这里的关键是 Image.Tile 尺寸跟 Sprite 的 Pixels Per Unit 挂钩，而 PPU 又跟项目里 Unity UI 的全局 Scale Factor 有关。第二个坑是当 RectTransform 尺寸不是原图的整数倍时，边缘会出现一个"半块"贴图，视觉上非常扎眼。解决办法要么是设计纹理时把图案做成可无缝拼接，并且尺寸设计成常见目标尺寸的约数；要么在代码里动态调整 Image 的尺寸，保证它是原图宽高的整数倍。

我在项目里一般不建议 UI 里大量使用 Tiled 做背景，除非纹理设计得非常好。因为平铺模式下 UI 网格会新增大量顶点，每平铺一格就多四个顶点（严格说按 Unity 的网格生成方式是以 tile 为单位切分），一个全屏背景可能生成上千个顶点，虽然不至于卡顿，但对移动端来说没必要。更优雅的做法是背景用 Sliced + 模糊图案，或者直接用 RawImage 平铺一张 256 的小纹理。

2.4 Filled：进度条和技能冷却的主力

Filled 是 Image 里最被低估的类型。它用 fillAmount（0 到 1）控制显示的比例，用 fillMethod 控制填充方式：Horizontal、Vertical、Radial90、Radial180、Radial360。这个模式天生适合做血条、能量条、技能冷却遮罩、扇形雷达图。

实际开发里，进度条用 Horizontal 和 Radial360 最多。Horizontal 简单，把 fillAmount 从 0 拉到 1，配合左对齐 Pivot，视觉效果就是从左到右填充。Radial360 做技能冷却罩，把一张半透明的技能图标放在底层，上层 Image 设置成 Radial360 + 灰色遮罩，通过 fillAmount 控制遮罩露出范围，就能实现"图标从灰到亮"的冷却效果。这个做法比用 Mask 或 Shader 简单得多，性能也完全够。

Filled 模式下有几个细节必须注意。第一，fillOrigin 的含义随 fillMethod 不同而不同。Horizontal 的 origin 有 Left/Right，Vertical 有 Bottom/Top，Radial 则按角度方向分为四个象限。如果你设置了 fillAmount 但没注意 origin，会出现"从右边开始空出来"这种反直觉的现象。第二，Filled 对 Sprite 的 border 不友好。如果你给一个九宫格 Sprite 设置 Filled 类型，网格生成会按扇形或矩形分区来处理，四个角的 border 不会像 Sliced 那样单独保持像素，所以进度条底部不要用带边框的图，不然填充到一半时边框会变形。我强烈建议进度条素材只用简单的纯色渐变图，或者用 Sliced 打底 + Filled 作为第二层。

第三，fillAmount 是 float，频繁改变它会导致 Image 的网格重建。进度条如果在 Update 里每一帧改 fillAmount，整个 UI 的 Canvas 可能跟着频繁 Rebuild。性能优化时要么把进度条放在独立 Canvas 上，要么用少量更新频率的曲线函数去驱动 fillAmount，比如每 0.1 秒更新一次，或者用协程让数值变化不产生连续的顶点重建。

3. Image 和布局系统协同工作的正确姿势

3.1 为什么 Image 的宽高经常"不听话"

很多人会碰到这个问题：放进 HorizontalLayoutGroup 或 VerticalLayoutGroup 之后，Image 被布局组件拉得失去比例。这是因为 Image 本身没有实现 ILayoutElement，它对布局系统没有提供 preferredWidth 或 preferredHeight。布局系统不知道该给它多大，所以只能按 group 里配置的尺寸去强制改 RectTransform，最终图片就被拉伸变形了。

解决思路是显式告诉布局系统 Image 期望的尺寸。你可以在同一个 GameObject 上挂 LayoutElement，设置它的 preferredWidth 和 preferredHeight 为 sprite 的像素宽高，这样布局组件会优先按 preferred 尺寸排。但 LayoutElement 的 preferredWidth 是静态的，不会自动跟随 Sprite 变化。如果你打算换图后也自动缩放，可以写一个小脚本，监听 Sprite 变化后更新 LayoutElement 的 preferred 值，或者在重置布局时调用 LayoutRebuilder.ForceRebuildLayoutImmediate。

这里顺便说一句，SetNativeSize 不能解决布局系统的问题。它只是改了 RectTransform.sizeDelta，但不影响 LayoutElement 的 preferred 尺寸。所以在布局容器里 SetNativeSize 可能在下一帧被布局组件重新覆盖，看起来就像"设置了不生效"。

3.2 用 AspectRatioFitter 保住图片比例

如果需求只是"无论如何保持图片原始宽高比"，那么不需要写任何脚本，直接在 Image 同节点挂 AspectRatioFitter，把 AspectMode 设为 Envelope Parent，再配合 width/height 两者中受控制的一侧，就能保证图片按 sprite 的宽高比缩放到父节点允许的最大尺寸。实测下来这比手动写 Update 强得多，而且不用关心分辨率变化。

AspectRatioFitter 的 AspectRatio 可以手动设置成任何 float，但一般用 Sprite 的原始宽高比。注意每次换 Sprite 时，这个 ratio 不会自动更新，需要代码里重新赋值。另一个细节是 AspectRatioFitter 和 ContentSizeFitter 如果同时挂在同一个对象上，容易引发布局死循环——AspectRatioFitter 要缩放尺寸，ContentSizeFitter 也要根据内容缩放尺寸，两者互相驱动。这时候需要把其中一个放到子节点或父节点，让它们分别处理不同方向，别让两个 fitter 在同层级较劲。

3.3 和 ContentSizeFitter 搭配时要注意什么

ContentSizeFitter 的思路是"根据内容决定尺寸"，但 Image 不是内容型控件，它没有原生 preferred width/height，所以像文本组件那样自动扩展是不行的。如果你确实需要类似"Image 自动包裹 Sprite"的效果，我的做法是给同物体挂一个自定义 LayoutElement 脚本，重写 ILayoutElement.CalculateLayoutInputHorizontal 和 Vertical，在拿到的 LayoutInput 里把 sprite.rect.width / sprite.rect.height 填进去。这样 ContentSizeFitter 就能读到 preferred 尺寸，自动把 Image 撑成图片原始大小。

实战里一个典型的组合是：外层 VerticalLayoutGroup 排列表，每行有一个图标（Image）和一段文字（Text），图标需要按不同 Sprite 自动调整宽高。给 Image 套一个自定义 LayoutElement，每次换 sprite 后调用 LayoutRebuilder.MarkLayoutForRebuild，整行高度会自动跟着图标高度变化。这个模式比固定 icon 尺寸灵活很多，也避免了图片被拉变形。

写这个脚本时，要注意 Sprite 为 null 时返回一个默认尺寸，否则布局系统可能读到 0 导致整行塌陷。另一个注意点是尽量在 LayoutElement 的 min/preferred/flexible 中选一种语义一致的值，不要混着填，否则在复杂的嵌套布局里会出一些玄学排序问题。

4. 渲染与性能：Image 的优化深度

4.1 合并批次的基本逻辑和 UI 网格

UGUI 的批次合并不是面向对象的，而是面向前后顺序的。Canvas 下的多个 CanvasRenderer 按照在 Canvas 中注册的顺序，依次提交各自网格。合并条件通常有三个：使用相同材质球、使用相同纹理、以及中间没有被不同深度或其他元素打断。Image 在这条规则里的影响非常大，因为它直接绑定 Sprite 纹理。

同一张图集里的多个 Image 就地合并的前提是它们之间没有插入一层不同材质的 UI 元素。如果你在图片列表里放了一个带 Shader 的高亮特效，它会把前后两个同图集 Image 的批次打断，合批就失效了。此外，Image 的 color 改变不会打断合批，因为颜色是顶点属性，存放在网格里，不是材质参数。这一点很有用：你可以在动画里频繁改 Image.color 的 alpha，而不会让 UI 重开批次。

Image 的尺寸变化和 Sprite 替换会改变网格内容，Canvas 会重新 Batched 数据。一次重排的 CPU 成本在复杂 UI 下还是比较明显的。我的建议是：同一界面的高频动效尽量控制在局部节点，必要时把动效区域放到独立 Canvas，避免因为动效不断引起整个 Canvas 的 Rebuild。

4.2 Overdraw 与透明区域

Image 最简单的形态是四个顶点加两个三角形。哪怕是完全透明的区域，只要图片矩形存在，Mesh 就存在，GPU 在渲染这个像素的时候就要执行一次透明混合。移动端填充率有限时，Overdraw 是很现实的成本。很多中低端机 UI 卡顿，不是顶点数爆炸，而是整个屏幕被多层半透明 UI 叠了一遍又一遍。

所以我在项目里看到透明区域的 Image 会特别警惕。比如一个圆形的头像，原图本身是矩形、四个角全透明，如果直接放上去，这四角的透明像素也会被 UGUI 渲染一遍。虽然透明像素在看不见的层面"无效果"，但它确实参与了 Blending。这种情况能用 RectMask2D 做裁剪的话，就让透明角不参与渲染；但注意 RectMask2D 的裁剪本身会增加一张模板或者额外绘制步骤。更简单的方式是把美术切图时就把透明区域裁掉，或者把不规则图形用多边形 Stage 在 PhotoShop 里处理成接近实际形状的网格。

一个更省的做法是设置 Image 的 alphaHitTestMinimumThreshold，把透明区域从 Raycast 中排除，但这只影响事件检测，不影响渲染。如果只想解决"透明区域挡住点击"，这个属性非常合适；如果想解决 Overdraw，它帮不上忙。

4.3 Raycast Target：默认勾选的隐性成本

Image 的 Inspector 上有一个 Raycast Target，默认是勾上的。它的作用是让这个 Image 接收 UI 事件：鼠标点击、拖拽、悬停等。如果你有一堆纯展示用途的 Image（比如背景、装饰线、不可点击的图标），它们默认参与了 GraphicRaycaster 的检测，每一帧排过一遍遮挡，在复杂 UI 里会增加不必要的 CPU 开销。

实际操作中，我习惯把所有纯装饰 Image 的 Raycast Target 都取消勾选。这样事件系统只检测真正需要交互的 UI，少了很多无谓的"挡路"问题。你可能遇到过"按钮被一个看不见的全屏 Image 挡住了点不中"的情况，根因就是这个全屏 Image 开着 Raycast Target。这也是"透明区域挡住了点击"问题的最常见来源之一。

不过不要为了性能把按钮本身的 Raycast Target 关掉，那会让按钮完全失去点击能力。另外，如果你在代码里动态改变 Image 的 raycastTarget，注意 Image 继承自 Graphic，它的 raycastTarget 属性在运行时改是生效的，影响的是下一次事件检测，不需要重新生成网格，放心用。

4.4 图集与 Sprite 的规范

Image 用的 Sprite 最终来自 SpriteAtlas。图集的意义不只是省显存，更重要的是让 UI 贴在同一张纹理上，便于合批。实际项目里要避免两种操作：一是加载单张零碎 PNG 给 Image，完全不进图集，导致每个 Image 单独一个 Texture，合批直接失效；二是把 UI 图集设置得过大，一张 4096 的图集在某些手机上显存占用大，而且容易超过设备单一纹理上限。

图集的配置里，Sprite 的 Packing Tag 要严格按 UI 界面或功能模块划分，不要把所有美术资源打一张图集。否则改动某一个 Sprite 会更新一整张大图，加载时间也会变长。代码里引用 Sprite 时要尽量用图集内 Sprite 对象而非单独 Asset，这样资源内存管理会更可控：图集作为整体加载和卸载，比零散加载命中率更高。

关于 Sprite 的 Reference Pixels Per Unit 也要提一下。UGUI 在生成网格时，会用 sprite 的 pixelsPerUnit 除以项目的 ReferencePixelsPerUnit（默认 100）来决定一个像素对应多少 UI 单位。如果两张图集的 PPU 设置不一致，同一 UI 里图片大小就会忽大忽小。遇到"明明 sprite 尺寸一样，显示出来尺寸不同"，第一步就去查这两张图的 Sprite 导入 PPU 和图集设置是否统一。

5. 运行时动态操作 Image 的落地写法

5.1 换图的两种常见方式和注意点

运行时给 Image 换图，最直白的是 image.sprite = newSprite。但这里有个隐藏问题：如果 newSprite 是动态加载出来的资源，比如用 Resources.Load 或 Addressables 异步加载，加载完成前 UI 上可能闪一下空白或者保留旧图。我建议先让 Image.enabled = false，加载完成后再赋值并开启，这样用户看不到"旧图被清空 / 新图未就绪"的中间态。

关于 overrideSprite，虽然 Unity 里 Image 同时有 sprite 和 overrideSprite 两个字段，现在的版本里 overrideSprite 已经标记为 deprecated，基本等价于直接改 sprite。如果你的代码还在大量使用 overrideSprite，建议逐步迁移，避免后续引擎版本行为差异。

换图后如果 Figure 尺寸变了，但 RectTransform 尺寸没跟着变，图片可能被拉伸或压缩。如果你的需求是"每次换图恢复原始比例"，赋值后调用 SetNativeSize 或在自定义 LayoutElement 时主动更新 preferredWidth/Height。如果只是临时替换相同用途的图（比如按钮 icon 从 A 换到 B），建议提前把图集内 Sprite 按尺寸规格统一，避免运行时反复变 size 引发布局抖动。

5.2 透明度渐变与淡入淡出的安全实现

Image 的淡入淡出本质上就是调整 color 的 alpha。你可以在 Update 里逐帧减 alpha，也可以写协程。但在实际项目里，我更推荐用 DOTween 的 CanvasGroup 或 Image.color 来驱动，省去自己管理协程的代码也易于打断。唯一要注意的是，DOTween 这种补间工具写 Tween 时不要在一个已销毁的 Image 上继续回调，否则会报 NullReferenceException，一般用 OnKill 或检查 gameObject 是否存活。

如果你自己写协程，我踩过的一个坑是：协程里等待的返回值类型问题。Unity 协程里如果要插延迟，必须 yield return new WaitForSeconds 而不是自己再套一层函数。还有，Image 在层级较多、CanvasGroup 也有 alpha 的时候，两者的透明度会相乘。像弹窗整体淡入时，父节点 CanvasGroup 的 alpha 和 Image.color 的 alpha 都在变化，最终显示透明度是两者乘积，调试时容易误判。

对于长时间持续的透明度变化，比如呼吸灯效果，不要每帧都创建一个新 Tween，那会造成大量垃圾对象。应该在同一条 Tween 上用 SetLoops(-1, LoopType.Yoyo) 循环，或者自己写一个轻量正弦波修改 alpha，并发控制在一两个数值变化上就好。

5.3 动态创建和销毁 Image 时最容易翻车的点

运行时通过代码创建 Image 很常见，但要注意一个非常基础的问题：动态 new GameObject 上的 Image 组件，需要手动设置它的 CanvasRenderer 会自动创建，这个不用担心；但要设置它的 RectTransform 尺寸和 anchor。很多新手只 new 了一个 GameObject 并 AddComponent，结果图片显示在原点且尺寸为 0，看起来就像"图片没显示"。实际上你看到的并不是图片没显示，而是尺寸是零。要先找机会 setup sizeDelta 或调用 SetNativeSize。

动态创建 Image 后，父节点的 Canvas 层级会影响它的渲染顺序。如果同一个 Canvas 下有多个动态 Image 按代码添加顺序排列，它们的渲染先后就是层级顺序的后到前。如果你要做"后来创建的显示在下层"，需要手动调用 transform.SetSiblingIndex(0) 或调整 position 的 z 值。这个和普通 GameObject 渲染顺序一致，但很多做 UI 的人会忽略。

销毁 Image 时，如果 sprite 来自 Addressables 或 Resources，销毁 UI 元素不会自动释放资源的引用。你需要先记录 sprite 引用并 release。否则 UI 元素虽然销毁了，但图集和纹理还在内存里，下次再次加载同样资源时可能命中缓存，造成不必要的内存峰值。我在一个中型项目里见过这个问题，后来统一封装了一个 UILoader 工具类，负责加载 Sprite、绑定 Image、并在销毁时统一 Release，才把内存曲线压下来。

6. 高频问题排查与避坑速查表

6.1 图片不显示、显示白块或洋红色

我把实际排查顺序列成一张速查表，按出现频率从上到下看：

排查这类问题我一般先在 Hierarchy 里选中该 Image，看 Inspector 里 Sprite 是否显示正常；然后右键该对象，看 Debug 模式下 CanvasRenderer 的 Material 是否正常；第三步是关掉其父节点的全部 Image 看是否被遮挡。这三个步骤能覆盖绝大多数"看不到图"的现场。

6.2 图片拉伸变形

图片被拉伸变形的最常见原因就是上文提过的：Image 的 RectTransform 被布局系统或动画强制改得跟 Sprite 原始宽高比不一致。如果你看到变形，先判断是编辑器静态变形还是运行时动态变形。静态变形基本是拖拽造成的：把 Image 的宽高手动改得和原图比例不一致；运行时变形更多来自 LayoutGroup、ContentSizeFitter 或代码里对 sizeDelta 的赋值。

解决方案分两层：如果只是临时显示，可以手动改宽高到 1:1；如果要求不随尺寸变化，需要选择 Sliced 或把控件放在 AspectRatioFitter 下。还有一种很隐蔽的情况是 Sprite 的 Pivot 在导入时被调偏了，比如美术导出 PNG 时边上有空白，Sprite 的 pivot 设置成 (0.5, 0.5)，显示时看起来就带透明边缘的"偏移"效果。这时候用 Sprite Editor 设置 Pivot 为 Center 也不会完全解决，得让美术裁掉空白。

6.3 九宫格切图失效

九宫格失效通常有几个层次。第一层是 Sprite 导入设置里 Texture Type 已设为 Sprite，但 Inspector 上没有显示 Border 可编辑的四个数字，说明这个 Sprite 没有定义边框。第二层是 Image Type 没有选 Sliced，或者选了 Sliced 但 Sprite 本身是 Simple 的。第三层是 Sliced 模式下 Image 尺寸小于 border 总和，发生退化。第四层是图集打包时把 Sprite 裁掉了一圈透明边，导致 border 的偏移量不再匹配原图。

我建议美术同事在处理 UI 切图时就把 border 写清楚：比如按钮背景，通常左右 border 相同且等于圆角半径，顶部底部 border 也等于圆角半径。如果你拿到一张没 border 的按钮图，用 Sprite Editor 手动拉出四条边也不是难事。关键是要理解 border 对应的是"不可拉伸的角区域"，不是"要保护的内容区域"。用来放文字的按钮背景，border 要确保文字区域不会被拉伸。

6.4 圆形头像、遮罩和 alphaHitTest 的取舍

做圆形头像最直接的做法是放一个半透明边缘的圆形 PNG，但四角区域会有透明像素，无法完全消除四周的"方框轮廓"。这个时候可以挂 Mask 组件或 RectMask2D，让头像显示范围被限制在圆形区域。但 Mask 组件使用模板缓冲，会增加额外的绘制开销，而且 Mask 区域内如果包含多个子 Image，批次数会受影响。RectMask2D 的裁剪方式更轻量，但与多个嵌套矩形裁剪的兼容性稍差，需要实测。

如果你只是想让"点击头像时，点在透明部分不算点击"，用 Image.alphaHitTestMinimumThreshold 即可。这个属性读到非透明像素阈值，大于设置值时返回 true。注意它要求 Sprite 的纹理是 Read/Write Enabled，并且纹理格式在计算时可读。编辑器下没问题，构建后如果纹理压缩成 DXT/ASTC，部分格式可能不支持精确读取，这时需要手动给关键头像纹理关掉压缩或者提供一条可读版本。

圆形头像的抗锯齿问题更麻烦。UGUI 默认 shader 不做特别抗锯齿，圆形裁剪边缘会有明显的锯齿。如果这是上线项目里不能避免的视觉效果，我建议让美术把头像做成带一圈 1-2 像素透明渐变的 PNG，然后是 Sliced 或 Simple 显示，边缘视觉柔化。想要更高质量的，可以换用自定义 UI Shader，在片元阶段按 UV 距离计算 alpha 实现抗锯齿圆形，但这个是另一个话题了。

结尾

写到这里，Image 的常见机制和实战坑基本都过了一遍。我个人实际操作中的体会是：UGUI 的 Image 看着只是个控件，但它和 Canvas、RectTransform、Sprite、图集、事件系统之间的交互远比想象中复杂。你在调一个 Image 的问题时，往往牵动的是整个 UI 数据链。建议各位在做界面时，一开始就上齐工具：关掉非交互 Image 的 Raycast Target，用 Sliced 做可缩放背景，用 Filled 做进度条，用 LayoutElement 管理布局尺寸，然后把动态资源统一封装。这样大多数隐藏在深处的 Image 坑，还没踩到就已经被绕开了。