DllImport需严格匹配windows API签名：函数名（含A/W后缀）、CallingConvention.Winapi、CharSet（Unicode优先）、StructLayout及字段对齐；字符串用StringBuilder或MarshalAs(LPWStr)，结构体用Marshal.SizeOf验证大小；句柄须用SafeHandle封装。
DllImport特性怎么写才不会报错
关键不是“能不能调”，而是DllImport的参数是否匹配windows API的实际签名。常见错误是函数名拼错、调用约定不一致、字符集没指定——比如调用MessageBoxA却没设CharSet = CharSet.Ansi，或调用GetSystemMetrics时漏了CallingConvention = CallingConvention.Winapi。
实操建议：
- 优先查MSDN原文，确认函数名（注意A/W后缀）、参数类型（如
int对应C的INT，但bool必须映射为bool或int）、返回值 - Windows API默认使用
StdCall，所以CallingConvention一般填CallingConvention.Winapi（它等价于StdCall） - 字符串参数务必显式指定
CharSet；多数现代API推荐用CharSet.Unicode，对应W版本函数（如MessageBoxW） - 结构体传参前加
[StructLayout(LayoutKind.Sequential)]，字段对齐按C端要求设Pack
如何安全传递字符串和结构体到Win32函数
字符串容易出问题：C#的string是托管对象，直接传给API可能被GC移动或释放。结构体若字段顺序/大小不匹配，会导致读写越界或静默错误。
实操建议：
- 字符串用
MarshalAs(UnmanagedType.LPWStr)标注，配合CharSet = CharSet.Unicode，让P/Invoke自动做UTF-16转换和内存固定 - 避免用
ref string或out string接收API输出的字符串；改用StringBuilder并预分配足够容量（如new StringBuilder(260)） - 结构体中含指针字段（如
LPVOID）时，用IntPtr代替，再手动Marshal.PtrToStructure解析 - 用
Marshal.SizeOf验证结构体大小是否与C头文件一致，尤其注意() bool在C里是1字节，但C#默认按4字节打包
常见错误信息对应的修复点
运行时报System.EntryPointNotFoundException，说明函数找不到；报System.accessViolationException，大概率是内存布局错或指针越界；而Attempted to read or write protected memory基本等于结构体字段没对齐或字符串没正确封送。
实操建议：
-
EntryPointNotFoundException：检查DLL名（"user32.dll"不能写成"User32.dll"）、函数名（区分大小写、有无A/W后缀）、目标平台（x64程序不能加载x86 DLL） -
AccessViolationException：关闭“仅我的代码”调试选项，在异常时看调用栈，重点查IntPtr是否为空、StringBuilder容量是否够、结构体Size是否准确 - 调试时启用
unsafe上下文，用fixed临时固定托管数组地址，验证是否真由GC引起
要不要用SafeHandle封装句柄资源
直接用IntPtr管理HANDLE非常危险：忘记CloseHandle就泄漏，提前释放又导致悬空指针。.net原生的SafeHandle子类（如SafeFileHandle）已内置引用计数和析构保障，但很多Win32句柄没现成封装。
实操建议：
- 自定义
SafeHandle子类时，必须重写IsInvalid（判断handle == IntPtr.Zero或handle == new IntPtr(-1)）和ReleaseHandle（只负责调用CloseHandle，不抛异常） - 构造函数必须传
ownsHandle = true，否则SafeHandle不会自动释放 - 不要在
ReleaseHandle里做日志或复杂逻辑——它可能在终结器线程执行，且不允许抛异常 - 若只是临时用，且能确保作用域明确，可用
using包裹SafeHandle实例；否则宁可多写一行CloseHandle，也别依赖GC
P/Invoke真正难的不是声明函数，而是把C的内存模型、调用契约和.NET的托管边界对齐。哪怕一个bool字段放错位置，都可能让整个结构体解析错位——这种问题往往不报错，只悄悄返回错误值。