企业官网建设流程全解析

搞过Java Web项目的朋友应该都有体会，"论坛系统"这四个字听起来平平无奇，但真正动起手来，从用户注册、帖子发布、评论互动到关注粉丝、消息通知、热帖排序，每个环节都能折腾出不少事。这篇想聊的项目是一个基于Spring Boot的粉丝交流论坛系统，项目编号project74251，核心就是围绕Spring Boot生态，搭一套给明星、UP主、主播或者博主做粉丝交流社区的后台与前端。如果你正准备做类似的毕设、个人项目，或者工作中需要一个轻量级的社区讨论模块，这篇内容应该能帮你少走不少弯路。

我会直接按实际开发顺序来拆：先讲清楚粉丝论坛这类系统的核心需求和技术选型为什么这么定，再细化数据表结构和关键功能的实现方式，最后把我在实操中遇到的典型问题和排查思路整理出来。全程以Spring Boot为主线，涉及MyBatis Plus、Redis、Spring Security、JWT这些常用组件，代码不会贴太多，但关键配置和思路会交代得很细，照着复现基本没问题。

1. 项目到底做什么？拆解粉丝交流论坛的核心需求

1.1 论坛系统不只是"发帖回帖"那么简单

很多人一听到论坛系统，第一反应就是"这不就是个发帖回帖的CRUD吗"。真上手就会发现，需求一旦加上"粉丝交流"这个前缀，事情就完全不一样了。

普通论坛的核心是"内容"，粉丝论坛的核心是"关系+内容"。粉丝来社区不只是看帖子，更是来找到同类、关注喜欢的人、参与互动、获得归属感。所以这个系统里，除了传统的板块、帖子、评论、回复之外，还得有用户关注、粉丝列表、点赞收藏、私信通知、个人主页、动态流这些社交属性非常强的模块。

从产品层面看，这个系统要解决的核心问题有四个：

一是身份与关系。用户能注册登录、关注其他用户、被关注、查看粉丝列表，这是社交网络的底层骨架。

二是内容生产与消费。用户能发帖、传图、评论、回复、点赞，这是社区活跃度的来源。

三是信息触达。有人回复你的帖子、有人关注了你、你的帖子被点赞了，系统得让用户知道，这就要做站内通知体系。

四是内容组织与治理。帖子要分区、要能分页浏览、要能按热度排序，还要有搜索和管理员删除的通道，否则社区很快就会变成信息垃圾场。

拿毕设或者个人项目的场景来说，把上面这四块做到能演示、能流畅运行、存在合理的边界情况处理，这个项目的完成度就足够拿得出手了。

1.2 为什么用Spring Boot做这类项目最省心

选择Spring Boot不是因为它时髦，而是因为它在"快速构建业务系统"这个维度上确实是最稳的选择。

第一，自动配置极大降低了集成成本。做论坛系统一定要连数据库、做鉴权、传文件、做缓存，如果裸用Spring MVC，光配置数据源、事务管理器、视图解析器、JSON序列化就能花掉好几天时间。Spring Boot通过starter机制把这些都吃掉了，你在pom.xml里引入spring-boot-starter-web、mybatis-plus-boot-starter、spring-boot-starter-data-redis，东西就能直接跑起来，省下的时间可以全部砸在业务逻辑上。

第二，生态成熟，遇到问题基本都是现成的答案。论坛系统涉及的鉴权、分页、文件存储、接口文档，Spring Boot社区里都有大量成型方案。比如JWT做无状态登录、MyBatis Plus的分页插件做列表查询、Redis做热点数据缓存、Spring Task做定时任务，每个组件拿出来都有海量的踩坑记录可以参考，这对个人开发者极其友好。

第三，部署和运维成本低。项目打包成jar包扔到服务器上，一条java -jar命令就能启动，配合Docker做容器化也方便。对毕设要装环境、做演示的场景，这种低心智负担的部署方式非常加分。

