UI半透明黑边发灰根源：Alpha混合与色彩空间

先讲个我昨天刚处理完的问题：一张圆角半透明弹窗，盖在一张深色背景图上，结果弹窗边缘多出一圈又黑又灰的“描边”，怎么调透明度都救不回来。再换个场景，一个带半透明遮罩的引导层，UI 同学说“我要的是透亮，为什么一跑起来像蒙了层灰纱”。这种问题我在社区里见过不下几十次，几乎每个做 UI 的人都会在某一天撞上，然后开始调混合模式、换图片格式、加 shader、改色值……一顿操作，碰巧能修好，但下次换个平台又翻车。

这篇就是想把“黑边”和“发灰”这两件事从玄学里拎出来。它不是什么 GPU 抽风，也不是设计稿导出的玄学问题，而是几套非常确定的数学规则在起作用——Alpha 混合公式、位图采样插值、颜色空间。理解了这三件事，你不仅自己能修，还能在评审的时候把原理讲清楚，让美术、前端、客户端同事不再靠感觉互相踢皮球。适合被半透明 UI 坑过的客户端开发、前端开发、Unity 开发者，以及想搞清楚“为什么导出后不一样”的 UI 设计师。

1. 先看现象：黑边和发灰为什么能坑到一代又一代 UI

1.1 两种典型现场

先说黑边。最常见的舞台是圆角卡片、弹窗描边、气泡、Tooltip 这一类：面板本身是半透明或者带一点毛玻璃效果，背后是一张对比度比较高的背景图，这时面板边缘会出现一条细长的深色线，尤其是圆角弧度大的位置最明显。把面板挪到白底下，这条线几乎看不见；挪到黑底下，它像描了黑边一样扎眼。

另一种黑边出在“把半透明内容渲染到 RenderTexture 再贴回 UI”的场景。比如你想给 UI 做一个实时模糊背景，先把 Camera 画面渲到 RT，再把 RT 用 RawImage 叠进界面。此时你会发现，RT 里物体和透明背景交接的边缘会发黑，整个 RT 的边缘还会有一圈很脏的暗边。很多人第一反应是改 RawImage 的透明度，结果越改越糟。

再说发灰。这个现象常出现在遮罩层、引导蒙层、半透明浮层上。设计师给的稿子是“黑色 30% 透明度”，在你机器上跑出来，却感觉像盖了一层均匀的灰布，暗部细节全部糊掉。还有一种场景：两个半透明层叠在一起，比如底部先有一个半透明白色背景卡片，上面再叠一个小半透明标签，标签已经写了 #FFFFFF 加 60% 透明度，但视觉上却呈现一种说不清道不明的脏灰色，既不够白也不算灰。

1.2 为什么说这是个“玄学重灾区”

这个问题的玄学之处在于：你很难靠“感受”找出规律。同样一张图，在 A 引擎里正常，放到 B 引擎里边缘黑了；同一套设计稿，Web 上跑出来和 Unity 里跑出来颜色不一样；甚至同一个引擎，从 Gamma 色彩空间切到 Linear 色彩空间，所有半透明遮罩的颜色都变了。

于是大家开始发明各种偏方：把透明底图往内缩一像素、给图片加描边反向遮丑、在边缘叠一个渐变遮罩、用纯黑或者纯白背景重新导出、调 Blend Factor 从 SrcAlpha 换成 OneMinusSrcAlpha……这些做法有时候确实能“表面修复”，但因为没碰到根因，换个资源、换台设备、换套 UI 层级又会复发。

其实“黑边”和“发灰”背后就是两类非常直观的数学问题：一类是颜色在透明像素边缘被错误地插值了，另一类是颜色在错误的空间里做了加法和乘法的平均。理解这两句话，就破案了一大半。

2. 根因第一课：Alpha 混合公式里藏着的“半透明错觉”

2.1 混合到底在算什么

不管你在哪个平台做 UI，只要涉及半透明，最终渲染管线里都在算下面这个公式（普通非预乘 Alpha）：

code复制// 普通 Alpha Blend（非预乘）
outColor.rgb = src.rgb * src.a + dst.rgb * (1 - src.a)
outColor.a   = src.a + dst.a * (1 - src.a)

