user32.dll加载失败主因是未用syscall.newlazydll延迟加载，而误用syscall.loaddll导致依赖缺失（如comctl32.dll）时静默失败；必须检查dll指针是否为nil，并确保函数名带w后缀、字符串参数经syscall.stringtoutf16ptr转换，结构体需严格对齐且内存有效。
syscall 和 unsafe 不是装饰品，而是你和操作系统对话的直连线路。封装底层系统调用或硬件交互模块，核心不是“让它跑起来”，而是“让它不崩、不漏、不歧义、不跨平台失能”。
用 syscall 封装 Windows API 时，为什么 user32.dll 加载失败？
常见现象是 dll.NewProc("CreateWindowExW").Call() 返回 0，且无错误提示——实际是 DLL 没加载成功，但没显式报错。
- 必须用
syscall.NewLazyDLL("user32.dll")，而非直接syscall.LoadDLL；前者延迟加载，后者在调用前就强制解析所有符号，容易因缺失依赖（如comctl32.dll）静默失败 - 调用前检查句柄：
if dll == nil { return errors.New("failed to load user32.dll") }，dll是指针，nil表示加载失败 - Windows API 函数名带
W后缀（宽字符），传参必须是syscall.StringToUTF16Ptr转换后的指针，不能用CString或直接传string
unsafe.Pointer 转结构体时，为什么程序 panic 或读到乱码？
典型场景：从驱动返回的内存块中解析 DEVICE_CAPABILITIES 结构体，结果字段全为零或越界访问。
- 结构体字段必须严格对齐：Windows SDK 中该结构体含
DWORD（uint32）、BOOLEAN（byte）等混合类型，Go 中需用//go:pack或手动填充，否则内存布局错位 - 转换前必须确认内存有效且长度足够：
if len(buf) - 禁止直接
(*T)(unsafe.Pointer(&buf[0]))—— 应先uintptr(unsafe.Pointer(&buf[0]))，再转unsafe.Pointer，避免逃逸分析误判
如何让硬件模块支持 Linux/Windows 双平台？
不是写两套代码，而是把平台差异收口到最小接口层。
- 定义统一抽象接口：
type Hardware interface { Init() error; Read([]byte) (int, error); Close() error } - 实现按构建标签分离：
//go:build windows和//go:build linux，分别导入golang.org/x/sys/windows或golang.org/x/sys/unix - 避免在业务逻辑里写
runtime.GOOS == "windows"—— 这会让测试和 mock 成本陡增；所有平台判断只出现在newHardware()工厂函数里 - Linux 下操作 /dev 目录设备文件时，注意
os.O_RDWR | os.O_SYNC组合是否被内核支持；某些嵌入式驱动不识别O_SYNC，会直接返回EINVAL
错误包装必须带原始 errno 吗？
必须。硬件交互失败时，仅说 “failed to write register” 毫无调试价值。
- Windows 错误用
syscall.GetLastError()获取，Linux 用errno（通过unix.Errno类型捕获） - 包装时保留原始码：
return fmt.Errorf("write register 0x%x failed: %w", addr, &os.PathError{Op: "write", Path: "/dev/hw0", Err: syscall.Errno(lastErr)}) - 上层调用方可用
errors.Is(err, syscall.ERROR_ACCESS_DENIED)或errors.Is(err, unix.EPERM)做精确分支，而不是字符串匹配
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
