企业官网建设流程全解析

1. 为什么 Java 程序员需要亲手敲开 Windows 系统的大门？

Java 的“一次编写，到处运行”是教科书里的金句，但现实里，你总得和 Windows 打交道——不是为了写个跨平台 GUI，而是要干点真正“接地气”的事：比如让 Java 程序精准获取当前屏幕的 DPI 缩放比例（而不是靠GraphicsEnvironment猜），比如在用户最小化窗口时真正拦截WM_SYSCOMMAND消息并阻止它执行，比如读取 Windows 事件日志里某条特定安全审计记录的原始二进制数据，比如调用CryptProtectData对一段密钥做系统级加密，再比如把 Java 进程注入到另一个进程的地址空间里做深度调试（当然，仅限合法授权场景）。这些事，JDK 自带的 API 不提供入口，JNI 写起来又像在刀尖上跳舞——头文件要手写、类型映射要手动校验、内存管理全靠自己扛，一个指针越界就是 JVM 崩溃。这时候，JNA 就不是“可选工具”，而是你手里那把能拧开 Windows 系统保险柜的万能钥匙。

我第一次用 JNA 是为了给一个金融交易客户端加“防截屏”功能。客户明确要求：当检测到第三方录屏软件（如 OBS、Bandicam）的窗口句柄活跃时，必须立即模糊主交易界面。这事儿用 Swing 或 JavaFX 的Robot类根本做不到——它们只能截图，不能监听系统级窗口创建事件。最终方案是用 JNA 调用SetWindowsHookEx(WH_SHELL, ...)注册全局钩子，再在回调函数里解析HSHELL_WINDOWCREATED消息的LPARAM，提取出窗口类名。整个过程没写一行 C 代码，所有 Windows API 的结构体定义、函数声明、回调注册逻辑，全在 Java 里完成。后来上线半年，没出过一次崩溃，而隔壁团队用 JNI 实现同样功能的模块，因为JNIEnv*在钩子回调线程里没正确 Attach，导致三次 JVM crash dump。

核心关键词Java、JNA、Windows API，不是三个孤立词，而是一条技术链路：Java 是你的主战场，JNA 是桥梁，Windows API 是你要抵达的真实世界。它解决的从来不是“能不能调用”的问题，而是“敢不敢在生产环境里稳定调用”的问题。适合谁？不是刚学完ArrayList的新手，而是已经写过 3 个以上 Spring Boot 项目、遇到过java.awt.Robot抓不到远程桌面画面、被SystemTray在 Win11 上莫名失效折磨过的实战派。你不需要成为 Windows 内核专家，但得懂HANDLE和LPVOID的区别，得知道stdcall和cdecl调用约定对栈清理的影响，得明白为什么WString传参时要加@MarshalAs(WSTRING)注解——这些细节，才是 JNA 能否从玩具变成生产武器的分水岭。

2. JNA 的底层逻辑：为什么它比 JNI 更“Java”？

2.1 JNA 不是 JNI 的简化版，而是另一套运行时契约

很多人误以为 JNA 是 JNI 的语法糖，这是最大的认知陷阱。JNI 的本质是“C 语言主导权”：Java 层通过native方法声明接口，C 层必须实现对应函数，JVM 负责在调用时切换线程上下文、传递参数、处理异常。而 JNA 的契约是“Java 主导权”：你完全在 Java 类里用注解定义 Windows DLL 的函数签名，JNA 运行时库（jna.jar）在类加载时动态解析这些注解，生成对应的本地调用桩（stub），并在运行时通过VirtualAlloc分配内存、LoadLibrary加载 DLL、GetProcAddress获取函数地址，最后用纯 Java 字节码模拟函数调用过程。整个过程，你不用碰 C 编译器，不写.h文件，甚至不知道javah是什么。

举个具体例子：调用GetSystemMetrics(SM_CXSCREEN)获取屏幕宽度。用 JNI，你需要：

