unsatisfiedlinkerror本质是jvm加载本地库失败，需按路径（java.library.path）、文件（存在性/命名/大小写）、依赖（ldd/otool检查）、架构（jvm与.so/.dll位数一致）四层顺序排查。
UnsatisfiedLinkError 报“动态链接库丢失”，本质不是 Java 代码出错，而是 JVM 在加载本地库（.so/.dll/.dylib）时找不到目标文件或其依赖项。排查要从路径、文件、依赖、架构四个层面入手，顺序理清就能快速定位。
确认 java.library.path 是否包含库所在目录
JVM 只在 java.library.path 指定的路径里找库，不会扫描当前目录、resources 或 jar 包内部。
- 运行时加参数指定路径：
-Djava.library.path=/opt/myapp/lib:/usr/local/lib（Linux/macOS 用冒号分隔，Windows 用分号） - 在代码中打印当前路径：
System.out.println(System.getProperty("java.library.path"))，核对输出是否真有你的库目录 - 别把 .so 放 src/main/resources 下——JVM 不会从这里加载；也别打包进 jar——
System.loadLibrary()不支持从 jar 内解压加载
验证库文件是否存在且命名正确
库名和文件名必须严格匹配规则，稍有偏差就会“找不到”。
-
System.loadLibrary("xxx")对应文件名是：Linux/macOS →libxxx.so，Windows →xxx.dll，<strong>macOS</strong> → <code>libxxx.dylib - 写成
loadLibrary("libxxx")是错的——JVM 会去找liblibxxx.so，根本不存在 - 检查文件是否真实存在：
ls -l /your/path/libxxx.so（Linux/macOS）或dir C:\path\xxx.dll（Windows） - 注意大小写：Linux/macOS 文件系统区分大小写，
LibXXX.so和libxxx.so是两个文件
检查库本身及其依赖是否完整
即使主库文件在路径里，若它依赖的其他动态库缺失，dlopen 仍会失败，报错常含 “not found” 或 “cannot open shared object file”。
- Linux：用
ldd libxxx.so查依赖，看有没有 “not found” 行；缺失的库需安装或补到LD_LIBRARY_PATH或/etc/ld.so.conf - Windows：用 Dependency Walker 或
dumpbin /dependents xxx.dll（需 Visual Studio 工具链），重点确认 VC++ 运行时（如 vcruntime140.dll）是否在 PATH 中 - macOS：用
otool -L libxxx.dylib查依赖，缺失项需用install_name_tool修正或补全路径
确认 JVM 与本地库架构一致
32 位 JVM 只能加载 32 位库，64 位同理。不匹配时错误可能不提示位数，只报 “dlopen failed” 或 “wrong ELF class”。
- 查 JVM 位数：
java -version看是否有 “64-Bit”；或代码中System.getProperty("sun.arch.data.model")返回 “64” 或 “32” - 查库位数：
file libxxx.so（Linux/macOS）看输出含 “ELF 64-bit” 还是 “32-bit”；Windows 用dumpbin /headers xxx.dll看 machine 字段 - 常见陷阱：Eclipse 或 IDE 默认用系统自带 JDK（可能是 64 位），但你编译的库是 32 位（或反之）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