src 是你正在绘制的半透明前景，dst 是画面中已经存在的背景。这个公式的含义很直白：前景颜色按自己的透明度权重参与，背景颜色按“剩下的透明度”权重参与。

举一个最简单的例子：一张完美的半透明白色卡片，src.rgb = (1, 1, 1)，src.a = 0.5，盖在纯黑背景 dst = (0, 0, 0) 上，理论上你希望得到的视觉是一个“亮度 50% 的灰色”。可在现实的 UI 渲染里，这个“亮度 50%”本身就有歧义——你是让数值变成 0.5，还是让物理亮度变成 0.5？这两个结果完全不是一回事，后面我会在颜色空间那一章展开。

再往深处看，这个公式还默认了一件事：src 的 RGB 颜色是“未乘过 Alpha 的原始颜色”。也就是图片里一个像素如果写成 rgba(255, 0, 0, 0.5)，它代表“一个半透明的纯红”。但问题是，很多图片存储格式、很多贴图导出流程，并不保证透明像素里存的是什么颜色。

2.2 三种“半透明”的认知偏差

第一种偏差叫“位图不知道什么是边界”。美术画一个白色圆角矩形，Photoshop 里看到的是白底，导出 PNG 后边缘会自带一圈过渡像素。可过渡像素里颜色是怎么填的，取决于美术在透明背景上怎么画、用什么底色导出。如果导出工具把全透明像素顺便清成了黑色，那这张图在普通 Alpha 混合下就会变成“白色往黑色过渡”的脏半透明。

第二种偏差叫“半透明不是调亮度”。很多人下意识认为“颜色不够透，就把颜色调深一点”“黑色调低透明度就是灰色”，这个直觉是错的。透明度和颜色是两个正交维度：一个红的 50% 透明，不管叠加多少次，色相还是红，只改变这个红和背景的占比。你看到的“灰色”实际上是亮度在页面上的表现，不是颜色值本身被抹掉了。

第三种偏差叫做“半透明渲染结果和设计软件里看到的结果不一定同空间”。设计稿里的图层混合通常基于一套接近感知均匀的显示空间，而游戏引擎或浏览器内部可能在线性空间里做物理正确的混合，也可能在老旧的 Gamma 空间里做数值平均。同一组色值，在不同空间的最终显示效果差出一大截。

这三点认知同时出错时，人的第一反应就是“调参玄学”。其实只要锁定问题出在公式的哪一项，就能对症下药。

3. 黑边的真凶：透明像素里的黑色残余与插值陷阱

3.1 从一张圆角贴图说起

假设你手里有一张 256x256 的圆角矩形图片，要做成 UI 面板。图片中间是不透明白色，四个圆角外是透明区域。问题来了：透明区域的 RGB 是什么？很多图像软件在保存时，会把透明像素的 RGB 统一写为 0，也就是 rgba(0, 0, 0, 0)，这是“最省事”的清理方式。

现在 GPU 在绘制时会对贴图做双线性过滤。采样点如果落在白色像素和透明像素之间，GPU 会把它们的颜色和 Alpha 都做线性插值。假设一个采样点刚好落在白色 rgba(255, 255, 255, 255) 和透明黑 rgba(0, 0, 0, 0) 正中间，采样结果是 rgba(127, 127, 127, 127)。

这个值被 Alpha 混合公式作用到深色背景上时，相当于把一个「偏灰、半透明」的颜色盖上去。结果就是你看到的那条灰黑色描边。美术脑海里想的过渡是“白色越来越淡，慢慢消失”，可文件里记录的却是“白色往黑色渐变，同时慢慢消失”。这个“往黑色渐变”的通道，就是黑边的真凶。

这种问题在贴图边缘锐利、放大缩小倍数大、还有模糊算法参与时格外严重。因为模糊和缩放都会扩大取样范围，让更多透明像素参与插值，黑边就被进一步放大。

3.2 非预乘和预乘：透明图像两种“存储观”

要根治黑边，必须先理解图像的两套存储观。

