UnsatisfiedLinkError本质是JVM找不到本地库或其依赖，主因包括java.library.path路径错误、架构不匹配、依赖库缺失、符号未定义等，需结合ldd/dumpbin、位数检查及环境变量综合排查。
Java报UnsatisfiedLinkError，先看java.library.path里有没有你的.so或.dll
这个错误本质是JVM找不到你用System.loadLibrary()声明的本地库文件，不是代码写错了，而是路径没对上。JVM只在java.library.path指定的目录里找，不会自动扫描当前目录、项目根目录或CLASSPATH。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 运行时加
-Djava.library.path=/your/native/lib/path，路径必须是绝对路径，多个路径用:（Linux/macOS）或;（Windows）分隔 - 在代码里用
System.getProperty("java.library.path")打印出来，确认它真包含你要的目录 - 别把
.so放在src/main/resources下——JVM不从这里加载本地库；也别放jar包里，System.loadLibrary()不支持从jar内解压加载 - Windows下注意
.dll依赖的其他.dll（比如VC++运行时）也要在PATH里，否则照样报这个错
System.load()和System.loadLibrary()到底该用哪个
两者行为差异很大，选错就白折腾路径。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
System.load("/full/path/to/your/libxxx.so")：传绝对路径，绕过java.library.path，适合调试阶段快速验证库本身是否可用 - 用
System.loadLibrary("xxx")：JVM会按规则拼路径和扩展名（Linux→libxxx.so，Windows→xxx.dll），但要求库名必须匹配，且必须在java.library.path中 - 常见坑：
loadLibrary("libxxx")是错的——JVM会去找liblibxxx.so；正确写法是loadLibrary("xxx")，对应文件名是libxxx.so - Mac上注意后缀是
.dylib，但loadLibrary()仍传"xxx"，JVM会自动找libxxx.dylib
64位JVM只能加载64位本地库，32位同理
架构不匹配时，UnsatisfiedLinkError常伴随“wrong ELF class”或“%1 is not a valid Win32 application”这类提示，但有时就干巴巴报错，容易误判为路径问题。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 查JVM位数：
java -version输出里有64-Bit字样；或者代码里用System.getProperty("sun.arch.data.model")，返回"64"或"32" - 查本地库位数：Linux/macOS用
file libxxx.so，看输出含ELF 64-bit还是32-bit；Windows用dumpbin /headers xxx.dll（需VS工具链） - Maven打包时如果用了
os-maven-plugin，确认os.detected.arch生成的classifier（如linux-x86_64）和你实际运行环境一致 - Docker里尤其容易翻车：基础镜像用
openjdk:17-jre-slim是amd64，但如果你挂载了arm64编译的.so，就必然失败
JNI库依赖的符号没找到，也会触发UnsatisfiedLinkError
不是你的libxxx.so找不到，而是它内部调用的某个函数（比如log4cplus_log或SSL_connect）在系统里缺失，JVM加载时直接拒绝。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- Linux下用
ldd -r libxxx.so检查未定义符号（undefined symbol行），重点关注libssl.so、libc.so等是否版本兼容或路径可及 - 如果依赖第三方动态库，确保它们也在
LD_LIBRARY_PATH里（Linux）或PATH里（Windows），而不仅仅是java.library.path - 静态链接能规避部分依赖问题（编译时加
-static-libgcc -static-libstdc++），但会增大体积，且无法静态链接glibc - Android上更典型：NDK编译的so若引用了高版本API的符号，在低版本系统上运行就会报这个错，得用
__ANDROID_API__宏控制
ldd或dumpbin看看so/dll自己靠不靠谱，比反复改java.library.path快得多。 
