Springboot3.5.x版本引入javaCv相关库版本问题以及精简引入包

背景

最近公司有个项目需要用到ffempeg,公司项目比较新，用的是最新的Springboot3.5.x版本，一开始在网上找了篇教程，引入了javacv-platform依赖，顺利完成了工作。但是后来打包之后发现jar包的内存从原本的100M变成了900多M，所以就在网上找了很多精简引入的教程，可按照他们的做法，很多都无法正常使用，就算可以使用，也都是针对Springboot2.x版本的，很容易出现版本冲突的情况，导致项目其它很多包直接爆红，很少见到有SpringBoot3.x版本的教程，特此写了这篇文章。

️ 问题根源：为什么 javacv-platform 如此“臃肿”？

要解决问题，必先究其根源。javacv-platform 的设计初衷是为了方便开发者，它是一个“聚合包”，通过 Maven 的  帮你一次性引入所有可能用到的组件和平台。

它默认包含了：

• 所有平台：Windows (x86, x86_64), macOS (x86_64, arm64), Linux (x86, x86_64, arm64, etc.)…
• 所有预编译库：FFmpeg, OpenCV, FlyCapture, etc…

这就好比你只想做一道番茄炒蛋，却直接买下了整个超市。打包时，Maven 会把这些所有平台的本地库文件（如 .dll, .so, .dylib）全部塞进你的 JAR 包里。你的应用明明只需要在 Linux 服务器上运行，却带着 Windows 和 macOS 的“行李”，体积能不大吗？

依赖

基础依赖： Springboot3.5.5、jdk17

我们希望：开发时只加载 Windows 依赖，打包部署到 Linux 服务器时只加载 Linux 依赖。

Maven 的 Profile 功能就是为此而生！

我们可以将平台依赖分别放到不同的 Profile 中，通过激活不同的 Profile 来动态加载依赖。

<properties>
    <javacv.version>1.5.8javacv.version>
    <javacv.ffmpeg.version>5.1.2-1.5.8javacv.version>
properties>

<dependencies>
    
    <dependency>
        <groupId>org.bytedecogroupId>
        <artifactId>javacvartifactId>
        <version>${javacv.version}version>
    dependency>
dependencies>

<profiles>
    
    <profile>
        <id>devid>
        <activation>
            <activeByDefault>trueactiveByDefault> 
        activation>
        <dependencies>
            <dependency>
                <groupId>org.bytedecogroupId>
                <artifactId>javacppartifactId>
                <version>${javacv.version}version>
                <classifier>windows-x86_64classifier>
            dependency>
            <dependency>
                <groupId>org.bytedecogroupId>
                <artifactId>ffmpegartifactId>
                <version>${javacv.ffmpeg.version}version>
                <classifier>windows-x86_64classifier>
            dependency>
        dependencies>
    profile>

    
    <profile>
        <id>prodid>
        <dependencies>
            <dependency>
                <groupId>org.bytedecogroupId>
                <artifactId>javacppartifactId>
                <version>${javacv.version}version>
                <classifier>linux-x86_64classifier>
            dependency>
            <dependency>
                <groupId>org.bytedecogroupId>
                <artifactId>ffmpegartifactId>
                <version>${javacv.ffmpeg.version}version>
                <classifier>linux-x86_64classifier>
            dependency>
        dependencies>
    profile>

    
    <profile>
        <id>macid>
        <dependencies>
            <dependency>
                <groupId>org.bytedecogroupId>
                <artifactId>javacppartifactId>
                <version>${javacv.version}version>
                <classifier>macosx-x86_64classifier>
            dependency>
            <dependency>
                <groupId>org.bytedecogroupId>
                <artifactId>ffmpegartifactId>
                <version>${javacv.ffmpeg.version}version>
                <classifier>macosx-x86_64classifier>
            dependency>
        dependencies>
    profile>
profiles>

• 本地开发：默认激活 dev profile，直接运行或打包即可，只会包含 Windows 依赖。
• Linux 服务器打包：在打包命令中指定 prod profile。

    mvn clean package -Pprod

• macOS 用户打包：

    mvn clean package -Pmac

这样，最终产出的 JAR 包就只包含了对应环境的本地库，体积大幅缩减，完美解决问题！

关于版本选择的说明

你可能会问，为什么不用最新的 JavaCV 版本？

在我的实践中，JavaCV 1.5.8 和 FFmpeg 5.1.2-1.5.8 这个组合在 Spring Boot 3.x + JDK 17 环境下表现得非常稳定。尝试升级到 JavaCV 1.5.9 或更高版本时，曾遇到过其传递依赖与 Spring Boot 自带的某些库（如 jakarta.servlet-api 等）产生细微冲突的情况。