Vulkan 作为现代低开销图形 API，将同步职责从驱动层完全移交给了开发者。与 OpenGL 的隐式同步不同，Vulkan 要求你显式地管理命令缓冲的生命周期、GPU 执行顺序以及内存可见性。这篇文章将系统性地拆解 Vulkan 同步体系中的每一个核心组件，从 Command Pool 的分配策略到 Timeline Semaphore 的高级用法，帮助你彻底掌握这块最难啃的骨头。
一、Command Pool 与命令缓冲分配策略
Command Buffer 本身不能直接从 Device 创建，必须通过 Command Pool 进行分配。Command Pool 是命令缓冲的内存池，它的设计直接影响多线程录制的效率。
VkCommandPoolCreateInfo poolInfo{};
poolInfo.sType = VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO;
poolInfo.queueFamilyIndex = graphicsQueueFamily;
poolInfo.flags = VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT;
VkCommandPool commandPool;
vkCreateCommandPool(device, &poolInfo, nullptr, &commandPool);
合理的 Command Pool 策略通常遵循一个核心原则：每个线程拥有独立的 Command Pool。原因在于 vkAllocateCommandBuffers 和 vkFreeCommandBuffers 在内部需要修改 Pool 的状态，如果多个线程共享同一个 Pool，就会产生锁竞争，破坏多线程扩展性。
推荐的工程实践：
- 为每个 worker 线程创建一个专用的
VK_COMMAND_POOL_CREATE_TRANSIENT_BITPool，用于帧内临时命令缓冲 - 为持久化的命令缓冲（如预录制的 UI 绘制命令）单独分配 Pool，避免频繁的 reset/free 开销
- 显式调用
vkResetCommandPool进行批量回收，远比逐个vkResetCommandBuffer高效
// 每帧开始时批量重置整个 Pool
vkResetCommandPool(device, frameCommandPool, 0);
// 然后重新分配命令缓冲
VkCommandBufferAllocateInfo allocInfo{};
allocInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO;
allocInfo.commandPool = frameCommandPool;
allocInfo.level = VK_COMMAND_BUFFER_LEVEL_PRIMARY;
allocInfo.commandBufferCount = 1;
VkCommandBuffer cmd;
vkAllocateCommandBuffers(device, &allocInfo, &cmd);
二、Primary 与 Secondary Command Buffer 的设计抉择
Vulkan 的命令缓冲分为两个层级：
| 特性 | Primary Command Buffer | Secondary Command Buffer |
|---|---|---|
| 可直接提交到 Queue | 是 | 否 |
| 可调用其他 Command Buffer | 是（vkCmdExecuteCommands） | 否 |
| 可在 Render Pass 内执行 | 是 | 是（需在 VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT 下录制） |
| 用途 | 主帧录制、顶层调度 | 多线程并行录制、材质/模型级别复用 |
Secondary Command Buffer 真正的价值在于并行录制。渲染线程可以分发多个任务给 worker 线程，各自独立录制 Secondary Command Buffer，最后由主线程在 Primary Command Buffer 中通过 vkCmdExecuteCommands 批量执行。
// Worker 线程录制 Secondary Command Buffer
VkCommandBufferBeginInfo beginInfo{};
beginInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO;
beginInfo.flags = VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT;
VkCommandBufferInheritanceInfo inheritanceInfo{};
inheritanceInfo.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_INHERITANCE_INFO;
inheritanceInfo.renderPass = renderPass;
inheritanceInfo.subpass = 0;
inheritanceInfo.framebuffer = framebuffer;
beginInfo.pInheritanceInfo = &inheritanceInfo;
vkBeginCommandBuffer(secondaryCmd, &beginInfo);
// ... 录制绘制命令 ...
vkEndCommandBuffer(secondaryCmd);
// 主线程在 Primary CB 中执行
vkCmdExecuteCommands(primaryCmd, secondaryCmdCount, secondaryCmds);
需要注意的是，Secondary Command Buffer 不接受 Pipeline 状态继承（除了 Render Pass 的继承信息），因此每个 Secondary CB 需要独立绑定 Pipeline、Descriptor Set 和 Vertex Buffer。
三、录制模式与生命周期管理
vkBeginCommandBuffer 的 flags 参数决定了命令缓冲的使用模式：
vkBeginCommandBuffer(cmd, &beginInfo);
三种录制模式：
| 标志位 | 含义 | 适用场景 |
|---|---|---|
VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT | 命令缓冲只提交一次后就会被重置或释放 | 每帧动态录制的渲染命令 |
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT | 命令缓冲将在 Render Pass 实例内执行（仅限 Secondary） | 并行录制 Subpass 内容 |
VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT | 命令缓冲可在多个执行中的提交中同时使用 | 极罕见，通常建议避免 |
ONE_TIME_SUBMIT 是最常用的模式，它给驱动提供了最大的优化空间。驱动知道命令缓冲不会被复用，因此可能采用更激进的内存策略。唯一需要注意的是，提交后必须等待 GPU 完成或保证同步安全，才能重置该命令缓冲对应的 Pool。
关于 SIMULTANEOUS_USE_BIT，绝大多数应用都不需要它。如果你需要在多个并行的 Queue Submit 中使用同一个命令缓冲，通常说明你更应该复制一份命令缓冲，或者重新设计提交结构。
四、Queue Submit 与 GPU 执行顺序
Vulkan 的 Queue Submit 是异步的。vkQueueSubmit 调用返回时，命令可能还没有开始在 GPU 上执行。这引出了 Vulkan 同步的第一条铁律：永远不要假设提交顺序等于执行顺序。
VkSubmitInfo submitInfo{};
submitInfo.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO;
submitInfo.commandBufferCount = 1;
submitInfo.pCommandBuffers = &cmd;
// 等待 imageAvailableSemaphore 后再开始执行
tsubmitInfo.waitSemaphoreCount = 1;
submitInfo.pWaitSemaphores = &imageAvailableSemaphore;
submitInfo.pWaitDstStageMask = waitStages;
// 执行完后发出 renderFinishedSemaphore 信号
submitInfo.signalSemaphoreCount = 1;
submitInfo.pSignalSemaphores = &renderFinishedSemaphore;
vkQueueSubmit(graphicsQueue, 1, &submitInfo, VK_NULL_HANDLE);
一个 Submit 内部的命令缓冲大致按数组顺序执行，但不同 Submit 之间完全没有顺序保证。如果你需要在两个 Submit 之间建立依赖，必须使用 Semaphore 或 Barrier。
此外，vkQueueSubmit 自身不是线程安全的——对同一个 Queue 的并发 Submit 需要外部同步（如互斥锁）。如果你有多线程提交需求，建议使用多个 Queue（如果硬件支持）。
五、Semaphore：GPU-GPU 同步的核心
Semaphore 是 Vulkan 中最基础的 GPU 内部同步原语。它只解决一个问题：Queue A 的某一批命令完成后，Queue B 的某一批命令才能开始。
经典的 Swapchain 渲染流程中，Semaphore 扮演了关键角色：
// 1. 从 Swapchain 获取图像（GPU 信号量）
vkAcquireNextImageKHR(device, swapchain, UINT64_MAX,
imageAvailableSemaphore, VK_NULL_HANDLE, &imageIndex);
// 2. 提交渲染命令，等待 imageAvailable，完成后发出 renderFinished
VkPipelineStageFlags waitStages[] = {VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT};
VkSubmitInfo submitInfo = {...};
submitInfo.pWaitSemaphores = &imageAvailableSemaphore;
submitInfo.pWaitDstStageMask = waitStages;
submitInfo.pSignalSemaphores = &renderFinishedSemaphore;
vkQueueSubmit(graphicsQueue, 1, &submitInfo, VK_NULL_HANDLE);
// 3. 提交到 Present Queue，等待 renderFinished
VkPresentInfoKHR presentInfo{};
presentInfo.sType = VK_STRUCTURE_TYPE_PRESENT_INFO_KHR;
presentInfo.waitSemaphoreCount = 1;
presentInfo.pWaitSemaphores = &renderFinishedSemaphore;
presentInfo.swapchainCount = 1;
presentInfo.pSwapchains = &swapchain;
presentInfo.pImageIndices = &imageIndex;
vkQueuePresentKHR(presentQueue, &presentInfo);
这里有两个 Semaphore 形成了一条完整的依赖链：vkAcquireNextImageKHR 发出 imageAvailableSemaphore 信号 -> Submit 等待这个信号后开始渲染 -> 渲染完成后发出 renderFinishedSemaphore -> Present 等待这个信号后执行呈现。
pWaitDstStageMask 是一个经常被误用的参数。它并不是控制哪一步等待 Semaphore，而是控制Pipeline 的哪个阶段会阻塞等待 Semaphore。如果设置为 VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT，整条 Pipeline 都会等待；如果设置为 VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT，则顶点处理等早期阶段可以继续执行，仅片段阶段阻塞。合理设置这个掩码可以显著减少 GPU 气泡。
六、Fence：CPU-GPU 同步的唯一手段
如果你需要从 CPU 侧知道 GPU 是否完成了某项工作，Fence 是唯一的选择。Semaphore 对 CPU 不可见，它只存在于 GPU 的内部执行流中。
// 提交时关联 Fence
vkQueueSubmit(graphicsQueue, 1, &submitInfo, frameFence);
// CPU 侧等待（阻塞或轮询）
vkWaitForFences(device, 1, &frameFence, VK_TRUE, UINT64_MAX);
vkResetFences(device, 1, &frameFence);
// 现在可以安全地释放/修改 GPU 资源
Fence 最常见的用途是帧循环同步。每帧都有一个对应的 Fence，在提交时关联。下一帧开始录制前，CPU 检查上一帧的 Fence 是否完成，以确保不会覆盖 GPU 仍在读取的资源。
// 帧循环中的典型模式
void renderFrame() {
// 等待本帧对应的前一个 Fence（如果有）
vkWaitForFences(device, 1, &inFlightFences[currentFrame], VK_TRUE, UINT64_MAX);
vkResetFences(device, 1, &inFlightFences[currentFrame]);
// 获取 Swapchain 图像
vkAcquireNextImageKHR(..., imageAvailableSemaphores[currentFrame], ...);
// 录制并提交命令缓冲
VkSubmitInfo submitInfo = {...};
submitInfo.pWaitSemaphores = &imageAvailableSemaphores[currentFrame];
submitInfo.pSignalSemaphores = &renderFinishedSemaphores[currentFrame];
vkQueueSubmit(graphicsQueue, 1, &submitInfo, inFlightFences[currentFrame]);
// Present
VkPresentInfoKHR presentInfo = {...};
presentInfo.pWaitSemaphores = &renderFinishedSemaphores[currentFrame];
vkQueuePresentKHR(presentQueue, &presentInfo);
currentFrame = (currentFrame + 1) % MAX_FRAMES_IN_FLIGHT;
}
vkWaitForFences 的 timeout 参数传 UINT64_MAX 表示无限等待。在非阻塞场景中，你可以先使用 vkGetFenceStatus 轮询状态。
七、Pipeline Barrier：执行依赖与内存依赖的统一
Pipeline Barrier 是 Vulkan 最强大也最复杂的同步工具，它同时解决两类问题：
- Execution Dependency：确保某类操作的命令在另一类操作之前完成（例如写入操作完成后，读取操作才能开始）
- Memory Dependency：确保缓存和内存的一致性（例如写入结果对后续读取可见）
VkMemoryBarrier memoryBarrier{};
memoryBarrier.sType = VK_STRUCTURE_TYPE_MEMORY_BARRIER;
memoryBarrier.srcAccessMask = VK_ACCESS_SHADER_WRITE_BIT;
memoryBarrier.dstAccessMask = VK_ACCESS_SHADER_READ_BIT;
vkCmdPipelineBarrier(
cmd,
VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, // srcStageMask
VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT, // dstStageMask
0, // dependencyFlags
1, &memoryBarrier, // memoryBarriers
0, nullptr, // bufferMemoryBarriers
0, nullptr // imageMemoryBarriers
);
srcAccessMask 和 dstAccessMask 描述的是内存访问类型。注意它们必须与 srcStageMask 和 dstStageMask 语义一致——你不能在 srcStageMask 里没有的阶段使用对应的 srcAccessMask。例如 VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT 只能在包含 VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT 的 srcStageMask 中使用。
常见的 Barrier 组合：
| 场景 | srcStageMask | srcAccessMask | dstStageMask | dstAccessMask |
|---|---|---|---|---|
| 渲染完成后读取像素 | COLOR_ATTACHMENT_OUTPUT | COLOR_ATTACHMENT_WRITE | FRAGMENT_SHADER | SHADER_READ |
| Compute Shader 写入后读取 | COMPUTE_SHADER | SHADER_WRITE | FRAGMENT_SHADER | SHADER_READ |
| Transfer 完成后用于渲染 | TRANSFER | TRANSFER_WRITE | FRAGMENT_SHADER / VERTEX_SHADER | SHADER_READ |
| Depth 写入后采样 | LATE_FRAGMENT_TESTS | DEPTH_STENCIL_ATTACHMENT_WRITE | FRAGMENT_SHADER | SHADER_READ |
八、Image Layout Transition 与 Image Memory Barrier
Vulkan Image 在不同使用阶段需要处于不同的 Layout。例如，Color Attachment 需要 VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL，而 Shader 读取需要 VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL。Layout 转换本身就是一次内存依赖操作，因此通过 VkImageMemoryBarrier 完成。
VkImageMemoryBarrier barrier{};
barrier.sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER;
barrier.oldLayout = VK_IMAGE_LAYOUT_UNDEFINED;
barrier.newLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL;
barrier.srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED;
barrier.dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED;
barrier.image = image;
barrier.subresourceRange.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
barrier.subresourceRange.baseMipLevel = 0;
barrier.subresourceRange.levelCount = mipLevels;
barrier.subresourceRange.baseArrayLayer = 0;
barrier.subresourceRange.layerCount = 1;
barrier.srcAccessMask = 0;
barrier.dstAccessMask = VK_ACCESS_TRANSFER_WRITE_BIT;
vkCmdPipelineBarrier(
cmd,
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
VK_PIPELINE_STAGE_TRANSFER_BIT,
0,
0, nullptr,
0, nullptr,
1, &barrier
);
oldLayout = VK_IMAGE_LAYOUT_UNDEFINED 意味着你不在乎 Image 之前的内存内容。如果是 MipChain 生成，从上一 Mip 级读取到下一级写入时，则需要精确指定 oldLayout 以保留数据。
对于 Queue Family Ownership Transfer（例如从 Graphics Queue 生成内容，然后交给 Compute Queue 处理），需要将 srcQueueFamilyIndex 和 dstQueueFamilyIndex 设为实际的 Queue Family 索引，而不是 VK_QUEUE_FAMILY_IGNORED。这涉及特殊的 Acquire/Release Barrier 配对。
九、Subpass Dependency：Render Pass 内部的精细化同步
Render Pass 可以包含多个 Subpass，每个 Subpass 可以读写不同的 Attachment。Vulkan 允许你在 Subpass 之间定义依赖关系，这就是 Subpass Dependency。
VkSubpassDependency dependency{};
dependency.srcSubpass = 0; // 第 0 个 Subpass
dependency.dstSubpass = 1; // 第 1 个 Subpass
dependency.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
dependency.dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
dependency.dstAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT;
dependency.dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;
一个典型的 Deferred Rendering 管线会涉及大量 Subpass Dependency：
- G-Buffer Subpass 写入各种 Attachment
- Lighting Subpass 读取 G-Buffer 作为 Input Attachment
- Postprocess Subpass 读取 Lighting 结果
VK_DEPENDENCY_BY_REGION_BIT 是一个重要的优化标志。它告诉驱动，依赖是按区域（通常是 tile）而非整个 Render Pass 实例生效的。这对 TBDR（Tile-Based Deferred Rendering）架构的移动端 GPU 尤其重要。
如果省略 Subpass Dependency，驱动可能无法正确同步 Attachment 的读写，导致画面撕裂或未定义行为。Vulkan Validation Layer 会对此类问题给出警告。
十、Timeline Semaphore：现代 Vulkan 的同步范式
传统的 Binary Semaphore 只有两个状态： signaled 和 unsignaled。这在大规模异步调度中显得捉襟见肘。VK_KHR_timeline_semaphore（Vulkan 1.2 核心）引入了 64 位整数值 Semaphore，支持 wait-before-signal，彻底改变了 Vulkan 同步模型。
VkSemaphoreTypeCreateInfo timelineCreateInfo{};
timelineCreateInfo.sType = VK_STRUCTURE_TYPE_SEMAPHORE_TYPE_CREATE_INFO;
timelineCreateInfo.semaphoreType = VK_SEMAPHORE_TYPE_TIMELINE;
timelineCreateInfo.initialValue = 0;
VkSemaphoreCreateInfo createInfo{};
createInfo.sType = VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO;
createInfo.pNext = &timelineCreateInfo;
VkSemaphore timelineSemaphore;
vkCreateSemaphore(device, &createInfo, nullptr, &timelineSemaphore);
使用 Timeline Semaphore 进行 Submit：
// 提交时信号量值加 1
uint64_t signalValue = frameNumber;
VkTimelineSemaphoreSubmitInfo timelineInfo{};
timelineInfo.sType = VK_STRUCTURE_TYPE_TIMELINE_SEMAPHORE_SUBMIT_INFO;
timelineInfo.signalSemaphoreValueCount = 1;
timelineInfo.pSignalSemaphoreValues = &signalValue;
VkSubmitInfo submitInfo{};
submitInfo.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO;
submitInfo.pNext = &timelineInfo;
submitInfo.signalSemaphoreCount = 1;
submitInfo.pSignalSemaphores = &timelineSemaphore;
vkQueueSubmit(queue, 1, &submitInfo, VK_NULL_HANDLE);
CPU 侧或 GPU 侧等待特定值：
// CPU 等待
uint64_t waitValue = targetFrame;
VkSemaphoreWaitInfo waitInfo{};
waitInfo.sType = VK_STRUCTURE_TYPE_SEMAPHORE_WAIT_INFO;
waitInfo.semaphoreCount = 1;
waitInfo.pSemaphores = &timelineSemaphore;
waitInfo.pValues = &waitValue;
vkWaitSemaphores(device, &waitInfo, UINT64_MAX);
Timeline Semaphore 相比 Binary Semaphore 的优势：
- 支持乱序等待：你可以在值 N 还没被 signal 时就提交等待值 N 的操作
- 单一 Semaphore 管理全部帧：不再需要每帧一个 Fence 的数组，一个 Timeline Semaphore 配合单调递增的整数值即可
- CPU-GPU 统一接口：CPU 可以等待 GPU Timeline，GPU Queue Submit 也可以等 Timeline 值
- 天然支持回滚检查：通过
vkGetSemaphoreCounterValue查询当前值，轻松判断某帧是否完成
十一、同步原语全景对比
| 特性 | Semaphore (Binary) | Semaphore (Timeline) | Fence | Event | Pipeline Barrier |
|---|---|---|---|---|---|
| GPU-GPU 同步 | 是 | 是 | 否 | 是（仅限同一 Queue） | 是（同 Submit/Queue） |
| CPU-GPU 同步 | 否 | 是（CPU 可查询/等待） | 是 | 是 | 否 |
| 跨 Queue 支持 | 是 | 是 | N/A | 否 | 否（需 Queue Family Transfer） |
| 可等待值 | 二元 | 64-bit 计数 | 二元 | 二元 | N/A |
| 性能开销 | 低 | 低 | 中 | 低 | 中（可能 flush GPU pipeline） |
| 主要用途 | Swapchain/Queue 间依赖 | 现代统一同步方案 | 帧循环/资源回收 | 细粒度 GPU 内部同步 | 资源状态转换、内存可见性 |
| Vulkan 版本 | 1.0 | 1.2 (或 KHR 扩展) | 1.0 | 1.0 | 1.0 |
FAQ
Q1: 为什么我的代码在 NVIDIA 上跑得好，在 AMD/Intel 上就出现画面撕裂？
这几乎肯定是同步缺失导致的。NVIDIA 驱动往往在某些场景下自动插入隐式同步，而 AMD 和 Intel 驱动更严格遵守 Vulkan 规范。请仔细检查你是否在 Render Pass 的 Attachment 读写之间、Queue Submit 之间以及资源 Layout 转换时插入了正确的 Barrier 或 Dependency。
Q2: Pipeline Barrier 应该放在哪里？每一帧都放很多 Barrier 会不会有性能问题？
Barrier 确实有性能成本，因为它可能导致 GPU Pipeline 的 stall 和缓存 flush。优化原则是：只在真正需要的地方插入，且尽可能合并多个 Barrier 为一次 vkCmdPipelineBarrier 调用。Vulkan 1.3 引入的 VK_KHR_synchronization2 提供了更灵活的 Stage/Access 掩码，可以减少过度同步。
Q3: Fence 和 Timeline Semaphore 都能做 CPU-GPU 同步，应该选哪个？
如果是新项目并且目标平台支持 Vulkan 1.2+，优先使用 Timeline Semaphore。它的语义更统一，不需要每帧维护 Fence 数组，代码更简洁。对于需要兼容旧设备或旧驱动的项目，Fence 仍然是安全的回退方案。
Q4: 什么时候需要使用 VK_DEPENDENCY_BY_REGION_BIT？
当你确定依赖关系是按像素区域生效而非全局生效时使用。典型的例子是同一 Attachment 在一个 Subpass 中写入，在下一个 Subpass 中作为 Input Attachment 读取。如果使用了全屏 quad 读取前一帧结果，则不应该用这个 flag。
Q5: 多个 Secondary Command Buffer 可以共享同一个 Command Pool 吗？
技术上可以，但会产生线程锁竞争。最佳实践是每个 worker 线程一个 Pool。如果 Secondary Command Buffer 是跨帧复用的（例如静态场景的预录制命令），可以为它们分配专用的持久 Pool，并在多线程分配时加锁保护。
Vulkan 的显式同步是一把双刃剑：它给了开发者榨干 GPU 性能的终极权力，也把调试复杂度推到了新的高度。掌握 Command Buffer 的生命周期管理、理解 Semaphore/Fence/Barrier 的适用边界、善用 Timeline Semaphore 简化同步模型，是每一个 Vulkan 开发者必须跨过的门槛。建议始终开启 Vulkan Validation Layer 和同步验证（Synchronization Validation）进行辅助排查，它能在开发阶段捕获绝大多数同步错误。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。