程序不崩却持续占内存：最危险的默认值原来是0

一次看似由 `RegisterDragDrop` 与 `RevokeDragDrop` 引发的内存泄漏，最终指向了更隐蔽的 Win32 生命周期错误：窗口过程把未处理消息直接返回了 `0`，而没有交给 `DefWindowProc`。程序没有崩溃，却悄悄阻断了系统完成最后清理的路径。

Raymond Chen 通过这个案例说明，API 调用成对出现，并不代表资源一定会立刻释放。理解窗口销毁、共享缓存与默认消息处理链，才能分辨“正常延迟清理”和真正的泄漏。

原文链接：

https://devblogs.microsoft.com/oldnewthing/20260924-00/?p=112728/

原文标题：No, really, you need to pass all unhandled messages to DefWindowProc, part 2

主要内容：

• `WM_DESTROY` 并非窗口生命周期的终点，后续消息仍承担系统级清理职责。

• 未处理消息必须转交 `DefWindowProc`；直接返回 `0` 等于错误地宣称消息已处理。

• `RevokeDragDrop` 会解除注册关系，但窗口级共享基础设施可能保留至窗口真正销毁时再清理。

• 应用状态被提前删除后，如果以“状态是否存在”决定是否转发消息，就可能吞掉关键清理消息。

• 资源问题往往不在分配与释放 API 本身，而在生命周期边界和消息分发协议上。

推荐理由：