普通 PNG、大多数设计软件导出的图片，用的是非预乘（Straight Alpha）格式：每个像素存独立的 RGB 和不透明度 A。透明像素的 A 等于 0，但 RGB 可以是任意值，可能永远不被渲染。问题是采样插值和 mipmap 生成时，这些 RGB 会被强行拉进计算，就出事了。

预乘（Premultiplied Alpha）是另一种存储方式：存入图片时，先让 RGB 乘以自身 A，再保存。一个纯白 50% 透明的像素，直接保存为 rgba(127, 127, 127, 127)，而不是 rgba(255, 255, 255, 127)。透明区域里没有意义的颜色值全部清零，变成 rgba(0, 0, 0, 0)。

两种格式在混合公式里的差别是这样的：

code复制// 非预乘 Alpha 混合：源颜色还要乘一次透明度
out.rgb = src.rgb * src.a + dst.rgb * (1 - src.a)

// 预乘 Alpha 混合：源颜色已经在贴图里乘过透明度，直接用
out.rgb = src.rgb + dst.rgb * (1 - src.a)

预乘格式做双线性插值时，白色像素和“无色透明像素”插值的结果是半透明白，而不是半透明白偏灰。因为透明区不再藏着黑色干扰项。所以几乎所有游戏引擎、合成器内部，最终都会转成预乘格式再上屏。Direct2D、Skia、Core Animation、Unity 的字体渲染，底层都在使用预乘思路。

如果你自己写 shader 或者做引擎封装，看到半透明纹理边缘发黑，第一时间要检查的就是：当前采样纹理有没有在 CPU 或者 GPU 端做预乘处理。美术资源如果是非预乘 PNG，引擎在导入时也需要明确标志，不能把直通图硬塞给预乘混合。

3.3 图片导出与渲染目标导致的边缘黑线

除了贴图自身，图片导出流程也会制造黑边。常见的情况是：美术在深色带透明背景的图里做抠图，导出 PNG 的时候使用“黑色透明背景”作为底色，结果边缘像素被压暗。解决办法是把 Photoshop 的首选项中“图像处理时透明区域存储为白色/黑色”检查一遍，更规范的做法是导出前先扩展边缘、或直接用带预乘导出的工具链。

渲染目标（RenderTexture）里的黑边是另一类独立问题：你先把一张 UI 面板渲染到 RT，RT 里除面板外的透明区域如果被清成了 rgba(0,0,0,0)，再把 RT 当普通纹理按非预乘方式贴回场景，透明区域的黑色采样值就会再次参与合成，最终 RT 和场景的交界处会出现深色叠影。

这种情况我常用的检查顺序是：

• 看 RT 的格式有没有 Alpha 通道，创建 RT 时不能只关心 RGB；
• 看摄像头 Clear Color 的 Alpha 值是多少，全 0 的清空方式在这种场景下并不等于“干净”，因为它给透明区域写入了黑色 RGB；
• 上屏时用的 Shader 或 RawImage 的混合模式，是预乘还是非预乘。

如果你的 UI 系统本身是普通混合，而 RT 里已经是预乘数据，就要把混合因子从 SrcAlpha, OneMinusSrcAlpha 改成 One, OneMinusSrcAlpha，否则透明边缘就会叠加一层暗边。这条经验和“RT 存出来灰灰的”一起出现时，基本可以 90% 确定是预乘/非预乘状态不匹配。

4. 发灰的真凶：颜色空间不统一，半透明变成“灰蒙蒙滤镜”

4.1 sRGB 和线性空间：为什么直接算会“灰”

讲完黑边，再说发灰。发灰的根子不在 Alpha，而在于颜色值本身是在哪个空间做平均的。

显示器呈现的亮度和你存的数值不是线性关系。一张 PNG 里存的 0.5，显示到屏幕上时物理亮度大概是约 0.214，并不是一半。这意味着你在计算机里做“50% 混合”时，如果直接把两个颜色数值拿来做线性平均，最终亮度一定偏离你的直觉。

最常见的错误发生在 gamma 空间直接混合。拿纯白 255 在纯黑背景上做 50% 透明混合，如果引擎不做线性转换，计算结果刚巧是 127 左右。这个值在 sRGB 显示器上对应的物理亮度只有大约 22%，人眼看到的效果就是“暗了一截的灰”，而不是通透的 50% 灰。所有半透明白色面板都像蒙了一层偏暗的滤镜，这就是发灰的第一种来源。

