VSCode 不支持 Unity Shader 的 HLSL 实时预览，其插件仅提供语法检查与补全，无法执行 GPU 渲染或处理 Unity 特有宏与变量；真正的实时效果依赖 Unity 编辑器热重载机制。
VSCode 本身不支持 Unity Shader 的 HLSL 实时预览，所谓“HLSL 解析 + 实时效果”是常见误解——你看到的着色器效果，从来不是 VSCode 渲染出来的。
为什么装了 HLSL 插件也看不到渲染画面？
VSCode 的 HLSL 支持（如 HLSL Tools 或 Shader languages support for VS Code）只做语法检查、补全和错误标记，不包含 GPU 渲染管线。它无法执行 UnityObjectToClipPos、不加载 UnityCG.cginc、也不模拟 Properties 块注入的变量（如 _MainTex）。所谓“实时预览”，必须依赖外部工具链或 Unity 编辑器自身。
- 所有声称“VSCode 内置 Shader 预览”的插件，实际都是调用本地 WebGPU/GLSL 沙盒（如
vscode-wgsl-renderer），但它们与 Unity 的 ShaderLab/HLSL 完全不兼容 -
#include "UnityCG.cginc"在 VSCode 中只是文本包含，不会触发宏展开或符号注入；_Time、unity_WorldToObject等变量在编辑器里标红是正常的，不是配置错误 - 如果你在
.shader文件里写 HLSL 片段却没看到补全，大概率是因为语言模式被设成了HLSL而非ShaderLab—— VSCode 不会自动识别 CGPROGRAM 块内的语言切换
真正能联动 Unity 的“准实时”方案
唯一可靠路径是让 VSCode 作为 Unity 的外部脚本编辑器，并利用 Unity 的热重载机制：修改保存 .shader 后，Unity 编辑器自动重新编译并刷新材质预览窗口。这不是 VSCode 的能力，而是 Unity 的行为。
- 确保 Unity Preferences → External Tools → External Script Editor 设为 VSCode（勾选 “Refresh assemblies after editing scripts”）
- 在 Unity 中打开材质 Inspector，勾选右上角的 “Lock” 图标，防止切换物体时丢失预览目标
- VSCode 中保存
.shader文件后，观察 Unity 控制台是否出现Shader compilation succeeded—— 这才是“实时”的信号，不是编辑器里的颜色块或悬停提示 - 不要依赖
glsl-canvas或ShaderToy类插件去“试跑” Unity Shader：它们解析的是纯 GLSL/WebGL，无法处理#pragma multi_compile、FallBack或UsePass等 Unity 特有指令
想看 HLSL 代码是否语法合法？用 shaderc 命令行验证
Unity 构建时实际调用的是 shaderc（基于 Google 的 shaderc 库）编译 HLSL/Cg。你可以手动复现这一过程，快速定位语法问题，比等 Unity 报错更快。
- 从 Unity 安装目录提取
shaderc.exe（通常在Editor/Data/Tools/shaderc下），或使用开源替代shadercCLI 工具 - 运行命令：
shaderc -f myshader.hlsl -o myshader.spv --target-env vulkan1.1 --stage frag（注意 stage 需匹配你的函数入口名，如frag对应@fragment fn fs_main） - 若报错
unknown type name 'float4'，说明缺失#include <metal_stdlib>或对应平台头文件 —— 这类错误 VSCode 的 HLSL 插件根本不会报，只有真实编译器会暴露 - Unity 的 HLSL 编译还受
UNITY_VERSION宏控制，直接拿 standaloneshaderc验证可能漏掉条件编译分支，仅作初步语法筛查
真正卡住开发进度的，从来不是 VSCode 能不能高亮 SV_POSITION，而是 UNITY_MATRIX_MVP 在不同 Unity 版本中是否已被弃用、tex2D 是否该换成 tex2Dlod、或者 FallBack 指向的 Shader 是否真的存在于项目中。这些必须回到 Unity 编辑器里验证，VSCode 只负责把代码写对、少拼错单词。
