1. 先搞明白：Shader在Unity里到底解决了什么问题
Shader在Unity里是所有图像渲染效果的底层执行者。说得直白一点，场景里有一个白色球体，要渲染成纯白色还是带高光的硬塑料质感，核心处理逻辑就在Shader里。如果你看到一个物体材质是透明的、发光的、会扭曲画面的，这些多半也是Shader干的活。以前很多Unity开发者把Shader当成“美术那边调整的材质文件”，其实这是一种误区：材质（Material）只是把Shader需要的参数打包管理，Shader本身才是真正决定“怎么画”的那段程序。
1.1 美术、材质与Shader三者到底什么关系
把三者放在一起说，是为了先帮你建立一张“职责分工”的心理模型。美术资源进引擎之后，会挂到模型上的MeshRenderer组件里，组件里需要一个Material，而Material里必须指定一个Shader。这个过程很多人一眼扫过就忘，但它决定了你后面所有调试的方向。
我常用一个简单的类比向新同事解释：Shader是“烹饪菜谱”，Material是“一桌点好的菜”，GPU则是“后厨团队”。菜谱里写了做法要多少油、多少盐、怎么翻炒，Material则是一张便签，上面填了“少放辣、多加蒜”，GPU按着菜谱和便签把食材（模型数据）做成最终端上桌的菜（屏幕像素）。菜谱永远能吃辣，但具体这桌菜辣不辣，看你便签怎么填。
这个类比其实也解释了性能问题的根源：后厨能力有上限，你在同一个Shader上叠加的功能越多，GPU要做的事越多。这也是很多新手忽略的一点——同一个Shader可以被几十个材质实例共用，改变的是参数，而不是代码逻辑。换错参数顶多是效果不对，但往Shader里加错功能，可能让所有引用它的材质一起变慢，影响面很大。
1.2 渲染管线：一个三角形是怎样变成屏幕像素的
Shader不是一个孤立文件，它活在一条非常漫长的流水线里。这条流水线在图形学里叫渲染管线（Render Pipeline），Unity引擎提供了内置管线、URP、HDRP三种可选类型，但Shader在其中的位置本质上是一样的。
粗粒度来说，一个三角形从场景到屏幕要经历这些阶段：
- 应用阶段：CPU把模型顶点、法线、UV、纹理交给GPU。
- 顶点处理：GPU把每个顶点从模型空间变换到世界空间，再到相机空间，最后输出裁剪空间坐标。
- 光栅化：GPU把顶点组成的三角形插值成密密麻麻的像素片元Fragment。
- 片元处理：对每个像素片元计算最终颜色，决定Alpha混合与深度写入。
- 输出合并：把结果写入帧缓冲，最终呈现在屏幕上。
Vertex Shader负责顶点处理，Fragment/Pixel Shader负责片元处理。这两个Shader共同决定了一个物体的最终外观，也是最常见的手写Shader形式。你在这两个环节里写的每一行代码，都会被GPU重复执行成千上万次，不同型号的手机、显卡对同样代码的执行效率差异可能非常夸张。我现在讲这些倒不是让你背渲染管线，而是想让你明白：Shader不是在某个控件上拖个滑块，它是一门跟硬件强相关的编程实践，你越早接受“自己是在给GPU写程序”，后面排查报错的心态就越稳。
1.3 为什么Unity开发者绕不开它
很多人初学Unity是从拖拽组件开始的，做个小游戏根本不需要写Shader。那为什么中间突然要补这一课？我给出两个理由。
第一个理由是默认Shader不够用。Unity自带的标准着色器确实覆盖了大部分PBR效果，可项目一旦涉及大面积透明、描边、溶解、扫描线、波光、发光UI、卡通渲染等效果，默认着色器要么做不出，要么性能上亏太多。这时候如果不写Shader，只能去商店买包，可买来的资源参数一团乱麻时，连改都不知道从哪里改。
第二个理由是Shader是项目性能优化绕不开的价值点。我在实际项目里遇过很多次：一个很普通的UI特效拖垮了整个页面，后来定位到是某个材质用了逐像素发光的坏方案，替换成预计算方案后帧率立刻改善。移动端项目尤其看重功耗、带宽和指令数，Shader的好坏直接影响发热和卡顿。如果你做独立游戏想做出独特风格，或者做商业项目想控制渲染成本，这门课早晚要补。
放心，基础向的Shader并没有高不可攀，它更像是一套有模板的填空题，把结构摸熟之后，很多东西是水到渠成的。下面我从选型讲起，带你看看Unity到底提供了哪些Shader入口。
2. 先把选型搞清楚：Unity里的Shader并不只有一种
在Project窗口右键Create > Shader，你会看到一堆选项：Standard Surface Shader、Unlit Shader、Image Effect Shader、Compute Shader，以及后续版本极力推荐的Shader Graph。很多新手在这就容易陷入选择困难，我分别说下它们的特点和适用场景。
2.1 Surface Shader：对新手最友好的起点
Surface Shader是Unity早期为了让美术和程序员都能快速开发而设计的一层封装。它本质上不是一个独立语法，而是自动生成大量光照计算的Vertex/Fragment代码，你只需要描述表面属性：颜色、法线、粗糙度、金属度、自发光等。
它的优点是写起来极度省事。声明一个CGPROGRAM，写好表面函数和光照模型，剩下的由Unity补齐。缺点是代码一旦复杂，自动生成的东西会引入很多看不见的指令开销，而且部分平台兼容性没那么稳定。所以它适合教学、原型验证和项目里的普通PBR材质，但不太适合追求极致性能和复杂多Pass效果的场景。
2.2 Vertex/Fragment Shader：最底层也最可控的手写方案
这是广大图形程序员的常用主力。它由输入结构、顶点着色器、输出结构、片元着色器共同组成。Shader的每个细节都由你掌握，没有多余自动生成的代码，性能优化时能够一笔一笔算清楚指令开销。
代价自然是更啰嗦、更容易犯错。比如顶点坐标变换、法线变换、UV坐标传递、插值，每一步都要心里有数。我建议你在掌握Surface Shader的基本写法后，尽快转到Vertex/Fragment Shader上，因为很多商业项目里的特效Shader其实都是这种手写风格，代码可读性和可移植性都更可控。
2.3 Compute Shader：另起炉灶的并行计算
Compute Shader不属于常规的渲染物体流程，它更像在GPU上跑的一段通用并行程序，用来做粒子、流体、屏幕后处理、大规模物理模拟等。新手阶段可以不必深入学习，但要知道它的存在，因为很多Mask、Dissolve、Morph等酷炫效果最终能靠它大幅提速。等你把常规Shader写顺了，再回头研究它，会更理解GPU的并行执行逻辑。
2.4 Shader Graph：面向可视化开发的替代路径
Shader Graph在Unity的URP/HDRP里是官方主推的可视化方案。不写代码，用节点连线就能构建材质逻辑。它非常适合特定项目：美术人员想自己调特效、不想反复麻烦程序员的时候，或者项目工期紧、需要快速搭出原型效果的时候。
但我要给一个提示：Shader Graph生成的代码在优化空间上不如手写细腻，它更适合中等复杂度的视觉效果，重度性能敏感的特效仍然建议手写。可以把它理解成“效率优先”的工具，而不是“极致性能优先”的方案。
2.5 不同类型Shader的对比速查
我整理了一张表，方便你根据项目场景快速做选型判断：
| 类型 | 学习难度 | 性能可控性 | 适合场景 | 不适合场景 |
|---|---|---|---|---|
| Surface Shader | 低 | 中 | 教学、原型、普通光照材质 | 重度性能优化、复杂多Pass效果 |
| Vertex/Fragment | 高 | 高 | 特效、后处理、自定义光照 | 快速迭代的小成本项目 |
| Compute Shader | 高 | 高 | 粒子、流体、通用并行计算 | 普通物体的基础渲染 |
| Shader Graph | 低 | 中 | 可视化调试、美术自主开发 | 极限性能、代码复用要求高 |
这张表不是定死的，实际项目里它们经常混用，同一个物体的不同特效也可能跨多个Pass，一套Shader用Vertex/Fragment，另一个Compute Shader在中间做数据准备。理解每个入口背后的取舍，比记住某个固定答案重要得多。
3. 上手实操：写第一个可以用的Shader
理论讲了半天，不如直接落地跑一个。下面的例子基于内置渲染管线，我写一个最基础的纯色Unlit Shader，然后逐行解释。
3.1 用ShaderLab搭建文件骨架
先新建一个着色器：Project窗口右键Create > Shader > Unlit Shader，命名成MyFirstShader。它会生成一个带坐标、法线、贴图采样的默认模板。我们把内容全部替换成下面这段：
Shader "Custom/MyFirstShader" { Properties { _Color ("主颜色", Color) = (1, 1, 1, 1) } SubShader { Tags { "RenderType"="Opaque" "Queue"="Geometry" } Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag #include "UnityCG.cginc" fixed4 _Color; struct appdata { float4 vertex : POSITION; }; struct v2f { float4 pos : SV_POSITION; }; v2f vert (appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); return o; } fixed4 frag (v2f i) : SV_Target { return _Color; } ENDCG } } }先把文件结构拆开看。最外层用字符串"Custom/MyFirstShader"作为Shader在材质面板里的显示路径。Properties块声明颜色参数，让外界通过Material控制。SubShader块存放真正可执行的渲染指令，里面的Pass是最小执行单元，每个Pass对应一次完整渲染流程。
你可能注意到这段代码里没有出现光照计算，因为Unlit Shader本身就不参与光源计算，它只输出颜色。这也是新手练习第一个Shader时最适合的起点，没有光照干扰，你能把注意力全放在结构和语义上。
3.2 逐段拆解关键字段
这段代码最需要理解的是顶点着色器里的坐标变换。appdata里只有一个顶点坐标POSITION，这是Unity内置的顶点语义；vert函数调用UnityObjectToClipPos，把模型空间下的顶点坐标直接变换到裁剪空间。为什么这里跳过了世界空间和相机空间？因为内置函数在内部帮你把矩阵乘法一次算完，代码看起来少，实际做的事情一点没少。
片元着色器更简单，它接收来了SV_POSITION插值后的坐标，直接返回一个fixed4颜色值。SV_Target语义告诉GPU，这个输出值要写入当前渲染目标。注意这里用的是fixed4低精度类型，在移动端上一般比float4更省带宽，但也会牺牲一定精度。你如果只是填色，fixed4够用；一旦涉及世界空间位置、法线计算，再考虑float4。
另外强调一句：Cg代码块必须在材质编辑器里选中Shader后，窗口下方会实时显示编译日志。如果代码写错，Inspector面板里会直接飘红，Console窗口打印错误详情。我一直建议新手把Console面板开在下方，一边改一边看编译结果，比在脑子里空想Debug快得多。
3.3 创建材质并挂到场景进行验证
接着在Project窗口右键Create > Material，创建材质MyTestMat，把Inspector里的Shader路径改成"Custom/MyFirstShader"，或者直接点Shader选择器输入框搜索路径。然后把材质拖到一个Cube上，场景里应该出现纯色的Cube，颜色由材质面板上的主颜色参数控制。调整颜色值，Cube会实时变化：
- 修改_Color的RGBA数值，物体颜色同步更新。
- 把Alpha调低，物体并不会因此变透明，因为SubShader的Tags里标了Opaque，没有开启混合模式。
- 尝试新建一个材质复用同一个Shader，即使颜色参数不同，Shader代码也只有一份，验证了“Shader被多个材质共用”的概念。
如果你用的是URP而不是内置管线，上面代码需要调整路径和宏，但它背后的流程没有变。我强烈建议你手动操作一遍，因为手动创建会帮你记住“材质-着色器-组件”的三层关系，以后看别人的项目，看到一个模型挂了一堆材质时，就能自动拆开每一层的作用。
4. 从纯色到光照：一个颜色值是怎么算出来的
只要会输出颜色，你已经跨过了Shader的第一道门槛。接下来绝大多数Shader要处理的核心命题是：一个像素的最终颜色，到底由哪些输入决定？这里我讲两个最核心的计算维度——坐标变换和光照，它们也是手写Vertex/Fragment代码时绕不开的地基。
4.1 顶点着色器里到底发生了什么
在Vertex阶段，GPU把网格数据按顶点为单位打开。每个顶点有位置、法线、UV、切线等属性，这些属性通过语义绑定进入appdata结构体。我见过很多人把这段代码当成例行公事，每次照抄，其实这里藏着大量信息。比如法线变换不能直接沿用位置矩阵，法线向量只做旋转不做平移；又比如不同平台对纹理坐标Y轴的处理不同，采样前要调整。
把顶点从模型空间变换到裁剪空间，是为了让GPU知道这个顶点应该出现在屏幕的哪个位置。裁剪空间的具体细节，后面有时间再展开，你先记住一个结论：顶点着色器输出的SV_POSITION，不能直接拿去做世界空间距离计算，否则结果会因为你摄像机的角度而改变。如果有需要在片元阶段使用世界坐标，正确做法是在顶点着色器里用UnityObjectToWorldDir或mul(unity_ObjectToWorld, v.vertex)计算出世界空间值，再通过v2f结构体传下去。这个坑我每次评审代码都会看到，一旋转物体，效果就崩。
4.2 光照的入门公式：N dot L
光照计算是整个Shader从“能显示颜色”到“看起来立体”的关键一步。最简单实用的模型是Lambert漫反射，核心就一行公式：NdotL = saturate(dot(N, L))。N是片元法线方向，L是片元指向光源的方向，点积后sat()取0到1之间。法线正对光源时值最大，背离光源时则为零。
把这个公式写成Shader，你会看到物体受光面亮、背光面暗，立体感马上出来。看起来神奇，其实它算的就是“法线方向与光线方向有多对齐”。另外别忘了加环境光，Unity通常提供一个全局环境色，不加的话背光面会完全死黑，画面太硬。高光部分可以用BlinnPhong模型进一步扩展，把视线方向和光源方向的中间向量V跟法线N再做一次点积，控制高光范围。这个模型在新手阶段比直接上手PBR更直观，能帮你建立起“光照=入射方向与表面朝向的匹配关系”这个核心直觉。
4.3 UV坐标和纹理采样：让物体有细节
纯色和光照只是起步，真正让物体丰富起来靠纹理采样。每个顶点带一组UV坐标，数值通常在(0,1)区间，记录了三角形每个角落对应纹理图像的位置，GPU在光栅化阶段会自动插值出每个像素的UV。片元着色器里用tex2D()就能完成采样：
fixed4 texColor = tex2D(_MainTex, i.uv); return texColor * _Color;物体表面就不再是单一颜色，而是整张贴图的内容。配合法线贴图、金属度贴图、粗糙度贴图，可以一步步接近PBR质感。这里有个性能提醒：纹理采样成本并不低，尤其是移动端GPU，每多一次采样都可能让带宽压力上升。你应该在Project Settings里调整纹理压缩格式，尽量用平台友好格式，而不是拖一张几兆的无压缩贴图就进场景。我在真实项目里踩过太多次，看似是美术资源问题，实际是Shader采样压力问题。
5. 常见问题排查与Debug：我日常踩过的坑
Shader学习曲线里，最劝退人的不是概念本身，而是报错和奇怪的显示效果。这一节把高频问题整理成一份速查手册，按“现象→原因→解决”的方式来讲。
5.1 初学者最常撞上的编译报错
第一类是“undeclared identifier”的变量声明问题。原因通常是你在Properties里声明了_Color，但在CGPROGRAM里忘了加fixed4 _Color;这一句。Properties里的声明只是给材质面板看的，真正让CG代码认识它，还需要在CG块里再用Cg变量声明一次。看似低级，实际非常高频。
第二类是语义不匹配。比如顶点着色器输出的SV_POSITION和片元里接收的变量对应不上，或者appdata里漏了TEXCOORD0，导致UV数据传不进去。我的排查习惯是先看Console第一行错误指向的代码行号，再对照结构体定义逐字检查，十有八九能定位。
第三类比较隐蔽，是平台差异造成的编译失败。同一段Shader在编辑器里编译通过，打包到特定GPU架构的手机上却报错，这通常跟half精度、内置函数名差异有关。应对办法是尽量用跨平台写法，并在项目初期确定目标平台，用真机测试而不是只在编辑器里看。
我把常见错误整理成了表格，方便你直接对照：
| 现象 | 常见原因 | 解决方式 |
|---|---|---|
| 材质全粉红 | Shader编译失败或包含不支持语法 | 看Console报错，核对CGPROGRAM/ENDCG配对 |
| 物体全黑 | 片元函数返回0或无光照变量 | 新建Unlit Shader隔离光照判断 |
| 旋转后效果崩 | 拿到裁剪坐标当世界坐标用 | 用unity_ObjectToWorld变换后再传UV/法线 |
| 真机报错编辑器正常 | half精度或内置函数不兼容 | 改用跨平台写法，真机测试 |
5.2 颜色不对、材质全粉、显示全黑
材质变成洋红色是Unity最著名的报错信号，说明Shader编译失败，或代码包含引擎不受支持的语法。遇到粉红先别急着狂改材质，先看Console日志，把报错的行列信息截下来搜索，多半能直接定位。漏了CGPROGRAM/ENDCG配对、属性声明和CG变量声明不一致，这些都是高发原因。
全黑显示则有两种常见来源。一种是片元函数返回了vec3(0)或者返回的变量没被正确赋值，在部分平台默认初始值可能为0。另一种是光照计算写了但方向向量没归一化，导致点积结果异常，呈现出发黑或闪烁。排查时可以先做一个纯白色Unlit Shader，确认物体本身能被渲染，再逐步把光照代码加回去，避免一次性引入太多变量。
5.3 Debug Shader的实用工具与习惯
第一个工具是Unity的Frame Debugger。Window > Analysis > Frame Debugger可以逐帧查看Draw Call、每个Pass的渲染顺序，还能看到每个Pass执行前后纹理和状态的变化。排查“为什么这个物体提前被画了”“为什么透明物体排序乱”时，它远比纸质文档直观。
第二个是很土的调试技巧：直接把变量输出成颜色。比如把法线输出成fixed4(i.normal * 0.5 + 0.5, 1.0)，你会看到一个平滑渐变，如果法线是乱的，画面就会呈出异常的硬边噪点，从而判断法线是否正确传递。相似地，把UV输出为颜色，可以快速查看UV展开是否正常。这个方法虽然土，但在真机上找不到调试器时极为有效。
最后是习惯问题：Shader里加注释。尤其在你写非标准光照模型时，后续维护者多看一眼注释就明白设计意图。我在团队里要求所有自定义Shader必须有头部注释，说明使用场景、输入参数、输出目标和已知采坑记录。短期内好像没什么用，三个月后维护起来，价值巨大。
提示：本小节里提到的调试手段都不需要额外插件，Unity编辑器自带的Frame Debugger加上低成本的输出颜色法，已经足够覆盖新手期的绝大部分调试需求。不用急着装一堆花哨的开发包。
最后聊聊我的一点使用心得
绕了一大圈，Shader其实不是一个需要先背完整本图形学才能动的东西。我从最早用Surface Shader改颜色，到后来手写全套的描边、溶解、后处理效果，中间经历了非常多次“编译失败-改-再失败-再改”的过程。真正让我进步最快的，不是看多少篇高深教程，而是手里有一个明确的目标效果，逼着我去理解顶点、UV、法线、光照这几个核心概念。
如果你现在正卡在“看到Shader代码就头大”的阶段，我给的建议是：选一个特别想实现的简单效果，比如让物体的颜色随时间闪烁，或者让物体在鼠标点选时变红。从纯色Shader一步步升级成带UV采样、带时间变量、带简单渐变的版本。当你亲身体会到一个小效果如何在Shader代码里从零到有，很多迷茫就会自然消失。
Shader不是美术专用，也不是程序员专属，它是物体资产和渲染表现之间最直接的翻译层。谁掌握它，谁就拿回了画面表现上的主动权。这个基础概念之后还可以继续扩展：多Pass效果、URP下的Shader差异、屏幕后处理特效、Compute Shader做粒子，等等。等你想继续往下走的时候，前面打的这些底子都会成为你的资产。在你手里的编译器亮出绿灯之前，先多做几个能跑的小例子，比什么都实在。
