loadLibrary找不到.so文件的典型表现是抛出UnsatisfiedLinkError: no xxx in java.library.path，说明JVM未在java.library.path指定路径中找到libxxx.so；需确保路径正确、文件名符合规则（无lib前缀和.so后缀）、架构匹配且系统依赖满足。
loadLibrary 找不到 .so 文件的典型表现
运行时抛出 UnsatisfiedLinkError: no xxx in java.library.path，说明 JVM 根本没扫描到你的 C++ 动态库。这不是 JNI 接口写错了，而是路径没对上。
-
System.loadLibrary("xxx")会自动拼接前缀和后缀：Linux 上找libxxx.so，Windows 上找xxx.dll，macOS 上找libxxx.dylib；传入的字符串不能带lib前缀或扩展名 - JVM 只在
java.library.path指定的路径里搜索，**不会**自动查当前目录、CLASSPATH或项目根目录 - Android 是个例外：它把 so 文件放
src/main/jniLibs/armeabi-v7a/等 ABI 子目录下，由打包工具自动处理，不走java.library.path
Java 层调用前必须确保 native 方法签名匹配
哪怕只差一个参数类型或大小写，UnsatisfiedLinkError 也会在首次调用时爆发，而不是加载时 —— 这容易误判为“加载成功但调用失败”。
- C++ 函数名必须严格遵循
Java_<package>_<class>_<method></method></class></package>规则，包名里的.要替换成_，例如com.example.NativeHelper的add方法，对应 C++ 函数名是Java_com_example_NativeHelper_add - 函数声明必须带
JNIEXPORT JNICALL，返回值和参数类型要用jint、jstring等 JNI 类型，不能直接用int或std::string - 如果 Java 方法是
static，C++ 函数第二个参数是jclass；如果是实例方法，第二个参数是jobject
Linux 下手动指定 so 路径的三种方式（按优先级）
别依赖默认路径。生产环境最稳的方式是显式控制，而不是靠用户改环境变量。
- 启动 JVM 时用
-Djava.library.path=/path/to/so/dir，多个路径用冒号分隔（Linux/macOS）或分号（Windows） - 在 Java 代码中调用
System.setProperty("java.library.path", "/path/to/so/dir")**无效** —— 因为ClassLoader在 JVM 启动时已缓存该值，运行时修改不生效 - 用
System.load("/absolute/path/to/libxxx.so")绕过路径查找逻辑，但必须传绝对路径，且无法跨平台复用
64 位 JVM 加载 32 位 so 必然失败
错误信息通常是 Invalid ELF header 或直接静默崩溃，尤其在 CI 环境或 Docker 容器里容易踩坑。
立即学习“Java免费学习笔记（深入）”；
- 检查 so 文件架构：
file libxxx.so输出里必须含ELF 64-bit，且和 JVM 位数一致（java -version看是否含64-Bit） - 交叉编译时注意工具链：用
aarch64-linux-android-clang编 Android，用x86_64-linux-gnu-gcc编服务端，别混用 - Linux 容器里缺系统依赖（如
libc.so.6版本太低）也会导致dlopen失败，可用ldd libxxx.so查未满足的依赖
JNI 的麻烦不在写代码，而在环境链路太长：Java 类路径、JVM 参数、so 文件名规则、ABI 匹配、系统 libc 版本，任意一环断掉都报同一个模糊错误。最容易被忽略的是——你本地跑通了，不代表部署机上也行；CI 构建的 so 文件架构，可能跟目标服务器不一致。
