编译、链接、ODR 与 ABI：定位二进制边界问题

把预处理、翻译单元、符号解析和运行时装载分开，再判断是缺少定义、违反 ODR，还是 ABI 不兼容。

一个 .cpp 文件连同预处理展开的头文件组成翻译单元。编译器通常先为各翻译单元生成目标文件，链接器再解析符号与重定位，动态链接程序还要经过运行时装载。因此“头文件找不到”“undefined reference / unresolved external symbol”“启动时缺少动态库”属于不同阶段。排查从失败命令、完整诊断、目标架构和实际输入文件开始，先确认实现文件确实加入目标，再比对声明与定义的命名空间、参数、const 限定及链接属性；不要先向链接参数里反复追加库。

ODR 即单一定义规则，并不等于“每个函数只能在整个工程出现一次文本”。C++17 允许满足条件的 inline 函数、inline 变量、类和模板在多个翻译单元中定义，但这些定义必须符合相应的一致性要求。头文件中由不同宏展开出不同类布局、不同 inline 函数体，是常见隐蔽问题。某些跨翻译单元的 ODR 违例不要求实现诊断，链接成功也不能证明程序合法。统一影响公共头文件的编译宏，比依赖链接器挑中某一份实现更可靠。

API 描述源码调用方式，ABI 还涉及名字修饰、参数传递、对象布局、虚函数机制和运行时约定。源码能重新编译，并不代表旧插件能直接加载新库。接口暴露 std::string、异常或由一方分配另一方释放的对象时，要验证编译器、标准库、配置及所有权协议的兼容性。libstdc++ 的 dual ABI 是具体例子：_GLIBCXX_USE_CXX11_ABI 的选择与 -std=c++17 不是同一个开关。extern "C" 可以约束语言链接，却不能自动统一结构体布局、调用约定和内存分配器。

排查链应留下可复核的证据：保存编译和链接命令、依赖版本、目标文件与最终二进制；检查预期符号是否定义、符号实际名称和运行时加载路径。在 Linux GNU 工具链可用 nm -C、readelf；Windows 的 MSVC 开发者终端可用 dumpbin。静态库是否被提取、顺序规则以及导出符号规则依赖链接器，不能把某平台上的解决办法直接当成 C++ 标准规则。修复后用原发布配置重新构建，并验证旧客户端或插件的兼容性测试。

# Linux，GNU Binutils；仅为排查命令示例，尚未执行。
# 将路径换成实际构建产物。
nm -C build/libcalc.a
readelf -Ws build/server
readelf -d build/server

# Windows，MSVC 开发者 PowerShell；仅为示例。
dumpbin /symbols build\calc.obj
dumpbin /exports build\calc.dll
dumpbin /dependents build\server.exe

深入面试与自测

现代 CMake 与 CTest：让依赖和测试跟着目标走

使用 target 表达依赖与使用要求，明确配置、构建和测试三个步骤，保证换机器、换配置时仍能复现。

把库和可执行文件建模成 target，并把头文件路径、编译特性和依赖挂到对应 target。PRIVATE 用于自身实现需要，PUBLIC 用于自身与使用者都需要，INTERFACE 用于使用者需要。判断依据是公共接口实际暴露了什么：若公开头文件包含某依赖的类型，使用者通常也需要该依赖的使用要求。尽量使用依赖包导出的命名目标，而不是散落的绝对路径；这让编译参数和传递依赖能随目标传播。

配置、构建和执行测试是不同工作。源码目录与构建目录分开，不同编译器、架构和 Sanitizer 配置使用独立目录。单配置生成器通过 CMAKE_BUILD_TYPE 选择 Debug/Release；Visual Studio 等多配置生成器通常在构建、测试阶段用 --config / -C 选择配置。缓存了旧编译器或错误依赖路径时，应新建干净构建目录验证，不要把偶然修好缓存当成根因。需要长期复现时，还应记录工具链版本、依赖锁定与配置参数。

include(CTest) 为项目提供 BUILD_TESTING 选项，启用时可用 add_test 注册测试。下面示例以 CMake 3.20+ 的常用接口为基线，先构建测试目标，再由 CTest 执行；注册测试不等于已经产生了测试程序。测试程序应通过返回值或测试框架明确报告失败。仅用 assert 充当全部测试，在定义 NDEBUG 的发布配置下会丢失检查。异步测试还应设置合理超时并清理线程、端口和临时目录，避免把残留进程造成的偶现失败误判成业务错误。

