ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

别再乱用SpringBoot了,这些坑你踩过几个

别再乱用SpringBoot了,这些坑你踩过几个 SpringBoot让Java开发变得前所未有的简单一个main方法就能启动Web服务一个注解就能完成数据库操作。但“简单”是把双刃剑——很多人只学会了怎么用却没搞懂背后的机制结果在项目中埋下无数暗雷。以下这些坑几乎每个SpringBoot开发者都踩过至少三个。坑一循环依赖你以为解决了其实没有两个Service互相注入A依赖BB又依赖A。SpringBoot默认允许循环依赖通过三级缓存帮你“兜底”。但这不是什么好事——它意味着你的代码结构已经混乱。更危险的是如果你在A的构造器里注入BSpring会直接报错。因为构造器注入无法使用三级缓存解决。很多人改成Autowired字段注入就“好了”但字段注入本身就不推荐它掩盖了设计问题。正确做法重新划分职责抽出第三个Service或者用Lazy延迟加载。但最好的方案是不要有循环依赖。坑二Transactional失效数据不一致你在Service方法上加了Transactional以为万事大吉。结果发现事务没回滚。原因可能有很多方法不是public的Spring AOP无法代理。同类内部调用比如this.save()不走代理对象。异常被catch了没有抛出去。抛的是检查异常而默认只回滚RuntimeException。正确做法确保事务方法由代理对象调用异常要抛出或手动setRollbackOnly()必要时指定rollbackFor Exception.class。坑三自动配置冲突Bean覆盖悄无声息你引入了一个starter它自动配置了一个DataSource。你又在自己的配置类里定义了一个DataSource。SpringBoot 2.1之后默认禁止Bean覆盖启动直接报错。但在老版本里它可能悄悄覆盖导致你连的数据库不是你以为的那个。正确做法用ConditionalOnMissingBean让自定义配置优先或者通过spring.main.allow-bean-definition-overridingtrue显式允许覆盖但不推荐。更重要的是启动时看自动配置报告确认哪些配置生效了。坑四配置文件加载顺序搞不清application.yml、application-dev.yml、application-prod.yml、环境变量、命令行参数……到底谁覆盖谁很多人改了配置不生效就是因为优先级搞反了。SpringBoot的配置优先级大致是命令行参数 环境变量 外部配置文件 内部配置文件。而application-{profile}.yml会覆盖application.yml中的同名属性。正确做法用--spring.profiles.activeprod明确指定环境敏感配置走环境变量。启动时加--debug查看配置加载详情。坑五打包成jar后找不到资源文件本地跑得好好的打成jar后报FileNotFoundException。因为你用了new File(src/main/resources/xxx)但jar包内没有“src”这个目录。资源文件在classpath里必须用ClassPathResource或getResourceAsStream()读取。正确做法统一用ClassLoader.getResourceAsStream(xxx)或者用Value(classpath:xxx)注入。坑六内嵌Tomcat性能没调优SpringBoot默认内嵌Tomcat最大线程数200连接数有限。高并发下请求直接排队。很多人上线前从不调整结果压测时QPS上不去。正确做法根据业务调整server.tomcat.max-threads、max-connections、accept-count。如果是I/O密集型适当加大CPU密集型则不宜过大。同时开启压缩、调整keep-alive。坑七版本升级牵一发而动全身SpringBoot 2.x升3.xJDK从8升17javax变成jakarta大量依赖不兼容。很多人直接改版本号结果启动报错几十个。正确做法升级前先看官方迁移指南逐步升级。用mvn dependency:tree排查冲突用spring-boot-properties-migrator辅助迁移。不要在生产环境直接升先在分支上跑通所有测试。结语SpringBoot的“约定优于配置”极大地提升了开发效率但约定背后的原理你必须懂。否则你只是在“碰运气”写代码。以上七个坑每一个都可能导致线上故障。避开它们的方法很简单多读官方文档多看自动配置源码多写测试多复盘线上问题。记住框架越智能你越要清楚它替你做了什么。
返回列表