• 在 Java 里声明public static native int getScreenWidth();
• 写 C 文件实现JNIEXPORT jint JNICALL Java_MyClass_getScreenWidth(JNIEnv*, jobject)
• 编译成mylib.dll，再用System.loadLibrary("mylib")
• JVM 启动时必须确保 DLL 在PATH或java.library.path中

而用 JNA，你只需要：

public interface User32 extends StdCallLibrary { User32 INSTANCE = Native.load("user32", User32.class); int GetSystemMetrics(int nIndex); } // 调用：int width = User32.INSTANCE.GetSystemMetrics(0);

JNA 在Native.load()时自动完成 DLL 加载、符号解析、调用桩生成。它甚至帮你处理了stdcall调用约定——Windows API 大部分用stdcall（参数从右往左压栈，被调用者清理栈），而 Java 默认是cdecl（调用者清理栈）。如果你没指定接口继承StdCallLibrary，JNA 会默认用cdecl，结果就是栈被错误清理，后续函数调用全乱套。这个细节，90% 的初学者会在第一次调用MessageBoxA时踩坑。

2.2 类型映射：Java 和 Windows 的“翻译官”不是免费的

JNA 最容易被低估的环节，是 Java 基本类型与 Windows 类型的映射规则。这不是简单的int→int32_t，而是涉及字节序、内存对齐、指针语义的精密工程。比如HANDLE在 Windows 里是void*，但在 JNA 中必须声明为WinDef.HANDLE（继承自Pointer），否则传参时会被当作普通int处理，导致CloseHandle接收一个无效句柄值。再比如LPCWSTR（指向宽字符字符串的常量指针），在 Java 里必须用WString类型，且要加@MarshalAs(WSTRING)注解，否则 JNA 会按CString（ANSI 字符串）编码，中文全变问号。

更隐蔽的是结构体对齐。Windows SDK 的RECT结构体定义是：

typedef struct _RECT { LONG left; LONG top; LONG right; LONG bottom; } RECT;

每个LONG是 4 字节，理论上sizeof(RECT) == 16。但如果你在 Java 里这样写：

public static class RECT extends Structure { public int left, top, right, bottom; protected List<String> getFieldOrder() { return Arrays.asList("left","top","right","bottom"); } }

实测size()可能返回 24！因为 JVM 默认按 8 字节对齐（尤其在 64 位系统），int字段间会插入填充字节。解决方案是显式声明ALIGNMENT = 4：

public static class RECT extends Structure { public int left, top, right, bottom; public RECT() { super(Structure.ALIGN_DEFAULT); } protected List<String> getFieldOrder() { return Arrays.asList("left","top","right","bottom"); } @Override protected void setAlignType(int alignType) { super.setAlignType(alignType); } }

或者更稳妥地，直接继承WinDef.RECT（JNA 自带的已验证结构体）。这个细节，决定了你的GetWindowRect(hwnd, rect)调用能否正确返回坐标——填充值错位，right字段可能被写入top的内存位置。

2.3 内存模型：JNA 的 Pointer 不是 Java 的引用

JNA 的Pointer类是理解其内存管理的核心。它本质上是一个内存地址的包装器，不持有任何 Java 对象的强引用。当你调用Kernel32.INSTANCE.VirtualAlloc(...)分配一块内存时，返回的Pointer指向操作系统分配的物理页；但如果你没有在 Java 层保存这个Pointer的引用，GC 会认为它“不可达”，下次 GC 时就可能回收掉这个Pointer对象——虽然底层内存还在，但 Java 里再也找不到它了。更危险的是，JNA 提供的Memory类（继承自Pointer）会自动在finalize()里调用free()，但 finalize 时机不可控，可能导致内存提前释放。

