根本原因是jvm未在java.library.path指定路径中找到符合命名规范的库文件；需确保库名不含前缀/后缀、文件名严格匹配（如linux下为libmylib.so）、路径已通过-djava.library.path显式配置并生效。
System.loadLibrary() 为什么找不到你的 .so/.dll
直接调用 System.loadLibrary("mylib") 却抛出 UnsatisfiedLinkError: no mylib in java.library.path，根本原因不是代码写错了，而是 JVM 根本没在它搜的路径里看到那个文件。OpenJDK 按固定顺序查三类位置：先是当前 ClassLoader 的 findLibrary() 返回路径（通常为空），再是 java.library.path，最后才是 sun.boot.library.path。你放错目录、没配对、或者名字拼错，都会卡在这一步。
-
libname参数不能带扩展名和前缀（Linux 不要libmylib.so，Windows 不要mylib.dll，只写"mylib"） - Linux 下实际查找的是
lib<name>.so</name>，Windows 是<name>.dll</name>，macOS 是lib<name>.dylib</name>—— 名字必须严格匹配 - 如果用了绝对路径，必须改用
System.load("/full/path/to/mylib.so")，loadLibrary()明确禁止路径分隔符（会直接 throw）
怎么让 java.library.path 包含你的开发目录
开发中本地库还没打包进 JRE，最稳妥的方式是启动时显式注入路径。不要依赖系统环境变量（比如 Linux 的 LD_LIBRARY_PATH 在某些容器或 IDE 启动方式下会被忽略），而要用 JVM 参数：
- 加到
java命令行：-Djava.library.path=/path/to/your/libs:/usr/lib/jni - IDEA 中在 Run Configuration → VM options 里填，注意多个路径用
:（Linux/macOS）或;（Windows）分隔 - 别把路径加到
PATH或LD_LIBRARY_PATH后就以为万事大吉 —— OpenJDK 不读这些来定位loadLibrary()的目标，只读java.library.path - 路径末尾不加斜杠，且确保该目录下确实有对应平台的二进制文件（比如你在 macOS 上跑，却只放了
.so，照样失败）
ClassLoader.findLibrary() 可以被重载，但慎用
如果你的库是随 jar 一起发布的（比如 native jar），可以自定义 ClassLoader 并重写 findLibrary(String libname)，返回你 jar 包内 /natives/{os}/{arch}/libmylib.so 的绝对路径。但开发阶段没必要这么绕 —— 这个机制主要是为框架（如 LWJGL、JavaCPP）服务的，普通项目硬套反而增加调试复杂度。
- 重写时必须返回完整绝对路径（
new File(...).getAbsolutePath()），相对路径会被忽略 - 返回 null 表示“我不管，你继续往下找”，返回空字符串或非法路径会直接触发
UnsatisfiedLinkError - 绝大多数开发场景，老老实实用
-Djava.library.path更快定位问题
验证路径是否生效的最快方法
别猜，直接打印出来看：
System.out.println(System.getProperty("java.library.path"));
运行后检查输出里有没有你期望的路径。如果没出现，说明 JVM 参数没传进去，或者 IDE 配置没生效。另外，可以用 strace -e trace=openat java YourMainClass 2>&1 | grep mylib（Linux）确认 JVM 真正 open 了哪些文件 —— 很多时候你以为它在找 libmylib.so，其实它在找 libmylib.so.1 或者 libmylib.so.1.0.0，那是链接器行为，和 Java 层无关。
真正麻烦的永远不是“怎么写那一行 loadLibrary”，而是“JVM 到底去哪找了、找到了什么、为什么拒绝加载”。盯住路径和文件名，比翻源码更管用。