这个项目的技术栈版本搭配，我建议控制在一个"稳妥"的组合上，不追求最新，但求兼容性好、资料多。我实测下来比较顺手的组合是：Spring Boot 2.7.x + JDK 8/11 + MyBatis Plus 3.5.x + MySQL 5.7/8.0 + Redis 6.x + Spring Security + JWT。这套组合的资料量非常庞大，几乎每个报错都能搜到解决方案。

1.3 技术选型：一套搭配合理的落地方案

论坛系统的技术选型，核心围绕"怎么用最顺手的工具解决业务问题"来定。我常用的搭配如下，其实也是这个project74251项目里比较合理的默认配置：

有人可能会问，为什么不用Shiro？因为Spring Security虽然上手门槛高一点，但和Spring Boot的整合更流程化，遇到问题也更容易搜到答案。论坛这种需要"登录才能操作"的接口，用Spring Security的SecurityFilterChain配合自定义JWT过滤器，改动量小且结构清晰。

还有一点必须说，项目的目录结构会影响你后续扩展的幸福感。我习惯的包结构是：config、controller、service、mapper、entity、dto、vo、common、utils。config放各种配置类，common放统一返回结果和异常处理，dto放请求参数，vo放响应结果，这样前后端接口对接时字段都是明确的，不会出现实体类直接暴露给前端的尴尬。

2. 数据模型设计：先把表结构想清楚再动手

2.1 用户体系：从注册到登录态的闭环

用户表是整个系统的地基，字段设计一定要规划好。我的做法是基础字段和扩展字段分开，基础的用户表只保存登录必要信息和基本资料，其他维度的信息通过关联表去扩展。

基础字段包括：id、username、password、nickname、avatar、email、phone、gender、signature、status、create_time。password存储的是BCrypt加密后的密文，前端传过来的明文密码在后端做加密，数据库里绝不存明文，这一点不管是毕设还是实际项目都要养成习惯。status字段用于封号/禁用，status为0时禁止登录和发帖。

注册流程上，我做了用户名唯一校验 + 邮箱/手机号选填的方式。用户名唯一校验要注意并发场景，所以user表里给username加了唯一索引，即使代码里漏了判断，数据库层也会兜底，返回DuplicateKeyException再统一转换成"用户名已存在"的提示。

登录成功之后，后端生成一个JWT令牌返回给前端。我的实现是把userId、username这些关键信息放进token的claims里，密钥放在application.yml配置中，过期时间按实际需求设置，一般演示项目设置成24小时或者7天都行。之后每次请求，前端在Header里带上Authorization: Bearer ，后端经Spring Security的过滤器解析并放行。

用户登录态还可以加上Redis的配合：登录成功后将用户基本信息缓存到Redis，key是login:user:{userId}，有效时间和token保持一致。这样后续获取当前登录用户时，优先从Redis拿，拿不到再查数据库回填，既快又能在用户被禁用时通过删除Redis记录来强制失效。

2.2 帖子与评论：论坛内容的基本盘

帖子表是论坛系统的核心内容承载，字段要覆盖"内容展示"和"排序检索"两个维度。

帖子表的核心字段：id、user_id、category_id、title、content、cover_image、view_count、like_count、comment_count、top、essence、status、create_time、update_time。这里要注意，把点赞数、评论数、浏览数这类计数做成冗余字段存在帖子表里，每次点赞或评论时对计数进行增减，而不是查询时去count子表，不然数据量上来之后接口会非常慢。

category_id关联板块表，做分区浏览用。top和essence这两个布尔字段，一个用于置顶，一个用于精华，是运营后台的基础能力。status字段控制帖子是否可见，0是正常，1是删除（逻辑删除），2是待审核，方便后续做内容治理。