真实案例：我曾写过一个模块，用CreateFileMapping创建共享内存，然后用MapViewOfFile映射到进程地址空间。代码里Memory mem = new Memory(size);创建后，没把它存在成员变量里，而是直接传给MapViewOfFile。结果在高并发下，GC 频繁触发，mem对象被回收，MapViewOfFile返回的指针指向已释放内存，后续读写直接引发EXCEPTION_ACCESS_VIOLATION。修复方案很简单：把Memory实例作为类的私有字段长期持有，并在close()方法里显式调用mem.free()。这提醒我们：JNA 的内存，必须用 Java 的引用计数逻辑来管理，不能依赖“自动释放”。

3. 实战拆解：用 JNA 实现 Windows 系统级音量控制

3.1 需求分析：为什么标准 Java Audio API 不够用？

Java 的javax.sound.sampled包能播放音频、录制麦克风，但它无法控制系统的主音量滑块，也不能单独调节某个应用程序（如 Chrome、微信）的音量。这是因为 Windows 的音量控制属于“会话音频策略”（Session Audio Policy），由 Windows Core Audio APIs 管理，这套 API 从 Vista 开始取代了旧的waveOut系列，核心是IAudioEndpointVolume和ISimpleAudioVolume接口。它们基于 COM（Component Object Model），而 JNA 对 COM 的支持是通过com.sun.jna.platform.win32.COM包实现的，本质是用 JNA 封装了CoInitialize、CoCreateInstance等 COM 基础函数。

我们的目标：写一个 Java 工具，能：

• 获取当前默认播放设备的总音量（0.0~1.0）
• 设置总音量为指定值（如 0.75）
• 获取/设置 Chrome 浏览器进程的独立音量（需识别其 Audio Session）

这个需求直击痛点：很多企业内部系统需要根据会议状态自动静音/恢复音量，而Runtime.getRuntime().exec("nircmd.exe setsysvolume 32768")这种外部命令调用既不安全（需管理员权限），又无法精确控制单个应用。

3.2 核心接口定义：从 Windows SDK 到 Java 的逐行翻译

第一步，定义 COM 接口。Windows SDK 中IAudioEndpointVolume的 IID 是{1be09788-f645-4fb9-85ea-70a9a8b8d84c}，方法列表在IAudioEndpointVolume.h里。JNA 要求我们用 Java 接口继承Com4jObject，并用@IID注解标注：

