E_NOINTERFACE错误主因是硬件或驱动不支持D3D12：Windows 10 1809+为最低系统要求，Intel HD 620、NVIDIA GTX 9xx前、AMD RX 400前显卡即使系统达标也大概率失败；需通过dxdiag确认功能级别含12_0以上，否则应降级至D3D_FEATURE_LEVEL_11_0测试。
DirectX 12渲染管线初始化失败：ID3D12Device创建卡住或返回E_NOINTERFACE
多数人在第一步就卡住，不是代码写错，而是环境或驱动不支持。Windows 10 1809+ 是硬性门槛，但更关键的是显卡驱动——Intel HD Graphics 620 及更老的核显、NVIDIA GTX 9xx 之前型号、AMD RX 400 系列之前显卡，即使系统版本达标，ID3D12Device::CreateDevice 仍大概率返回 E_NOINTERFACE。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先运行
dxdiag，确认“显示”页中“功能级别”包含12_0或更高（不是只写“DirectX 12”） - 用
D3D_FEATURE_LEVEL_11_0尝试创建设备，若成功说明硬件不支持 D3D12，别硬扛 - VS 项目属性里必须开启“通用 Windows 平台”支持（
Windows SDK≥ 10.0.17763.0），否则链接时d3d12.lib找不到
CommandQueue和CommandList生命周期管理不当导致GPU崩溃
DirectX 12 把资源同步甩给开发者，ID3D12CommandQueue::ExecuteCommandLists 提交后不能立刻重用 ID3D12GraphicsCommandList，也不能在它还在 GPU 执行时调用 Reset —— 这是野指针级错误，表现常为黑屏、程序无响应或 DXGI_ERROR_DEVICE_REMOVED。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每个帧使用独立的
ID3D12CommandAllocator，提交前调用Reset；不要复用 allocator 给多个 command list - 用
ID3D12Fence+Signal/Wait判断 GPU 是否完成执行，再重置 allocator 和 command list - 避免在每帧开头就
Resetcommand list，应先Close上一帧的 list，再Resetallocator，最后Resetlist
Root Signature配置错一个参数，PSO编译就静默失败
ID3D12Device::CreateGraphicsPipelineState 返回 S_OK 但渲染无输出？大概率是 root signature 描述符数量、着色器寄存器绑定或 ShaderVisibility 不匹配。D3D12 不报错，只静默禁用对应寄存器绑定。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
D3D12_ROOT_PARAMETER_TYPE_DESCRIPTOR_TABLE时，确保pDescriptorRanges指向的数组生命周期覆盖整个 PSO 创建过程（别传栈变量地址） - CBV/SRV/UAV 绑定到 vs/ps 阶段，必须显式设置
ShaderVisibility = D3D12_SHADER_VISIBILITY_VERTEX或_PIXEL，默认是_ALL但某些驱动会忽略 - 调试时临时把 root signature 设为
D3D12_ROOT_SIGNATURE_FLAG_ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT以外全开，排除签名限制问题
Descriptor Heap分配越界：GetCPUDescriptorHandleForHeapStart返回无效地址
常见于动态 descriptor 分配场景：ID3D12DescriptorHeap::GetCPUDescriptorHandleForHeapStart 返回的 handle 加上 offset 后，超出 heap 容量，但 D3D12 不检查，结果是纹理采样黑块、常量缓冲区读取乱码。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
ID3D12DescriptorHeap::GetDesc拿到NumDescriptors，所有 offset 计算必须 ≤ 这个值减一 - CPU handle 偏移单位是
ID3D12Device::GetDescriptorHandleIncrementSize的返回值（不是 sizeof(void*)），务必缓存该值，别每次调用 - SRV heap 和 CBV_SRV_UAV heap 必须分开创建，混用会导致 handle 解析错位，尤其在 AMD GPU 上更敏感
真正麻烦的不是 API 调用本身，而是每个对象背后隐含的 GPU 状态依赖和内存可见性边界。比如 ID3D12Resource::WriteToSubresource 写完顶点数据，不插 ResourceBarrier 切换 D3D12_RESOURCE_STATE_VERTEX_AND_CONSTANT_BUFFER，GPU 可能读到旧数据——这种 bug 往往只在特定 GPU 或驱动版本下才暴露。
