正确使用dllimport加载user32.dll需匹配stdcall调用约定、charset.auto编码、intptr句柄类型及structlayout结构体布局，字符串输出必须用stringbuilder，否则易引发entrypointnotfound、accessviolation或乱码等错误。
怎么用 DllImport 正确加载 user32.dll 中的函数
直接能用，但必须匹配调用约定、字符集和参数类型，否则运行时崩溃或返回错误值。Windows API 默认是 StdCall，C# 的 DllImport 默认却是 WinApi（即 StdCall），这点刚好对得上；但容易忽略的是字符串编码和结构体布局。
常见错误现象：EntryPointNotFoundException（函数名找不到）、AccessViolationException（内存越界）、GetLastError() 返回 126（模块未找到）或 127（过程未找到）。
-
user32.dll是系统 DLL，无需复制到项目目录，但不能写成"./user32.dll"或带扩展名路径——直接写"user32.dll" - 函数名大小写必须完全一致，例如
FindWindow不是findwindow，也不加前缀（如FindWindowA或FindWindowW）除非你显式指定CharSet - 推荐显式声明
CallingConvention = CallingConvention.StdCall，避免跨平台混淆；同时设CharSet = CharSet.Auto让 .NET 自动选A/W版本（现代 Windows 只用W） - 如果函数参数含指针或结构体（如
RECT、POINT），必须用[StructLayout(LayoutKind.Sequential)]标记结构体，否则字段偏移错乱
FindWindow 和 SendMessage 的典型用法与陷阱
这两个是最常被用来做窗口查找和模拟交互的函数，但实际调用中极易出错：比如传入空字符串、句柄为 0 却没检查、消息参数类型不匹配。
示例：查找记事本窗口并发送关闭消息
[DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto, CallingConvention = CallingConvention.StdCall)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
<p>[DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
public static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);</p><p>// 调用
var hwnd = FindWindow(null, "无标题 - 记事本");
if (hwnd != IntPtr.Zero)
{
const uint WM_CLOSE = 0x0010;
SendMessage(hwnd, WM_CLOSE, IntPtr.Zero, IntPtr.Zero);
}</p>
-
FindWindow第一个参数是类名，传null表示忽略；第二个是窗口标题，支持部分匹配，但区分大小写（实际取决于目标程序实现） -
SendMessage的wParam/lParam类型是IntPtr，不是int或long—— 在 64 位进程里它们是 8 字节，用int会导致高位截断 - 调用后建议检查
Marshal.GetLastWin32Error()，尤其当返回值为 0 或IntPtr.Zero时 - 不要在 UI 线程长时间阻塞调用（如循环等待窗口出现），容易导致界面假死；改用
FindWindowEx+ 重试或EnumWindows配合回调
为什么 GetWindowText 返回空字符串或乱码
根本原因是缓冲区长度单位理解错误 + 字符编码没对齐。该函数要求传入的是「字符数」而非「字节数」，且缓冲区必须可写、足够大、以 \0 结尾。
- 声明时必须用
StringBuilder传入缓冲区，不能用string（.NET 字符串不可变） - 缓冲区容量要 ≥ 实际所需字符数 + 1（留给结尾 \0），例如
new StringBuilder(256) -
CharSet = CharSet.Auto下，底层调用的是GetWindowTextW，返回 Unicode 字符，不会乱码；若误设CharSet.Ansi，则可能截断或转码失败 - 目标窗口可能拒绝获取文本（如某些 UWP 应用或权限受限进程），此时返回 0，需配合
GetLastError()判断是否为 5（拒绝访问）
正确写法：
[DllImport("user32.dll", CharSet = CharSet.Auto)]
public static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int nMaxCount);
<p>var sb = new StringBuilder(256);
int len = GetWindowText(hwnd, sb, sb.Capacity);
string title = len > 0 ? sb.ToString() : string.Empty;</p>
64 位程序调用时句柄溢出或 InvalidCastException
这是最隐蔽也最容易被忽略的问题：32 位下 HWND 是 int，64 位下是 long，但 Windows SDK 统一定义为 IntPtr。如果你把 API 声明里的参数/返回值写成 int 或 uint，在 x64 进程里就会丢高 32 位。
- 所有句柄类型（
HWND、HDC、HMODULE等）一律用IntPtr，别图省事换int - 消息常量（如
WM_MOUSEMOVE）仍是uint，没问题；但涉及句柄运算（如hwnd.ToInt32()）必须确认当前平台位数，否则崩溃 - 使用
IsWow64Process检查目标进程是否为 32 位（仅当你要向其他进程注入或读内存时才需要） - 调试时打开“仅我的代码”会掩盖 P/Invoke 异常，建议在 Visual Studio 中禁用该选项，直接看原生异常堆栈
底层细节藏得深，但只要坚持用 IntPtr 接句柄、用 StringBuilder 接输出字符串、每次调用后查错误码，大部分问题都能定位到具体哪一行。别信“差不多能跑就行”，Windows API 对类型和内存的要求是刚性的。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