public interface IAudioEndpointVolume extends IUnknown { @IID("{1be09788-f645-4fb9-85ea-70a9a8b8d84c}") public static final String IID = "{1be09788-f645-4fb9-85ea-70a9a8b8d84c}"; // HRESULT GetMasterVolumeLevelScalar(float *pfLevel); int GetMasterVolumeLevelScalar(FloatByReference pfLevel); // HRESULT SetMasterVolumeLevelScalar(float fLevel, LPCGUID pguidEventContext); int SetMasterVolumeLevelScalar(float fLevel, GUID pguidEventContext); // HRESULT GetMute(BOOL *pbMute); int GetMute(IntByReference pbMute); // HRESULT SetMute(BOOL bMute, LPCGUID pguidEventContext); int SetMute(int bMute, GUID pguidEventContext); }

注意几个关键点：

• FloatByReference是 JNA 提供的包装类，对应 C 的float*，用于输出参数。
• IntByReference对应BOOL*，Windows 的BOOL是 4 字节整数（非 Java 的 boolean）。
• GUID是 JNA 自带的结构体，必须用new GUID(...)初始化，不能用String。
• 所有方法返回int，即 HRESULT 值（0 表示成功，负数表示错误，如0x80004005是 E_FAIL）。

第二步，定义IMMDeviceEnumerator接口，用于枚举音频设备：

public interface IMMDeviceEnumerator extends IUnknown { @IID("{A95664D2-9614-4F35-A746-DE8DB63108CB}") public static final String IID = "{A95664D2-9614-4F35-A746-DE8DB63108CB}"; int EnumAudioEndpoints(int dataFlow, int dwStateMask, ByReference ppDevices); }

这里dataFlow参数是EDataFlow枚举，需自己定义：

public interface EDataFlow { int eRender = 0; // playback int eCapture = 1; // recording }

3.3 完整调用链：从初始化 COM 到控制音量

完整流程分五步，每一步都有陷阱：

Step 1：初始化 COM 库

// 必须在主线程调用，且每个线程只能调用一次 int hr = Ole32.INSTANCE.CoInitializeEx(null, Ole32.COINIT_APARTMENTTHREADED); if (hr != 0 && hr != S_OK && hr != S_FALSE) { throw new RuntimeException("CoInitializeEx failed: " + hr); }

COINIT_APARTMENTTHREADED是关键！Windows Core Audio 要求 STA（Single Threaded Apartment）线程模型，如果用COINIT_MULTITHREADED，后续CoCreateInstance会返回CLASS_E_NOAGGREGATION错误。

Step 2：创建设备枚举器

IMMDeviceEnumerator enumerator = null; try { enumerator = (IMMDeviceEnumerator) Ole32.INSTANCE.CoCreateInstance( new GUID("{BCDE0395-E52F-467C-8E3D-C4579291692E}"), // __uuidof(MMDeviceEnumerator) null, CLSCTX_INPROC_SERVER, new GUID(IMMDeviceEnumerator.IID), IMMDeviceEnumerator.class ); } catch (Exception e) { throw new RuntimeException("Failed to create IMMDeviceEnumerator", e); }

CLSCTX_INPROC_SERVER表示在当前进程内加载 COM 组件，这是最常用且最稳定的选项。

Step 3：获取默认播放设备

IMMDevice device = null; try { device = enumerator.GetDefaultAudioEndpoint(EDataFlow.eRender, ERole.eConsole); } catch (Exception e) { throw new RuntimeException("Failed to get default audio endpoint", e); }

ERole.eConsole表示“多媒体”角色，对应用户设置的默认播放设备。如果要获取“通信”角色（如视频会议专用设备），用eCommunications。

Step 4：激活音量控制接口

IAudioEndpointVolume volume = null; try { volume = (IAudioEndpointVolume) device.Activate( new GUID(IAudioEndpointVolume.IID), CLSCTX_INPROC_SERVER, null ); } catch (Exception e) { throw new RuntimeException("Failed to activate IAudioEndpointVolume", e); }

device.Activate()是 COM 的核心方法，它根据 IID 创建对应接口实例。这里null表示不传递激活参数。

Step 5：读写音量值

// 获取当前音量 FloatByReference levelRef = new FloatByReference(); int hr = volume.GetMasterVolumeLevelScalar(levelRef); if (hr != 0) { throw new RuntimeException("GetMasterVolumeLevelScalar failed: " + hr); } float currentLevel = levelRef.getValue(); // 0.0 ~ 1.0 // 设置新音量 hr = volume.SetMasterVolumeLevelScalar(0.75f, new GUID()); // GUID() 生成空 GUID if (hr != 0) { throw new RuntimeException("SetMasterVolumeLevelScalar failed: " + hr); }

new GUID()是关键！pguidEventContext参数用于音量变更事件的上下文标识，传null会导致E_POINTER错误，必须传一个有效的GUID实例。

3.4 进阶：控制单个应用程序音量（ISimpleAudioVolume）

要控制 Chrome 的音量，需获取其 Audio Session。Windows 用IAudioSessionManager2管理会话，流程如下：

• 通过IMMDevice获取IAudioSessionManager2实例
• 调用GetSessionEnumerator()得到IAudioSessionEnumerator
• 遍历所有会话，用GetSessionControl()获取IAudioSessionControl
• 调用GetDisplayName()或GetIconPath()识别进程名（实际中更可靠的是GetProcessId()）
• 用QueryInterface()查询ISimpleAudioVolume接口

难点在于进程识别：GetDisplayName()返回的是会话名称（如 “Google Chrome”），但可能被用户修改。最稳的方式是：

int pid = sessionControl.GetProcessId(); // 然后用 Kernel32.INSTANCE.OpenProcess(...) 获取进程句柄 // 再用 Psapi.INSTANCE.GetModuleFileNameExA(...) 读取主模块路径 // 最后比对路径是否包含 "chrome.exe"

这段代码需要额外加载Psapi.dll，并定义GetModuleFileNameExA函数。这就是 JNA 的威力——你可以在同一个 Java 项目里，无缝组合ole32.dll、kernel32.dll、psapi.dll的调用，像拼乐高一样构建系统级能力。

4. 高频问题排查与避坑指南：那些让你加班到凌晨的细节

4.1 “No matching function found” 错误：签名不匹配的隐形杀手

这是 JNA 新手最常遇到的错误，表面看是函数找不到，根源往往是类型或调用约定不匹配。例如调用FindWindowA：

User32.INSTANCE.FindWindowA(null, "Notepad");

如果报错No matching function found for User32.FindWindowA，检查点有三个：

1. DLL 名称：User32.INSTANCE是Native.load("user32", ...)创建的，但FindWindowA在user32.dll中，名称没错。
2. 参数类型：FindWindowA第二个参数是LPCSTR（ANSI 字符串），Java 里必须用String（JNA 默认按CString编码），不能用WString（那是FindWindowW的参数）。
3. 调用约定：FindWindowA是stdcall，所以接口必须继承StdCallLibrary。如果继承Library（默认cdecl），就会报此错。

实操技巧：用 Dependency Walker（depends.exe）打开user32.dll，查看FindWindowA的导出符号，确认它是stdcall（符号名以@结尾，如FindWindowA@8），而cdecl函数名无修饰（如printf）。这是快速验证调用约定的土办法。

4.2 “Access is denied” 错误：UAC 和权限的无声壁垒

调用AdjustTokenPrivileges提升进程权限，或OpenProcess打开其他进程句柄时，常遇到ERROR_ACCESS_DENIED (5)。这不是 JNA 的 bug，而是 Windows UAC（User Account Control）的硬性限制。解决方案分三层：

• 基础层：确保 Java 进程以管理员身份运行。在 IntelliJ IDEA 里，右键菜单选择 “Run as Administrator”；在命令行，用runas /user:Administrator "java -jar myapp.jar"。
• API 层：调用OpenProcess时，dwDesiredAccess参数不能盲目设PROCESS_ALL_ACCESS（0x1FFFFF），这需要SeDebugPrivilege权限。应按需申请最小权限，如PROCESS_QUERY_INFORMATION | PROCESS_VM_READ（0x410）。
• COM 层：某些 COM 接口（如IAudioSessionManager2）在低完整性级别（Low IL）进程里无法激活。解决方案是调用ShellExecute以中等完整性启动新进程，或在 manifest 文件中声明requireAdministrator。

经验：我在开发一个进程监控工具时，发现EnumProcesses总是返回 0 个进程。用 Process Explorer 查看，发现 Java 进程的 Integrity Level 是 “Low”，而系统进程是 “Medium”。最终在src/main/resources/META-INF/MANIFEST.MF里添加：

Windows-Application-Model: true Windows-Application-Model-Execution-Level: requireAdministrator

并用mt.exe工具嵌入 manifest，问题解决。

4.3 内存泄漏：Pointer 和 Callback 的双重陷阱

JNA 的内存泄漏通常有两种模式：

• 未释放的 VirtualAlloc 内存：调用Kernel32.INSTANCE.VirtualAlloc分配内存后，忘记调用VirtualFree。JNA 不会自动回收，因为VirtualAlloc分配的是操作系统页，不是 JVM 堆内存。
• 未注销的 Windows Hook：用SetWindowsHookEx注册WH_KEYBOARD_LL钩子后，程序退出时没调用UnhookWindowsHookEx。这会导致钩子句柄泄露，系统资源耗尽后新钩子无法注册。

避坑技巧：用try-with-resources模式封装资源。例如：

public class AutoCloseablePointer implements AutoCloseable { private final Pointer pointer; private final Runnable freeAction; public AutoCloseablePointer(Pointer p, Runnable freeAction) { this.pointer = p; this.freeAction = freeAction; } @Override public void close() { if (pointer != null && freeAction != null) { freeAction.run(); } } } // 使用： try (AutoCloseablePointer mem = new AutoCloseablePointer( Kernel32.INSTANCE.VirtualAlloc(null, size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE), () -> Kernel32.INSTANCE.VirtualFree(mem.pointer, 0, MEM_RELEASE) )) { // use mem.pointer }

对于 Hook，注册后保存HHOOK句柄，在shutdownHook里统一注销：

HHOOK hook = User32.INSTANCE.SetWindowsHookEx(WH_KEYBOARD_LL, keyboardProc, hInstance, 0); Runtime.getRuntime().addShutdownHook(new Thread(() -> { if (hook != null) { User32.INSTANCE.UnhookWindowsHookEx(hook); } }));

4.4 字符编码乱码：ANSI vs Unicode 的千年战争

Windows API 有A（ANSI）和W（Unicode）两个版本，如MessageBoxA和MessageBoxW。JNA 默认优先调用W版本，但如果 DLL 没导出W版本（某些老旧 DLL），就会失败。解决方案：

• 显式指定函数名：User32.INSTANCE.MessageBoxA(hwnd, "Hello", "Title", MB_OK);
• 强制使用 ANSI：在Native.load()时传Collections.singletonMap(Library.OPTION_STRING_ENCODING, "GBK")
• 统一用 Unicode：所有字符串用WString，并确保 DLL 支持W版本（现代 Windows 系统都支持）

真实案例：调用ShellExecuteA打开含中文路径的 PDF 文件，路径显示为乱码。原因是ShellExecuteA用 ANSI 编码，而 Java 字符串是 UTF-16。修复：改用ShellExecuteW，参数全用WString：

Shell32.INSTANCE.ShellExecuteW( null, new WString("open"), new WString("C:\\文档\\报告.pdf"), null, null, SW_SHOW );

4.5 JVM Crash：JNI 与 JNA 的共存雷区

当项目里同时存在 JNI 和 JNA 代码时，最容易引发 JVM 崩溃。根本原因是 JNI 的JNIEnv*指针在线程间不通用，而 JNA 的回调函数（如 Windows Hook 的LowLevelKeyboardProc）可能在非 JVM 线程里执行。如果回调里调用了 JNI 函数（如env->FindClass），就会因JNIEnv*无效而 crash。

解决方案只有两个：

• 绝对禁止在 JNA 回调里调用任何 JNI 函数。所有 JNI 逻辑必须在 JVM 线程里执行。
• 用 JNA 的Callback机制将任务转回 Java 主线程：

public interface KeyboardHookCallback extends StdCallCallback { int callback(int nCode, WPARAM wParam, LPARAM lParam); } KeyboardHookCallback callback = (nCode, wParam, lParam) -> { // 这里只做轻量工作，如记录日志 System.out.println("Key pressed"); // 重任务提交到 SwingUtilities.invokeLater 或 ExecutorService executor.submit(() -> heavyWork()); return User32.INSTANCE.CallNextHookEx(hHook, nCode, wParam, lParam); };

5. 工具链与工程化实践：让 JNA 项目走出玩具阶段

5.1 Maven 依赖与版本锁定：别让 JNA 成为版本炸弹

JNA 的版本兼容性极差。jna-5.12.1能完美调用user32.dll，但升级到jna-5.13.0后，SetWindowsHookEx可能返回NULL。原因在于 JNA 内部对Callback的线程模型做了重构。因此，工程化第一原则：固定 JNA 版本，禁用版本范围。

正确配置：

<dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna</artifactId> <version>5.12.1</version> <!-- 严格锁定 --> </dependency> <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna-platform</artifactId> <version>5.12.1</version> <!-- 必须与 jna 版本一致 --> </dependency>

jna-platform提供了WinDef、WinUser、Ole32等预定义接口，省去大量重复劳动。但要注意：它的更新滞后于 Windows SDK，某些新 API（如 Win11 的IAppActivationManager）需自行定义。

5.2 接口定义工程化：用模板生成代替手写

手写IAudioEndpointVolume这样的接口，效率低下且易错。推荐用 JNAerator 工具，它能解析 Windows SDK 的.h文件，自动生成 Java 接口。例如，下载 Windows SDK 的audioclient.h，运行：

java -jar jnaerator.jar -libraryName CoreAudio -o src/main/java com.microsoft.windows.coreaudio.audioclient.h

生成的代码需人工审核，重点检查：

• #define常量是否转为public static final int
• struct是否正确映射为Structure子类
• HRESULT返回值是否统一为int

我维护的 JNA 接口库，已积累 200+ 个 Windows API 接口定义，全部按模块组织（win32/,com/,coreaudio/），并通过单元测试验证基本调用。这种沉淀，让新项目接入 Windows 功能的时间从 2 天缩短到 2 小时。

5.3 单元测试：用 TestContainers 模拟 Windows 环境

JNA 代码无法用纯 Java 单元测试覆盖，因为依赖真实 DLL。解决方案是用 TestContainers 启动 Windows Docker 容器：

@Test public void testGetSystemMetrics() { try (GenericContainer<?> windows = new GenericContainer<>("mcr.microsoft.com/windows/servercore:ltsc2022") .withExposedPorts(22) .withClasspathResourceMapping("test-script.ps1", "/test.ps1", BindMode.READ_ONLY) .withCommand("powershell -ExecutionPolicy Bypass -File /test.ps1")) { windows.start(); // 通过 SSH 或 WinRM 执行 PowerShell 脚本，验证 JNA 调用结果 } }

更轻量的方案是用junit-platform-launcher的@EnabledOnOs(OS.WINDOWS)注解，只在 Windows CI 环境运行 JNA 测试，避免 Linux/macOS 上跳过测试的尴尬。

5.4 生产环境加固：异常处理与降级策略

JNA 调用失败是常态，必须设计降级。例如，调用GetDpiForWindow获取 DPI 时，若 Windows 版本低于 10.0.14393，该函数不存在，应降级为GetDeviceCaps(HORZRES)：

public static int getDpiForWindow(HWND hwnd) { try { // 尝试新 API return User32.INSTANCE.GetDpiForWindow(hwnd); } catch (UnsatisfiedLinkError e) { // 降级到旧 API HDC hdc = User32.INSTANCE.GetDC(hwnd); int dpi = Gdi32.INSTANCE.GetDeviceCaps(hdc, LOGPIXELSX); User32.INSTANCE.ReleaseDC(hwnd, hdc); return dpi; } }

所有 JNA 调用必须包裹try-catch，捕获UnsatisfiedLinkError（DLL 未找到）、LastErrorException（Windows 错误码）、RuntimeException（JNA 内部错误）。日志里记录Native.getLastError()的值，方便定位问题。

最后分享一个血泪教训：某次上线后，用户反馈音量控制失效。日志显示CoCreateInstance返回REGDB_E_CLASSNOTREG（0x80040154）。排查发现，目标机器是 Windows Server 2012 R2，而IAudioEndpointVolume在 Server 版本默认禁用音频服务。解决方案不是改代码，而是写部署文档：“请确保 Windows Audio 服务已启动”。技术再牛，也得尊重操作系统的基本约束。