帖子内容字段用哪种类型、存不存富文本，这取决于你的界面呈现方式。我的建议是：如果只是纯文本加表情，用TEXT类型就够；如果要支持图片上传，最好把图片单独处理，在内容里只保存图片URL，或者用富文本编辑器的时候要注意XSS过滤。

评论表的设计相对简单：id、user_id、post_id、parent_id、content、like_count、create_time。这里的parent_id很关键，用来做"楼中楼"回复。一级评论的parent_id为0或null，回复别人的评论时parent_id填对方的评论id。查询时先查出顶级评论，再根据parent_id把子评论关联出来，前端展示成缩进的层级。实际开发中也可以把楼层号（floor）加进表里，方便做"几楼"的展示。

2.3 关注/粉丝/点赞：社交关系怎么落表

社交关系这块，是粉丝论坛区别于普通内容论坛的核心，需要认真设计。

关注关系用一张表搞定：id、user_id、follow_user_id、create_time。user_id是关注者，follow_user_id是被关注者，用户id和关注对象id加上联合唯一索引，防止重复关注。我遇到过一个问题：如果没加唯一索引，前端重复点击关注时可能产生两条互逆的记录，关注列表和粉丝列表数字就不对了。加了唯一索引之后，配合服务端逻辑的先查再插，就能把这个问题扼杀在摇篮里。

查询"某个用户的粉丝列表"和"某个用户关注了谁"其实就是在follow表里按不同字段去查。需要特别注意的一点是，粉丝列表的分页排序应该按关注时间倒序，新关注的排前面，这样更符合社交产品的体验。

点赞关系表：id、user_id、target_id、target_type、create_time。做成target_type是为了能同时支持"给帖子点赞"和"给评论点赞"，target_id存对应帖子或评论的id。点赞和取消点赞是高频操作，在Redis里做计数会更好，具体做法我放在后面"Redis缓存与性能优化"里展开。

另外，帖子详情页经常要展示"当前用户是否已关注作者""当前用户是否已点赞"这类状态，如果每次查询都去数据库判断，接口压力大，性能差。我的做法是：在进入帖子列表或详情时，从Redis里读取当前用户的点赞和关注集合（Set），一次性判断完再拼装到VO里返回给前端。

3. 核心功能实操：从0到1把论坛跑起来

3.1 JWT登录鉴权怎么做才顺手

登录鉴权是整个系统的门面，配置得是否顺手直接影响后续所有接口的开发效率。

Spring Security整合JWT的实现，核心思路是"无状态"：服务端不保存用户的登录会话，只在用户登录成功后发一个签名Token，客户端每次请求带上这个Token，服务端验签通过就认为用户已登录。

配置层面分成三步走：

第一步，放行无需认证的接口。通常注册、登录、验证码接口、首页轮播图和帖子列表接口这些是可以匿名访问的，需要在SecurityConfig里通过permitAll()放行。注意放行的路径要精确，不能把管理员接口也放出去。

第二步，注册JWT过滤器。在Spring Security的过滤链中加入一个OncePerRequestFilter，每次请求进来先取Header中的Authorization字段，去掉"Bearer "前缀得到Token，然后解析Token里的userId，再把用户信息塞进SecurityContext中。这样Controller里就可以通过@AuthenticationPrincipal或者自定义注解拿到当前登录用户的信息。

第三步，配置无状态会话和权限规则。sessionCreationPolicy设为STATELESS，表示不用HttpSession；再对管理员接口统一加上hasRole("ADMIN")之类的权限控制。

关于Token过期失效，我建议在JWT的claims里放一个loginTime，同时把Redis里的登录标记和Token的过期时间对齐。当用户修改密码、被管理员封号，或者主动注销时，把Redis里的记录删掉，这个用户的登录态就立即失效了。只依赖JWT本身是无法做到主动失效的，这也是网上很多人踩坑之后总结出来的经验。

3.2 帖子发布与分页：平滑加载的细节

发帖接口的实现不复杂，但有几个细节很容易被忽略。