构建是否“可复现”需要分层描述：相同输入能得到同样行为，不自动等于二进制逐字节相同。时间戳、绝对路径、依赖下载来源和工具链差异都可能影响产物。面试讨论应说清自己保证的是依赖可追溯、干净机器可构建，还是位级可复现；再给出相应的验收办法。最有价值的验证是从空构建目录执行规定流程，并检查测试确实被发现且失败能使流水线失败。

# CMakeLists.txt 示例；需要自行提供 src/calc.cpp、include/ 和 tests/calc_test.cpp。
# 此配置和以下命令尚未在本资料编写阶段执行。
cmake_minimum_required(VERSION 3.20)
project(Calc LANGUAGES CXX)
include(CTest)
add_library(calc src/calc.cpp)
target_include_directories(calc PUBLIC include)
target_compile_features(calc PUBLIC cxx_std_17)
if(BUILD_TESTING)
  add_executable(calc_tests tests/calc_test.cpp)
  target_link_libraries(calc_tests PRIVATE calc)
  add_test(NAME calc_contract COMMAND calc_tests)
  set_tests_properties(calc_contract PROPERTIES TIMEOUT 20)
endif()

# Linux 或 Windows：已安装 Ninja 及对应编译器，单配置生成器。
cmake -S . -B build-release -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build-release
ctest --test-dir build-release --output-on-failure

# Windows：已经使用 Visual Studio 多配置生成器完成配置时。
cmake --build build-vs --config Release
ctest --test-dir build-vs -C Release --output-on-failure

深入面试与自测

警告、静态分析与 CI：建立能解释的质量门槛

诊断必须基于真实构建参数，门槛必须能发现实际缺陷，同时保留工具版本和误报处理的证据。

编译警告首先用于暴露可疑转换、未初始化路径、生命周期和接口误用，不是“无 bug 证明”。GCC/Clang 的 -Wall 并不表示所有警告，-Wextra 也不是语言规则的全集；部分诊断依赖优化或数据流分析。先固定受支持工具链，对自己的 target 启用经验证的警告集合，再逐步处理历史问题。全局 -Werror 可能让一次编译器升级因新警告阻断构建，因此可把工具链升级与业务变更分开，并对例外记录最小范围和原因。

静态分析器需要知道实际 include 路径、宏、语言版本和平台，否则分析的是另一个程序。clang-tidy 可以读取 compile_commands.json；用 CMake 导出时应选择支持该功能的生成器，例如 Ninja 或 Makefiles，而不是假定任意生成器都会产生该文件。先分析一小组有代表性的目标，核对诊断位置和触发条件，再决定是否加入门禁。自动修复也要审阅：编译通过不能证明所有权、锁顺序或业务语义没有改变。

CI 应覆盖不同失败机制，而不是堆叠近似检查。可将快速构建与契约测试放在每次变更上，将 ASan/UBSan、TSan 和较长故障场景放到独立作业，按项目规模安排频率。每个作业保存编译器版本、提交标识、随机种子和必要日志。测试失败时首先保证能定位到具体场景；重跑通过只能说明症状不稳定，不能自动删除失败记录。使用第二编译器有助于暴露可移植性问题，但不是每个小变更都需要任意扩张平台矩阵。

测试设计从可观察契约出发：错误输入是否被拒绝，异常后状态是否一致，停止后线程是否退出，重试是否重复产生副作用。覆盖率只是执行到代码的线索；一行被执行过不代表边界、并发交错和断言足够。对修复类变更，最有力的回归测试能在修复前触发原问题，并在修复后验证行为，而不只是照抄实现分支。对不稳定并发问题，使用可控同步点、超时和状态断言，比增加随机 sleep 更容易解释。

# Linux，Clang + Ninja；在项目根目录执行的示例，尚未执行。
cmake -S . -B build-tidy -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
clang-tidy -p build-tidy src/calc.cpp

# 以下为 GCC/Clang 警告的示意集合，应按项目和工具链验证后用于 target：
# -Wall -Wextra -Wpedantic
# Windows MSVC 常见基线为 /W4，不能将 GNU 参数原样套用。

深入面试与自测

