Spring Boot依赖管理：选型、配置与版本冲突排查-北京尧图网络

新建一个Spring Boot工程时最让人纠结的其实往往不是业务代码而是pom.xml或者build.gradle里那一堆依赖。我见过不少同行尤其是刚开始做Java后端的时候会从老项目里把pom整个复制过来结果版本对不上、依赖冲突一堆、启动报错要排查半天。这篇文章我就想以创建项目时的视角把Spring Boot里最常用的一批依赖、它们各自的定位、选型逻辑和实操中容易踩的坑一次讲清楚。无论你是刚准备动手建第一个Spring Boot项目还是已经写过几个小项目但一直对依赖这块“照抄”这篇都值得花几分钟过一遍。很多人在创建项目时把依赖看作“填空题”其实依赖选型直接决定后面几个月的开发体验。每个依赖背后都有一套技术栈和默认行为加了某个依赖它不会只在代码里多一个import而是会带来一连串传递依赖、自动配置和运行时开销。所以这篇不只是列清单更想让你理解“为什么这个项目需要这个依赖”以及“当它和别的依赖打架时该怎么处理”。1. 为什么Spring Boot项目的依赖不能“抄作业”1.1 依赖选型背后是技术栈决策很多新手刚接触Spring Boot时习惯从网上的开源项目里抓一份pom过来然后改改项目名就开始写Controller。这种做法在最开始确实能跑但等到功能复杂起来往往会出现两类问题一是引入了大量根本用不到的依赖项目启动慢、打包体积大安全漏洞面也跟着变大二是真正需要某个能力的时候发现手头的依赖版本和Boot版本不兼容再回头去改就已经很痛苦了。依赖选型本质上是一次技术栈决策。举个最简单的例子你操作数据库到底用Spring Data JPA还是MyBatis这不是“顺手加一个starter”的问题而是决定了你后面所有的数据访问层代码怎么写、复杂查询怎么组织、事务怎么管理。同样缓存选Redis、消息队列选RabbitMQ还是Kafka每一类中间件的starter都会引入各自的客户端和自动配置逻辑写法和运维方式都完全不同。所以我的建议是新建项目时先想清楚三件事这个项目核心是API服务还是后台管理数据访问是走ORM还是原生SQL需不需要接入缓存、消息、分布式等中间件。想清楚之后再动手添加依赖而不是“先把可能用到的都加上宁可多不可少”。依赖这东西加上去容易想移除的时候往往牵一发而动全身。另外我见过不少人因为“别人项目里都这么写”就盲目引入特别多的starter比如要个定时任务把Quartz加进来要个接口文档把Springfox和Knife4j都加进来要个文件上传又把一堆上传框架塞进来。结果项目还在开发阶段依赖冲突、版本不一致的问题就开始频繁出现。依赖越少排查问题的范围越小运行时的不确定性也越低。1.2 Spring Boot的依赖管理机制为什么Spring Boot官方starter很多都不需要写版本号这背后是两个关键角色spring-boot-starter-parent和spring-boot-dependencies。spring-boot-starter-parent是你在pom里声明的一个“特殊父工程”它除了管理依赖版本还负责设置Maven的编译插件、资源过滤规则、JDK版本等一揽子默认配置。而spring-boot-dependencies则是一个BOMBill of Materials里面把Spring Boot官方生态以及常用的第三方库版本都集中做了一版互通性验证。你继承了这个parent之后就相当于自动拿到了这一套经过测试的版本组合因此官方starter比如spring-boot-starter-web、spring-boot-starter-data-jpa等等都不需要手动写版本号。但这里要特别注意BOM覆盖的是“官方认可”的版本。第三方的starter比如MyBatis的mybatis-spring-boot-starter或者一些专有组件starter并没有被纳入Spring Boot的BOM这时候你必须自己声明版本号。同时如果你的公司内部有统一的私服仓库和公共父工程不打算直接继承Spring Boot的parent也可以改为在dependencyManagement中单独引入spring-boot-dependencies效果类似但独立维护性更好。用Gradle创建Spring Boot项目时逻辑是一样的通过io.spring.dependency-management插件或者Spring Boot插件自带的依赖管理能力同样不需要逐个写版本号。但Gradle的依赖解析策略和Maven不完全相同比如Gradle默认取的是“最高版本”冲突处理上更暴力这也在实际项目中带来了另一类“隐性坑”。下面我会在版本与冲突部分再详细展开。2. 创建项目时必配的基础依赖清单2.1 Web层spring-boot-starter-web与它的兄弟如果你创建一个标准的Web API服务spring-boot-starter-web几乎是九成项目的默认选择。这一个starter里包含了Spring MVC、内嵌的Tomcat、Jackson序列化、日志桥接等一大堆开发Web功能所需的组件。可以说只要把它加进去你就能直接写RestController接口然后mvn spring-boot:run把服务跑起来。这里有一个容易踩的细节Spring Boot 2.3之前的版本中spring-boot-starter-web会顺带提供参数校验相关的依赖但之后版本它被拆分了出去。如果你在接口里用Valid、Validated这些注解却发现怎么都不生效通常就是因为漏了spring-boot-starter-validation。这个starter体积很小但经常被漏掉。现在创建项目时只要用了参数校验我基本会直接把validation一起加上免得后面再补。另一个兄弟是spring-boot-starter-webflux它面向响应式编程默认内嵌的是Netty用的是Spring WebFlux那套Mono/Flux模型。如果你的接口不需要高并发下的响应式能力我建议不要把它和web混在一起用。因为两者都依赖Spring MVC的路由和WebFlux的路由一旦同时存在于classpath应用会以Spring MVC为主但可能会因为类冲突出现一些莫名其妙的警告或行为。2.2 数据访问JPA、MyBatis、JDBC三选一数据访问层的选型是Spring Boot项目里最容易让新人纠结的地方。其实核心就三条路线spring-boot-starter-data-jpa、mybatis-spring-boot-starter、spring-boot-starter-jdbc。它们各自代表不同的开发风格。spring-boot-starter-data-jpa基于Hibernate实现核心思路是“以对象为中心”。你定义实体类通过注解描述表和字段的映射关系CRUD操作由JpaRepository封装好的方法帮你完成很多简单查询甚至不用写SQL。它非常适合业务模型清晰、以单表操作为主的场景开发效率很高。但缺点也很明显复杂查询、多表join、SQL调优这些场景一旦绕过JPA去写Query原生SQL你会感到它替你做的封装反而成了约束。mybatis-spring-boot-starter则是“以SQL为中心”的思路。SQL写在自己手里关联查询、子查询、分页都能精确控制对复杂业务和遗留数据库支持更好。代价是每张表都要写Mapper接口和XML批量插入、动态SQL有时候会很繁琐。如果你团队里有人习惯写SQL或者公司对数据库查询有强监管需求MyBatis往往更稳妥。spring-boot-starter-jdbc是最轻量的一种选择。它不引入ORM提供的是JdbcTemplate这样的工具类直接写SQL、直接绑定参数。项目不大、只是做几个简单查询的时候用它完全足够而且没有N1查询、懒加载这类问题。三者的适用场景用一个不太严谨但好理解的说法JPA适合快速开发、映射关系清晰的小中型项目MyBatis适合复杂查询和SQL精细控制的团队JdbcTemplate适合轻量依赖、不愿引入重框架的场景。技术方案核心依赖优势短板Spring Data JPAspring-boot-starter-data-jpa开发快对象映射自动化复杂SQL控制困难MyBatismybatis-spring-boot-starterSQL精细可控支持复杂查询Mapper样板代码多JdbcTemplatespring-boot-starter-jdbc轻量直接执行SQL缺少ORM能力手工映射多2.3 数据库驱动与连接池选完数据访问框架还需要引入对应的数据库驱动。用得最多的就是MySQL和PostgreSQL。MySQL驱动这里有个容易被忽视的变化早期坐标是mysql:mysql-connector-java但新版已经把坐标改成了com.mysql:mysql-connector-j如果还按老的坐标拉在仓库里可能解析到旧版本造成和新版MySQL通信的一些兼容问题。建议直接使用最新坐标由Spring Boot的BOM统一管理版本。PostgreSQL驱动相对简单坐标是org.postgresql:postgresql版本也由Boot管理。这里要注意URL参数特别是时区、SSL相关配置不同云环境默认行为差异很大本地连不上大概率就是驱动参数和数据库侧配置不一致导致的。连接池方面Spring Boot 2.7之后的spring-boot-starter-jdbc已经默认集成HikariCP不用再单独引入。HikariCP的特点是轻量、性能好还提供了maximum-pool-size、connection-timeout、minimum-idle等关键参数这些参数在默认值下并不一定适合你的生产环境。我常用的配置是maximum-pool-size设置为CPU核心数 × 2 应用程序并发数再取一个合理值具体要通过压测不断调整。实际操作中连接池太小会导致高峰期连接等待太大会让数据库后端线程数飙升反而拖垮性能。如果你使用的是默认HikariCP应用启动时遇到连接相关问题记得先看spring.datasource.hikari.*配置是否合理。很多人只配置了url和用户名密码却在没有数据库连接的情况下启动HikariCP会按照初始化机制反复尝试最终报出“Connection is not available”之类的错误这对定位问题其实是有利信号因为它明确指向了数据源配置。3. 开发效率与体验类依赖3.1 Lombok能用但别滥用Lombok是几乎所有Spring Boot项目的常驻依赖它可以自动生成getter、setter、toString、equals、构造器以及日志对象等。加依赖后你只要在实体类上写Data、Slf4j代码里就能直接使用这些方法。但Lombok有一个被反复讨论的副作用它在编译期修改AST生成代码这让你在IDE里看到的源码和实际编译后的代码并不一致。比如你用了Data以为字段发生了变更会同步更新hashCode和equals但其实这几个方法是自动生成后不会再和字段变化保持同步的。再比如Java新版本发布后Lombok版本如果没跟上很可能在编译阶段直接报错尤其升级JDK时会让你措手不及。所以我现在的习惯是能用Java自带record解决的简单DTO就不加Lombok确实需要大量实体类简化时再引入同时锁定一个和当前JDK兼容的Lombok版本。还有一个问题就是Builder。构建器模式确实漂亮但Builder和Data一起用的时候如果处理不当会有序列化或者构造上的坑。比如在Spring Boot反序列化JSON时Jackson需要无参构造函数而Builder会生成全参构造器如果没有额外的无参构造处理会出现反序列化失败。这种问题在排查时并不直观你甚至会怀疑是不是JSON格式错了。使用Lombok前请先花点时间看看它生成的构造器行为而不是无脑堆注解。3.2 Validation与配置处理参数校验这块前面提到需要单独引入spring-boot-starter-validation。有了它Controller层就可以通过NotBlank、NotNull、Email、Pattern这类注解配置字段规则再用Valid触发校验。如果校验不通过Spring会抛出MethodArgumentNotValidException你可以通过统一的异常处理器把错误信息返回给前端。这里有个实用经验自定义异常响应体时最好把BindingResult里的多个错误都拼接起来返回而不是只拿第一个错误。否则前端会反复提交、反复改一个错体验很差。配置处理方面spring-boot-configuration-processor这个依赖也很容易被忽略。加上它之后你在编写ConfigurationProperties配置类时IDEA就能给出application.yaml里的键值提示还能在配置项写错时给出警告。它看起来只是一个开发期工具但实际价值很大项目配置项多了以后光靠记忆根本记不住键名这个处理器能减少很多“配置写错但找不到原因”的排查时间。3.3 热部署与测试开发调试时spring-boot-devtools能提供自动重启和热替换。改完代码Build一下应用会自动重启省掉了手动停止再启动的步骤。但注意devtools在有些公司的生产环境是不允许出现的它对性能有影响而且会引入restart相关的线程生产环境千万别图方便把它留在pom里。建议通过maven profile或dependencyManagement在打包时排除它。测试方面spring-boot-starter-test是一个很全面的测试“全家桶”里面包含了JUnit 5、Spring Test、Mockito、AssertJ、JSONassert等。它几乎不需要你再单独引入其他测试库。写集成测试时配合SpringBootTest就能加载完整上下文。这里提醒一下跑测试时如果应用里加了Security、Redis等starterSpringBootTest会把它们全部启动起来导致测试环境依赖很多外部服务。常见做法是用TestConfiguration或MockBean把外部依赖替换成Mock或者用DataJpaTest这种切片测试只加载数据访问层。4. 常用中间件与扩展组件依赖4.1 缓存、消息队列与定时任务缓存应用里最常见的是Redis对应的依赖是spring-boot-starter-data-redis。这个starter默认使用Lettuce客户端而且支持连接池。早期很多老项目用Jedis如果你是新建项目我更推荐直接走默认的Lettuce因为它是线程安全的可以在多个线程里复用同一个连接在连接数、性能上都表现得不错。使用Redis时我还建议配合spring-boot-starter-cache来使用Spring Cache抽象。它能在方法上通过Cacheable、CacheEvict这些注解管理缓存不用自己写RedisTemplate的get、set逻辑。消息队列的选择就看场景RabbitMQ对应spring-boot-starter-amqpKafka对应spring-kafka。如果你只是希望系统间解耦、异步处理一些任务RabbitMQ的AMQP协议足够稳定配置也不复杂。Kafka更适合大数据量日志、流式处理的场景。没有特殊要求时避免同时引入多套MQ客户端每套都会带来自己的序列化方式、线程池和监控指标维护成本会成倍增加。定时任务这块Spring Boot本身就支持Scheduled这个注解来自spring-boot基础包不需要额外加依赖。如果你只需要简单的定时轮询、固定间隔执行直接用就行。真正需要使用Cron表达式做复杂任务调度、需要任务持久化或集群环境下不重复执行时再考虑quartz或xxl-job这类框架其中Quartz只需要org.quartz-scheduler:quartz就够了。4.2 安全、监控与接口文档安全方面spring-boot-starter-security是Spring生态的核心选择。但要注意它的默认行为是只要依赖在classpath里所有接口都会被拦截并且生成一个随机密码启动日志里能看到用户名是user密码是那一串UUID。新手第一次加这个依赖往往会发现接口突然全部401然后一头雾水这就是安全默认生效导致的。想用好Security至少要会写SecurityFilterChain的配置类明确放行路径和认证方式否则它不会是我们想要的“安全”而是一道莫名其妙的门。监控方面spring-boot-starter-actuator提供应用的健康检查、指标、日志级别动态调整等能力。生产环境中我建议只暴露health、info等端点其他的比如env、beans、heapdump可能泄露敏感信息。配合Spring Boot Admin或者Prometheus就可以实现简单的应用监控面板对中小型团队来说性价比很高。接口文档是协作开发中几乎绕不开的工具。老牌的Springfox由于和Spring Boot 2.6以后默认的路径匹配策略PathPatternParser不兼容很容易报NullPointerException。现在新建项目我优先推荐springdoc-openapi对应的starter是org.springdoc:springdoc-openapi-starter-webmvc-ui它接入起来更顺和Spring Boot新版兼容性更好提供/swagger-ui.html页面也支持OpenAPIDefinition这些注解。4.3 微服务场景依赖组合如果你创建的不只是单体应用而是一个微服务模块那么除了Spring Boot基础依赖还会面对注册中心、配置中心、服务调用等一堆问题。目前国内用得较多的组合是spring-cloud-starter-alibaba-nacos-discovery做注册发现spring-cloud-starter-alibaba-nacos-config做配置中心spring-cloud-starter-openfeign做声明式服务调用再配合spring-cloud-starter-loadbalancer做客户端负载均衡。很多同学加了这些依赖后服务启动不起来或者服务间调用不了大多数是因为缺少对应的BOM管理比如没有引入spring-cloud-alibaba-dependencies这个BOM又或者spring-cloud版本和spring-cloud-alibaba版本对不上。微服务依赖的“版本矩阵”要比单个Boot项目复杂得多一定要在创建项目前查好版本对应关系。另外团队不大、没有强制拆分诉求的话我建议先不要上微服务套件单体应用加一个模块拆分就够了。微服务带来的运维复杂度远不是几个依赖能解决的。5. 版本冲突与依赖排查的实操记录5.1 用什么工具看清依赖树依赖出问题的时候第一件事不是去改代码而是看清当前的依赖树。Maven项目里用mvn dependency:treeGradle项目里用gradle dependencies。这两个命令会把所有直接依赖和传递依赖以树形结构打出来。找冲突时我通常会在结果里搜索某个包名然后看它出现了几个版本是谁引进来的。比如你发现项目里有“jackson-databind”两个版本就能顺着依赖树找到是哪个库带进来的。很多时候不是我们主动引入冲突而是某个starter内部引用了旧版的Jackson另一组件引用了新版两边一打架反射调用时找不到方法就会出现NoSuchMethodError。看清依赖树后可以用Maven的exclusions排除旧版本或者通过dependencyManagement强制指定统一版本。Gradle的冲突策略是自动选取最高版本但这未必是正确的。A依赖2.0B依赖3.0Gradle可能直接选了3.0但A的代码调用的却是2.0里的私有方法运行时照样崩。所以Gradle项目里排查依赖冲突除了看依赖报告还要注意是不是需要显式使用resolutionStrategy来强制锁定版本。不要相信“Gradle自动处理冲突”这种话它只是帮你选择不代表帮你解决。5.2 常见报错与解决依赖问题在Spring Boot项目里表现出的症状五花八门这里列几个高频的方便你对号入座。NoSuchMethodError和ClassNotFoundException是最常见的。前者往往是版本冲突某个类存在但是缺少目标方法多发生在Jackson、Spring核心包上先看依赖树找出具体传递链再统一版本。后者先确认是否确实漏引依赖比如用了Valid才发现没有validation用了ConfigurationProperties却没有引入处理器的元数据包。接口突然全部401多半是启动了Security默认机制。解决办法就是写一个SecurityFilterChain的Bean在permitAll和authenticated之间做好区分。如果用了JWT这类无状态方案还要自定义OncePerRequestFilter来解析Token。mapper接口扫描不到是MyBatis很经典的问题。可能是因为Mapper接口和SpringBootApplication不在同一个包下且没有使用MapperScan扫描也可能是因为只写了Mapper接口却忘了加Mapper注解。通常启动的时候会有“Property sqlSessionFactory or sqlSessionTemplate are required”这类报错按这个线索回溯即可。HikariCP启动时连接超时先去确认数据库地址、端口、用户名、密码。如果你本地的数据库没启动但配置了自动重连Spring Boot启动不会立刻失败而是会卡住一段时间等连接池初始化。我建议把spring.datasource.hikari.initialization-fail-timeout调整到较小值方便在开发阶段快速暴露问题。5.3 版本选择的两个原则版本选择上我自己的原则非常简单能用Spring Boot BOM管理的就用Boot给的版本不自己乱填版本号第三方组件一定要选一个和当前Boot大版本兼容的版本。Spring Boot 3.x基于Jakarta EE 9很多老依赖如果还按javax的坐标引入编译和运行铁定出问题。实际工作中我会在创建新项目之前去某个技术文档库或者官方release说明里查一下所选第三方starter的“Recommended Spring Boot Version”。比如有些第三方组件会在文档里明确写“Compatible with Spring Boot 2.x/3.x”。如果文档没说就看它的Maven坐标发布时间判断和对应Boot版本的匹配度。另一个容易忽略的点是Java版本也会间接影响依赖版本。Spring Boot 3.0之后最低要求Java 17如果你的项目还在用JDK 8那么能用的Boot版本只能是2.7.x这时候就不要去强行引入只支持Boot 3.x的组件。换句话说Java、Spring Boot、第三方库三个版本是联动系统任何一方的升级都可能导致另外两方被迫变动。6. 各场景下的推荐依赖组合参考很多人在创建项目时希望直接有一个“可抄的清单”这里我就按三类常见场景整理一份相对稳妥的依赖组合供你按需参考。需要说明的是基础依赖比如spring-boot-starter-web、spring-boot-starter-test、spring-boot-maven-plugin在绝大多数项目里都是标配这里就不再重复列举。第一类标准REST API服务。这是最常见的单体后端服务。如果做的是纯粹对外提供JSON接口、不含页面渲染那么spring-boot-starter-web加spring-boot-starter-validation是最基础的组合。数据访问按团队偏好选JPA或MyBatis再配上数据库驱动。如果接口文档需要输出给前端把springdoc-openapi-starter-webmvc-ui加上。缓存、消息等除非已经明确的业务需求否则建议先不加。第二类后台管理系统或企业内部应用。这类项目往往会引入Security做权限控制再加一个actuator方便健康检查。如果管理系统包含大量表单和列表也许需要分页插件比如MyBatis场景下的pagehelper-spring-boot-starter。定时任务如果只是做简单数据同步、报表生成直接用Scheduled即可不必上Quartz。第三类微服务开发。除了Boot基础库还要考虑Spring Cloud和Spring Cloud Alibaba的BOM注册中心、配置中心、OpenFeign、LoadBalancer这些通常是一起出现的。做微服务时网关模块还需要引入对应的spring-cloud-starter-gateway注意它是基于WebFlux的所以不要在网关项目里引入spring-boot-starter-web否则会冲突。这部分复杂度很高依赖组合要和团队统一标准避免每个人项目里引入不同的版本组合给后续联调制造麻烦。使用上述任何一种组合时都建议遵守一个原则最小化。先把核心链路跑通再按业务需要逐步增补。项目创建时的依赖越精简后期排查问题的范围就越小。这不是“少用技术”而是让技术为业务服务不要让一长串依赖成为交付的负担。7. 创建项目时的实操心得与补充建议光看依赖清单还不够真正落到构建文件里还有一些细节要提醒。比如如果你用的是Spring Initializr或者IDEA的Spring Project向导创建出来的项目里默认只有一个spring-boot-starter和一个spring-boot-starter-test连Web依赖都没有。很多人对此很意外以为向导会自动带上Web。所以新建项目后的第一件加依赖的事就是把spring-boot-starter-web补上。再比如spring-boot-maven-plugin这个插件在构建文件里看起来不起眼但没了它你用mvn package打出来的jar根本执行不了java -jar因为它负责把Spring Boot的可执行jar进行“重新打包”。所以这个插件不是可有可无的它一定要在buildplugins里保留。另外每个依赖都建议显式写好注释哪怕是临时加的一个测试依赖。项目时间长了以后pom里几十个依赖谁能记得哪个依赖是给哪块功能用的我自己会在每个dependency上方写一行中文注释说明引入原因、对应模块代码规范好维护的人就少骂一句。多模块项目就是一个值得说的点。如果你的工程不是单模块而是拆成common、core、api、admin这种结构那么父pom可以把所有依赖统一用dependencyManagement管理版本子模块里只声明用到的依赖而不写版本号。这样能避免子模块之间版本不一致。Spring Boot parent的继承和模块间的依赖关系要先规划清楚否则子模块启动时会遇到“找不到Spring Boot自动配置”的问题。最后再说一点依赖白名单的意义。在一些公司里公共组件会和业务项目分开业务项目里随意引入各种第三方库往往会带来版本管理失控。如果你有权限在团队里推动规范我建议制定一个Spring Boot常用依赖清单规定哪些是框架标配、哪些需要审批才能引入、哪些明确禁止。一条简单的规则就能避免很多人把项目搞乱。说了这么多我个人在实际操作中最深的体会是依赖不是越多越强而是越合适越好。每次往构建文件里加一个新依赖前我应该先问自己三个问题这行代码真的需要它吗它会带来哪些传递依赖会不会影响别的模块如果以后不用了需要多费多少事才能把它安全移除三个问题都能回答清楚再把它加进去。还有一个习惯大家都说好新建项目永远从最小依赖启动先把Hello World跑通再启动到数据库、缓存、认证那些高阶模块一步一步往上加。每次加完立刻启动验证一遍有问题当场发现不要攒到最后一口气全配上再启动否则报错了你连是谁引入的问题都分不清。

Spring Boot依赖管理：选型、配置与版本冲突排查

相关推荐

论文降重与降AIGC：破解查重标红和AI误判

CANoe+CAPL打造Bootloader刷写上位机：协议拆解与代码实践

第一次小考全流程拆解：出题、评分、监考与复盘一次讲透

更多资讯

GPT-4更新与API降价：创业公司如何应对大模型生态冲击

自动化办公实战：从流程梳理到AI辅助的完整指南

边际电价机制解析：效率损失到底出在哪一步？

80%的AI应用会消失？工程思维才是超能力

OpenHarmony内核开发实战：任务管理与定时器从入门到精通

Django模板系统深入实践：语法、继承、自定义与性能优化

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？