C++按引用捕获抛出的异常时为何原变量与捕获变量地址不同

出现地址不匹配的现象，和引用捕获的语法逻辑完全无关，本质是你对throw的实际执行流程存在认知偏差：

• 执行throw a的瞬间，C++运行时不会直接传递原栈上变量a的地址或引用，而是会通过拷贝/移动构造生成一个完全独立的异常对象。这个对象存储在运行时专门划分的异常内存区域，和main栈帧上的局部变量a没有任何内存关联。
• 当异常从try块向外抛出、触发栈展开流程，最后匹配到对应catch块时，catch(int& s)里的引用s，绑定的就是throw阶段生成的那个独立异常副本，而非原栈上的a。两者本来就不是同一个内存实体，地址自然完全不同。

最直观的佐证：如果这个引用真的绑定到原栈上的a，栈展开过程会逐个析构try块作用域内的所有局部变量，等执行到catch块时a早就被销毁，引用会直接变成悬空野引用，完全违背C++的异常安全设计。

“C无法通过引用捕获异常”是完全错误的结论，恰恰相反，*按引用捕获是C异常处理的官方推荐最佳实践*，只是它的绑定逻辑和很多人想象的不一样：

• 如果换成按值捕获的写法catch(int s)，运行时会对之前生成的独立异常副本再做一次拷贝，生成第三个临时对象作为s的实体，这时候三个内存地址（原a、throw生成的异常副本、catch按值接收的s）会完全不同。
• 用引用捕获catch(int& s)的核心价值，就是省掉catch阶段的第二次冗余拷贝，让引用直接指向throw生成的初始异常对象。这种写法不仅能减少不必要的性能损耗，更重要的是处理自定义类类型异常时，可以避免对象切片问题，正常支持多态行为。

不少开发者做这类测试时，会默认“throw 变量x”就是把x本身的引用传给catch，这个假设从C++标准层面就不成立：

• 标准明确规定，throw操作的产出是一个独立的异常对象，生命周期由运行时托管。从这个对象构造完成的那一刻起，它就和写在throw后面的原操作数没有任何绑定关系。
• 哪怕原操作数所在的栈帧因为异常展开被完全销毁，这个独立的异常对象依然会完整存活，直到整个异常处理链路走完才会被释放。
• 你可以做个简单验证：在catch块里执行s = 10，等catch流程走完回到main函数的正常逻辑时，原变量a的值依然是初始的3，完全不会被catch内的修改影响，这也能直接证明两者的内存独立性。

内容的提问来源于stack exchange，提问作者Ritz Ganguly