Vulkan 1.4多线程命令缓冲构建线程安全，前提是每个线程使用独立VkCommandBuffer和VkCommandPool、录制期间不修改共享资源；vkBegin/vkEnd/vkCmdDraw等函数可并发调用，但提交与同步必须由主线程统一管控。
能，但必须满足三个硬性前提：每个线程用独立的 VkCommandBuffer、独立的 VkCommandPool、录制期间不修改共享资源状态。 Vulkan 1.4 的多线程命令缓冲构建是线程安全的，前提是开发者自己管好资源隔离——API 不会替你加锁，也不会报错告诉你“你正在并发改管线”。
每个线程必须分配专属 CommandPool
共用一个 VkCommandPool 是最常见崩溃源头。Vulkan 规范明确要求：同一 VkCommandPool 的内存分配（vkAllocateCommandBuffers）和重置（vkResetCommandPool）不是线程安全的。
- 为每个工作线程创建独立的
VkCommandPool，使用相同队列家族索引但不同句柄 - 分配时传入线程局部的
commandPool，而非全局池 - 避免在录制中调用
vkResetCommandPool—— 它会破坏其他线程正在使用的缓冲区 - 销毁时确保所有该池分配的
VkCommandBuffer已提交且完成执行（用vkWaitForFences等待）
CommandBuffer 录制函数本身可并发调用
vkBeginCommandBuffer、vkCmdDraw、vkEndCommandBuffer 这些函数只要操作的是不同 VkCommandBuffer 实例，就允许跨线程同时调用。这是 Vulkan 区别于 OpenGL/DX11 的关键设计。
- 线程函数里直接传入本线程专属的
cmd_buf句柄，不要传引用或全局变量 -
VkCommandBufferBeginInfo.flags建议设为VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT，避免重复提交风险 - 不要在线程中调用
vkCmdBindDescriptorSets同时更新同一个描述符集——即使只读也要确保该描述符集在录制全程不被其他线程写入 - 顶点/索引缓冲区、管线对象等只读资源可以共享，但必须保证它们在所有线程完成录制前不被
vkDestroy*或重映射
主线程负责统一提交 + 同步必须分清 Fence 和 Semaphore
Worker 线程只管录制，提交和同步必须收口到主线程。这里最容易混淆的是：哪个同步对象该在哪用。
立即学习“C++免费学习笔记（深入）”；
- 用
VkFence等待所有 Worker 线程完成录制：调用vkQueueSubmit前，先vkWaitForFences确保所有vkEndCommandBuffer返回 - 用
VkSemaphore协调 GPU 执行顺序：比如“渲染完成”信号量必须在vkQueueSubmit中作为pSignalSemaphores传入，交给呈现队列消费 - 绝对不要把
VkFence传给vkQueueSubmit的pSignalSemaphores字段——类型不匹配会导致未定义行为，Validation Layer 有时也不报 - 提交时批量传入所有线程生成的
VkCommandBuffer数组，不要逐个vkQueueSubmit
真正难的不是并发录制，而是让所有线程对“哪些资源正在被谁读写”有确定共识。Vulkan 不隐藏状态，也就意味着任何竞态都不会自动修复——比如一个线程刚绑定完管线，另一个线程立刻 vkDestroyPipeline，录制可能成功但执行必崩。这类问题往往只在高负载下复现，且 Validation Layer 很难覆盖。