第一个是参数校验。帖子标题不能为空、长度要限制（比如5到50个字符），正文内容必填。用Hibernate Validator的@NotBlank、@Size注解配一个全局异常处理器，能省掉大量手写判断逻辑。我在全局异常处理里统一拦截MethodArgumentNotValidException，把第一条校验失败信息提取出来返回给前端，格式是"标题长度必须在5到50个字符之间"这种可读性强的提示。

第二个是敏感词过滤。这个功能看似非必须，但加上之后项目的完整度会提升很多。我用的方式是维护一个敏感词列表文件，发帖时用DFA算法做敏感词匹配，命中就在内容里替换成*号。实现思路不复杂，每次发帖时加载词库到内存构建一个字典树，然后遍历内容进行匹配替换。

第三个是关键——分页查询。论坛首页帖子列表、板块帖子列表、用户个人中心发布的帖子，分页是绕不开的场景。我用的是MyBatis Plus的分页插件，配置一个MybatisPlusInterceptor，把分页拦截器加进去就可以了。查询时直接page(new Page<>(pageNum, pageSize), wrapper)，返回的IPage里有records、total、pages这些现成字段，前端拿到就能渲染。

分页接口还要注意两个附加需求：一是筛选置顶帖和精华帖，二是隐藏当前用户拉黑的作者。这两个都可以通过QueryWrapper的orderByDesc("top")，或者"NOT IN (SELECT user_id FROM blacklist WHERE ...)"这类SQL来实现。粉丝论坛还有一个特殊需求：用户关注的人的帖子优先展示，这个可以设计成"先展示关注流，再展示全部"，SQL上用UNION把结果拼接起来。

3.3 热帖排序：不是简单的order by

一个只有时间倒序的论坛，老帖子永远沉底，新帖质量低就没人看，社区氛围会迅速恶化。所以，热帖排序是一个必做的功能。

主流做法是引入一个热度值公式。比较经典的是Hacker News的算法，分值 = (点赞数 - 反对数) / pow((当前时间 - 发布时间)的小时数 + 2, 1.5)。放在粉丝论坛的语境里，可以简化成热度分 = (点赞数 * 2 + 评论数 * 3 + 浏览数 * 0.5) / pow(帖龄小时数 + 2, 1.2)。

这个公式的关键是"时间衰减"：新帖子有额外的优势，老帖子即使点赞很多，也必须持续获得新的互动才能维持热度。帖子的浏览量、点赞数、评论数在Redis里随时都在变化，每次查询热帖时实时从MySQL算一遍也可以，但数据量上去后会很吃力。

我的做法是：搞一个定时任务，每10分钟计算一次所有"活跃帖子"的热度分，更新到帖子表里的heat_score字段；前端按热度排序时直接order by heat_score desc。活跃帖子的定义可以是"最近7天内有更新的帖子"，用create_time、update_time字段过滤，避免全表计算。

定时任务用Spring的@Scheduled注解就能实现，加个@EnableScheduling开启支持。在线程池里丢一个任务去算，把对主业务流程的影响降到最低。这是我在实际演示中觉得效果最稳的方案。

3.4 消息通知：异步处理的实战选择

消息通知模块是粉丝论坛里"看不见但感知很强"的部分。用户可能不会主动去看消息列表，但要是有人回复他、关注他，界面上一个红色角标能立刻让他感知到"社区活着"。

通知类型我建了一张枚举表：0=回复、1=点赞、2=新增关注、3=系统通知。通知表结构：id、receiver_id、sender_id、type、content、target_id、is_read、create_time。receiver_id是接收人，sender_id是触发人，target_id可以是帖子id或评论id，方便前端点击跳转到对应内容。

实现上要注意"异步"两个字。如果用户发帖成功后，同步去给所有粉丝发通知，接口响应时间会明显拉长，粉丝多的时候甚至超时。我用的方案是Spring Boot自带的异步任务：在Service方法上加@Async注解，把发送通知的逻辑丢到线程池里执行，主流程立刻就返回了。同时配合@EnableAsync开启异步支持。

