尧图网站建设 
简介《Spring Boot实战派》配套源码面向Java后端开发者和Spring Boot学习者帮助你从实际代码中理解框架的核心机制与项目落地方式。压缩包共包含10124个文件大小约103MB以java源码、xml配置、properties属性文件、html页面和class编译产物为主完整覆盖书籍所涉及的多模块工程结构。目前已有1152人学习/下载。源码内容涵盖自动配置、起步依赖、嵌入式Web服务器、健康检查与Actuator、RESTful API开发、JPA/Hibernate数据访问、Spring Security权限控制、配置管理、集成测试、定时任务、RabbitMQ/Kafka消息集成、Redis缓存、国际化、邮件服务及Docker/Kubernetes云原生等主题每个主题都有可运行的示例代码。通过分析这些代码读者能掌握在真实业务场景中组合运用Spring Boot各类组件的方法提高后端开发效率与代码质量。1. Spring Boot实战派源码一份能直接启动的后端工程不是 PPT 式的 Demo做后端这几年我下过不少号称“实战派”的资源一半是文档配截图代码根本跑不起来。这份《Spring Boot实战派源码》属于另一类拿到手就是一个完整的可启动工程Spring Boot 版本、依赖、配置、前端静态页都是齐的启动后能直接看到页面和数据交互不是给你一堆散装代码自己拼。课程设计里常见的商城、预约、办公用品管理这类题目基本都能从这套源码里找到能改的底子。它适合两类人一类是课程设计需要交一个能演示的系统另一类是已经写过 Hello World、想照着规范分层抄一套真实后端骨架的开发者。下面我从工程结构讲到改造再讲到排错把这份源码怎么用、坑在哪一次说清。2. 源码目录与核心模块先看懂工程再动手改业务2.1 从 pom.xml 和启动类开始别急着点 Run拿到源码先别急着点 Run。我第一件事永远是打开根目录的 pom.xml确认三件事Spring Boot 版本、Java 版本、依赖有没有锁版本。这套实战派源码的 Spring Boot 版本锁在 2.7.x 这一代这种课程设计向源码十有八九都停在这个版本线上因为稳定、资料多、遇到坑一搜就能找到答案不会一上来就撞上 Spring Boot 3 的 jakarta 命名空间迁移问题。很多初学者喜欢一上来就改版本号比如听说 Spring Boot 3.5 支持虚拟线程就手痒。虚拟线程确实香java21 spring boot 3.5 在配置文件里开spring.threads.virtual.enabledtrue就能用但如果这套源码里有老拦截器、老过滤器或者javax开头的依赖升级会引出一堆兼容问题。我在实际项目里就因为在升级时没留意 Tomcat 与 Undertow 对虚拟线程的支持差异花了两晚上处理连接池超时。所以我的习惯是先用源码自带的版本把流程跑通再谈升级别在第一天就给自己挖坑。启动类的位置也是不少人翻车的地方。Spring Boot 默认扫描启动类所在包及子包如果启动类放在com.example而接口写在com.example.demo没问题反过来就扫描不到。可以看看源码包里的目录常见结构是这样src/main/java/com/example/ ├── config/ // 配置类缓存、WebSocket、CORS ├── controller/ // 接口层 ├── service/ // 业务层 ├── mapper/ // 数据访问层 ├── entity/ // 实体类 └── DemoApplication.java // 启动类这个结构看着简单但它决定了后面所有组件扫描的边界。如果你在别的目录新建了 controller结果接口一直 404先别查业务代码先看启动类在哪个包。这一条能解决一半的“为什么我的接口访问不到”类问题。包里还有resources/static和resources/templates两个目录前者放静态资源后者放模板页面不要搞混否则页面样式的排查会非常痛苦。2.2 三层架构与一次请求的完整流转这套源码内部是标准的 Controller → Service → Mapper 三层。我习惯拿其中一个查询接口当线索把整条链路读通而不是每个文件都看一遍。以源码里的用户查询为例三层各自的职责是这样层职责源码里对应的类Controller接收 HTTP 请求、做参数校验、返回统一结构SysUserControllerService业务逻辑、事务控制、缓存策略SysUserServiceMapperSQL 执行、数据映射SysUserMapper一次请求从 Controller 进入Service 处理业务Mapper 执行 SQL结果再原路返回。你可能觉得这是老生常谈但很多课程设计源码的问题恰恰出在这一层有人把业务逻辑全写在 Controller 里有人 Service 里直接new一个 Mapper 实例而不是注入这些代码跑起来没问题但没法扩展也没法单元测试。我看这套源码比较顺眼的一点是用了构造器注入而不是字段注入。构造器注入的好处是依赖关系明确测试的时候直接new就能传参进来不会出现容器还没启动就一堆 null 的玄学问题。另外如果你在源码里看到循环依赖比如 A Service 注入 B Service、B 又注入 A建议早点拆掉Spring Boot 2.6 之后默认禁止循环依赖启动直接报错这也是我踩过的坑。判断循环依赖有个笨办法看启动日志里有没有The dependencies of some of the beans in the application context form a cycle这句话有就把互相注入的字段改成方法调用或者抽一个中间层。这层还要留意一点 Mapper 的写法。现在这类源码里 MyBatis-Plus 的出场率很高这套里也用到了BaseMapper你会发现不少单表查询没有 XML 文件。这不是代码缺漏而是框架帮你生成了通用 SQL。用LambdaQueryWrapper写条件会比QueryWrapper更安全因为前者是编译期校验字段名后者是字符串重构时字段一改名就翻车。这里先记着后面改造接口时会用到。2.3 配置文件里最值得抄的两个地方多环境与日志级别这套源码的配置分成两份一份开发环境的application-dev.yml一份生产环境的application-prod.yml通过spring.profiles.active切换。这个做法建议直接抄哪怕你只是做课设。因为你很容易遇到这种情况本机 MySQL 密码和别人不一样直接改主配置来回冲突多环境配置一拆就干净了。第二个值得抄的是 spring boot 日志。源码里把日志级别拆到了配置里Controller 层打成 infoMapper 层打成 debug查问题的时候能看到 SQL平时又不会被刷屏。常见做法是logging: level: com.example.mapper: debug com.example.controller: info file: name: logs/spring.logcom.example.mapper: debug的意思是把这个包下的 Mapper 接口日志开到 debug这样控制台和日志文件里能看到每条 SQL 和入参排查慢查询和空结果时非常有用。file.name指定日志落盘路径解决控制台输出被刷新掉、翻不到报错的问题。如果你只是临时验证也可以不改配置文件启动时加--debug参数但那样日志量太大我一般不用。数据量大以后再加上logback-spring.xml做滚动切割按天滚动再保留 30 天这套源码里的基础配置已经够入门阶段用了。注意application.yml里如果同时存在spring.profiles.active: dev和application-dev.ymlSpring Boot 加载配置的逻辑是后者覆盖前者所以环境相关的配置都放进对应 profiles 文件里别散落在主配置里不然后面看配置会疯掉。这也是我接手这套源码后第一眼就检查的东西算是职业病了。3. 实战改造把通用骨架改成你自己的业务3.1 数据库连接从 H2 切到 MySQL这类源码为了演示方便默认数据源往往是 H2 内存库好处是第一次启动零配置就能跑但你要交课设或者部署到服务器必须切成 MySQL。打开application-dev.yml就能确认替换数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver sql: init: mode: neverurl里有几个参数不能省characterEncodingutf8保证中文不乱码serverTimezoneAsia/Shanghai避免 MySQL 8 报时区错误。驱动名要留意MySQL 5.x 用com.mysql.jdbc.DriverMySQL 8 及以上必须换成com.mysql.cj.jdbc.Driver写错直接 ClassNotFoundException。spring.sql.init.modenever表示启动时不自动执行schema.sql和data.sql。如果你不关掉它每次启动都可能重建表甚至清数据等发现数据没了再后悔就晚了。切换完数据源还要确认建表脚本。常见做法是源码里带一份sql/init.sql用命令行先建库再导入mysql -u root -p -e CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARACTER SET utf8mb4; mysql -u root -p shop sql/init.sql第一行创建数据库DEFAULT CHARACTER SET utf8mb4是为了支持 emoji 和生僻字比 utf8 更省心。第二行把表结构和初始化数据导入进去。这一步建议手动做不要依赖 Spring Boot 自动建表原因很简单自动建表虽然方便但表的注释、索引、字段类型常常不合预期后面接 MyBatis-Plus 时会有类型映射的坑。3.2 新增一个业务接口从实体到接口的完整链路改造的第二步是照葫芦画瓢加一个你自己的业务接口。以“用户管理”为例完整链路是实体 → Mapper → Service → Controller我们一步步来。先写实体类Data TableName(sys_user) public class SysUser { TableId(type IdType.AUTO) private Long id; private String username; private String email; private LocalDateTime createTime; }这里用了 Lombok 的Data省去一堆 getter/setter。TableName(sys_user)是 MyBatis-Plus 的注解把实体映射到表TableId(type IdType.AUTO)表示主键自增。如果你不想依赖 MyBatis-Plus也可以写原生 MyBatis 在 XML 里维护 SQL但那样每个单表操作都要写一遍我一般只在多表关联时才用 XML。接着是 Mapperpublic interface SysUserMapper extends BaseMapperSysUser { Select(SELECT * FROM sys_user WHERE username #{username}) SysUser selectByUsername(String username); }extends BaseMapperSysUser让这个接口有了基础的增删改查方法这是 MyBatis-Plus 的常见做法。Select注解直接写在方法上适合简单查询复杂 SQL 建议挪到 XML 里一是便于维护二是方便 DBA 评审。注意#{username}是预编译参数不要写成${username}后者会把参数直接拼进 SQL有注入风险别在这个地方图省事。然后是 ServiceService public class SysUserService { private final SysUserMapper sysUserMapper; public SysUserService(SysUserMapper sysUserMapper) { this.sysUserMapper sysUserMapper; } public SysUser findByUsername(String username) { return sysUserMapper.selectByUsername(username); } }这里用的是构造器注入配合final字段依赖关系在编译期就固定了。注意 Service 接口和实现类在这套源码里没有拆成两个文件。不少教材喜欢接口/实现分离但真实项目里如果只有一个实现拆开反而增加理解成本这也是为什么这套源码直接写一个类而不是两个属于实战里的取舍。最后是 ControllerRestController RequestMapping(/api/user) public class SysUserController { private final SysUserService sysUserService; public SysUserController(SysUserService sysUserService) { this.sysUserService sysUserService; } GetMapping(/{username}) public ResultSysUser getUser(PathVariable String username) { return Result.ok(sysUserService.findByUsername(username)); } }RestController表示所有方法返回 JSON不用再在方法上写ResponseBody。ResultSysUser是统一返回结构我一般的习惯是让它至少包含code、message、data三个字段这样前端拦截器可以统一处理登录失效和业务错误码。上面的GetMapping(/{username})是 REST 风格路径参数URL 形如/api/user/admin。如果你更习惯/api/user?usernameadmin这种写法把注解改成GetMapping然后加一个RequestParam String username就行两者都能跑但路径参数在 REST 语义和缓存命中上更有优势。3.3 集成常用组件caffeine 缓存与 WebSocket 配置改造过程中两个组件被问得最多缓存和 WebSocket。先说缓存。如果你的接口每次查询都打数据库哪怕只是几千条数据的小系统压测时也容易把连接池打满。常见做法是把热点数据缓存到本地这里用 Caffeine可以理解成 Guava Cache 的升级版。配置如下Configuration EnableCaching public class CacheConfig { Bean public CacheManager cacheManager() { CaffeineObject, Object caffeine Caffeine.newBuilder() .maximumSize(500) .expireAfterWrite(Duration.ofMinutes(10)); CaffeineCacheManager manager new CaffeineCacheManager(user, order); manager.setCaffeine(caffeine); return manager; } }maximumSize(500)是缓存最多放 500 个 key超出后按近似 LRU 淘汰expireAfterWrite(Duration.ofMinutes(10))表示写入 10 分钟后过期。对于课设和中小系统这个配置够用。如果你希望缓存淘汰更积极把maximumSize调小比如 100内存占用会更低。启用后在 Service 方法上加上Cacheable(cacheNames user, key #username)Spring 就会先查缓存再查数据库这是缓存接入最省事的方式。再说 WebSocket。我看到很多人在网上搜 “spring boot 集成 web socket yml 配置”这里提醒一句Spring Boot 的标准 Starter 里没有spring.websocket.path这类配置网上那些直接写在 yml 里的写法大多是自定义属性别照抄。最常见的做法是用 Java 配置注册一个 WebSocket 端点Configuration public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(new ChatHandler(), /ws/chat) .setAllowedOrigins(*); } }addHandler的第一个参数是自定义的消息处理器第二个参数是握手路径。setAllowedOrigins(*)表示允许所有来源跨域连接本地调试很方便。注意这个*在 Spring Boot 2.7 里能用但如果以后把源码升到 Spring Boot 3.1 及以上通配符会被拒绝必须写具体的来源域名否则浏览器握手阶段直接 403 失败。如果使用注解版ServerEndpoint的写法则还需要注入ServerEndpointExporter的Bean否则端点根本不会注册Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); }两个方案都能用Spring Boot 2.7 时代我推荐WebSocketConfigurer方式路径和控制逻辑都集中在一个配置类里比较好排错。注解方式适合从 Java EE 时代过来的老手但你要是第一次做 WebSocket建议老老实实用配置类。3.4 文件上传与 MinIO 集成的常见做法很多课设系统都绕不开文件上传头像、图片、附件都要落地。最省事的办法是传到本地目录但部署到服务器后重启或扩容时文件容易丢所以我一般建议直接引 MinIO。它虽然是独立服务但源码里集成很简单。先在application.yml里写配置这是自定义属性不是 Spring Boot 标准配置minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: course-design再用ConfigurationProperties读取Component ConfigurationProperties(prefix minio) public class MinioProperties { private String endpoint; private String accessKey; private String secretKey; private String bucket; // getter/setter 略 }prefix minio表示把 yml 里minio前缀下的属性映射到这个类的字段上。endpoint是 MinIO 服务的访问地址如果跑在服务器上要换成内网地址避免走公网来回绕。access-key和secret-key默认都是minioadmin生产环境一定记得改。上传文件的核心逻辑就两步判断 bucket 是否存在不存在就创建然后putObject写文件。配合一个PostMapping(/upload)前端用input typefile就能把文件传上来返回的 URL 直接拼上endpoint和对象名就能访问。这块在整个源码改造里算是最独立的一块放在最后做不影响主流程。4. 避坑与常见问题端口、时区、注入、静态资源、WebSocket4.1 端口被占用启动直接报错现象点击启动后控制台报Port 8080 was already in use应用起不来。原因本地有其他进程占了 8080。常见的是上一次启动没关干净或者 Nginx、其他 Java 服务占用了端口。解决先确认谁占的端口再决定杀掉进程还是换端口。Windows 上netstat -ano | findstr 8080 taskkill /PID 进程号 /FLinux 上lsof -i:8080 kill -9 进程号如果你不想杀进程也可以在application.yml里临时换端口server.port: 8081。注意如果页面或前端代码里写死了 8080换端口后页面访问要同步改否则就会出现后端起来了、浏览器打不开的现象这类问题最容易让人误判成源码坏了。我的习惯是开发阶段固定一个端口不轻易换只有在端口冲突时才临时切。4.2 数据库连不上时区和驱动两个经典报错现象启动报Cannot create PoolableConnectionFactory或者 SQL 执行时报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。原因前者大概率是驱动类名写错或者密码不对。后者是 MySQL 8 的时区校验问题serverTimezone没设置或者设置了但值不认识。解决驱动用com.mysql.cj.jdbc.DriverURL 里加上serverTimezoneAsia/Shanghai这两个条件满足后时区报错基本消失。如果还报检查一下 MySQL 服务和连接串用的版本是否一致比如本机是 MySQL 5.7但代码里按 MySQL 8 写的驱动也会出现兼容问题。这一类问题排查时先看完整错误栈不要只看第一行。常见做法是先把spring.datasource.hikari.connection-timeout调到 3000 毫秒让连接失败快速返回避免启动时卡几分钟才报错这样调试反馈会快很多。4.3 Bean 注入失败启动时一片红现象启动时报No qualifying bean of type xxxMapper available或者Field xxxMapper in com.example.service.XXXService required a bean of type xxxMapper that could not be found。原因Mapper 接口没被扫描到。常见三个原因Mapper 接口没有加Mapper注解启动类没加MapperScan(com.example.mapper)启动类包路径不对导致扫描范围没覆盖到 Mapper 包。三者占了我遇到过的八成以上。解决最简单的方法是给每个 Mapper 接口加Mapper注解一劳永逸或者在启动类上统一加MapperScan(com.example.mapper)。如果加了还报错看看启动类包路径是不是com.example而 Mapper 包是不是在com.example.demo.mapper这类路径错位问题改注解没用要把启动类往上挪一层或者调整包的归属关系。还有一个容易被忽略的点如果 Service 里用了private final字段加构造器注入而这个 Service 没加Service注解同样会报找不到 Bean。所以报错时先看是不是类上的注解丢了这是最快的路径。4.4 静态资源 404页面样式全丢现象接口能通HTML 页面能打开但 CSS、JS、图片全部 404页面看起来像没穿衣服。原因静态资源没放在 Spring Boot 默认扫描的位置或者被拦截器拦了。Spring Boot 默认从classpath:/static/、classpath:/public/、classpath:/resources/、classpath:/META-INF/resources/加载静态资源很多人把static目录建在了src/main/java下面那当然找不到。解决把静态文件挪到src/main/resources/static/下重启再试。如果文件位置没问题还 404检查是不是引入了 Spring Security 或者自定义拦截器。常见做法是在 Security 配置里放行静态路径Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers(/static/**, /css/**, /js/**, /images/**).permitAll() .anyRequest().authenticated(); }注意这是 Spring Boot 2.7 的写法WebSecurityConfigurerAdapter在 Spring Security 5.7 之后标记废弃Spring Boot 3 直接移除需要改成 SecurityFilterChain 的 Bean 方式这也是网上很多老代码在 Spring Boot 3 上编译不过的原因。如果你不想动安全配置资源访问被拦时可以先临时放行确认是拦截器问题再收紧别一上来就怀疑源码缺文件。4.5 WebSocket 握手 403升级后的通配符失效现象前端new WebSocket(ws://localhost:8080/ws/chat)一直报 403后端没有明显报错只有握手失败记录。原因本地调试时setAllowedOrigins(*)在 Spring Boot 2.7 没问题但升级到 3.1 以后Spring 对 allowed origins 的校验收紧通配符*不能再用于setAllowedOrigins。解决开发环境换成具体 originregistry.addHandler(new ChatHandler(), /ws/chat) .setAllowedOrigins(http://localhost:5173);前端地址是http://localhost:5173就写这个不要写*。如果你确实要允许所有来源可以用setAllowedOriginPatterns(*)这个是特意为通配符场景保留的 API语义上和setAllowedOrigins有区别。这个坑在源码自带的 2.7 环境里不会出现但一旦你动了升级的念头大概率会碰上先记下来到时候少走弯路。5. 进阶验证用 curl、日志和压测确认改造没改坏改完源码先别急着打开浏览器一顿点。我的习惯是先跑一遍接口验证三件套curl 看响应、日志看细节、压测看会不会崩。先拿刚才新增的用户接口练手curl -X GET http://localhost:8080/api/user/admin \ -H Content-Type: application/json \ -w \nHTTP_CODE:%{http_code}\n-w参数会在请求结束后打印额外信息这里用来输出 HTTP 状态码。返回 JSON 里有数据且HTTP_CODE:200说明接口通了。如果返回 404先查路径对不对返回 500立刻去日志文件里翻异常栈tail -f logs/spring.log就能实时看到不需要重新启动应用。然后确认 SQL 有没有按预期执行。因为配置里 Mapper 层是 debug 日志日志里会看到 MyBatis 打印的 Preparing和 Parameters两行前者是最终执行的 SQL 模板后者是绑定参数。看到这两行说明 Mapper 链路没问题。最后做一次轻量压测确认缓存和连接池扛得住ab -n 200 -c 20 http://localhost:8080/api/user/admin-n 200表示总共发 200 个请求-c 20表示并发 20。重点看两个指标Requests per second代表吞吐Failed requests必须为 0。如果你加了 Caffeine 缓存第二次压测的吞吐应该明显高于第一次这个对比就是缓存生效的直接证据。并发压测过程中如果出现Connection refused多半是数据库连接池太小或者服务本身扛不住这时候看一眼 Hikari 的配置再决定调maximum-pool-size还是优化 SQL。数据库连接池参数小项目 10 到 20 够用别一上来就调到 100连接池不是越大越好反而会把数据库拖垮。顺便说下我自己的习惯。自从有一次改完接口忘了重启、测试时拿旧代码跑却死活 debug 不进断点之后我每次改完源码都强制走一遍这个流程curl 验证新增接口grep 日志确认 SQL 与参数再快速压 200 个请求看失败数。这套流程半小时内就能跑完能挡住一大半“改完就崩”的问题。这套《Spring Boot实战派源码》我也用同样的流程验证过整体工程结构值得参考照着改业务比从头搭省不少事。希望帮到你。本文还有配套的精品资源点击获取 Spring Boot实战派源码：工程结构、改造与避坑指南
简介《Spring Boot实战派》配套源码面向Java后端开发者和Spring Boot学习者帮助你从实际代码中理解框架的核心机制与项目落地方式。压缩包共包含10124个文件大小约103MB以java源码、xml配置、properties属性文件、html页面和class编译产物为主完整覆盖书籍所涉及的多模块工程结构。目前已有1152人学习/下载。源码内容涵盖自动配置、起步依赖、嵌入式Web服务器、健康检查与Actuator、RESTful API开发、JPA/Hibernate数据访问、Spring Security权限控制、配置管理、集成测试、定时任务、RabbitMQ/Kafka消息集成、Redis缓存、国际化、邮件服务及Docker/Kubernetes云原生等主题每个主题都有可运行的示例代码。通过分析这些代码读者能掌握在真实业务场景中组合运用Spring Boot各类组件的方法提高后端开发效率与代码质量。1. Spring Boot实战派源码一份能直接启动的后端工程不是 PPT 式的 Demo做后端这几年我下过不少号称“实战派”的资源一半是文档配截图代码根本跑不起来。这份《Spring Boot实战派源码》属于另一类拿到手就是一个完整的可启动工程Spring Boot 版本、依赖、配置、前端静态页都是齐的启动后能直接看到页面和数据交互不是给你一堆散装代码自己拼。课程设计里常见的商城、预约、办公用品管理这类题目基本都能从这套源码里找到能改的底子。它适合两类人一类是课程设计需要交一个能演示的系统另一类是已经写过 Hello World、想照着规范分层抄一套真实后端骨架的开发者。下面我从工程结构讲到改造再讲到排错把这份源码怎么用、坑在哪一次说清。2. 源码目录与核心模块先看懂工程再动手改业务2.1 从 pom.xml 和启动类开始别急着点 Run拿到源码先别急着点 Run。我第一件事永远是打开根目录的 pom.xml确认三件事Spring Boot 版本、Java 版本、依赖有没有锁版本。这套实战派源码的 Spring Boot 版本锁在 2.7.x 这一代这种课程设计向源码十有八九都停在这个版本线上因为稳定、资料多、遇到坑一搜就能找到答案不会一上来就撞上 Spring Boot 3 的 jakarta 命名空间迁移问题。很多初学者喜欢一上来就改版本号比如听说 Spring Boot 3.5 支持虚拟线程就手痒。虚拟线程确实香java21 spring boot 3.5 在配置文件里开spring.threads.virtual.enabledtrue就能用但如果这套源码里有老拦截器、老过滤器或者javax开头的依赖升级会引出一堆兼容问题。我在实际项目里就因为在升级时没留意 Tomcat 与 Undertow 对虚拟线程的支持差异花了两晚上处理连接池超时。所以我的习惯是先用源码自带的版本把流程跑通再谈升级别在第一天就给自己挖坑。启动类的位置也是不少人翻车的地方。Spring Boot 默认扫描启动类所在包及子包如果启动类放在com.example而接口写在com.example.demo没问题反过来就扫描不到。可以看看源码包里的目录常见结构是这样src/main/java/com/example/ ├── config/ // 配置类缓存、WebSocket、CORS ├── controller/ // 接口层 ├── service/ // 业务层 ├── mapper/ // 数据访问层 ├── entity/ // 实体类 └── DemoApplication.java // 启动类这个结构看着简单但它决定了后面所有组件扫描的边界。如果你在别的目录新建了 controller结果接口一直 404先别查业务代码先看启动类在哪个包。这一条能解决一半的“为什么我的接口访问不到”类问题。包里还有resources/static和resources/templates两个目录前者放静态资源后者放模板页面不要搞混否则页面样式的排查会非常痛苦。2.2 三层架构与一次请求的完整流转这套源码内部是标准的 Controller → Service → Mapper 三层。我习惯拿其中一个查询接口当线索把整条链路读通而不是每个文件都看一遍。以源码里的用户查询为例三层各自的职责是这样层职责源码里对应的类Controller接收 HTTP 请求、做参数校验、返回统一结构SysUserControllerService业务逻辑、事务控制、缓存策略SysUserServiceMapperSQL 执行、数据映射SysUserMapper一次请求从 Controller 进入Service 处理业务Mapper 执行 SQL结果再原路返回。你可能觉得这是老生常谈但很多课程设计源码的问题恰恰出在这一层有人把业务逻辑全写在 Controller 里有人 Service 里直接new一个 Mapper 实例而不是注入这些代码跑起来没问题但没法扩展也没法单元测试。我看这套源码比较顺眼的一点是用了构造器注入而不是字段注入。构造器注入的好处是依赖关系明确测试的时候直接new就能传参进来不会出现容器还没启动就一堆 null 的玄学问题。另外如果你在源码里看到循环依赖比如 A Service 注入 B Service、B 又注入 A建议早点拆掉Spring Boot 2.6 之后默认禁止循环依赖启动直接报错这也是我踩过的坑。判断循环依赖有个笨办法看启动日志里有没有The dependencies of some of the beans in the application context form a cycle这句话有就把互相注入的字段改成方法调用或者抽一个中间层。这层还要留意一点 Mapper 的写法。现在这类源码里 MyBatis-Plus 的出场率很高这套里也用到了BaseMapper你会发现不少单表查询没有 XML 文件。这不是代码缺漏而是框架帮你生成了通用 SQL。用LambdaQueryWrapper写条件会比QueryWrapper更安全因为前者是编译期校验字段名后者是字符串重构时字段一改名就翻车。这里先记着后面改造接口时会用到。2.3 配置文件里最值得抄的两个地方多环境与日志级别这套源码的配置分成两份一份开发环境的application-dev.yml一份生产环境的application-prod.yml通过spring.profiles.active切换。这个做法建议直接抄哪怕你只是做课设。因为你很容易遇到这种情况本机 MySQL 密码和别人不一样直接改主配置来回冲突多环境配置一拆就干净了。第二个值得抄的是 spring boot 日志。源码里把日志级别拆到了配置里Controller 层打成 infoMapper 层打成 debug查问题的时候能看到 SQL平时又不会被刷屏。常见做法是logging: level: com.example.mapper: debug com.example.controller: info file: name: logs/spring.logcom.example.mapper: debug的意思是把这个包下的 Mapper 接口日志开到 debug这样控制台和日志文件里能看到每条 SQL 和入参排查慢查询和空结果时非常有用。file.name指定日志落盘路径解决控制台输出被刷新掉、翻不到报错的问题。如果你只是临时验证也可以不改配置文件启动时加--debug参数但那样日志量太大我一般不用。数据量大以后再加上logback-spring.xml做滚动切割按天滚动再保留 30 天这套源码里的基础配置已经够入门阶段用了。注意application.yml里如果同时存在spring.profiles.active: dev和application-dev.ymlSpring Boot 加载配置的逻辑是后者覆盖前者所以环境相关的配置都放进对应 profiles 文件里别散落在主配置里不然后面看配置会疯掉。这也是我接手这套源码后第一眼就检查的东西算是职业病了。3. 实战改造把通用骨架改成你自己的业务3.1 数据库连接从 H2 切到 MySQL这类源码为了演示方便默认数据源往往是 H2 内存库好处是第一次启动零配置就能跑但你要交课设或者部署到服务器必须切成 MySQL。打开application-dev.yml就能确认替换数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver sql: init: mode: neverurl里有几个参数不能省characterEncodingutf8保证中文不乱码serverTimezoneAsia/Shanghai避免 MySQL 8 报时区错误。驱动名要留意MySQL 5.x 用com.mysql.jdbc.DriverMySQL 8 及以上必须换成com.mysql.cj.jdbc.Driver写错直接 ClassNotFoundException。spring.sql.init.modenever表示启动时不自动执行schema.sql和data.sql。如果你不关掉它每次启动都可能重建表甚至清数据等发现数据没了再后悔就晚了。切换完数据源还要确认建表脚本。常见做法是源码里带一份sql/init.sql用命令行先建库再导入mysql -u root -p -e CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARACTER SET utf8mb4; mysql -u root -p shop sql/init.sql第一行创建数据库DEFAULT CHARACTER SET utf8mb4是为了支持 emoji 和生僻字比 utf8 更省心。第二行把表结构和初始化数据导入进去。这一步建议手动做不要依赖 Spring Boot 自动建表原因很简单自动建表虽然方便但表的注释、索引、字段类型常常不合预期后面接 MyBatis-Plus 时会有类型映射的坑。3.2 新增一个业务接口从实体到接口的完整链路改造的第二步是照葫芦画瓢加一个你自己的业务接口。以“用户管理”为例完整链路是实体 → Mapper → Service → Controller我们一步步来。先写实体类Data TableName(sys_user) public class SysUser { TableId(type IdType.AUTO) private Long id; private String username; private String email; private LocalDateTime createTime; }这里用了 Lombok 的Data省去一堆 getter/setter。TableName(sys_user)是 MyBatis-Plus 的注解把实体映射到表TableId(type IdType.AUTO)表示主键自增。如果你不想依赖 MyBatis-Plus也可以写原生 MyBatis 在 XML 里维护 SQL但那样每个单表操作都要写一遍我一般只在多表关联时才用 XML。接着是 Mapperpublic interface SysUserMapper extends BaseMapperSysUser { Select(SELECT * FROM sys_user WHERE username #{username}) SysUser selectByUsername(String username); }extends BaseMapperSysUser让这个接口有了基础的增删改查方法这是 MyBatis-Plus 的常见做法。Select注解直接写在方法上适合简单查询复杂 SQL 建议挪到 XML 里一是便于维护二是方便 DBA 评审。注意#{username}是预编译参数不要写成${username}后者会把参数直接拼进 SQL有注入风险别在这个地方图省事。然后是 ServiceService public class SysUserService { private final SysUserMapper sysUserMapper; public SysUserService(SysUserMapper sysUserMapper) { this.sysUserMapper sysUserMapper; } public SysUser findByUsername(String username) { return sysUserMapper.selectByUsername(username); } }这里用的是构造器注入配合final字段依赖关系在编译期就固定了。注意 Service 接口和实现类在这套源码里没有拆成两个文件。不少教材喜欢接口/实现分离但真实项目里如果只有一个实现拆开反而增加理解成本这也是为什么这套源码直接写一个类而不是两个属于实战里的取舍。最后是 ControllerRestController RequestMapping(/api/user) public class SysUserController { private final SysUserService sysUserService; public SysUserController(SysUserService sysUserService) { this.sysUserService sysUserService; } GetMapping(/{username}) public ResultSysUser getUser(PathVariable String username) { return Result.ok(sysUserService.findByUsername(username)); } }RestController表示所有方法返回 JSON不用再在方法上写ResponseBody。ResultSysUser是统一返回结构我一般的习惯是让它至少包含code、message、data三个字段这样前端拦截器可以统一处理登录失效和业务错误码。上面的GetMapping(/{username})是 REST 风格路径参数URL 形如/api/user/admin。如果你更习惯/api/user?usernameadmin这种写法把注解改成GetMapping然后加一个RequestParam String username就行两者都能跑但路径参数在 REST 语义和缓存命中上更有优势。3.3 集成常用组件caffeine 缓存与 WebSocket 配置改造过程中两个组件被问得最多缓存和 WebSocket。先说缓存。如果你的接口每次查询都打数据库哪怕只是几千条数据的小系统压测时也容易把连接池打满。常见做法是把热点数据缓存到本地这里用 Caffeine可以理解成 Guava Cache 的升级版。配置如下Configuration EnableCaching public class CacheConfig { Bean public CacheManager cacheManager() { CaffeineObject, Object caffeine Caffeine.newBuilder() .maximumSize(500) .expireAfterWrite(Duration.ofMinutes(10)); CaffeineCacheManager manager new CaffeineCacheManager(user, order); manager.setCaffeine(caffeine); return manager; } }maximumSize(500)是缓存最多放 500 个 key超出后按近似 LRU 淘汰expireAfterWrite(Duration.ofMinutes(10))表示写入 10 分钟后过期。对于课设和中小系统这个配置够用。如果你希望缓存淘汰更积极把maximumSize调小比如 100内存占用会更低。启用后在 Service 方法上加上Cacheable(cacheNames user, key #username)Spring 就会先查缓存再查数据库这是缓存接入最省事的方式。再说 WebSocket。我看到很多人在网上搜 “spring boot 集成 web socket yml 配置”这里提醒一句Spring Boot 的标准 Starter 里没有spring.websocket.path这类配置网上那些直接写在 yml 里的写法大多是自定义属性别照抄。最常见的做法是用 Java 配置注册一个 WebSocket 端点Configuration public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(new ChatHandler(), /ws/chat) .setAllowedOrigins(*); } }addHandler的第一个参数是自定义的消息处理器第二个参数是握手路径。setAllowedOrigins(*)表示允许所有来源跨域连接本地调试很方便。注意这个*在 Spring Boot 2.7 里能用但如果以后把源码升到 Spring Boot 3.1 及以上通配符会被拒绝必须写具体的来源域名否则浏览器握手阶段直接 403 失败。如果使用注解版ServerEndpoint的写法则还需要注入ServerEndpointExporter的Bean否则端点根本不会注册Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); }两个方案都能用Spring Boot 2.7 时代我推荐WebSocketConfigurer方式路径和控制逻辑都集中在一个配置类里比较好排错。注解方式适合从 Java EE 时代过来的老手但你要是第一次做 WebSocket建议老老实实用配置类。3.4 文件上传与 MinIO 集成的常见做法很多课设系统都绕不开文件上传头像、图片、附件都要落地。最省事的办法是传到本地目录但部署到服务器后重启或扩容时文件容易丢所以我一般建议直接引 MinIO。它虽然是独立服务但源码里集成很简单。先在application.yml里写配置这是自定义属性不是 Spring Boot 标准配置minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: course-design再用ConfigurationProperties读取Component ConfigurationProperties(prefix minio) public class MinioProperties { private String endpoint; private String accessKey; private String secretKey; private String bucket; // getter/setter 略 }prefix minio表示把 yml 里minio前缀下的属性映射到这个类的字段上。endpoint是 MinIO 服务的访问地址如果跑在服务器上要换成内网地址避免走公网来回绕。access-key和secret-key默认都是minioadmin生产环境一定记得改。上传文件的核心逻辑就两步判断 bucket 是否存在不存在就创建然后putObject写文件。配合一个PostMapping(/upload)前端用input typefile就能把文件传上来返回的 URL 直接拼上endpoint和对象名就能访问。这块在整个源码改造里算是最独立的一块放在最后做不影响主流程。4. 避坑与常见问题端口、时区、注入、静态资源、WebSocket4.1 端口被占用启动直接报错现象点击启动后控制台报Port 8080 was already in use应用起不来。原因本地有其他进程占了 8080。常见的是上一次启动没关干净或者 Nginx、其他 Java 服务占用了端口。解决先确认谁占的端口再决定杀掉进程还是换端口。Windows 上netstat -ano | findstr 8080 taskkill /PID 进程号 /FLinux 上lsof -i:8080 kill -9 进程号如果你不想杀进程也可以在application.yml里临时换端口server.port: 8081。注意如果页面或前端代码里写死了 8080换端口后页面访问要同步改否则就会出现后端起来了、浏览器打不开的现象这类问题最容易让人误判成源码坏了。我的习惯是开发阶段固定一个端口不轻易换只有在端口冲突时才临时切。4.2 数据库连不上时区和驱动两个经典报错现象启动报Cannot create PoolableConnectionFactory或者 SQL 执行时报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。原因前者大概率是驱动类名写错或者密码不对。后者是 MySQL 8 的时区校验问题serverTimezone没设置或者设置了但值不认识。解决驱动用com.mysql.cj.jdbc.DriverURL 里加上serverTimezoneAsia/Shanghai这两个条件满足后时区报错基本消失。如果还报检查一下 MySQL 服务和连接串用的版本是否一致比如本机是 MySQL 5.7但代码里按 MySQL 8 写的驱动也会出现兼容问题。这一类问题排查时先看完整错误栈不要只看第一行。常见做法是先把spring.datasource.hikari.connection-timeout调到 3000 毫秒让连接失败快速返回避免启动时卡几分钟才报错这样调试反馈会快很多。4.3 Bean 注入失败启动时一片红现象启动时报No qualifying bean of type xxxMapper available或者Field xxxMapper in com.example.service.XXXService required a bean of type xxxMapper that could not be found。原因Mapper 接口没被扫描到。常见三个原因Mapper 接口没有加Mapper注解启动类没加MapperScan(com.example.mapper)启动类包路径不对导致扫描范围没覆盖到 Mapper 包。三者占了我遇到过的八成以上。解决最简单的方法是给每个 Mapper 接口加Mapper注解一劳永逸或者在启动类上统一加MapperScan(com.example.mapper)。如果加了还报错看看启动类包路径是不是com.example而 Mapper 包是不是在com.example.demo.mapper这类路径错位问题改注解没用要把启动类往上挪一层或者调整包的归属关系。还有一个容易被忽略的点如果 Service 里用了private final字段加构造器注入而这个 Service 没加Service注解同样会报找不到 Bean。所以报错时先看是不是类上的注解丢了这是最快的路径。4.4 静态资源 404页面样式全丢现象接口能通HTML 页面能打开但 CSS、JS、图片全部 404页面看起来像没穿衣服。原因静态资源没放在 Spring Boot 默认扫描的位置或者被拦截器拦了。Spring Boot 默认从classpath:/static/、classpath:/public/、classpath:/resources/、classpath:/META-INF/resources/加载静态资源很多人把static目录建在了src/main/java下面那当然找不到。解决把静态文件挪到src/main/resources/static/下重启再试。如果文件位置没问题还 404检查是不是引入了 Spring Security 或者自定义拦截器。常见做法是在 Security 配置里放行静态路径Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers(/static/**, /css/**, /js/**, /images/**).permitAll() .anyRequest().authenticated(); }注意这是 Spring Boot 2.7 的写法WebSecurityConfigurerAdapter在 Spring Security 5.7 之后标记废弃Spring Boot 3 直接移除需要改成 SecurityFilterChain 的 Bean 方式这也是网上很多老代码在 Spring Boot 3 上编译不过的原因。如果你不想动安全配置资源访问被拦时可以先临时放行确认是拦截器问题再收紧别一上来就怀疑源码缺文件。4.5 WebSocket 握手 403升级后的通配符失效现象前端new WebSocket(ws://localhost:8080/ws/chat)一直报 403后端没有明显报错只有握手失败记录。原因本地调试时setAllowedOrigins(*)在 Spring Boot 2.7 没问题但升级到 3.1 以后Spring 对 allowed origins 的校验收紧通配符*不能再用于setAllowedOrigins。解决开发环境换成具体 originregistry.addHandler(new ChatHandler(), /ws/chat) .setAllowedOrigins(http://localhost:5173);前端地址是http://localhost:5173就写这个不要写*。如果你确实要允许所有来源可以用setAllowedOriginPatterns(*)这个是特意为通配符场景保留的 API语义上和setAllowedOrigins有区别。这个坑在源码自带的 2.7 环境里不会出现但一旦你动了升级的念头大概率会碰上先记下来到时候少走弯路。5. 进阶验证用 curl、日志和压测确认改造没改坏改完源码先别急着打开浏览器一顿点。我的习惯是先跑一遍接口验证三件套curl 看响应、日志看细节、压测看会不会崩。先拿刚才新增的用户接口练手curl -X GET http://localhost:8080/api/user/admin \ -H Content-Type: application/json \ -w \nHTTP_CODE:%{http_code}\n-w参数会在请求结束后打印额外信息这里用来输出 HTTP 状态码。返回 JSON 里有数据且HTTP_CODE:200说明接口通了。如果返回 404先查路径对不对返回 500立刻去日志文件里翻异常栈tail -f logs/spring.log就能实时看到不需要重新启动应用。然后确认 SQL 有没有按预期执行。因为配置里 Mapper 层是 debug 日志日志里会看到 MyBatis 打印的 Preparing和 Parameters两行前者是最终执行的 SQL 模板后者是绑定参数。看到这两行说明 Mapper 链路没问题。最后做一次轻量压测确认缓存和连接池扛得住ab -n 200 -c 20 http://localhost:8080/api/user/admin-n 200表示总共发 200 个请求-c 20表示并发 20。重点看两个指标Requests per second代表吞吐Failed requests必须为 0。如果你加了 Caffeine 缓存第二次压测的吞吐应该明显高于第一次这个对比就是缓存生效的直接证据。并发压测过程中如果出现Connection refused多半是数据库连接池太小或者服务本身扛不住这时候看一眼 Hikari 的配置再决定调maximum-pool-size还是优化 SQL。数据库连接池参数小项目 10 到 20 够用别一上来就调到 100连接池不是越大越好反而会把数据库拖垮。顺便说下我自己的习惯。自从有一次改完接口忘了重启、测试时拿旧代码跑却死活 debug 不进断点之后我每次改完源码都强制走一遍这个流程curl 验证新增接口grep 日志确认 SQL 与参数再快速压 200 个请求看失败数。这套流程半小时内就能跑完能挡住一大半“改完就崩”的问题。这套《Spring Boot实战派源码》我也用同样的流程验证过整体工程结构值得参考照着改业务比从头搭省不少事。希望帮到你。本文还有配套的精品资源点击获取