GDB 与 core dump：从崩溃现场建立因果链

保存匹配的二进制、符号和上下文；把最后崩溃的位置与最早破坏状态的位置分开。

core dump 是特定时刻进程内存状态的快照，通常能帮助还原寄存器、调用栈和部分对象，不是完整的执行录像。调查前先确认 core 对应哪个构建，获取准确的可执行文件、调试符号和共享库版本。拿最新本地代码配旧 core，可能得到看似合理但实际错误的源码位置。发布产物宜保留构建标识与符号归档，使线上问题能映射回确切源码，而不是临时用 Debug 重编译替换证据。

进入 GDB 后先核对文件和共享库，再看异常信号、崩溃线程和所有线程调用栈。选择有意义的帧，查看参数、对象生命周期与附近控制流。优化构建出现变量被优化掉、内联帧或栈回溯不完整时，应把这些记为证据限制，而不是猜一个值。若崩溃发生在 malloc、容器析构或字符串复制中，既可能是当前调用参数错误，也可能是更早的越界写、重复释放或数据竞争；需要结合 Sanitizer、最小复现和时间线缩小范围。

死锁与高延迟不一定会生成崩溃 core。分析无响应进程时，要区分线程在正常等待任务、等待 I/O、争抢锁还是形成环形等待。多次采样若总停在同一位置只是线索，仍需还原哪个线程持有哪个资源、谁负责唤醒以及谓词是否能改变。采集现场会影响时序，在线附加调试器也可能暂停业务，应在有明确处置流程的环境中操作；本节只给离线 core 的分析示例。

Linux 没有生成 core 时，要检查进程资源限制、core_pattern 的目标或收集程序、目录权限、磁盘空间及进程属性，而不只执行一次 ulimit。core 可能包含用户输入、令牌和其他内存数据，排障归档应按敏感诊断产物控制访问与保留期限。Windows 常用转储与 WinDbg/Visual Studio 对应流程；Linux 的 core 文件路径和 GDB 命令不能原样等价于 Windows 的全部行为。

# Linux + GDB：已有受控保存的匹配产物和 core；以下命令尚未执行。
gdb ./release/server ./diagnostics/core

# 以下输入 GDB 交互界面：
info files
info sharedlibrary
info threads
thread apply all bt
frame 0
info args
info locals

# 再按实际堆栈选择 frame N，不要机械停留在 frame 0。
# bt full 等命令可能展示敏感内存内容，分享前须审查。

深入面试与自测

ASan、UBSan、TSan：检测能力、盲区与修复顺序

选择与失败机制对应的检测器，用报告定位第一处违规，并明确“没有报告”不等于程序正确。

ASan 通过编译插桩和运行时检测一类内存访问错误，例如越界、释放后使用和非法释放；UBSan 检测被启用的特定未定义行为类别。它们不能覆盖全部 C++ 未定义行为，也不能验证业务结果。编译和最终链接都需要相应参数，最好使相关自有代码与可重编译依赖都进入同一检测配置。完全未插桩的代码、未执行路径和工具不能观察到的行为，仍可能隐藏问题。

TSan 主要用于动态检测数据竞争，要与“逻辑竞态”区分。两个原子变量分别读写可能没有数据竞争，却可能破坏多字段业务不变量；线程安全队列也可能因关闭协议错误导致永远等待。TSan 不提供死锁、饥饿和所有内存序算法正确性的通用证明。官方支持平台和架构有范围，本节命令针对 Linux Clang；不要假定原生 Windows 上可以直接使用同一套 TSan 工作流。

把 ASan/UBSan 与 TSan 放在独立构建目录和测试作业中。工具会增加内存、运行时间开销并改变布局与调度，超时阈值应针对检测环境有依据地设置。遇到报告先检查第一处违规访问及其分配、释放或竞争线程栈，修复后重跑原用例；后续崩溃可能只是状态被破坏的连锁反应。忽略项应只用于已理解且能解释的边界，不要为获得绿色结果屏蔽整个模块。

整数溢出也要按语义分类：有符号整数溢出属于需要避免的未定义行为，普通无符号运算按模运算定义，并不因为回绕就自动属于同一种 UB。但长度、价格或容量计算即使使用无符号数，业务上也可能不允许回绕。应在运算前用上界检查、受检运算或更宽且足够的类型处理，而不是期待默认 UBSan 配置替业务定义范围。诊断报告最终必须落到输入验证和状态不变量上。