有人可能会说，消息队列不是更好吗？对，如果这个系统要支撑高并发大流量，用RabbitMQ或RocketMQ是正解。但对于毕设和个人项目，异步线程池已经能完美解决问题，还能减少一套中间件的学习和部署成本。我建议先上异步任务，等明确出现了消息积压问题再引入MQ。这个取舍原则是：不过度设计。

4. 安全与性能：这些坑我替你踩过了

4.1 常见的接口安全问题怎么防

论坛系统是典型的高交互产品，你的内容接口必然暴露给最终用户，所以安全这东西它宁可多写，不能不写。常见的安全问题有这么几个，必须处理：

XSS攻击。用户提交帖子内容、评论内容时，如果直接存到数据库，前端再直接渲染，黑客就能通过构造JavaScript代码来盗取用户信息。初级防护是后端过滤，使用自定义过滤器对请求体里的HTML标签和script事件进行转义。我用的方案是写一个XssFilter，继承OncePerRequestFilter，在body读取时把<、>、script、onerror等关键词替换成安全的转义字符。注意要做白名单处理，允许使用正常的富文本标签如p、br、img，防止把用户的排版也一起过滤掉了。

SQL注入。虽然MyBatis的#{}预编译已经天然防住了大部分注入，但如果在XML里写了${}，而且入参是外部传入的字段名或排序方式，就要非常小心。我的习惯是排序字段不允许前端直接传入，后端做一个白名单映射：传0按最新，传1按热度，传2按评论数，内部再转成安全字段。这样就算前端传了"id; drop table user"，到后端也只是一串普通字符串，不会拼进SQL里。

接口鉴权。必须保证：不是登录用户就不能发帖评论；不是管理员就不能删帖删评论。我通过Spring Security的@PreAuthorize注解控制接口权限，比如发帖接口加@PreAuthorize("isAuthenticated()")，管理员删除接口加@PreAuthorize("hasRole('ADMIN')")，这样就算有人猜到接口路径，没权限也进不来。

4.2 Redis缓存与性能优化

缓存是用来解决"热点数据反复查询数据库"问题的，论坛系统有几个非常适合放Redis的场景。

第一个是热点帖子详情。一个帖子被多次访问，每次访问都要查数据库、还有可能关联查询作者信息、点赞状态，如果不做缓存，一个爆款帖子就能把数据库打爆。我的做法是：帖子详情接口先查Redis，key是post:detail:{id}，没有则查数据库并设置缓存，给一个合理的过期时间比如30分钟；对于被点赞、评论导致计数变化的场景，直接删缓存，下次请求时回填。

第二个是首页的热帖列表。首页通常是被访问最频繁的接口，可以把热帖列表整体缓存起来，key是hot:post:{pageNum}，超时时间设置短一点比如5分钟，数据更新后主动删除列表缓存。这样首页的QPS可以非常轻松地扛上去。

第三个是点赞和计数的Redis化。帖子被点赞时，不是直接更新MySQL里的like_count，而是先在Redis里做INCR操作，把变化记录下来，再通过一个后台任务定时把Redis里的最新数值批量同步回MySQL。这个做法能扛住活动期间的流量高峰。Redis里再维护一个set来记录"谁给这个帖子点过赞"，key是post:liked:{postId}，返回给前端的"当前用户是否已点赞"状态，直接查这个Set就行。

在使用Redis的过程中，最容易踩的一个坑是缓存穿透：频繁查询一个不存在的帖子ID，每次都会打到数据库。解决方式是在查询结果为空时也往Redis里存一个空值（比如空字符串），过期时间设置短一点，这样下一次同样ID的请求直接返回空，不再穿透到数据库。另一招是使用布隆过滤器，但空值缓存在这个场景下已经够用，不需要复杂化。