物理正确的做法是：先把 sRGB 颜色解码成线性亮度，在线性空间里做混合，再把结果编码回 sRGB 输出。同样半透明白盖黑底，线性亮度 0.5 最终编码成 sRGB 大约 188，而不是 127，视觉效果更亮也更干净。

很多老引擎、老 UI 框架为了省性能，全程在 gamma 空间里直接混合，于是半透明层一多，颜色就会像“脏玻璃”一样浑浊，黑色遮罩层也让暗部糊成一片。如果你把项目从 Gamma 色彩空间迁移到 Linear 色彩空间，会发现所有半透明遮罩的层次突然变得干净、通透，这正是因为混合计算终于发生在物理亮度上。

4.2 反复叠加的半透明层与颜色规范化

发灰的另一种来源是“半透明层叠了太多次”。设想你有三层面板，每层都是白色 50% 透明，在最底层放一张图片。理论上三层叠下来确实会比一层更白，但如果每一层里还套了设计师额外给的“半透明灰底色”，那么结果就会一层层往下压，最终所有细节都被淹没在中间调里。

这种情况经常发生在团队协作时：设计师为了在截图里表达“这里有一个半透明遮罩”，直接在图层上画了一个 50% 的灰色填充块；开发接到设计稿后，用同样的灰色值再加了一个 30% 透明度的黑色层。两个操作叠加，产生了一个和原始意图完全不匹配的“规范灰”。

所以我要给 UI 协作提一个反直觉建议：在设计稿里，半透明面板的颜色值不要直接读取最终叠加后的色值，而是应该读取图层面板里的基础色和透明度。交付给开发时，写清楚“底色 #FFFFFF + 透明度 60%”或者“底色 #000000 + 透明度 30%”，不要让开发从效果图上反推一个已经叠加过底色的灰值。否则开发照着颜色一填，等于把“混合后的结果”当成了“参与混合的源”，再叠加一次后就必然发灰。

另一个常见的发灰变体是背景模糊。半透明面板加 backdrop-filter 或高斯模糊时，如果模糊层背后是一个黑色渐变的复杂背景，模糊算法会把各个像素的颜色做平均，黑色比例大的区域会呈现一种灰雾感。这不是 bug，而是模糊本来就包含“颜色平均”，你看到灰是因为背景里黑和白参与平均的数量接近。这种情况下能做的是调整面板底色，而不是想办法关掉模糊。

5. 各端实操：Unity、Web、WPF/Qt 的透明正确姿势

5.1 Unity：先在“色彩空间”和“图集属性”里排查

Unity 项目遇到半透明发灰，先打开 Project Settings > Player > Other Settings > Color Space，看当前是 Gamma 还是 Linear。如果整个项目已经有不少 UI 内容，盲目切换 Linear 会让所有场景光照变化巨大，不能为了半透明面板单独切。但对于纯 UI 或偏 UI 的项目，直接上 Linear 是提高通透感的正路。

黑边问题需要检查三处。

第一，贴图导入属性。选中出问题的贴图，在 Inspector 里看 Alpha Is Transparency 是否勾选，这个选项影响引擎如何处理透明像素的边缘。如果你的图集已经包含了带预乘处理的自定义 Shader，这里反而要小心双重预乘。

第二，图集出血（Padding）。UI Atlas 打包时，如果图集边缘没有足够的 2~4 像素扩充，采样接近图集边缘时就会取到相邻图片的像素，产生彩色或黑色描边。Unity 的 Sprite Atlas 默认有 Padding，但旧版或自研图集会忽略，这是圆角图标边缘突然出现黑线的高频原因之一。这类问题肉眼看着像“纹理脏了”，其实是图集采样越界。

第三，UI Shader 的混合因子。默认 UGUI 的 UI/Default 是普通 SrcAlpha 混合，如果你把渲染到 RenderTexture 的半透明内容贴进 RawImage，RT 里的数据如果是按预乘生成的，就要换一个 Blend One OneMinusSrcAlpha 的 Shader，同时把 Shader 里采样出来的颜色做相应处理。