# Linux + Clang，源文件名为示例；以下命令尚未执行。
# ASan 与 UBSan 组合；编译和链接由 clang++ 一次完成。
clang++ -std=c++17 -O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined app.cpp -o app-asan
./app-asan

# 多线程程序的 TSan 独立构建，不与 ASan 放在同一个二进制。
clang++ -std=c++17 -O1 -g -fno-omit-frame-pointer -fsanitize=thread -pthread threaded_app.cpp -o app-tsan
./app-tsan

# 实际工程应把插桩同时应用到相关编译与链接步骤，
# 并核查依赖库、Clang 版本及目标平台的支持范围。

深入面试与自测

基准测试与火焰图：证明优化改善了什么

先定义指标和负载，再测量、提出假设、修改、对照；明确 CPU 时间与端到端等待时间的区别。

性能问题先用业务可观察的目标描述：固定吞吐下的 p99 延迟、达到某延迟目标时的容量，或每个请求的 CPU 与内存成本。明确输入分布、并发模型、缓存冷热、数据规模与测量边界；只测一次平均耗时，无法支撑尾延迟结论。比较前后版本时保持硬件、编译配置和负载一致，记录重复运行波动，避免把热机、CPU 频率或后台任务变化误认为代码收益。

微基准适合隔离某个假设，但要防止被测工作被优化掉，也要判断初始化、分配和缓存预热是否属于真实成本。Google Benchmark 提供计时与防优化辅助工具；这些工具并不自动让一个不合理的输入变得真实。对可在编译期确定的表达式，即使使用 DoNotOptimize，也仍应检查实际生成代码与数据依赖。小规模热点的加速还要回到端到端负载验证：局部节约可能被锁竞争、I/O 或内存占用抵消。

CPU 火焰图把采样到的调用栈聚合展示，横向宽度代表采样权重，纵向代表调用深度，横轴不是请求时间线。父帧宽度包含子调用成本，不能把各层宽度相加当作独立耗时。颜色也不自动表示温度或严重程度。CPU 采样主要回答 CPU 在执行什么；服务慢却 CPU 不忙时，要补充等待、调度、锁、I/O 和请求追踪，不能只根据一张 CPU 火焰图排除所有瓶颈。

优化要有可反驳的假设，例如“重复解析占用 30% CPU，缓存后可减少该部分，但会增加内存并改变失效路径”。每次修改保留正确性检查、资源消耗和延迟分布对照。Amdahl 定律可约束预期：若固定工作负载中仅 20% 时间可被优化，即使该部分耗时降为零，理论整体加速上限也只有 1.25 倍；这依赖工作量和其他成本不变。容量与负载结构改变后，不能机械沿用这个数字。

深入面试与自测

缓存、NUMA 与伪共享：把硬件假设变成证据

关注访问模式和跨核一致性开销，区分真正的数据共享、伪共享与内存带宽瓶颈。

CPU 访问内存的成本不仅取决于元素个数，还取决于空间与时间局部性、工作集、访问顺序、依赖链和硬件预取能力。连续容器在顺序遍历时通常更有利于局部性，但不能据此断言它在所有增删查场景都更快。先从实际访问模式解释假设，再测量吞吐、CPU 周期、缓存失效和带宽等证据；计数器名称与可用性依赖硬件和权限，不应把一次高 miss 数直接等同为唯一瓶颈。

伪共享发生在多个线程修改逻辑上独立、却位于同一缓存一致性粒度中的数据时。即使每个字段使用 atomic，语言层面没有数据竞争，缓存行仍可能在核心间频繁转移所有权。常见改法是每线程局部累计后合并、分离高频写字段或调整布局；填充会增加工作集，读者又可能失去局部性。优化应证明跨核流量下降且端到端指标改善，而不是默认给所有成员加 alignas(64)。

NUMA 系统的内存位置会影响远端访问成本。Linux 的内存策略与页面实际分配/缺页时机相关，改变线程运行位置或策略不代表已有页面自动迁移；线程策略的作用范围也需要明确。可先比较单节点和跨节点负载，记录线程、数据的归属与远端访问，再评估 first-touch 初始化、分片或显式策略。把全部线程固定到少量核心可能降低迁移，也可能造成负载不均和排队，必须与未绑定基线对照。