4.3 文件上传：图片头像的处理细节

粉丝论坛的用户头像、帖子图片上传，是躲不开的功能。Spring Boot处理单文件上传本身很简单，一个MultipartFile参数就搞定，但有几个要点需要注意。

文件类型校验。前端传什么文件，后端不能全盘照收，否则别人传一个JSP或EXE上来，再配合静态资源映射漏洞，可能导致服务器被黑。我的校验方式是双重校验：先校验Content-Type，再校验文件后缀名，白名单里只放jpg、jpeg、png、gif、webp这几种。再进一步，可以用ImageIO读取文件头，判断真实格式，防止攻击者伪造扩展名。这个操作代码量不大，但对安全性的提升是质变的。

文件大小限制。在Spring Boot的配置里设置上传大小上限：spring.servlet.multipart.max-file-size=5MB、max-request-size=20MB。图片上传之前，还可以使用Java的ImageIO对图片做压缩处理，把超过一定尺寸的图片等比缩小，既能节省存储空间，又能提升页面加载速度。

存储路径处理。在本地环境建议把文件存到项目外的目录，比如D:/forum-data/upload/，不要存到项目内的static资源目录，否则重新部署时文件会全被清掉。访问的时候，可以配置一个静态资源映射，把/upload/**映射到服务器的物理路径。生产环境如果条件允许，可以把文件扔到云存储上，或者用MinIO自建一个对象存储服务，思路类似，只是把保存路径换成了云端的Bucket路径。

5. 常见问题速查：从启动到上线的排错实录

5.1 启动与配置类问题

问题：项目启动时报"Invalid bound statement (not found)"

这个报错在MyBatis Plus项目里出现频率极高，基本都是因为Mapper接口和XML文件没有关联上。我的排查顺序是：第一步看Mapper接口上有没有@Mapper注解，或者启动类上有没有@MapperScan；第二步看application.yml里mybatis-plus.mapper-locations配置是否指向了正确的XML目录；第三步看target/classes目录下有没有编译进去XML文件。实际上，第三步经常是罪魁祸首，因为IDEA不会自动把resources下的XML复制到target目录，需要在pom.xml里显式配置 。

问题：Spring Boot启动时端口被占用

改成其他端口的方式很简单，但是要注意有没有多个服务同时使用同一个端口。开发阶段本机同时开MySQL、Redis、前端项目和服务端，端口冲突很正常。用netstat -ano | findstr 8080可以快速找到是哪个进程占用了端口，不用乱猜。

问题：Redis连接不上导致的启动失败

Spring Boot的Redis自动配置在连不上Redis时会让整个项目启动失败。如果你只想先跑通代码逻辑、不想开Redis，可以把Redis配置里的timeout调短，或者干脆先注掉Redis依赖。但更好的做法是：项目里用到的Redis功能明确标注，启动前记得先启动Redis，这也算工作流标准。

5.2 数据访问与分页问题

问题：MyBatis Plus分页不生效，查询返回所有数据

这个问题的根源通常是没配置分页插件。很多人引入了mybatis-plus-boot-starter，以为分页功能是默认开启的，其实必须手动注入MybatisPlusInterceptor并addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL))。配置之后分页才能正常组装LIMIT语句。

另外注意分页参数是当前页页码和每页条数，很多人传成"起始偏移量"，导致翻页错乱。如果要做"按某字段排序"，要确保排序字段在表里真实存在，如果传了表里不存在的字段名做ORDER BY，MyBatis Plus在自动生成SQL时会直接报语法错误。

问题：逻辑删除配置不生效

论坛系统的删帖更建议用逻辑删除，保留数据，避免影响关联表和统计结果。MyBatis Plus的逻辑删除配置需要两步：实体字段加@TableLogic注解，application.yml里设置logic-delete-field和logic-delete-value、logic-not-delete-value。一定要确认两处的字段名和值是对上的，否则会出现"删除后的记录还能查出来"或"正常记录也被过滤"的诡异现象。

5.3 前端联调与跨域问题

问题：前端请求后端接口报跨域错误

前后端分离开发时跨域问题几乎每个项目都会遇到。我的做法是写一个CorsFilter配置类，直接在Spring Boot后端统一允许跨域请求。给出具体的配置：allowedOriginPatterns配成""，allowedMethods配成GET、POST、PUT、DELETE、OPTIONS，allowedHeaders配成""，allowCredentials设为true。注意allowedOriginPatterns不要写"*"再用allowCredentials(true)会冲突，网上很多旧教程把这两者等价写会让你踩坑。

问题：带Token请求时出现OPTIONS预检请求

这是浏览器CORS机制的行为：当请求包含自定义Header（比如Authorization）时会先发一个OPTIONS预检请求。服务端必须对OPTIONS请求放行，否则前端会报跨域失败。上面CorsFilter的配置里allowedMethods包含OPTIONS就能解决，前提是Spring Security的配置里也放行OPTIONS请求。

问题：接口返回的数据结构前后端对不上

我建议项目一开始就统一返回结果类Result ，结构固定为code、message、data三个字段。前端走axios封装，在拦截器里统一判断code，code为200时取出data，为401时跳转登录页。这类规范看起来麻烦，但开发到后面能省掉几乎所有联调纠纷。

这里还要顺带提一句，分页接口返回的数据结构也要提前定好，我的习惯是返回{records, total, pages, current, size}。前端拿到records渲染列表，total作为分页组件的总数。如果前后端某一方少传了一个字段，分页效果就会变得很别扭。

5.4 部署与上线问题

问题：本地跑得好好的，部署到服务器后上传图片失效

这是典型的本地文件路径和服务器路径不一致导致的。本地用的是Windows路径，服务器是Linux路径，图片上传的保存路径写死就完了。解决办法是把文件上传基础路径配置到application.yml里，通过配置项去指定；部署时用环境变量覆盖配置。另外服务器上这个目录如果不存在，程序第一次保存文件时会报FileNotFoundException，需要在代码里判断目录不存在就主动创建。

问题：生产环境的JWT密钥太弱

如果你打算把项目发布到公网，一定不要把密钥硬编码在代码里。JWT密钥过短或过于简单（比如"secret"这种字符串），攻击者是可以暴力破解的，一旦密钥泄露，任何人都能伪造登录Token。建议生成一个足够长的随机字符串，放到环境变量或配置中心里，必要时定期轮换。

问题：数据库数据备份意识

发布个人项目到服务器，哪怕只是演示用，也建议定时备份MySQL数据。操作系统层面写个crontab脚本，每天凌晨备份一次数据库到指定目录，定期同步一份最近的数据。很多人在上学期间做毕设，演示前一分钟发现数据库误删了，那种绝望我是见过的；一个自动备份脚本能救命，这个经验强烈建议提前抄下来。

几点实操后的个人体会

这个项目在Spring Boot整个体系里，属于"能撑起完整业务流程，又不会大到失控"的典型规模。真正做完一遍，你对Spring Boot的理解会从"会用注解"提升到"知道一个系统从收到请求到返回响应的完整链路"。我自己在实际开发中的体会是，先别急着写代码，把数据表和接口规划做扎实，过程中至少能少返工一半。

最后分享两个小技巧：第一，开发过程中多用MyBatis Plus的代码生成器，把实体类、Mapper接口、Service、Controller一次性生成出来，再手动去改业务逻辑，省下的时间非常可观；第二，接口测试用IDEA自带的HTTP Client就可以，每个接口提前写好请求样例，配合开发环境变量管理Token，比每次都打开Postman要顺手得多。光这两点，就能让你在敲代码的时候多出不少摸鱼时间。别问我怎么知道的，都是亲手试过的。