C++协程帧销毁释放规则及final_suspend相关技术疑问

问题1：若final_suspend()未调用handle.destroy()或返回std::suspend_never，co_await完成后CF是否会被正确销毁？ #

• 如果返回std::suspend_never：co_await会直接跳过挂起逻辑，此时编译器会自动插入handle.destroy()的调用，协程帧会被正常销毁，不会出现内存泄漏。
• 如果返回自定义挂起类型且未调用handle.destroy()：协程帧会滞留在堆内存中，造成内存泄漏，必须由外部通过coroutine_handle手动调用destroy()才能完成清理。

问题2：若final_suspend()返回std::suspend_always会发生什么？ #

协程会在final_suspend处挂起，此时协程帧不会自动销毁，控制权返回给调用方。这种场景下必须由外部持有协程句柄，并在合适时机（比如所有依赖协程帧的异步操作完成后）调用handle.destroy()，否则会引发内存泄漏。这种模式常用于需要外部控制协程生命周期的场景，比如异步任务回调执行完毕后再清理资源。

问题3：CF的释放是否与~promise_type()的编译器推导析构函数相关？ #

协程帧的销毁分为两个独立步骤：

1. 销毁帧内所有对象（包括promise_type实例，此时会调用~promise_type()）；
2. 释放协程帧占用的堆内存（由协程分配器完成，默认是operator delete）。

~promise_type()不管是编译器默认生成还是自定义实现，仅负责清理promise自身持有的资源，和协程帧内存的释放没有直接关联。但handle.destroy()会先触发~promise_type()的调用，再执行内存释放操作。

关于Lewis Baker的建议：尽量让协程在final_suspend处挂起，核心目的是避免协程帧过早销毁导致悬空引用。如果返回std::suspend_never，协程结束后会立即销毁帧，但若此时还有异步回调或其他操作在引用帧内对象（比如promise里的状态），会触发未定义行为。挂起后由外部控制销毁时机，能确保所有依赖操作完成后再清理，安全性更高。而std::suspend_never本身不会导致内存泄漏，但必须保证没有后续操作依赖协程帧内的资源。

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