布局实验容易混入其他变量。比较两个计数器实现时要保持工作量、线程数、同步语义和编译配置一致，记录核心拓扑，并区分真正争用同一个计数器与各自计数器同处一行。若需要运行时汇总局部计数，要补充同步或快照协议，不能为了性能引入普通变量并发读写。缓存行大小和破坏性干涉粒度不是所有平台固定 64 字节，布局要求还可能成为公开类型 ABI 的一部分。

深入面试与自测

异常安全、错误协议与故障注入：明确提交点

把可能失败的准备工作放在状态提交前，说明失败后保留什么，并区分内存回滚与外部副作用。

异常安全保证描述失败后的状态：基本保证要求对象不变量仍成立且资源不泄漏；强保证要求操作失败时可观察状态不变；不抛保证要求操作不以异常逃出。RAII 能在栈展开时释放资源，但自动析构不会撤销已经修改的业务字段、已发送的邮件或已提交的数据库事务。设计时列出状态不变量、所有可能失败点和对外可见的提交点，再选择能实际实现的保证。

实现强保证的常见方式是先在临时对象上完成分配、校验与计算，成功后用确定不会抛出的步骤提交。下面实验对 std::vector<std::string> 使用默认分配器，在候选副本上校验，再 swap 替换；复制和校验失败都发生在修改原状态之前。若换成具有特殊传播语义的自定义分配器、带副作用的元素或不同提交步骤，必须重新检查前提，不能机械推广“copy-and-swap 永远安全”。

错误协议要帮助调用方决策。区分输入非法、资源不足、可重试的短暂故障和结果未知；为错误附加阶段、操作标识和必要上下文，而不是用一个布尔值吞掉信息。C++17 可以用项目定义的结果类型或异常，std::expected 是 C++23 标准库设施，不能默认在 C++17 中可用。noexcept 是边界承诺：异常逃出会调用 terminate，并不代表编译器已经证明实现不会抛出。析构或清理应有明确的失败处理，不能在已有异常传播时再次抛出导致意外终止。

故障注入针对实际失败边界进行：候选复制失败、校验失败、提交前失败、外部提交成功但响应丢失，需要不同断言。本节实验只验证内存内更新的两个人工注入点和输入拒绝，未模拟所有分配失败，也不覆盖并发访问。外部系统的结果未知要依靠幂等键、查询状态、日志或补偿协议处理，不能把抛出异常等同于远端操作未发生。

深入面试与自测

#include <cassert>
#include <iostream>
#include <stdexcept>
#include <string>
#include <utility>
#include <vector>

class Config {
public:
    explicit Config(std::vector<std::string> initial)
        : values_(std::move(initial)) {
        validate(values_);
    }

    const std::vector<std::string>& values() const noexcept {
        return values_;
    }

    void replace(const std::vector<std::string>& next, int fail_point = 0) {
        auto candidate = next;  // Allocation/copy may throw; values_ is unchanged.
        if (fail_point == 1) {
            throw std::runtime_error("injected after copy");
        }
        validate(candidate);
        if (fail_point == 2) {
            throw std::runtime_error("injected before commit");
        }
        // std::vector<std::string> uses the default allocator here.
        // swap is the non-throwing commit; there are no concurrent readers.
        values_.swap(candidate);
    }

private:
    static void validate(const std::vector<std::string>& values) {
        if (values.empty()) {
            throw std::invalid_argument("empty configuration");
        }
        for (const auto& value : values) {
            if (value.empty()) {
                throw std::invalid_argument("empty entry");
            }
        }
    }
    std::vector<std::string> values_;
};

static void check(bool condition) {
    assert(condition);
    if (!condition) {
        throw std::logic_error("check failed");
    }
}

int main() {
    Config config({"old-a", "old-b"});
    const auto original = config.values();
    const std::vector<std::string> replacement{"new-a", "new-b"};

    for (int point : {1, 2}) {
        bool caught = false;
        try {
            config.replace(replacement, point);
        } catch (const std::runtime_error&) {
            caught = true;
        }
        check(caught);
        check(config.values() == original);
    }

    bool invalid_caught = false;
    try {
        config.replace({"valid", ""});
    } catch (const std::invalid_argument&) {
        invalid_caught = true;
    }
    check(invalid_caught);
    check(config.values() == original);

    config.replace(replacement);
    check(config.values() == replacement);
    std::cout << "transaction checks passed\n";
}

