做了不少这类基于 Spring Boot 的论坛网站，从最简单的课程设计到后来接商用的社区项目，踩过的坑累积起来能写一长串。今天不聊抽象概念，直接以一套完整可运行的论坛项目为主线，把从需求拆分、表设计、权限控制、帖子模块、缓存优化到部署上线的全过程拆给你们看。不管你是刚学完 Spring Boot 想做第一个完整项目，还是带着毕设需求找思路，或者想拿论坛当跳板去理解电商、内容平台，这篇文章都值得跟着过一遍。
论坛网站的核心其实不复杂：用户注册登录、发帖回帖、板块分类、管理员删帖禁言，再加一点点赞收藏和积分，就是这个形态的全部家当。难的是怎么把这几件事做得清楚、稳定、不埋雷，以及后端代码怎么安排才不会被后续需求改到崩溃。后面每一步我会先说为什么这么做，再给可直接抄的代码片段，尽量用工程视角代替教科书描述，这才是实际项目里真正用得到的东西。
1. 项目立项：需求边界与整体方案设计
1.1 论坛到底需要哪些功能模块
很多人在动手前最容易犯的错，就是想把论坛做成贴吧加知乎加小红书的缝合体。我见过有人一开始就规划了动态、私信、视频、打赏，结果写了两个月还停在注册页面。做任何项目，第一步一定是砍需求，把论坛的核心闭环圈出来。
一个最小可用的论坛系统，通常只需要六个模块：
- 用户模块：注册、登录、个人资料、头像上传。这是所有操作的认证基础。
- 板块模块：也就是分类，比如“技术讨论”“资源分享”“站务反馈”，板块要有管理员。
- 帖子模块：发布、编辑、删除、详情查看、分页列表。帖子是内容核心。
- 评论模块：回帖和楼层讨论，至少要支持分页查询。
- 点赞与收藏：这是提升活跃度的关键，同时能练到关联表和缓存设计。
- 管理后台：用户禁用、帖子置顶或删除、板块创建与调整，走管理员角色。
非核心但强烈建议加上的模块是：站内通知、积分经验、热门排序。通知可以在有人回复你帖子时触发，积分能驱动用户参与，热门排序则是检验你写复杂查询和缓存能力的试金石。至于私信、好友、动态流，第一版坚决不做，等核心跑通再迭代。
这一阶段的产出不应该是“我决定做这些功能”，而是一张功能清单加状态图。每项功能必须标注优先级、所属角色、数据来源，比如“帖子删除”的前端权限是登录用户只能删自己和管理员能删全部，后端必须区分校验。把这块理清楚，后面写实体类和控制器才能不打架。
1.2 技术选型：为什么是SpringBoot + MyBatis-Plus + MySQL + Redis
技术栈看起来常规，但在论坛这类以关系型数据和列表查询为主的系统里，常规就是最可靠的选择。
- Spring Boot：目前 Java Web 绝对的主流，直接绕开一堆 XML 配置，内嵌 Tomcat，打 jar 就能跑。版本建议用 2.7.x 或 3.x，配合 Jakarta 命名规范，新手选 2.7 更省心，因为网上资料最多。
- MyBatis-Plus：比纯 MyBatis 少写大量 CRUD 模板代码，内置分页插件、逻辑删除、自动填充。论坛业务里帖子、评论、用户都是标准单表操作，直接用 BaseMapper 的方法能覆盖八成功能，复杂查询再用注解 SQL。
- MySQL：论坛天然适合关系型数据库。帖子属于用户、评论属于帖子、点赞属于用户和帖子，全是强关联，MySQL 的事务和索引能保证数据一致性。
- Redis：承担登录 Token 缓存、热点帖子缓存、点赞计数、评论计数。论坛读多写少，Redis 命中率高的情况下可以把 QPS 拉高一个量级，不需要一开始就上分库分表。
- Spring Security + JWT：负责登录认证和接口权限控制。Session 方案在单体应用也够用，但前后端分离项目里 JWT 更自然，无状态、易横向扩展。
这套组合最适合中小体量的社区系统，单机部署能支撑日活几万以内的规模。完全不建议在课程设计阶段引入微服务和消息队列，那是给自己挖坑。非要说扩展点，Elasticsearch 可以等帖子量到百万级再说，前期 MySQL 的 LIKE 查询加索引足够应付。
1.3 前端方案取舍：服务端渲染还是前后端分离
论坛项目的前端有两条路线：用 Thymeleaf 做服务端渲染，或者用 Vue/React 做前后端分离。
如果你目标是快速跑通、把重心放在 Java 后端，选 Thymeleaf。这种方案不涉及跨域，登录状态靠 Session 或 Cookie，页面由后端直接渲染，写完立刻能看到效果，非常适合课程设计和内部系统。
但如果你想拿这个项目当简历亮点，我会建议上前后端分离：Vue 3 + Element Plus + Axios，登录用 JWT，后端只提供 JSON 接口。开发时后端开 8080，前端跑在 5173，通过 nginx 转发或用后端 CORS 配置解决联调问题。工程量会增加三分之一左右，但你能学到跨域、Token 存储、路由守卫这些生产环境必用的知识。
我通常建议如果时间少于两周，用 Thymeleaf；时间充裕或者想进互联网公司，就做前后端分离。后面所有接口设计都按 RESTful + JSON 来写，无论你选哪种前端都能直接对接。
2. 数据库模型与表结构设计
2.1 核心表拆解：用户表、板块表、主题贴表、回帖表
数据库设计决定了论坛能跑多远，很多坑在项目第三天就暴露出来，根源往往是一张表少了字段。我按实际项目里最不容易出问题的结构给你拆。
用户表user：
CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录用户名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `email` varchar(100) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT '1' COMMENT '1正常 0禁用', `role` varchar(20) NOT NULL DEFAULT 'USER' COMMENT 'USER/ADMIN', `score` int NOT NULL DEFAULT '0' COMMENT '积分', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里最重要的几个点：密码字段存的是 BCrypt 哈希，绝对不能是明文；username 必须唯一索引；status 做禁用标识，比物理删除更安全；role 字段用于区分管理员，简单项目不用单独搞角色表。
板块表board是论坛的分类骨架，字段有id、name、description、sort_order、topic_count、status。要留意的是topic_count这种冗余计数字段。它和评论数、点赞数一样，如果每次查询都COUNT(*)汇总，数据量上来后会非常慢，所以我在工程里直接用事务维护这个冗余字段，帖子发布时加一，删除时减一。
主题贴表topic是整个论坛的中枢，结构对应实际发帖的内容和状态：
CREATE TABLE `topic` ( `id` bigint NOT NULL AUTO_INCREMENT, `board_id` bigint NOT NULL COMMENT '所属板块id', `user_id` bigint NOT NULL COMMENT '发帖人id', `title` varchar(100) NOT NULL, `content` text, `view_count` int NOT NULL DEFAULT '0', `reply_count` int NOT NULL DEFAULT '0', `like_count` int NOT NULL DEFAULT '0', `is_top` tinyint NOT NULL DEFAULT '0' COMMENT '是否置顶', `is_essence` tinyint NOT NULL DEFAULT '0' COMMENT '是否精华', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1正常 0删除', `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`), KEY `idx_board_time` (`board_id`, `create_time`), KEY `idx_user_time` (`user_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;注意view_count每次浏览帖子详情时加一，不能用 Redis 临时乱加后不落库，否则重启就丢。reply_count和评论表关联，新增评论时事务更新这一字段。
回帖表reply更加简单，核心字段是topic_id、user_id、content、quote_reply_id（可选，引用楼层）、create_time。这里不建议存楼层号，因为删除回复会导致楼层号混乱，楼层号可以在查询时用ROW_NUMBER()动态算，或者干脆前端自己显示序号。
2.2 设计点赞、收藏、关注时要注意什么
点赞、收藏都属于多对多关系，最自然的方式是建关联表：
CREATE TABLE `topic_like` ( `id` bigint NOT NULL AUTO_INCREMENT, `topic_id` bigint NOT NULL, `user_id` bigint NOT NULL, `create_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_topic_user` (`topic_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;唯一索引uk_topic_user保证一个用户只能点赞一次。接口里不要先查再插再报错，而是直接用 “INSERT IGNORE” 或 “ON DUPLICATE KEY UPDATE”，这样并发重复点击时不会出脏数据。取消点赞走 DELETE，同时把topic.like_count减一。
收藏表topic_favorite和点赞表结构类似，区别是取消时是软删还是硬删。我建议直接用物理删除，收藏关系不需要历史记录。关注关系表可以设计成user_follow，存follower_id和followee_id，同样用唯一索引防止重复关注。这些表看起来简单，但在数学上非常容易因为缺少唯一索引造成重复数据，这是新手最容易忽视的地方。
2.3 索引与关联查询的取舍
论坛页面基本是列表页和详情页，列表页的查询模式非常固定：按板块查帖子、按用户查帖子、按时间或热度排序。所以索引设计就围绕这几个查询来建，而不是给每个字段都加上索引。
核心原则是：
- 等值字段放前面，范围字段放后面。
(board_id, create_time)适合板块内按时间排序；(user_id, create_time)适合查某人的发帖历史。 - 排序字段尽量走索引，如果能被覆盖索引满足，性能会非常好。
- 关联查询尽量少用多表 JOIN。帖子列表需要显示发帖人头像和昵称，我的做法是
topic表冗余user_nickname和user_avatar两个字段，发帖时写入，修改个人资料时批量更新相关帖子。虽然这是“反规范化”，但在论坛这种场景里能少掉一大半 JOIN，查询速度肉眼可见地快。 content这种大文本不要放进列表查询的SELECT *里，只查列表需要的字段，详情接口再单独查content。
数据库设计结束后，最好把所有建表 SQL 放进schema.sql并用 Spring Boot 的spring.sql.init机制在测试环境自动执行。真正上线时再用 Flyway 管理版本，但这属于加分项，后面再讲。
3. 关键功能实现：注册登录与权限控制
3.1 用户注册与密码加密（BCrypt）
注册接口的后端逻辑是：校验用户名是否唯一、校验密码长度、邮箱格式，然后密码加密后插库。密码加密我固定用 Spring Security 自带的BCryptPasswordEncoder，不要自己写 MD5 加盐，那是早已被淘汰的做法。
@Service public class UserService { private final UserMapper userMapper; private final BCryptPasswordEncoder passwordEncoder; public UserService(UserMapper userMapper, BCryptPasswordEncoder passwordEncoder) { this.userMapper = userMapper; this.passwordEncoder = passwordEncoder; } public void register(RegisterRequest request) { LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(User::getUsername, request.getUsername()); if (userMapper.selectCount(wrapper) > 0) { throw new BizException("用户名已被占用"); } User user = new User(); user.setUsername(request.getUsername()); user.setPassword(passwordEncoder.encode(request.getPassword())); user.setNickname(request.getNickname() == null ? request.getUsername() : request.getNickname()); user.setRole("USER"); user.setStatus(1); userMapper.insert(user); } }BCrypt 的好处是自带随机盐，每次加密结果不同，就算两个用户密码相同，存储的哈希也不一样。密码校验直接调passwordEncoder.matches(rawPassword, encodedPassword)，循环次数默认 10，老机器上也就是几十毫秒的事，安全性有保障。
3.2 登录会话方案：JWT还是Session
论坛这种场景，我更推荐 JWT。流程是：登录成功后，后端生成一个 Token，里面包含用户 ID、用户名、角色，设置过期时间，返回给前端；前端把它存在 localStorage 里，每次请求在 Authorization 头带上；后端过滤器解析 Token，构建安全上下文。
public String generateToken(User user) { return Jwts.builder() .setSubject(user.getId().toString()) .claim("username", user.getUsername()) .claim("role", user.getRole()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 86400000L)) .signWith(Keys.hmacShaKeyFor(secret.getBytes(StandardCharsets.UTF_8))) .compact(); }JWT 本身是无状态的，服务器不存会话，天然适合前后端分离和后端横向扩展。但要注意两个问题：
- Token 无法主动失效。用户被管理员禁用后，只要 Token 没过期仍然能用。解决办法是查询用户表时检查
status，禁用用户时直接查库拦截，而不是只依赖 Token。 - 不要把敏感数据放 Token 里，比如手机号、邮箱。Token 只是身份证，不是数据仓库。
如果你做的是 Thymeleaf 非前后端分离，用 Session 更省事，Spring Security 的默认机制就是 Session，加一个登录页就完事。两种方案没有绝对优劣，但我后面接口代码统一按 JWT 写，方便你迁移到前后端分离。
3.3 基于Spring Security的接口权限拦截
有了 JWT，还得让 Spring Security 认它。核心步骤是：写一个过滤器，从请求头取 Token，解析后如果合法就把用户信息放进 SecurityContext；再写一个安全配置类，放行注册登录接口和静态资源，其他接口全部认证。
@Configuration @EnableWebSecurity public class SecurityConfig { private final JwtAuthenticationFilter jwtFilter; @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/login", "/api/auth/register").permitAll() .requestMatchers(HttpMethod.GET, "/api/boards", "/api/topics/**").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated() ) .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); } }这里有几个特别容易踩的坑：
.requestMatchers("/api/topics/**").permitAll()只放行了 GET 请求，POST、PUT、DELETE 还是需要登录。如果你把整组接口都 permitAll，就会出现游客也能发帖的低级漏洞。hasRole("ADMIN")默认会在角色前加ROLE_前缀，所以数据库里的角色要存ADMIN，不能存ROLE_ADMIN。- 403 和 401 的区别一定要分清楚：未登录返回 401，登录了没权限返回 403。在全局异常处理器里针对
AccessDeniedException和AuthenticationException分别响应。
3.4 角色与权限细分：怎么给管理员留出口
论坛管理员的权限通常是：删帖、置顶、加精、禁言用户、管理板块。如果只靠role字段判断“是否管理员”会不够灵活，比如你想让某个版主只能管理自己的板块，就需要细粒度权限。
我的建议是初期用简单角色，后期抽象成permission概念。最简单的做法是用户表加role字段，并配合接口@PreAuthorize("hasRole('ADMIN')")做方法级权限。如果觉得一个角色不够，可以扩充为USER、BOARD_ADMIN、ADMIN三个角色，再在业务里判断板块归属：
@PreAuthorize("hasAnyRole('ADMIN','BOARD_ADMIN')") public void deleteTopic(Long topicId, Long currentUserId) { Topic topic = topicMapper.selectById(topicId); // 版主只能删自己板块的帖子 if (!isAdmin(currentUserId) && !isBoardOwner(topic.getBoardId(), currentUserId)) { throw new BizException("无权删除该板块帖子"); } topic.setStatus(0); topicMapper.updateById(topic); }这样以后如果真要上 Spring Security 的 ACL 或动态权限，也能平滑迁移。权限的教训是：前端隐藏按钮只是体验优化，后端每一个写操作都必须校验身份和资源归属，这是安全底线。
4. 帖子与评论模块的落地编码
4.1 发帖、改帖、删帖的校验逻辑
帖子模块的代码最能看出一个人的工程素养。发帖接口要校验：是否登录、帖子标题不能为空且长度限制、内容不能为空、板块是否存在且启用、用户是否被禁言。这些逻辑写在 Service 层而不是 Controller 层，Controller 只做参数接收和响应包装。
发帖后，除了插入topic表，还要同时把板块的topic_count加一，并且给用户增加积分。这两个操作必须在一个事务里，否则会出现帖子插入成功但计数没更新的问题。用@Transactional保证原子性。
@Transactional public Long createTopic(TopicCreateRequest request, Long userId) { User user = userMapper.selectById(userId); if (user == null || user.getStatus() == 0) { throw new BizException("用户不存在或已被禁用"); } Board board = boardMapper.selectById(request.getBoardId()); if (board == null || board.getStatus() == 0) { throw new BizException("板块不存在或已停用"); } Topic topic = new Topic(); topic.setBoardId(request.getBoardId()); topic.setUserId(userId); topic.setTitle(request.getTitle()); topic.setContent(request.getContent()); topic.setUserNickname(user.getNickname()); topic.setUserAvatar(user.getAvatar()); topicMapper.insert(topic); // 板块帖子数加1 board.setTopicCount(board.getTopicCount() + 1); boardMapper.updateById(board); // 积分加2 user.setScore(user.getScore() + 2); userMapper.updateById(user); return topic.getId(); }@Transactional默认只回滚RuntimeException，如果代码里用 try-catch 吞掉了异常，事务就不会回滚。另外要注意事务方法不能是同类内部调用，否则代理不生效，这也是很多“明明加了注解但没事务”的原因。
删除帖子时建议逻辑删除，把status置为 0，而不是直接DELETE。一方面保留数据用于审计，另一方面reply_count、评论数据联动容易出错。如果彻底物理删除，评论表也得连坐，逻辑删除能把这些坑全部避开。
4.2 评论与楼层设计：懒加载和分页实现
评论模块常见的做法是在帖子详情页直接加载全部回复，数据量不大时完全没问题。但当回复数超过几百条，一次性加载就卡了。我的方案是：帖子详情接口只返回帖子主体和评论摘要，评论全部通过分页接口异步加载。
评论分页查询需要注意ORDER BY create_time ASC以保证楼层顺序。分页参数用pageNum和pageSize，配合 MyBatis-Plus 的分页插件：
public Page<Reply> getReplies(Long topicId, long pageNum, long pageSize) { LambdaQueryWrapper<Reply> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Reply::getTopicId, topicId) .eq(Reply::getStatus, 1) .orderByAsc(Reply::getCreateTime); return replyMapper.selectPage(new Page<>(pageNum, pageSize), wrapper); }MyBatis-Plus 分页插件要先在配置类注册PaginationInnerInterceptor，否则selectPage不生效。分页结果建议不要直接返回IPage实体，而是转成一个带total、records、pageNum、pageSize的统一响应对象，这样前端用起来更顺手。
评论发布和帖子发布类似，插入评论后更新topic.reply_count。如果帖子被删或者板块被隐藏，要拦截评论新增。
4.3 搜索功能：先做数据库模糊查询，再做ES
论坛必须有搜索，不然内容沉淀下来就是死数据。初期直接用 MySQL 的LIKE查询就好：
public Page<Topic> searchTopics(String keyword, long pageNum, long pageSize) { LambdaQueryWrapper<Topic> wrapper = new LambdaQueryWrapper<>(); wrapper.like(Topic::getTitle, keyword) .or() .like(Topic::getContent, keyword) .eq(Topic::getStatus, 1) .orderByDesc(Topic::getCreateTime); return topicMapper.selectPage(new Page<>(pageNum, pageSize), wrapper); }这段代码能跑，但数据量一旦超过十万，%keyword%这种开头模糊查询是走不了索引的，会全表扫描。所以论坛访问量上来以后，搜索功能要迁移到 Elasticsearch。我的建议是前期在 MySQL 里做好基础搜索，同时把帖子标题和内容在发布、编辑时同步一份到 ES，等搜索引擎集成好后再切换搜索入口。
4.4 点赞与热度排行：用Redis List/Hash还是直接查库
热度排行是论坛项目里最容易被搞复杂的功能。实际上你只需要定义一个简单的热度公式，比如热度 = 浏览量 * 0.5 + 点赞数 * 2 + 评论数 * 3，然后按分数排序。
直接查库写法：
SELECT * FROM topic WHERE status = 1 ORDER BY view_count * 0.5 + like_count * 2 + reply_count * 3 DESC LIMIT 20;这种写法在数据量小时没问题，但一旦量大，这个表达式无法走索引，必然临时文件排序。更好的做法是给topic表加一个hot_score字段，每当浏览、点赞、评论动作发生时异步更新hot_score，然后直接ORDER BY hot_score DESC LIMIT 20，这个字段加索引后查询非常快。
点赞功能上手时用数据库自增就好：
@Transactional public void likeTopic(Long topicId, Long userId) { try { topicLikeMapper.insert(new TopicLike(topicId, userId)); topicMapper.increaseLikeCount(topicId); } catch (DuplicateKeyException e) { throw new BizException("你已经点过赞了"); } }后续如果想扛更大并发，再把点赞请求先打到 Redis 的Set里，定时异步同步到数据库。但前期完全没有必要，直接数据库反而逻辑更透明、不容易出账不平。
5. 性能优化与高并发场景的提前准备
5.1 缓存策略：热门帖子缓存 + 缓存一致性
论坛的读取远多于写入，热门帖子的被浏览次数甚至能占全站请求的一半。所以一定要引入 Redis 做缓存。我的策略分成两层：
第一层，帖子详情缓存。以topic:detail:{id}为 key，缓存帖子主体信息，设置 10 到 15 分钟过期。发帖、改帖、删帖时主动删除对应缓存，下次请求自动回源。
第二层，首页帖子列表缓存。以板块 ID 和页码为 key，比如topic:list:board:{boardId}:page:{pageNum}，缓存时间 5 分钟。这样可以压住首页的数据库流量。
public Topic getTopicDetail(Long id) { String key = "topic:detail:" + id; String cache = redisTemplate.opsForValue().get(key); if (cache != null) { return JSON.parseObject(cache, Topic.class); } Topic topic = topicMapper.selectById(id); if (topic == null || topic.getStatus() == 0) { throw new BizException("帖子不存在"); } redisTemplate.opsForValue().set(key, JSON.toJSONString(topic), 10, TimeUnit.MINUTES); return topic; }缓存一致性最忌讳的是“先更新数据库再更新缓存”，尤其是在并发写时容易造成缓存与库不一致。我的习惯是：更新数据库后直接删除缓存，等下一次读请求再把新数据写进缓存，也就是经典的 Cache Aside 模式。删除缓存失败的概率远小于更新缓存造成的并发错乱。
5.2 分页查询的性能陷阱和解决方案
分页很容易出问题，尤其在深分页上。比如翻到第 1000 页，OFFSET 19980 LIMIT 20，MySQL 依然要扫描前 19980 条数据然后丢弃，性能会越来越差。
解决深分页的常用方案有两种：
- 延迟关联：先只取主键分页，再关联回原表取数据。
- 游标分页：用
WHERE id > 上次最后一条ID ORDER BY id LIMIT 20，适用于点击“加载更多”而不是页码切换的场景。
论坛列表用游标分页很合适，粉丝刷帖子、版块看更新都不需要跳页。接口设计为接受cursor参数，返回nextCursor。实现起来也不难，就是查询条件里加一个gt条件。
public List<Topic> listByCursor(Long boardId, Long cursor, Integer limit) { LambdaQueryWrapper<Topic> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Topic::getBoardId, boardId) .eq(Topic::getStatus, 1) .lt(cursor != null, Topic::getId, cursor) .orderByDesc(Topic::getId) .last("LIMIT " + limit); return topicMapper.selectList(wrapper); }需要注意last("LIMIT ...")不要拼接用户输入，limit 参数要手动限制最大 100，防止恶意拉取全表数据。
5.3 图片上传与静态资源处理
论坛用户头像和帖子配图是刚需。图片存储最简单的方式是本地磁盘目录 + Nginx 静态映射。Spring Boot 里通过 MultipartFile 接收文件，落盘到/data/upload，再把文件路径/uploads/2024/...jpg保存到数据库。
@PostMapping("/upload") public String upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { throw new BizException("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String filename = UUID.randomUUID() + ext; String datePath = new SimpleDateFormat("yyyy/MM/dd").format(new Date()); File dest = new File(uploadDir + "/" + datePath + "/" + filename); dest.getParentFile().mkdirs(); file.transferTo(dest); return "/uploads/" + datePath + "/" + filename; }这里必须做扩展名白名单校验，防止有人传 jsp、html 等危险文件。图片格式只允许 jpg、png、gif、webp，同时限制单文件大小，通常 2MB 以内。条件允许的话，把文件的后缀统一改成.jpg再存储，避免伪造扩展名。
上线后本地图片目录不适合大规模场景，需要迁移到 OSS 对象存储，比如用云服务商的标准接口，业务代码里封装一个StorageService接口，本地实现和云端实现可以随时切换。这个设计是低调但很值钱的点。
6. 部署上线与常见问题排查
6.1 本地开发联调要设置哪些配置
打开application.yml，第一个要改的一定是数据库和 Redis 的连接参数。我先给出一份本地可跑的完整配置：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/forum?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 data: redis: host: localhost port: 6379 servlet: multipart: max-file-size: 5MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: status logic-delete-value: 0 logic-not-delete-value: 1 jwt: secret: your-secret-key-at-least-32-bytes expire: 86400serverTimezone=Asia/Shanghai是从 MySQL 驱动的“日期差 8 小时”最常见的解药。logic-delete-field配置好之后，MyBatis-Plus 会自动在 SELECT 语句里加上WHERE status = 1，在 DELETE 时自动转 UPDATE，这会省掉大量重复手写条件。
6.2 Docker Compose一键启动后端环境
本地联调最容易崩的不是代码，而是环境。队友的 MySQL 版本不一样、Redis 没装，每次都能浪费半小时。组合一个docker-compose.yml可以一分钟拉起依赖环境：
version: "3.8" services: mysql: image: mysql:8.0 container_name: forum-mysql environment: MYSQL_ROOT_PASSWORD: 123456 MYSQL_DATABASE: forum ports: - "3306:3306" volumes: - ./mysql-data:/var/lib/mysql - ./schema.sql:/docker-entrypoint-initdb.d/schema.sql command: --character-set-server=utf8mb4 redis: image: redis:7-alpine container_name: forum-redis ports: - "6379:6379"然后执行docker compose up -d，数据库初始化脚本自动执行，配好schema.sql后，后端项目直接mvn spring-boot:run就能跑。这样团队协作的体验好很多，也方便你自己在另一台电脑上快速复现环境。
后端容器化部署则写一个 Dockerfile，用 Maven 构建完之后复制 jar 到运行镜像：
FROM maven:3.8-openjdk-11 AS build COPY . /app WORKDIR /app RUN mvn clean package -DskipTests FROM openjdk:11-jre-slim COPY --from=build /app/target/forum.jar /app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "/app.jar"]这里有个经验点：镜像里的时区默认是 UTC，论坛的create_time如果用new Date()写入，会差 8 小时。加环境变量ENV TZ=Asia/Shanghai，或在启动命令里加-Duser.timezone=Asia/Shanghai就能解决。
6.3 常见问题实录：跨域、乱码、Security放行、事务失效
跨域是前后端分离最容易遇到的第一道坎。Spring Boot 里加一个 WebMvcConfigurer 统一处理：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }配置 CORS 的时候注意，allowCredentials(true)和allowedOrigins("*")不能同时用，必须用allowedOriginPatterns("*")，否则浏览器会直接报错。这个问题我排查过很多次，几乎所有新手都会踩。
中文乱码多半出在 MySQL 连接串没加characterEncoding=utf8，或者数据库建表时没用utf8mb4。只要你统一在 JDBC 连接、建表语句、Spring 配置三处都指定 utf8mb4，乱码基本能避免。如果发现已存在的库还是乱码，用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4转一下。
接口 404 但 controller 明明存在，八成是 Security 拦截了请求但没有放行 OPTIONS 预检请求，或者过滤器把请求处理掉了。解决办法是在 SecurityConfig 里.requestMatchers(HttpMethod.OPTIONS, "/**").permitAll()，让浏览器跨域预检直接通过。
事务失效的场景，抖音上总结过的常见套路全是真的：同类内部调用、方法被 private 修饰、异常被 catch 住、类没有被 Spring 管理。最容易漏的是内部调用，比如PlanService.createTopicAndAddScore()调用同类里的createTopic()，即使后者标了@Transactional也不会生效。解决办法是把需要事务的代码拆到另一个 Service，或者用AopContext.currentProxy()自调用，但这种奇技淫巧不如老老实实拆类。
还有一个论坛专属的坑：帖子详情浏览次数用普通update累加，并发下会有丢失更新。简单的方法是使用 SQL 原子更新：
UPDATE topic SET view_count = view_count + 1 WHERE id = #{id}这样并发也不会丢数据。低并发时确实没感觉，但一旦上了点流量，这类型问题会从线上日志里跳出来打脸。提前用原子更新，收益非常高。
我个人在实际项目里还有一个习惯：把所有外部调用和易错分支全量打印日志，但不打密码和 Token。论坛作为内容社区，日志里至少能看到谁在什么时间发了一篇带敏感词的帖子，管理员处理起来才有依据。这算是“安全性和排错性”之间的一个平衡，做内容产品的一定要放在心上。
到最后，你会发现基于 Spring Boot 的论坛网站是一个极其完整的全栈练习场景：它足够简单，让新手不会迷失在微服务里；它又足够真实，包含了用户认证、内容管理、计数统计、缓存、搜索、部署这些大厂项目会遇到的共性问题。把这个项目吃透，再去做博客、商城、内容管理系统，会发现绝大多数模块都能复用。希望这篇拆解能让你少走几趟弯路，把时间花在真正值得打磨的功能上。
