1. 论坛类项目的定位与整体架构思路去年有个做数码测评的朋友找到我说他们那个几百人的数码爱好者社群一直靠聊天群维系内容沉不下去好帖子三天就被刷没了想做个能长期沉淀内容、又能让大家按兴趣分板块讨论的论坛。这个需求其实特别典型——数码论坛系统看似是“老技术”但真要做好涉及并发、内容治理、检索、权限、缓存一致性这些硬骨头一点不比现在流行的应用简单。我前后花了大概六周把这个东西从零搭到能上线跑中间踩的坑足够写一篇长文。这篇文章就把整套设计、选型理由、核心代码和排查经验都摊开讲适合想自己动手做社区系统的开发者也适合接手存量论坛二次开发的同学参考。先说清楚这个“49数码论坛”大概是什么形态用户注册登录后可以按版块手机、相机、耳机、外设、二手、闲聊等发帖帖子支持图文混排和 Markdown支持多级评论、点赞、收藏、关注、私信通知顶部有热度排行榜站内全文检索做得比较细。它不是那种大厂级别的超大规模社区目标很明确——支撑几千到几万注册用户、日均几千帖的中小型数码社区单机多实例加一套中间件就够用成本可控维护简单。这个定位非常关键因为定位决定了你不会去上微服务全家桶不会搞消息队列集群也就避免了一堆维护负担。架构上我最终定的是前后端分离 单体分层的路子。后端用 Spring Boot 3 MyBatis-Plus数据库 MySQL 8缓存和计数用 Redis全文检索用 Elasticsearch图片走对象存储前端用 Vue 3 Element Plus整体用 Docker Compose 编排部署。为什么不上微服务因为对一个中小社区来说用户、帖子、评论这些模块之间的调用关系密到不行硬拆成服务分布式事务、链路追踪、服务发现的复杂度会直接吃掉你所有的开发时间。单体分层配合清晰的模块边界后期真到了瓶颈再按模块拆也完全来得及。1.1 为什么分层要“按领域切”而不是“按技术切”很多新手做分层喜欢按 Controller、Service、DAO 一刀切所有业务的 Controller 放一起、Service 放一起。项目小的时候看着整齐一旦帖子、评论、用户逻辑各自膨胀你会在一个巨大的 Service 包里迷路。我采用的是先按领域分包、领域内再分层的做法com.forum49 ├── user 用户域注册、登录、资料、关注 │ ├── controller │ ├── service │ ├── mapper │ └── model ├── content 内容域帖子、评论、标签 ├── interact 互动域点赞、收藏、通知 ├── search 检索域ES 索引、搜索 └── common 公共工具、异常、拦截器、配置这样每个域的改动都收敛在一个包内找代码不用全局搜索。更实际的好处是将来如果真要拆服务content这个包基本可以直接挪成一个独立服务迁移成本很低。这是我在第二个论坛项目里才悟到的教训——第一个项目按技术分层改一个发帖逻辑要在七八个目录里跳来跳去。1.2 核心依赖版本与选型理由版本这块我踩过坑特别是 Spring Boot 3 强制要求 JDK 17而有些老教程还在用 JDK 8混着来会编译报错。下面是我实际跑通的组合后面所有代码都基于这个环境组件版本选型理由JDK17 (LTS)Spring Boot 3 的最低要求长期支持稳定Spring Boot3.2.x生态成熟自带 Actuator 便于监控MyBatis-Plus3.5.x单表 CRUD 省事复杂查询仍可写 XMLMySQL8.0JSON 字段、窗口函数支持好社区资料多Redis7.x缓存、计数、分布式锁一把梭Elasticsearch8.x中文分词、相关性排序成熟Vue3.4组合式 API 写复杂交互更清爽Element Plus2.x表单、表格、分页组件开箱即用选 MyBatis-Plus 而不是 JPA是因为论坛里大量是“列表页 多条件筛选 分页”、排行榜这种偏 SQL 的活儿手写 SQL 心里更有底性能也更好控。JPA 在复杂关联查询上很容易生成一堆低效 SQL排查起来头疼。提示Spring Boot 3 里javax.*全部换成了jakarta.*如果你从旧项目拷代码第一件事就是全局替换包名否则一堆ClassNotFoundException。2. 数据库表结构设计与关键字段取舍表结构是论坛的地基地基歪了后面全歪。我见过不少论坛因为一开始表设计随意后面加个“多级评论”要改三张表。所以这一块我花了整整两天画 ER 图、推演各种查询场景下面把核心表讲透。2.1 用户表与内容表的核心设计用户表看着简单但有几点必须提前想好。密码绝对不能明文我用BCrypt加盐哈希用户名和邮箱都要唯一索引防止注册并发时插入重复数据再加一个status字段标记正常/禁言/封禁社区治理少不了它。CREATE TABLE t_user ( id BIGINT NOT NULL AUTO_INCREMENT, username VARCHAR(32) NOT NULL COMMENT 登录名, nickname VARCHAR(32) NOT NULL COMMENT 展示昵称, password VARCHAR(100) NOT NULL COMMENT BCrypt 哈希, email VARCHAR(64) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0正常 1禁言 2封禁, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;内容表这块是重点。帖子表除了标题正文还要冗余几个计数字段view_count、comment_count、like_count。为什么冗余因为列表页要显示这些数字如果每次都去 join 评论表 count 一遍列表页会直接卡死。冗余的代价是计数可能不一致这个后面用 Redis 做原子计数、定时回写来解决。CREATE TABLE t_post ( id BIGINT NOT NULL AUTO_INCREMENT, board_id INT NOT NULL COMMENT 所属版块, user_id BIGINT NOT NULL COMMENT 作者, title VARCHAR(120) NOT NULL, content MEDIUMTEXT NOT NULL COMMENT 正文 HTML/Markdown, content_type TINYINT NOT NULL DEFAULT 0 COMMENT 0Markdown 1富文本, view_count INT NOT NULL DEFAULT 0, comment_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 0 COMMENT 0正常 1隐藏 2删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_board_time (board_id, create_time), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意那个idx_board_time联合索引它是我列表页查询的关键。列表页默认按版块 时间倒序这个索引能直接命中避免全表扫描。2.2 多级评论与点赞表怎么设计才不返工评论是论坛里最容易被低估的部分。一开始我想简单点就做一级评论结果用户马上要求“楼中楼”。我的方案是用root_id和parent_id两字段做扁平化多级root_id指向这条评论所属的顶级评论用于快速拉取某条评论下的所有回复parent_id指向直接回复的那条评论用于显示“回复 某某”。这样只存一张表查一级评论按root_id 0查某楼所有回复按root_id 评论id都不用递归。CREATE TABLE t_comment ( id BIGINT NOT NULL AUTO_INCREMENT, post_id BIGINT NOT NULL, user_id BIGINT NOT NULL, root_id BIGINT NOT NULL DEFAULT 0 COMMENT 顶级评论id0为自己是顶级, parent_id BIGINT NOT NULL DEFAULT 0 COMMENT 直接回复对象, content TEXT NOT NULL, like_count INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_post_root (post_id, root_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;点赞表我用了联合唯一索引来天然防重CREATE TABLE t_like ( id BIGINT NOT NULL AUTO_INCREMENT, target_id BIGINT NOT NULL COMMENT 帖子或评论id, target_type TINYINT NOT NULL COMMENT 1帖子 2评论, user_id BIGINT NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_target (user_id, target_type, target_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;有了这个唯一索引即使用户疯狂点击点赞按钮数据库层也会直接拦截重复插入服务端只要捕获唯一键冲突异常就当“已点赞”处理比先查再插稳得多也少了一次查询。注意content我用了 MEDIUMTEXT因为数码帖经常有人贴超长的参数对比表TEXT 的 64KB 上限会被撑爆。3. 后端核心模块的实现与实操细节表设计定了之后就是写代码。这一部分我挑几个最容易出问题、也最能体现设计功力的模块来讲登录鉴权、发帖、点赞计数、评论树每个都给出关键实现和踩坑点。3.1 JWT 登录鉴权与防刷设计登录我用JWT Redis 白名单的组合。纯 JWT 有个致命问题没法主动失效用户改密码或者被封禁后旧 token 还是能用到过期。所以我在 Redis 里存一份 token 的 JTI唯一标识校验时不但验签名还查 Redis 里这个 JTI 是否还在。public String login(String username, String rawPassword) { User user userMapper.selectByUsername(username); if (user null || !passwordEncoder.matches(rawPassword, user.getPassword())) { throw new BizException(用户名或密码错误); } if (user.getStatus() 2) { throw new BizException(账号已被封禁); } String jti UUID.randomUUID().toString(); String token Jwts.builder() .setId(jti) .setSubject(String.valueOf(user.getId())) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600_000L)) .signWith(secretKey) .compact(); // 白名单7天过期和 token 同步 redisTemplate.opsForValue().set(token:jti: jti, user.getId(), 7, TimeUnit.DAYS); return token; }封号时直接删掉该用户所有 JTI 即可实现强制下线。注册接口一定要加验证码 IP 限流否则分分钟被脚本灌满垃圾账号。我用 Redis 做简单计数限流同一个 IP 一分钟内注册请求超过 5 次就拒绝。String key reg:limit: ip; Long cnt redisTemplate.opsForValue().increment(key); if (cnt 1) redisTemplate.expire(key, 1, TimeUnit.MINUTES); if (cnt 5) throw new BizException(操作过于频繁请稍后再试);3.2 发帖时的内容安全与 XSS 过滤用户发帖如果允许富文本等于把 XSS 攻击的大门打开。正文里塞一段script就能盗取其他用户的登录态。我的处理是白名单过滤只允许安全的标签和属性其余全部转义或剥离。private static final Safelist SAFELIST Safelist.relaxed() .addTags(figure, figcaption) // 允许图片说明 .addAttributes(img, src, alt, width, height) .addProtocols(img, src, http, https); public String clean(String dirtyHtml) { if (StringUtils.isBlank(dirtyHtml)) return ; return Jsoup.clean(dirtyHtml, , SAFELIST); }如果是 Markdown 模式我会用 CommonMark 渲染再走一遍同样的白名单清洗——因为你永远不知道渲染器会不会因为某个语法产生意外的 HTML。这两步缺一不可。发帖还有两个实操细节值得说一是标题长度限制在 120 字符以内太长的标题会破坏列表布局二是发帖内容要同步写一份到 ES否则搜不到新帖。我的做法是发帖事务提交后发一个事件异步建索引主流程不阻塞。Transactional public Long publish(PostDTO dto, Long userId) { String safeContent xssFilter.clean(dto.getContent()); Post post new Post(); // ... 赋值 postMapper.insert(post); // 事务提交后再建索引避免事务回滚导致脏索引 TransactionSynchronizationManager.registerSynchronization( new TransactionSynchronization() { Override public void afterCommit() { searchService.indexPost(post); } }); return post.getId(); }提示索引一定放在事务提交之后做。我早期图省事直接在事务里建索引结果事务回滚了ES 里却多了一条幽灵帖用户搜到点进去是空的排查了半天。3.3 点赞计数Redis 原子操作 定时回写点赞是并发最高、最容易把数据库打挂的操作。如果每次点赞都update t_post set like_count like_count 1热点帖能瞬间产生大量行锁。我的方案是Redis 存增量定时批量回写。public void like(Long targetId, int targetType, Long userId) { String likeKey like: targetType : targetId; Boolean ok redisTemplate.opsForSet().isMember(likeKey, userId); if (Boolean.TRUE.equals(ok)) { throw new BizException(你已经点过赞了); } redisTemplate.opsForSet().add(likeKey, userId); redisTemplate.opsForHash().increment(like:delta, likeKey, 1); }然后用一个定时任务每 5 分钟把like:delta里的增量批量刷回数据库并清空已刷的 field。这样数据库压力从“每次点赞一次写”降为“每 5 分钟一批写”。点赞数展示时读的是“数据库值 Redis 增量未回写部分”保证用户看到的是实时的。要注意回写任务的重试。如果回写半途失败增量不能丢。我的做法是先读出增量、写库成功后再删 field如果写库失败就保留下个周期重试。宁可重复刷下面会讲怎么幂等也不能丢。3.4 评论树的组装与 N1 问题规避前面说了评论表用root_id扁平化存。查询时一级评论分页查出来再一次性把这一页所有评论的所有回复查出来在内存里组装成树。千万不要循环查每一条评论的回复那就是经典 N1 查询一页 20 条评论能发出 21 条 SQL。// 第一步查一页顶级评论 ListComment roots commentMapper.selectRootPage(postId, offset, size); if (roots.isEmpty()) return Collections.emptyList(); // 第二步一次性查这些顶级评论下的所有回复 ListLong rootIds roots.stream().map(Comment::getId).toList(); ListComment replies commentMapper.selectByRootIds(rootIds); // 第三步内存组装 MapLong, ListComment replyMap replies.stream() .collect(Collectors.groupingBy(Comment::getRootId)); roots.forEach(r - r.setReplies( replyMap.getOrDefault(r.getId(), Collections.emptyList())));回复如果特别多比如某条引战评论下几百条回复一次性全查也会拖慢。我的处理是每楼最多展示 3 条最新回复 “查看全部 N 条回复”点开再单独分页拉取。这个是产品层面的取舍也是性能层面的必要妥协。4. 全文检索与前端交互的关键实现论坛内容一旦上千帖靠数据库LIKE %关键词%搜索就彻底玩不转了不光慢还搜不准。搜索引擎这块和前端体验是用户感知最强的部分值得单独拉出来讲。4.1 Elasticsearch 索引映射与中文分词中文搜索最大的坑是分词。ES 默认的 standard 分词器是按字切的“数码相机”会被切成“数、码、相、机”搜索体验灾难。我装了IK 分词器并定义了索引映射标题权重高于正文。PUT /forum_post { mappings: { properties: { postId: { type: long }, title: { type: text, analyzer: ik_max_word, search_analyzer: ik_smart, boost: 3 }, content: { type: text, analyzer: ik_max_word, search_analyzer: ik_smart }, boardId: { type: integer }, userId: { type: long }, createTime: { type: date } } } }ik_max_word用于建索引时尽量细粒度切ik_smart用于查询时粗粒度切这样召回率和准确率都兼顾。标题设boost: 3让标题命中的帖子排前面符合用户直觉。搜索时还要支持按版块过滤和时间筛选用 bool query 组合{ query: { bool: { must: { multi_match: { query: 降噪耳机, fields: [title^3, content] } }, filter: { term: { boardId: 3 } } } }, highlight: { fields: { title: {}, content: { fragment_size: 100 } } } }高亮字段返回给前端展示。搜索页最怕的是新发的帖子搜不到所以前面讲的“事务提交后异步建索引”必须可靠我还加了一个补偿任务每小时比对 MySQL 里更新时间和 ES 里文档时间把漏掉的补进去。4.2 帖子详情页与缓存策略帖子详情页是全站访问量最高的页面必须上缓存。我用Cache-Aside 模式读的时候先查 Redis没有就查 MySQL 再回填写的时候更新数据库并删除缓存。public PostVO getPostDetail(Long postId) { String key post:detail: postId; PostVO cached (PostVO) redisTemplate.opsForValue().get(key); if (cached ! null) return cached; Post post postMapper.selectById(postId); if (post null || post.getStatus() ! 0) { // 缓存空值防穿透短过期时间 redisTemplate.opsForValue().set(key, NULL_PLACEHOLDER, 60, TimeUnit.SECONDS); throw new BizException(帖子不存在); } PostVO vo buildVO(post); // 加随机过期时间防缓存雪崩 long ttl 300 ThreadLocalRandom.current().nextInt(60); redisTemplate.opsForValue().set(key, vo, ttl, TimeUnit.SECONDS); return vo; }这里有两个防坑点。防穿透查不存在的帖子时缓存一个空占位符否则恶意请求会一直打到数据库。防雪崩过期时间加随机数避免一大批缓存同时失效把数据库冲垮。浏览量计数我没走高并发的 Redis 方案因为帖子详情页本身有缓存直接view_count 1请求量已经可控用 MySQL 的原子自增就够。等哪天真成瓶颈再迁移不必过早优化。4.3 前端列表虚拟滚动与富文本渲染前端我遇到的最大性能问题是长列表卡顿。帖子列表如果一次渲染几百个 DOM 节点滚动会掉帧。解决方法是分页 下拉加载每页 20 条配合IntersectionObserver做触底自动加载。如果帖子卡片信息很重多个缩略图那种还可以上虚拟滚动只渲染视口内可见的卡片。const observer new IntersectionObserver((entries) { if (entries[0].isIntersecting !loading.value hasMore.value) { page.value loadPosts() } }, { rootMargin: 200px })富文本渲染要注意后端已经过滤过 XSS前端用v-html展示是相对安全的但最好还是再套一层 DOMPurify 做二次防护尤其是二手交易版块用户发的内容比较杂。import DOMPurify from dompurify const safeHtml computed(() DOMPurify.sanitize(post.content))评论组件的多级回复我用递归组件把评论结构传给子组件自己递归渲染。注意加max-depth限制比如只显示三层更深的直接平铺否则深层嵌套的缩进会把窄屏用户的评论区挤成一条竖线。5. 部署上线、性能调优与常见问题排查代码写完了能不能稳定跑起来是另一回事。上线这套东西我用的是 Docker Compose一台 4 核 8G 的服务器就跑得挺顺。这一部分讲讲部署要点和那些真金白银踩出来的坑。5.1 Docker Compose 编排与 Nginx 反代各组件我用一个 compose 文件编排网络内部互通只有 Nginx 暴露到外面。MySQL、Redis、ES 都不对公网开放端口安全第一。services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_PWD} volumes: - ./data/mysql:/var/lib/mysql networks: [forum] redis: image: redis:7-alpine command: redis-server --appendonly yes volumes: - ./data/redis:/data networks: [forum] es: image: elasticsearch:8.11.0 environment: - discovery.typesingle-node - ES_JAVA_OPTS-Xms1g -Xmx1g networks: [forum] app: build: . depends_on: [mysql, redis, es] networks: [forum] networks: forum:两个实操提醒MySQL 一定要挂数据卷容器删了数据不能丢ES 单独限一下 JVM 内存它默认会吃掉主机一半内存跟别的服务抢资源。Nginx 那边配好 gzip、静态资源缓存和 API 反代前端打包产物直接丢 Nginx 目录。5.2 常见问题速查表下面这个表是我上线初期每天都要翻的基本覆盖了 90% 的故障现象可能原因排查方向解决办法帖子列表越来越慢索引失效、深分页EXPLAIN看执行计划保证命中联合索引深分页改游标点赞数对不上Redis 增量未回写/重复刷查like:delta残留回写幂等 定时校对新帖搜不到索引事件丢失查 ES 文档数与 MySQL 差异加小时级补偿任务图片上传超时Nginx 请求体限制查client_max_body_size调大限制并做前端压缩登录态随机失效Redis 被清或 JTI 丢失查 Redis 内存与持久化AOF 持久化 内存扩容评论区缩进错乱递归层级过深检查最大深度限制超过三层平铺显示深分页这个坑单独说一下。limit 100000, 20这种查法MySQL 会先扫过前十万行再丢弃越翻越慢。我的处理是游标分页记住上一页最后一条的id下一页查where id lastId order by id desc limit 20。列表页和评论区都改成这个模式后翻到第一百页也是毫秒级。5.3 我个人踩过的三个真实坑第一个坑是自增主键暴露业务量。帖子 ID 直接连号展示出来有心人一看就知道站里总共多少帖。后来我把对外展示的 ID 换成了雪花算法生成的 long连续性好很多。第二个坑是验证码被绕过。早期验证码校验成功后没把验证码从 Redis 删掉同一个验证码能反复用被脚本钻了空子批量注册。修起来就一行代码——校验成功后立即delete。第三个坑最隐蔽Redis 和数据库的计数加了两次。因为回写任务用了“读增量 - 写库 - 删 field”的流程有次网络抖动导致删 field 失败下个周期又读了一遍同样的增量刷进去计数就多了。后来我在回写时用了幂等键 记录已回写批次才彻底解决。这个教训告诉我凡是“读-改-删”三步走的地方都要假设中间步骤会失败。6. 二次开发与后续可扩展的方向上线跑了半年这套系统基本稳定中间做过几次迭代。如果你是接手类似的论坛项目或者想在这套基础上继续加功能有几个方向投入产出比很高。比如站内消息中心我原来只做了私信后来加了“有人回复你”“有人点赞你”的系统通知用户活跃度肉眼可见地涨实现上无非是多一张通知表加一个未读数 Redis 缓存。再比如用户等级和积分体系发帖、被赞、连续签到都加积分配合等级头衔对社区氛围的刺激非常直接。还有一块是内容治理。数码论坛难免有人发广告、引战。我加的关键词敏感词过滤是第一道防线用 DFA 算法做前缀树匹配比正则快得多后续可以接一个简单的文本分类模型做辅助。二手交易版块还要额外加防诈骗提示和交易信用记录这块规则性强靠产品设计比靠算法有效。最后分享一个心得中小论坛真正的技术瓶颈很少是“量太大”而是设计时想得不够远。表结构、缓存键命名、索引规划这些前期多花一天后面能省一周的返工。我第一个论坛项目因为帖子表没冗余计数后期列表页优化整整重构了一轮。这一套东西你照着搭下来跑个几万用户的小社区绰绰有余剩下的就像我常跟同行说的——先让它跑起来再用真实流量告诉你去优化哪儿。