聊聊我用SpringBoot从零搭建动漫社区这件事事情的起因其实很偶然。有天晚上我在漫友群里看到有人在抱怨说现在的讨论阵地太散了新番情报在微博、长评在贴吧、二创在B站、老番考据散落在各种论坛的角落里想找一个能集中聊动漫的地方越来越难。群里你一句我一句地聊到半夜最后不知道怎么的就变成了要不我们自己做个平台吧。于是就有了这个基于SpringBoot的动漫爱好者在线讨论与分享平台。从需求梳理到技术选型从数据库设计到核心功能落地从本地调试到打包部署前前后后折腾了两个多月。这篇文章不打算写成一个标准的技术教程而是想把这个项目从0到1的完整决策过程、实现细节、以及那些误打误撞踩出来的坑原原本本分享出来。如果你也打算做一个类似的社区类项目或者正在准备SpringBoot相关的毕设/个人项目这应该是我能给出的最有用的一份参考。1. 平台定位与需求拆解动手前先把要做什么想透1.1 用户画像与核心诉求很多做社区类项目的人一上来就急着建表写接口结果做到一半发现功能失控或者做完了一个什么都有但什么都不好用的平台。我在项目启动前做了一个简单的用户画像分析。这个平台的核心用户大致分三类。第一类是学生党时间充裕追番量很大喜欢实时讨论剧情走向也喜欢分享自己的画作和剪辑。第二类是上班族碎片化时间刷手机需要快速了解新番评价和老番补番建议偶尔参与评论区互动。第三类是考据党对作品的世界观、声优、制作公司等细节有浓厚兴趣愿意生产高质量的图文内容。这三类人对平台的核心诉求其实高度一致找到同好、聊到具体内容、方便地分享与收藏。区别在于表达方式的深浅——学生党偏好短平快的讨论帖考据党需要支持长文和多图。1.2 功能清单的收敛哪些必须有哪些先砍掉基于核心诉求我把功能清单拆成了三层。第一层是基石功能没有它们平台就不成立用户注册登录、动漫条目库、发帖与讨论、评论与回复、点赞与收藏、个人主页。第二层是体验增强功能关注与粉丝、标签体系、热门榜单、内容搜索。第三层是原本想做但最终决定砍掉或延期的实时聊天室需要WebSocket且维护成本高、个性化推荐算法冷启动数据不够、弹幕功能跟前端渲染深度耦合、积分签到对社区氛围没有本质帮助。这个收敛过程非常重要。一个个人项目如果同时做三层功能大概率每层都做不深。我当时的原则是第一层必须打磨到能用、好用第二层挑选两到三个做深第三层只在数据库设计阶段预留字段和接口位置不实际开发。后来事实证明确实应该这样做。核心功能做到位以后第二层里我重点做了标签体系和热门榜单这两块在演示和日常使用中的存在感远高于当初设想的聊天室。1.3 为什么是SpringBoot而不是Python或Node技术选型是我纠结最久的一件事。当时摆在面前的方案有几个Python的Django/Flask、Node.js的Express、Java的SpringBoot以及传统SSM框架。最终选择SpringBoot理由有三点。第一这类社区平台本质上就是业务系统用户管理、内容管理、权限校验、数据统计这些恰恰是Java生态最成熟的领域。SpringBoot把这些能力的接入成本压到了极低一个starter依赖加一行注解就能获得完整能力。第二生态覆盖面广做论坛类的所有基础设施几乎都有现成方案比如鉴权、缓存、定时任务、搜索引擎、消息队列后续想扩展什么功能都接得进去。第三实际就业和面试的需求Java后端岗位对SpringBoot的要求几乎是明牌做这个项目的同时可以把自动装配原理、常用注解、事务机制这些后端硬通货一并吃透。对比来看Django开发效率确实高但在一台低配学生服务器上长期运行Java应用的内存和稳定性控制其实更让我放心。Node.js做高并发IO很强但社区平台的关键不在于IO吞吐而在于业务逻辑的清晰和数据的可维护性这一点SpringBoot的工程化优势非常明显。至于SSM——没有SpringBoot的时候我也用SSM写过东西对比之下你就会明白SpringBoot省掉的那几十行XML配置对后期维护来说有多宝贵。2. 技术选型与版本决策SpringBoot版本背后的门道2.1 版本选择2.7.x是稳妥之选项目开始前Spring Boot 3.x已经发布但经过一番调研我最终选了Spring Boot 2.7.18。原因如下。3.x系列强制要求JDK 17及以上而当时我的服务器上跑的是JDK 8。虽然可以在本地用新版本开发但部署环境的成本是实实在在的。2.7.x是SpringBoot 2.x的最后一个版本属于长期维护的终点站修过的稳定性和安全漏洞的数量是最多的。另外我当时计划引入的一些中间件客户端官方对3.x的适配还没有完全覆盖如果都升级到能兼容SpringBoot 3的版本等于把周边依赖整体换成一遍出问题的面积太大了。对比项Spring Boot 2.7.xSpring Boot 3.x最低JDK版本JDK 8JDK 17Jakarta EE规范javax.*jakarta.*周边starter兼容性绝大多数中间件稳定适配部分组件需要等待适配学习参考资料量极多踩坑经验好搜相对少一些适合场景部署环境以JDK8为主、追求稳定新项目且环境允许JDK17顺便说一句开发工具也很关键。直接用IDEA的Spring Initializr创建项目时会根据你选的SpringBoot版本自动匹配依赖版本这时候注意别无脑选最新版。我见过不少同学用JDK 21配SpringBoot 2.3编译都过不去这就是版本组合的基础功课没做好。如果你本机的JDK版本比较新但项目要用JDK 8编译记得在IDEA里把Project Structure和Settings里的Java编译器目标版本全部改成8这样才不会出现代码能跑但打包出来运行报错的尴尬。2.2 MySQL和Redis的职责边界社区类项目的数据存储我最终用了MySQL Redis的组合这也是国内中小型项目的标准答案。MySQL负责的是所有需要持久化、需要事务保障的业务数据用户信息、帖子内容、评论、关注关系、收藏记录。Redis负责的是三类高频读写的场景。第一类是缓存比如用户信息缓存、首页热门帖子缓存减少数据库重复查询。第二类是计数器和去重集合比如帖子点赞数、用户是否已点赞的判断。第三类是临时性数据比如图片验证码、登录状态token。这里有一个关键判断标准什么数据该进Redis、什么数据该留在MySQL不以访问量高不高唯一标准而是看数据丢失后的影响。点赞数如果因为Redis故障丢了一小部分补齐的难度还能接受所以可以先用Redis。但用户余额、订单这类数据如果一个字节都不能丢就必须靠MySQL的事务机制保证。对社区平台来说帖子正文和评论内容属于高价值数据必须直接落到MySQLRedis里的缓存副本可以随时丢弃重建这个责任边界要非常清楚。2.3 单体优先别在起步阶段就想着微服务我在设计架构时反复说服自己绝对不上微服务。这里的逻辑不复杂。微服务解决的是组织协作和独立扩展的问题对应的是多个团队维护多个模块的场景。个人项目或者课程设计一个人维护一个代码库单体应用加合理的模块分包扩展性和维护性完全够。强行上Spring Cloud Alibaba那套注册中心、网关、配置中心只会把大量时间消耗在基础设施的调试上核心业务功能迟迟没法推进。单体架构下我做了清晰的分层约定controller层只做参数接收和简单校验service层承载业务逻辑和事务边界mapper层专职数据访问缓存entity只做表映射dto专注接口出入参定义config统一管理配置类。这个约定在项目变大时就是救命的稻草至少我后期往里面加功能时很清楚每一段代码应该放在哪个包里。不过单体不等于不做扩展预留。在Service接口设计时我刻意避免了把具体实现类写死在调用处而是依赖接口编程。这样将来真要拆出独立的搜索服务或者推荐服务只需要替换实现而不用改上游调用逻辑。3. 数据库设计动漫社区的几张核心表怎么演进3.1 用户表与关注关系的边界用户表是整个系统的地基字段设计不复杂但有几个地方我专门做了取舍。基础字段是id、username、password、avatar、signature、role、create_time。password存储的必须是加密后的密文——我用的BCrypt这是Spring Security里默认支持的算法加密时自动加盐验证时无需手动处理盐值。关注关系我单独建了一张follow表字段有id、follower_id、following_id、create_time关键点在于给(follower_id, following_id)建了唯一索引。这样用户重复关注时数据库层面就能拦住。判断我是否已关注他的查询就是走这个唯一索引的一次点查成本极低。这里有一个设计反思。最初我考虑过用粉丝表和关注表两张表记录方便统计粉丝数但做数据一致性的成本马上上来了——每产生一次关注就要往两张表各插一条数据还得处理事务回滚。最终我选择只用一张follow表粉丝数和关注数通过COUNT查询或者Redis计数派生出来。对社区平台来说粉丝数多一点少一点并不那么实时敏感用派生数据完全够用。3.2 帖子、评论与楼中楼的结构设计帖子表是内容系统的重头。字段包括id、user_id、anime_id、title、content、category、status、view_count、like_count、comment_count、create_time、update_time。category字段区分帖子类型比如讨论、分享、求助、考据。status字段用于内容管理比如正常、隐藏、锁定这个字段在社区运营中比很多人想象的重要——遇到引战帖时直接改状态就能沉帖不需要物理删除。评论部分我一开始设计了方案A父评论和子评论分两张表。理由是逻辑清晰一级评论和楼中楼互不干扰。但很快发现一个现实问题查询某个帖子的全部讨论时需要先查出所有一级评论再根据一级评论的id批量查子评论然后还要在内存里组装树形结构。两张表的JOIN操作在这个场景下变得特别别扭。后来改成方案B只用一张评论表包含id、post_id、user_id、parent_id、root_id、reply_to_user_id、content、create_time。parent_id表示直接回复的是哪条评论root_id表示该评论所属的最顶层评论。这样查询时先按post_id和root_id为NULL找出一级评论分页再根据这些一级评论的id集合一次性查出所有子评论最后在Java内存里按root_id和parent_id组装成树。数据库只做两次查询比递归查询的效率高了一个量级。这里有一个容易踩的坑楼层号不等于评论表的总行数。因为用户可能删除自己的评论如果简单地用COUNT(*)算楼层删除后所有后续楼层号都会错位。我在设计时给评论增加了is_deleted字段删除实际上只是伪删除楼层号直接从本楼之上的有效评论数算出这样保证了楼层的稳定性。3.3 动漫条目库与标签体系如果让用户随便填一个动漫名后面的聚合查询就完了。同一个作品可能叫《进击的巨人》也可能叫《Attack on Titan》还可能被用户简写成巨人。所以我在设计时单独建了anime表维护标准条目id、title_cn、title_jp、cover、year、season、status连载/完结、rating。帖子表通过anime_id关联到条目库无论用户发哪个讨论帖都能准确回溯到同一个作品条目下。这个设计带来的直接好处是每个作品的作品详情页可以聚合出该作品下的所有帖子、评论数、讨论热度用户分享补番笔记时也能找到对应条目。标签体系我用了经典的三表设计tag表、post_tag中间表。中间表的联合唯一索引两条腿(id, tag_id)防止用户给同一篇帖子重复打上同一个标签。热门标签榜就通过聚合中间表数据生成。标签的作用不只是分类更重要的价值是提供了一个跨帖子的聚合维度比如用户点击催泪这个标签就能看到所有被打上这个标签的帖子这种浏览路径在社区产品里的转化率非常高。4. 核心功能模块的落地不只是写出一堆接口4.1 注册登录模块安全意识的第一次觉醒对一个真实上线的项目来说注册登录模块是安全风险最集中的地方也是很多教程最容易草率处理的地方。密码存储用了BCrypt加密。具体到我这个SpringBoot项目引入spring-security-crypto依赖后可以直接使用BCryptPasswordEncoder。注册时对明文密码加密落库登录时调用matches方法验证。这一步能防的是数据库泄露后密码被反推的风险彩虹表攻击在带盐的BCrypt面前基本失效。登录态管理我选择了JWT方案。用户登录成功后服务端生成一段包含用户id和过期时间的token返回给前端前端在后续请求的Authorization头中携带。服务端提供一个拦截器统一校验从Header中取出token解析出userId后存入ThreadLocal这样后续业务代码里直接就能取到当前用户不需要每个接口都写一遍解析逻辑。未登录用户可以浏览帖子列表和详情但不能发帖、点赞、评论这个判断就在拦截器里完成——对于GET请求放行对写操作校验token是否存在。这个方案在开发期够用部署后也验证了它的稳定性。如果你后续做更精细的权限管理可以平滑迁移到Sa-Token或Spring Security接口层面几乎不用改。4.2 帖子列表与详情避免N1查询的坑帖子列表接口看似简单实际上最容易埋雷。数据库里帖子表、用户表、标签关联表分开存放如果写代码时采用先查帖子再在循环里查作者的昵称、查帖子的标签就会出现经典的N1查询——查一次列表N条数据结果触发了N次额外的数据库查询接口性能直线下降。我的方案是分两步。第一步只分页查询帖子主表数据。第二步拿到这一页帖子的user_id集合用IN语句一次性查出用户信息再拿id集合查标签和帖子标签的中间表在内存里完成组装。与N次查询相比这样固定为3次查询性能损耗有个数量级的差距。帖子详情页的数据组装逻辑与此类似额外增加了帖子正文、作者完整信息、标签列表、当前用户是否已点赞已收藏四个标志位的查询。另外一个经验是列表接口和详情接口返回的字段一定要分开用不同的DTO。列表接口返回摘要信息就行千万不要把帖子正文这样的大字段也返回。详情DTO则可以包含完整内容。否则一次性把所有字段塞给前端列表页传输体积大、渲染慢接口表也混乱了。4.3 点赞与收藏Redis扛住热点的姿势点赞和收藏是社区里读写不均衡最典型的场景。一个帖子可能被几千人点赞但每个人查看自己是否点赞过这个帖子是高频操作。如果每次都查MySQL数据库的压力很快就上去了。我用Redis的Set集合来记录谁点赞过哪些目标。key的设计是like:post:{postId}集合里的member是userId。点赞时执行SADD取消点赞时执行SREM判断是否已点赞执行SISMEMBER。这三种操作都是O(1)时间复杂度Redis单机抗几万QPS毫无压力。帖子表里的like_count字段平时并不实时更新而是在Redis里通过INCR/DECR维护一个计数器然后由一个定时任务每隔几分钟把计数器同步一次到MySQL。这个方案有一个细节必须注意Redis里的数据和MySQL之间的最终一致性。如果同步任务挂掉了MySQL里的点赞数就会落后。我在同步脚本里做了补偿机制每次同步后会记录last_sync_time下次同步时把这段时间内的增量重新刷一遍保证两边最终达到一致。对于社区平台的点赞场景几秒到几分钟的延迟完全在可接受范围内。4.4 搜索功能从MySQL LIKE到中文分词平台上线初期帖子量不多搜索直接用MySQL的LIKE %keyword%是能跑的。但中文搜索有个天然问题分词。用户搜巨人希望匹配《进击的巨人》但如果帖子正文里只出现了进击的巨人这个完整词组简单的LIKE匹配在部分场景下会漏掉结果。SpringBoot项目里做中文分词搜索最轻量的方案是Elasticsearch IK分词器。但引入Elasticsearch意味着服务器内存要求直线上升个人项目几乎吃不消。我的折中方案是两步走。早期版本用MySQL的LIKE配合ngram全文解析器这个方案可以在MySQL 5.7以上的InnoDB表上直接使用对大字段建FULLTEXT索引配合ngram分词器搜索准确率比LIKE好不少部署零额外成本。后期如果数据量真的上来再平滑迁移到Elasticsearch。这里要提一下搜索的降级策略。即使将来引进了ES搜索服务挂掉时接口也不能报500。我在搜索接口上加了异常捕获和降级逻辑ES不可用时自动退回MySQL LIKE查询虽然慢一点但至少功能可用。这个思维在互联网项目里挺重要。5. SpringBoot关键机制的实战应用框架不只是脚手架5.1 自动装配在项目里到底做了什么很多人在简历上写熟悉SpringBoot自动装配原理但真到项目里却说不出自己项目里的哪个功能是靠自动装配实现的。这个项目帮我彻底把这个概念串起来了。以我们用的Redis为例。SpringBoot引入spring-boot-starter-data-redis后真正帮我们做事的核心是RedisAutoConfiguration这个自动配置类。SpringBoot启动时扫描AutoConfiguration.imports文件发现当前Classpath里存在RedisOperations这个类条件注解ConditionalOnClass的判断就自动创建RedisTemplate、StringRedisTemplate等Bean。而application.yml里的spring.redis.host、port等配置则通过ConfigurationProperties绑定到RedisProperties类上再注入到自动配置里。我实际开发时还利用这个机制写过一个小型starter把文件上传的配置封装成FileStorageAutoConfiguration外部只需要提供上传路径、允许的扩展名等几个配置项就能自动组装出上传服务Bean。写完之后我对约定优于配置这句话的体会瞬间不一样了——自动装配不是在背后偷偷做了什么高深的事而是把那些具有固定初始化流程的组件从让你自己写配置类变成了按条件帮你准备好Bean。5.2 常用注解如何各司其职SpringBoot项目里的注解看似多但梳理清楚就是在回答这个类在系统里扮演什么角色的问题。RestController注册HTTP接口层它把Controller和ResponseBody组合在一起返回的Object会被Jackson自动序列化成JSONcontroller方法上也可以直接用ResponseBody。Service标注业务逻辑层事务边界就在这个层的方法上。Repository标注数据访问层异常会被统一转换成Spring的数据访问异常体系。ConfigurationProperties是我用的比较多的一个注解。上传路径、JWT密钥和过期时间、跨域白名单、Redis缓存策略这些业务参数我都放到一个配置类里用ConfigurationProperties(prefix app.xxx)统一绑定。相比散落的Value这个方式的好处是集中管理、类型安全IDEA里还能自动提示。还有两个注解值得单独说。第一个是Transactional在发帖场景中我需要同时完成插入帖子主记录、更新用户的发帖数字段、建立帖子与标签的关联关系三步操作任何一个失败都不能让前面成功的写入残留。所以在Service方法上标注Transactional让这三步处于同一个数据库事务中报错时整体回滚。第二个是Validated配合参数对象上的NotBlank、Size等约束注解实现接口参数的声明式校验省掉了代码里一堆if判断。5.3 用EventListener解耦发帖后的通知流程没有事件机制的时候发帖后的逻辑是硬编码在Service里的插入帖子、更新统计、给关注者生成通知、触发内容审核。这样写的问题在于每加一个发帖后要做的事就要去改动发帖Service的方法代码越加越肿职责也越来越混乱。用EventListener重构之后发帖Service只负责把帖子数据写入数据库然后通过ApplicationEventPublisher发布一个事件。关注通知、统计更新、内容审核分别实现自己的监听方法用EventListener标注各自独立处理。这样新增一个发帖后要做的动作只需要新增一个监听器类不需要动已经存在的代码。配合Async注解这些监听器还是异步执行的。用户发帖时接口响应不需要等待关注通知批量生成完毕用户体验会更好。这里要提醒一个细节Async要生效必须开启EnableAsync而且方法不能从同一个类的内部调用自己否则代理不生效异步会静默退化成同步。5.4 定时任务番剧日历与热度榜的后台引擎社区平台有很多数据需要周期性更新我用SpringBoot自带的Scheduled定时任务解决。第一个定时任务是热度榜。每天凌晨两点统计前24小时所有帖子的浏览量、点赞数、评论数按加权公式计算热度分然后写入redis缓存的热榜key中。首页热榜接口只读缓存不存在每次请求都去跑一遍聚合SQL的问题。第二个定时任务是点赞数据的落库同步每5分钟把Redis里的点赞计数器写回MySQL。第三个任务是会话清理定期清除过期的验证码和临时token。cron表达式的格式是秒 分 时 日 月 周比如0 0 2 * * ?表示每天凌晨2点执行。?号用在日和周两个字段中表示不指定值这套规则第一次接触时容易踩坑建议写好表达式后去cron在线校验工具里验证一遍再上线。单机部署时这套方案没有任何问题但如果你以后把应用部署在多台服务器上相同的定时任务会在每个实例上同时执行——我之前就亲眼见过双实例部署导致同一批热度数据被重复刷新。这时要么引入分布式任务调度框架要么在任务执行前加一个分布式锁。个人项目阶段用单机即可但要有意识地知道这个边界在哪里。6. 前端与部署落地的最后一公里6.1 前后端分离还是服务端渲染视频演示和日常使用的场景决定了我们团队采用前后端分离方案。前端基于Vue3 Element Plus开发打包成静态文件后由Nginx托管后端接口独立部署。这个方案的优点是前端交互体验更接近真实产品在大屏演示时效果好很多。而最需要处理的是跨域问题。前端页面在localhost:5173开发服务器上接口请求指向localhost:8080浏览器会拦截。我在后端用CorsFilter统一处理了跨域只允许配置的前端域名白名单访问写操作同时允许携带token和凭证。上线部署时Nginx里配置反向代理把/api路径转发到后端服务前端页面和接口就同源了。前后端分离的项目这个坑一定会踩一次提前了解可以省下不少调试时间。6.2 打包部署与Tomcat替换本地开发调试完毕接下来的事情就是打包部署。SpringBoot应用默认使用内嵌Tomcat所以打包成可执行jar后一条java -jar命令就能启动。我用的命令是mvn clean package -DskipTests跳过单元测试加快打包速度。打出来的jar在服务器上用nohup java -jar xxx.jar app.log 21 方式启动日志重定向到文件方便排查问题。关于Tomcat替换的问题之所以会有人把内嵌Tomcat替换成宝兰德这类中间件一般是因为项目要运行在特定的基础软件环境上。技术上SpringBoot支持打包成war包部署到外置容器第一步在pom.xml中把packaging从jar改成war。第二步在启动类上继承SpringBootServletInitializer并重写configure方法。第三步把内嵌Tomcat的依赖作用域设为provided打包时排除掉。完成这三步后打出的war包就可以放到宝兰德等外置容器的webapps目录下部署了。不过说实话对绝大多数个人项目和毕设而言直接jar包运行是最省事的内嵌Tomcat的性能和稳定性完全够用。替换中间件这件事如果不是环境硬性要求不建议自找麻烦多配置一步就多一个出问题的可能。6.3 上线后的健康观测与日志排查部署上线只是第一步如何发现问题才是运维的关键。SpringBoot Actuator提供了很多现成的监控端点我主要用health检查应用是否存活、metrics查看JVM内存和线程池状态。需要提醒的是生产环境一定要把/actuator的端点暴露控制好可以在配置里通过management.endpoints.web.exposure.include精确指定开放哪些端点否则敏感信息全部暴露在外会变成安全隐患。日志方面我用Logback的配置实现按天滚动输出按大小切分历史日志保留最近30天的日志文件。这样排查问题时可以直接跳转到对应日期和对应级别的日志里搜索关键字。配合MySQL的慢查询日志我发现了几个当初没建索引的查询在数据量增长后性能明显下降后来给post表的user_id和anime_id都补了索引后慢查询数量锐减。上线后的性能冒烟测试也值得做一次。用ApacheBench或者JMeter对帖子列表、详情、点赞这三个核心接口做简单的并发测试就可以发现哪些接口的耗时和吞吐量需要优化。我的经验是优先关注慢接口背后的SQL而不是上来就引入复杂缓存框架——很多问题本质上就是一条SQL缺索引。7. 踩坑实录开发中最深刻的几场排障历程7.1 JSON序列化循环引用的栈溢出第一个让人印象深刻的坑发生在帖子详情接口调试到一半的时候前端突然收到500错误后端日志里一片StackOverflowError。排查后发现根因是实体类之间的双向关联。用户实体里有List 帖子实体里又有关联的用户对象。Jackson序列化User时发现它有List 于是序列化PostPost里又有User序列化User……无限套娃。最直接的修复方式是在关联字段上加JsonIgnore但这样会误伤一些场景——比如帖子列表接口本来就需要展示作者昵称。后来我改用DTO方案接口返回前把Entity转换成DTODTO里只包含前端真正需要的字段不在DTO里放双向引用对象。数据量不大时用Hutool或Spring自带的BeanUtils做属性拷贝就能搞定。这个坑的深层教训是Entity是跟数据库表结构对齐的内部对象接口返回是外部契约两者从一开始就应该隔离。7.2 MyBatis-Plus分页不生效的真相列表页的分页功能我用了MyBatis-Plus提供的内置分页插件。但配置完发现分页查询返回的total永远是0records也只有当前页的数据完全没有分页效果。排查的过程让我意识到分页插件不是引个依赖就能用的。它必须显式地在配置类里注册PaginationInnerInterceptor这个拦截器。没有注册拦截器时Page对象虽然有值但SQL并没有被拦截拼接LIMIT结果就是查询没有得到限制。注册时还需要指定数据库类型比如DbType.MYSQL插件才能生成正确方言的LIMIT语句。网上很多教程只写了引入两个依赖忽略了注册拦截器这一步导致大量人踩这个坑。如果你是按教程操作却分页失败先检查一下配置类里有没有new PaginationInnerInterceptor()。另外如果你配置了多数据源拦截器必须要分别加到每个数据源的SqlSessionFactory里只加一个数据源会导致另一个数据源的分页静默失效。7.3 JDK版本与SpringBoot版本组合的兼容性排查这台项目开发过程中我还遇到过本地能跑打包后却启动报错的问题。报错信息定位到spring-beans的CGLIB相关类网上搜了半天最终发现是JDK版本和SpringBoot版本组合不兼容。具体情况是我本机的默认JDK是21而项目用的SpringBoot 2.7.x内部依赖的CGLIB版本对JDK 21的字节码版本支持不完善。解决办法有两个路径第一个路径是把项目JDK降到8或11跟SpringBoot 2.7完全匹配第二个路径是升级到SpringBoot 3.x跟上JDK 21的节奏。考虑到我项目里已有的一些依赖对SpringBoot 3的适配还有风险我选择了把JDK降回8。这个问题的本质是版本矩阵管理意识——SpringBoot的major.minor版本不是随便配的每一步依赖的升级都可能因为JDK版本断层而暴雷。在这里也补充一个实践技巧IDEA创建SpringBoot项目时SpringInitializr会默认选中最新的SpringBoot稳定版但如果你计划部署的服务器是JDK8环境记得手动把版本改成2.7.x否则项目就会按照3.x的JDK17要求来编译打包出去的jar在服务器上起不来。7.4 时区引发的时间差问题最后一个小坑但非常隐蔽。测试用户在服务器上发帖发现创建时间比本地时间快了8个小时。排查发现这是MySQL连接串里的serverTimezone参数没有配置时区导致的默认使用了服务器系统时区而服务器时区是UTC和北京时间的东八区差了8个小时。SpringBoot的数据库连接配置里JDBC连接串应当加上serverTimezoneAsia/Shanghai甲骨文官方驱动的新版本还需要配合useSSLfalse参数避免连接警告。另外在Java侧时间类型我统一使用LocalDateTime它是无时区概念的时间表示方式配合MySQL的datetime字段和Jackson序列化配置在整个链路里不会发生时区偏移。时间字段处理看似不起眼但如果不统一约定几乎必然会出问题。我自己在做这个项目的过程中有一个很深的体会技术栈本身并不神秘SpringBoot最大的价值是帮你把那些繁琐的配置和重复的工作压缩到最小把精力留给真正的业务逻辑和流程设计。但是一个完整可用的平台真正的难点从来不在某个接口怎么写而在于对业务需求的理解、对数据模型的设计、以及对各种边界情况的处理。功能做到什么程度、数据放在哪里、什么时候用缓存什么时候直接查库、哪些问题能接受延迟最终一致这些判断才是一个开发者的核心价值所在。如果你也想照着这个思路做一个类似的项目我的建议是不要贪多求全把核心链路做深做透远好过做一个功能堆砌但处处是半成品的平台。每一行代码都清楚在解决什么问题这样的项目做完你的收获会比想象中大得多。