补充一个很隐蔽的坑：Unity 的 UI 在 Linear 色彩空间下，图片采样如果不做 sRGB 解码，UGUI 默认 Shader 会在采样后直接拿原始 sRGB 数值参与混合，半透明图会变得更暗。遇到“切了 Linear 后 UI 反而灰了”的情况，不是 Linear 的错，是贴图的 sRGB 标志或者 UI Shader 的颜色空间转换有问题。

5.2 Web/CSS：检查图片导出方式与滤镜叠加

Web 端，浏览器内部的大部分 2D 合成已经走预乘流程，遇到黑边先别怀疑浏览器，先去检查图片本身的透明像素颜色。

CSS 背景图的半透明黑边，90% 是素材抠图没处理好。我处理过最典型的一个例子：同事从设计稿里导出一张带圆角的图片，透明背景是由 AI 工具自动生成的，放页面里无论怎么加 border-radius 都有黑边。后来把这几个透明像素在 Photoshop 里放大看，发现 RGB 值根本不是 0，而是 18、22、31 这种暗蓝色，圆角边缘就是从半透明的不干净像素过渡过来的。修法是把图片导入 Photoshop，使用“图层样式 - 描边 - 内部扩展”，把边缘颜色扩展进透明区域，然后重新导出。

CSS 的 filter: blur() 配合 backdrop-filter 使用，也会让半透明边缘发黑。因为模糊算法会把透明区域当成 rgb(0,0,0,0) 来取平均值，黑色被模糊进面板边界。你把 backdrop-filter 或者模糊容器的 background-color 从透明改成一件很淡的纯色（比如 #FFFFFF），情况会立刻缓解。这不算治本，但至少不会再出现那条刺眼黑线。

另一个 Web 独有的“发灰”来自多个半透明背景层叠加。CSS 背景图层级是这样的：

code复制background-image: linear-gradient(...), url(...), rgba(0,0,0,.5)

从外层到内层，每个半透明层都在和已经合成的下层做混合。如果底色带一个很强的黑白渐变，上面又盖了带 alpha 的黑色层，那么所有中间调都会被压成灰。设计稿里看起来是“角落有微妙阴影”，代码里实现出来就可能变成“整个面板蒙灰”。原因是设计软件中同一个图层同时有渐变和透明度，导出后被拆成了两个合成层，叠加顺序变了。让设计直接导出完整面板图，比在 CSS 里叠加还原要稳定得多。

5.3 WPF/Qt：预乘格式、像素对齐和模糊效果

WPF 里最常见的是 DropShadowEffect 和 BlurEffect 造成的边缘发黑。WPF 的 Effect 在内部处理时，透明区域的数据不一定经过像素级修正，当元素半透明或背景为透明窗口时，模糊结果会在边缘累积暗色。最直接的绕过方式：避免给透明区域直接上 Effect，而是在截图前先把底层裁成不透明面板；如果必须要阴影，可以用一张预生成的阴影 PNG 代替实时 Effect。

WPF 另一个高频问题是“半像素渲染”导致的细黑线。UI 元素尺寸或者位置出现小数时，比如元素放在 x=10.5 的位置，透明背景和面板边缘就会产生一个插值误差，表现为发虚的深色细线。遇到这种黑边，先给容器加上 UseLayoutRounding="True" 和 SnapsToDevicePixels="True"，大概率能解决。

Qt 则要看清图像的存储格式。QImage 的 Format_ARGB32 是非预乘格式，Format_ARGB32_Premultiplied 是预乘格式。如果图片加载时用的 Format_ARGB32，普通绘制还没有问题，但执行 QPainter::drawImage 并在上面叠加半透明效果时，透明像素里的黑色残余终于开始捣乱。改成预乘格式后，大部分边缘脏色会消失。

在做半透明无边框窗口时，Qt 要求设置 WA_TranslucentBackground，此时窗口的整体合成依然走系统合成器。如果窗口中的控件使用 setWindowOpacity 做了整体半透明，又会引入系统级合成器的空间转换，显示效果和设计稿不一致时，我通常会建议先关掉 setWindowOpacity，用窗口背景色加半透明绘制替代，因为系统级窗口透明度不会照顾你素材里的预乘状态。

