glslangValidator编译GLSL失败主因是未指定stage（需-V和-S）或入口名不匹配（需--entry）；SPIR-V变量名丢失需glslang加--debug、spirv-cross自动识别OpName；C++调用需Compiler接管vector内存或用shared_ptr管理生命周期。
glslangValidator 编译 GLSL 到 SPIR-V 失败：常见原因和命令写法
直接用 glslangValidator 编译 GLSL 源码时，最常见的失败不是语法错，而是着色器模型（stage）没指定或入口名不匹配。
- 必须用
-V（不是-S）启用 Vulkan 语义；-S vert或-S frag要显式声明 stage，否则默认按 OpenGL 处理，生成的二进制无法被 Vulkan 驱动加载 - 入口函数名默认是
main，但如果你改了（比如叫vs_main），得加--entry=vs_main，否则spirv-cross后续解析会报Invalid SPIR-V binary: Entry point not found - GLSL 版本声明要匹配目标 Vulkan 版本：
#version 450是最稳的选择；#version 460在某些旧版 glslang（如 11.x）里不支持，会静默降级或报错 - 输出文件必须用
-o指定，不能靠重定向：glslangValidator -V shader.vert > shader.spv会生成非法二进制——SPIR-V 是小端 32 位字数组，重定向破坏字节对齐
正确示例：
glslangValidator -V -S vert --entry=main -o vert.spv shader.vert
spirv-cross 反编译出 C++ 代码时变量名全变成 v_123：怎么保留原始名
默认情况下 spirv-cross 会丢弃所有 debug 名字信息，只靠类型和序号生成临时变量名。这不是 bug，是设计行为——SPIR-V 二进制里 debug 名字是可选 section，glslang 默认不写入。
- 编译时加
--source-entire-module和--preserve-numeric-types没用，它们不影响名字 - 关键开关是
glslangValidator的--preserve-urls（旧版）或更可靠的--debug（glslang ≥ 12.0）：它会让 glslang 把OpName指令写进 SPIR-V -
spirv-cross本身不需额外参数，只要输入 SPIR-V 含OpName，它就会自动用原始名；验证方法是用spirv-dis shader.spv | grep OpName - 注意：启用
--debug会增大 SPIR-V 体积（约 +10%～20%），发布构建建议关掉
C++ 项目里调用 spirv-cross API 解析 SPIR-V：别直接 new std::vector
官方文档示例喜欢把 SPIR-V 当作 raw buffer 传给 Compiler 构造函数，但实际项目里容易因生命周期搞错导致 crash。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
Compiler构造函数接受const uint32_t*和size_t，但它**不拷贝数据**；如果传入的std::vector<uint32_t></uint32_t>是局部变量，构造完立刻析构，后续调用compile()就读野指针 - 安全做法是让
Compiler拥有数据：用std::vector<uint32_t> spirv = load_spirv_file("shader.spv"); Compiler c(std::move(spirv));</uint32_t>——Compiler内部会接管 vector 的内存 - 如果必须复用同一份 SPIR-V 数据（比如多 stage 共用同一个 binary），就用
std::shared_ptr<:vector>></:vector>管理，再传原始指针给Compiler，并确保 shared_ptr 生命周期长于 Compiler 实例 - 别用
fread(..., sizeof(uint32_t), ...)直接读文件到uint32_t*：SPIR-V 文件是小端，而 fread 不做字节序转换；必须用std::vector<char></char>先读整块，再 reinterpret_cast + memcpy 或用 spirv-tools 自带的spvBinaryParse
glslang + spirv-cross 链路在 Windows 上找不到 DLL：路径和运行时依赖
Windows 下静态链接 glslang/spirv-cross 很麻烦，多数人选择动态链接，但常卡在 LoadLibrary 失败或 GetProcAddress 找不到符号。
- glslang 的
glslang.lib是 import lib，对应glslang.dll；spirv-cross 没官方 DLL，自己编译时得开BUILD_SHARED_LIBS=ON，否则只有静态库 - MSVC 编译的 DLL 依赖
vcruntime140.dll和msvcp140.dll，这些不在系统 PATH 里时，程序启动就崩；别指望用户装 VC redist，把它们和你的 exe 放同目录最省事 - spirv-cross 的 C++ API 头文件（
spirv_cross.hpp）和 glslang 的头（glslang/Public/ShaderLang.h）没有隐式依赖关系，但链接时顺序很重要：你的 obj → spirv-cross → glslang → SPIRV-Tools → OGLCompiler → HLSL —— 少一个或顺序错，LNK2019一堆未解析符号 - 用
dumpbin /dependents your_app.exe检查是否漏了SPIRV-Tools-shared.dll；这个库 glslang 也依赖，但名字容易被忽略
工具链版本对齐很关键：glslang 12.2 + spirv-cross 2023.03 是目前最稳组合；混用 11.x 和 2024.x 容易出现 Invalid SPIR-V magic number 或结构体偏移错乱。
