UnsatisfiedLinkError主因是路径、库名、依赖或架构不匹配。需确认：库名符合平台规范（如loadLibrary("mylib")对应libmylib.so）；库在java.library.path中；依赖库完整（用ldd/Dependency Walker检查）；JVM与库架构一致（32/64位、ARM/x86）。
遇到 UnsatisfiedLinkError，说明 JVM 找不到或加载不了你指定的本地库（.dll / .so / .dylib），核心问题通常出在“路径、名字、依赖、架构”这四点上，不是代码写错，而是环境没配对。
确认库名是否匹配系统约定
System.loadLibrary("foo") 不是加载 foo.dll 或 libfoo.so，而是按平台自动补前缀和后缀：
Windows → foo.dll，Linux → libfoo.so，macOS → libfoo.dylib。
所以传入的名字必须和文件名去掉前缀/后缀后的部分完全一致（大小写敏感）。
- 检查实际文件名：比如有
libmylib.so，就要调用loadLibrary("mylib")，不能写"libmylib"或"mylib.so" - Windows 下若文件是
MyLib.dll，调用时得用loadLibrary("MyLib")，注意大小写
验证库文件是否在 java.library.path 路径中
JVM 只在 java.library.path 指定的目录里搜索本地库。这个路径默认包含系统路径（如 /usr/lib）、JRE 的 bin 目录等，但不包含当前工作目录或 classpath。
- 运行时打印路径：
System.out.println(System.getProperty("java.library.path"));，确认你的库所在目录是否在里面 - 临时添加路径：启动 JVM 时加参数
-Djava.library.path=/path/to/your/libs，多个路径用:（Linux/macOS）或;（Windows）分隔 - 不推荐用
System.load()绝对路径来绕过——它虽能加载，但会掩盖路径配置问题，不利于部署
检查本地库的依赖是否完整
你的库可能依赖其他动态库（比如用 C++ 写的库依赖 libstdc++.so 或 Visual C++ 运行时），而这些依赖没被系统找到。
立即学习“Java免费学习笔记（深入）”；
- Linux：用
ldd yourlib.so查看缺失的 so；常见缺libgcc_s.so.1、libstdc++.so.6等，可通过apt install libstdc++6补齐 - Windows：用
Dependency Walker或dumpbin /dependents yourlib.dll查依赖，重点关注MSVCP140.dll、VCRUNTIME140.dll是否存在（对应 Visual Studio 2015+ 运行时） - macOS：用
otool -L yourlib.dylib查依赖，注意@rpath是否解析正确，必要时用install_name_tool修正
核对 CPU 架构与 JVM 位数是否一致
32 位 JVM 无法加载 64 位库，反之亦然；ARM JVM 也不能加载 x86_64 库。
- 查 JVM 位数：
System.getProperty("sun.arch.data.model")返回"64"或"32" - 查库架构：
file yourlib.so（Linux/macOS）或dumpbin /headers yourlib.dll（Windows） - 特别注意：IDE（如 IntelliJ）可能默认用 64 位 JVM，但打包的 JRE 或服务器环境可能是 32 位，务必统一
不复杂但容易忽略——多数情况只需比对一次库名、路径、依赖、架构，就能定位到具体哪一环断了。