6. 排查不靠玄学：一套可复现的定位流程

6.1 先截屏，用取色器还原“值”

遇到黑边或发灰，不要盯着屏幕反复调参数，第一步是拿到确定性的数值证据。

把界面截屏或者暂停渲染，把出现问题的像素颜色用取色器取出来，和背景图、设计稿的数值做对比。例如一个带半透明白卡片的界面，卡片中心在深色背景上取出来是 r=128，边缘是 r=90。记录这些数值之后，再建立一个最小化测试：一块纯色底，一张纯色半透明面板，重新渲染，再看取色结果。如果最小化测试里问题复现，就能把嫌疑锁定在基础混合链路；如果问题不出现，说明是背景内容或纹理采样引发。

这个方法看起来笨，却是最能打破团队争论的手段。很多人争论“到底是美术图问题还是引擎问题”，各执一词，截个图放取色器里一比，数值偏低还是偏高就一目了然。

6.2 五个关键检查点

定位半透明渲染问题，我总结了五个固定检查点，按顺序排查，九成情况能收敛。

• 检查资源透明像素里的实际颜色：把出现黑边的贴图在图片工具里放到透明网格层，取边界颜色看 RGB 是否接近纯黑或奇怪杂色；如果是，先修复资源或者转预乘格式。
• 检查混合模式和预乘状态：当前绘制用的 Blend 是 SrcAlpha, OneMinusSrcAlpha 还是 One, OneMinusSrcAlpha？素材和渲染目标的数据是哪一种格式？只要两边不匹配，边缘必出问题。
• 检查色彩空间：项目在 Gamma 还是 Linear？半透明叠加结果是否比设计稿暗？如果半透明遮罩呈现不正常的灰暗，往往是颜色数值没做线性解码。
• 检查图集与采样边界：贴图放大后边缘溢出了多少？图集有没有做 padding？UI 元素有没有被 mask 裁剪时和相邻元素共用一条纹理边缘？
• 检查多次叠加顺序：设计稿给的是一个半透明层，代码里是不是被拆成了两个层叠加？两个半透明层之间的颜色空间混合顺序是否和 Photoshop 一致？

这五个检查点不依赖具体引擎，它们剖析的是所有半透明渲染都会经过的路径。无论你是 Unity、Qt、Web 还是自研引擎，都可以顺着这个清单往下挖。

6.3 几个我已经替你踩过的坑

最后一个坑，也是最容易误导人的：为消除发灰，把半透明面板的 Alpha 从 10% 调到 0%，视觉上确实“不灰了”，但你实际上丢掉了设计想要的层次。发灰不是“透明度太高”，而是“混合空间不对”，如果基础渲染空间不对，把透明调成 5%，会从一个很深的脏灰变成一个很浅的脏灰，问题并没有消失。

另一个坑是试图用锐化或者模糊特效把黑边藏起来。我曾经见过有人为了盖掉按钮边缘黑边，在周围加了一圈模糊的白色光晕。光晕一加，边缘确实看不出来了，但整个面板在滚动时出现拖影，性能也下降。查了半天，最后发现那只是图集里 button 的 sprite 与其他元素共用 padding 不足。用特效遮丑永远是最后手段，不能替代根因修复。

还有一类问题是“只在特定手机/显卡上出现”。这时候先检查平台色彩空间设置，再检查 GPU 是否支持你用的混合扩展。移动端某些 GPU 在低精度帧缓冲下做混合时，半透明渐变的 banding 也会被误认为发灰，这时可以加一点 dithering 抖动来改善，但毕竟不是“黑边/发灰”问题的主线。

在动手改任何代码之前，下一次 UI 半透明再翻车，打开取色器、翻一翻透明像素的 RGB、确认一下自己的 RT 是预乘还是非预乘，这三个动作比调半天模糊参数有用得多。半透明的坑，从底层来看反反复复只有那么三四个原因，一次搞明白，之后就能从“玄学调参”转为“按图索骥”了。