C#无边框窗体重写WndProc后调整大小时内存持续上涨咨询

先搞懂WndProc的工作原理 #

WndProc是Windows Forms窗体与Windows系统消息机制交互的核心方法。系统会给窗体发送上百种消息（比如鼠标移动、窗口尺寸变更、绘制指令等），每个消息对应唯一的Msg值（你代码里的0x84就是WM_NCHITTEST消息，用来判断鼠标当前落在窗口的哪个区域）。重写这个方法的目的是拦截特定消息做自定义逻辑处理——处理完后要么返回指定结果告诉系统“我已经处理完了”，要么调用base.WndProc让系统执行默认的消息处理流程。

内存增长的可能原因 #

这段WndProc代码本身逻辑简洁，直接导致内存持续增长的概率极低，更可能是以下几种情况：

• 临时资源的正常分配与延迟回收：调整窗口大小时，系统会触发一系列连锁操作：重绘窗口、更新控件布局、创建临时GDI渲染缓冲区等。这些操作会临时分配内存，而.NET的垃圾回收（GC）不会立刻回收这些临时对象，在调试工具里就会显示内存占用上升。只要停止调整后内存能回落，就属于正常现象。
• 调试环境的干扰：如果是在Visual Studio调试模式下运行，调试器会跟踪所有对象的分配、保留调试信息，导致内存显示比实际发布后的运行状态高很多。建议编译成Release版本再测试，看内存是否真的持续上涨。
• 关联代码的隐性内存分配：你只贴了WndProc的代码，但窗口调整大小时，窗体的Resize事件、控件的布局逻辑可能会触发其他代码——比如每次 resize 都重新创建控件实例、加载数据、分配新的集合对象等，这些才是内存增长的真正源头。
• 值类型的微小开销（几乎可忽略）：你代码里每次处理WM_NCHITTEST都新建了Point对象，不过Point是值类型，分配在栈上而非堆上，不会导致堆内存的持续增长，对整体内存占用影响极小。可以改成Point pos = Point.FromLParam(m.LParam);简化代码，效率会稍高一点，但不会解决内存增长问题。

排查建议 #

1. 编译Release版本运行，排除调试工具的干扰。
2. 使用Visual Studio的内存探查器，查看内存增长时具体是哪些对象在积累，定位到对应的代码模块。
3. 检查窗体的Resize事件处理逻辑，有没有不必要的对象创建、资源分配操作。

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