在C#开发中，进程通信是一项关键技术，它让不同进程间能够交换数据、协同工作。而SendMessage作为常用的进程通信方式，看似简单易用，实则暗藏诸多陷阱。若不了解这些，很容易在开发过程中遇到各种难以排查的问题。接下来，让我们通过真实案例来剖析那些容易被忽视的SendMessage陷阱。

句柄泄漏：资源的无声流失 

在使用SendMessage进行进程通信时，句柄的正确管理至关重要。但很多时候，程序员会在不经意间陷入句柄泄漏的困境。

假设我们有一个主进程和一个子进程，主进程需要向子进程发送消息来控制其行为。在获取子进程窗口句柄时，如果代码逻辑存在问题，就可能导致句柄无法正确释放。

// 错误示例
IntPtr targetHandle = FindWindow(null, "ChildProcessWindowTitle");
if (targetHandle!= IntPtr.Zero)
{
    // 发送消息
    SendMessage(targetHandle, WM_CUSTOM_MESSAGE, IntPtr.Zero, IntPtr.Zero);
    // 这里没有释放句柄，多次调用后会导致句柄泄漏
}

随着程序的不断运行，每次获取句柄却不释放，系统资源会被逐渐耗尽，最终导致程序崩溃或运行异常。正确的做法是在使用完句柄后，及时释放它，确保资源的有效管理。

消息阻塞：程序的意外停滞 

消息阻塞是SendMessage另一个常见的陷阱。SendMessage是一种同步消息发送方式，这意味着在目标窗口处理完消息之前，调用线程会一直被阻塞。

在一个图形界面应用中，主窗口需要向一个长时间运行的子窗口发送消息。如果子窗口由于某些原因（如复杂的计算任务）无法及时处理消息，主窗口线程就会被阻塞，导致界面失去响应，用户体验极差。

// 假设子窗口处理消息的方法很耗时
private void ChildWindowProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam)
{
    if (msg == WM_CUSTOM_MESSAGE)
    {
        // 进行复杂的计算任务，耗时较长
        for (int i = 0; i < 100000000; i++)
        {
            // 模拟计算
        }
    }
    return DefWindowProc(hwnd, msg, wParam, lParam);
}

当主窗口调用SendMessage向子窗口发送消息时，由于子窗口处理消息缓慢，主窗口线程会被阻塞，无法处理其他用户操作，如点击按钮、拖动窗口等。为了避免这种情况，可以考虑使用异步消息发送方式，或者优化子窗口的消息处理逻辑，确保消息能够及时处理。

消息参数错误：通信的混乱之源 

在使用SendMessage时，消息参数的正确设置至关重要。如果参数设置错误，可能会导致进程通信出现混乱，甚至引发程序崩溃。

在一个进程间传递数据的场景中，需要通过SendMessage发送一个包含自定义结构体的消息。如果在封送和解封送结构体时出现错误，就会导致接收方无法正确解析数据。

// 定义自定义结构体
[StructLayout(LayoutKind.Sequential)]
public struct CustomData
{
    public int Data1;
    public string Data2;
}

// 发送消息时封送结构体错误示例
CustomData data = new CustomData { Data1 = 100, Data2 = "Test" };
IntPtr buffer = Marshal.AllocHGlobal(Marshal.SizeOf(data));
Marshal.StructureToPtr(data, buffer, false);
SendMessage(targetHandle, WM_CUSTOM_MESSAGE, IntPtr.Zero, buffer);
// 这里没有正确释放分配的内存，并且可能存在封送错误

在接收方，由于发送方的封送错误，导致无法正确从消息参数中解析出数据，从而使进程通信出现错误。正确处理消息参数，确保数据的准确传递，是避免这类问题的关键。

SendMessage在C#进程通信中虽然强大，但隐藏的陷阱不容忽视。通过对句柄泄漏、消息阻塞、消息参数错误等真实案例的分析，希望能帮助开发者在使用SendMessage时更加谨慎，避免陷入这些常见的陷阱，编写出稳定可靠的程序。

阅读原文：原文链接