背压、优雅停机与容量：为服务设计有限资源边界

入口、队列、执行和下游各自有预算；过载时明确拒绝与恢复，停机时明确谁停止、谁唤醒、谁回收。

服务过载时，增加线程或无限排队通常只把压力转移到内存、连接或下游。先给系统定义可接受的在途请求数、队列长度、排队字节数、任务期限与下游并发上限；只限制任务数量不足以约束大请求的内存。入口达到预算后要选择有语义的拒绝、降级或延迟接纳，并让调用方知道是否适合重试。已经过期的任务应尽早取消或跳过，避免继续花费资源完成无人等待的结果。

背压应沿资源链传播，而不是只在一个队列上加锁。生产速度长期高于消费速度时，有限队列必须让生产者等待、失败或丢弃，具体策略由业务决定；日志、支付和视频帧不能使用同一种丢弃规则。阻塞生产者要考虑其是否占有消费者需要的锁或线程，否则可能造成资源环路。取消还需要释放请求预算、连接和临时缓冲区，不能仅把一个标志改为 true。

优雅停机是协议：先停止接收新任务，标记队列关闭并唤醒等待者；再根据策略排空已有任务或取消未执行任务，给在途 I/O 和任务设置总截止时间；最后等待工作线程退出后销毁共享资源。关闭状态与队列谓词必须在相同同步规则下访问，消费者应能区分“暂时为空”和“关闭且已空”。不要持有工作线程退出所需的互斥锁执行 join。C++20 的 jthread/stop_token 提供协作取消机制，也不会自动打断所有阻塞系统调用。

容量规划需要稳定负载曲线：随着到达率增加，观察有效吞吐、排队时间、错误率、CPU、内存和下游饱和点。Little 定律 L = λW 使用一致系统边界下的长期平均量，且要求系统处于合适的稳定条件。例如平均 2000 请求/秒、系统内平均停留 0.05 秒，对应平均约 100 个系统内请求；这不是“队列必须设 100”的结论，也不能将 p99 直接代入求精确容量。峰值突发、超时、故障容量和安全余量需另行评估。

深入面试与自测

项目面试与分布式故障：超时、幂等和一致性的边界

用需求、状态机、失败窗口和验证证据回答项目追问；每个“保证”都要说明适用范围。

项目介绍先给出可验证的约束：服务处理什么请求，数据规模和到达率如何测量，允许多大延迟和不一致窗口，自己负责哪部分。随后解释关键路径、状态存储、并发模型和最困难的失败场景。没有实际测量的数据应标注为估算或设计目标，不把本地实验写成线上收益。本节题目是工程推演题，不声称来自任何公司的真实面试。

超时表示调用方没有在期限内取得结果，并不证明远端未执行。重试前要确认操作是否安全重复、剩余总期限和重试预算。连接、TLS、请求传输、排队和响应读取的计时范围应根据客户端实现核查；不同层各自重试会放大请求。用有上限的退避和抖动分散重试，选定负责重试的一层，并区分明确拒绝与结果未知。过载时盲目重试可能让系统更难恢复。

幂等设计需要稳定操作标识、请求语义与持久状态。同一操作重试使用同一键；相同键但不同参数应按协议拒绝或明确处理。若业务写入与幂等记录分开提交，崩溃窗口仍可重复执行，因此要在同一事务中提交，或使用能恢复的持久状态机。键的作用域、并发重复请求、保留时间和响应重放都要设计。仅在内存 set 中记录已处理 ID 无法抵抗进程重启，也不能自动解决跨服务副作用。

消息“至少一次”通常意味着消费者必须面对重复，“至多一次”可能牺牲丢失后的恢复；exactly-once 需要明确是哪段读、处理和写入受到协议约束。Kafka 事务可以支持其规定范围内的消费与生产原子关系，但不能自动让外部邮件或支付只发生一次。跨数据库与消息系统常用事务 outbox 保证业务变更与待发事件同事务写入，再重试投递；投递仍可能重复，消费者需要幂等或 inbox。最终一致性也要有可追踪的收敛条件、积压监控与修复流程。

深入面试与自测