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<t>()</t>验证结构体大小是否与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字段放错位置，都可能让整个结构体解析错位——这种问题往往不报错，只悄悄返回错误值。
