Spring Boot与MyBatis实战：构建校园匿名树洞心理健康平台

简介本资源是一个面向高校开发者与Java初学者的校园心理健康服务平台实战项目聚焦于解决学生心理困扰表达难、支持渠道少的问题提供匿名树洞、留言互动、心理测试、专家咨询等核心功能。压缩包共110个文件含76个Java业务类如UserController、AppointmentController等体现MVC分层、17张界面与图标JPG/PNG资源、4个MyBatis映射XML配置文件、3份说明文档MD格式、2个配置文件properties及构建脚本mvnw.cmd整体大小为4.73MB。已有187人学习下载项目结构规范完整呈现SpringBoot自动配置、MyBatis动态SQL封装、RESTful接口设计及前后端交互逻辑代码注释清晰数据库表设计合理适合作为Web全栈开发入门实践与课程设计参考。1. 项目缘起为什么我们需要一个校园“树洞”在校园里学生们面临着学业压力、人际关系、未来规划等多重挑战这些情绪需要一个安全、私密的出口。传统的心理咨询室预约制存在门槛而公开的社交平台又缺乏匿名性和安全感。这就是“校园树洞”类应用诞生的土壤——它像一个数字化的匿名倾诉墙允许学生以化名或完全匿名的方式发布心情、困惑或秘密并获得来自同龄人的共鸣、安慰或建议。我最近完成了一个名为“校园树洞-心理健康平台”的系统核心就是用Spring Boot和MyBatis这套经典组合拳快速搭建一个稳定、易维护的后端服务。选择这个技术栈原因很直接Spring Boot 的“约定大于配置”理念能让我快速搭建项目骨架避免在繁琐的 XML 配置上浪费时间而 MyBatis 作为一款半自动化的 ORM 框架在需要复杂 SQL 查询和高度定制化数据操作的场景下比如树洞帖子的多条件筛选、评论的分层查询比全自动化的 JPA/Hibernate 更加灵活可控。这个项目不仅仅是一个技术Demo它触及了校园场景下一个真实且迫切的需求如何用技术为心理健康提供一种低门槛、高包容性的支持方式。接下来我会从零开始拆解这个系统的核心设计、关键实现、以及那些在教程里不会写的“坑”和实战技巧。无论你是想学习 Spring Boot MyBatis 的实战集成还是对构建一个具有社交属性的 Web 应用感兴趣这篇文章都能给你提供一份可直接复现的“地图”。2. 系统架构与核心模块设计一个完整的“树洞”平台远不止一个发帖和看帖的功能。它需要兼顾匿名性、社区氛围、内容管理以及数据安全。我的系统主要分为以下几个核心模块用户匿名体系模块这是树洞的基石。用户无需实名注册系统通过设备标识如经过哈希处理的UUID或一次性会话Token来区分用户。核心是保证“同一设备”在一定周期内身份连贯以便管理自己的帖子但对其他用户完全匿名。内容发布与互动模块包括树洞帖子支持文本、图片、评论、点赞或暖心、拥抱等情感化交互。评论设计成可嵌套的以支持对话。内容过滤与安全模块这是重中之重。匿名环境易滋生不当言论必须集成敏感词过滤、图片鉴黄、甚至简单的情绪分析如识别极端消极内容并提示求助热线。后台管理模块供管理员审核内容、管理用户封禁违规设备标识、查看系统数据大盘。数据统计与看板模块匿名化统计每日发帖量、情绪标签分布、热门话题等为校园心理辅导工作提供数据参考。技术架构选型后端Spring Boot 2.7.x选择此稳定版本而非最新版避免踩坑新版本兼容性问题 MyBatis-Plus 3.5.x极大简化单表CRUD。数据库MySQL 8.0主要存储用户匿名标识、帖子、评论、审核日志等。缓存Redis用于存储会话Token、热点帖子、敏感词库提升响应速度。文件存储本地存储或集成OSS如阿里云OSS用于用户上传的图片。安全与过滤集成自建敏感词库DFA算法、第三方内容安全API如阿里云内容安全。部署通过 Docker 容器化便于在校园服务器或云主机上部署。这个架构在保证功能完整性的同时也考虑了校园环境内可能有限的服务器资源尽量选用轻量级、易维护的组件。2.1 数据库表结构设计要点数据库设计直接决定了业务逻辑的复杂度和性能。这里分享几个核心表的设计思路和避坑点。1. 树洞帖子表 (hole_post)CREATE TABLE hole_post ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, anonymous_id varchar(64) NOT NULL COMMENT 匿名用户标识哈希值, content text NOT NULL COMMENT 帖子内容过滤后, raw_content text COMMENT 原始内容审核用, image_urls varchar(1024) DEFAULT NULL COMMENT 图片链接JSON数组格式, emotion_tag varchar(20) DEFAULT NULL COMMENT 情绪标签如开心、烦恼、求助, is_anonymous tinyint(1) DEFAULT 1 COMMENT 是否匿名发布目前均为1, view_count int(11) DEFAULT 0 COMMENT 浏览数, like_count int(11) DEFAULT 0 COMMENT 点赞/暖心数, comment_count int(11) DEFAULT 0 COMMENT 评论数, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 状态0-待审核1-已发布2-审核驳回3-用户删除, audit_remark varchar(255) DEFAULT NULL COMMENT 审核备注, 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_anonymous_id (anonymous_id), KEY idx_status_createtime (status,create_time) COMMENT 用于审核队列和时间线查询 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT树洞帖子表;设计思考与避坑anonymous_id这里没有用自增ID关联用户表而是直接存储一个不可逆的哈希标识如MD5(设备ID 盐值)彻底切断与真实身份的关联。注意需要考虑设备更换的场景是否允许用户通过“口令”找回历史帖子这是一个产品决策点本系统暂未实现。raw_content和content这是一个重要的审计设计。raw_content存储用户原始输入用于后台审核追溯。content存储经过敏感词过滤、脱敏处理后的内容用于前端展示。两者分离既满足了安全审查需求又避免了前端展示时二次处理的开销。image_urls使用 JSON 格式存储多个图片链接如[/upload/abc.jpg, /upload/def.jpg]比用逗号分隔更规范方便前端直接JSON.parse()。字段长度1024需要根据业务预估防止溢出。status状态机明确的状态流转0-1-3 或 0-2是后台管理逻辑清晰的基础。常见坑直接物理删除帖子会导致评论数据“悬空”采用逻辑删除status3是更稳妥的做法。索引策略idx_status_createtime复合索引对于后台按审核状态和时间排序查询至关重要也能优化前端时间线瀑布流的查询性能status1按create_time倒序。2. 评论表 (hole_comment)嵌套评论或称“楼中楼”的设计是关键。我采用了经典的“路径枚举”方案而非邻接表递归查询效率低或嵌套集插入复杂。CREATE TABLE hole_comment ( id bigint(20) NOT NULL AUTO_INCREMENT, post_id bigint(20) NOT NULL COMMENT 所属帖子ID, parent_id bigint(20) DEFAULT 0 COMMENT 父评论ID0表示直接评论帖子, path varchar(255) NOT NULL DEFAULT COMMENT 评论路径格式父path-当前id, anonymous_id varchar(64) NOT NULL COMMENT 评论者匿名标识, content text NOT NULL COMMENT 评论内容, like_count int(11) DEFAULT 0, status tinyint(4) DEFAULT 1 COMMENT 状态1-正常2-删除, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_post_id (post_id), KEY idx_path (path(100)) COMMENT 用于查询子评论树 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;path字段详解假设帖子下第一条评论ID是100那么它的path就是100。对这条评论的回复ID是101那么path就是100-101。再对101的回复ID是102path就是100-101-102。优势查询某个评论的所有后代极其高效SELECT * FROM hole_comment WHERE path LIKE 100-% ORDER BY path一次查询就能按层级顺序取出整棵子树。插入操作需要先查询父评论的path然后拼接CONCAT(parent_path, -, #{newId})。这里有个技术难点newId在插入前是未知的。我的做法是先插入评论获取LAST_INSERT_ID()作为newId然后再用这个newId去更新本条记录的path字段。这需要在一个事务内完成或者使用 MyBatis 的SelectKey或useGeneratedKeys属性来获取插入后的主键。3. 敏感词库与审核日志表敏感词表 (sensitive_word) 很简单就是id和word。关键在于加载到内存Redis并使用 DFA 算法进行匹配速度极快。 审核日志表 (audit_log) 则记录每一次后台操作通过、驳回、删除包含操作者管理员、目标类型帖子/评论、目标ID、操作原因、时间等。这是满足内容监管合规性的重要依据。3. Spring Boot 与 MyBatis-Plus 的集成与高效配置项目采用 Spring Boot 来管理整个应用的生命周期和依赖用 MyBatis-Plus 作为数据访问层的主力。这一步的配置是基础但细节决定成败。3.1 Maven依赖与基础配置在pom.xml中除了标准的spring-boot-starter-web、mysql-connector-java外关键依赖如下dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.16/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency选择 Druid 连接池是因为它强大的监控和防 SQL 注入能力适合生产环境。MyBatis-Plus 版本建议选择当前稳定的次新版避免使用最新的3.5.4可能遇到一些与 Spring Boot 2.7 的兼容性小问题如某些自动配置顺序。application.yml的核心配置spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_hole?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword druid: initial-size: 5 min-idle: 5 max-active: 20 validation-query: SELECT 1 redis: host: localhost port: 6379 database: 0 lettuce: pool: max-active: 8 mybatis-plus: configuration: map-underscore-to-camel-case: true # 自动转换下划线命名到驼峰 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 开发环境开启SQL日志 global-config: db-config: logic-delete-field: status # 全局逻辑删除字段注意与业务字段区分 logic-delete-value: 2 # 逻辑已删除值 logic-not-delete-value: 1 # 逻辑未删除值 mapper-locations: classpath:mapper/*.xml # XML映射文件位置注意logic-delete-field的配置需要谨慎。如果业务表本身有一个status字段表示业务状态如0待审核1已发布那么全局逻辑删除配置会与之冲突。更佳实践是不在全局配置而是在每个需要逻辑删除的实体类字段上使用TableLogic注解单独指定这样更清晰避免混淆。3.2 MyBatis-Plus 实体类、Mapper 与 Service 的构建MyBatis-Plus 极大地简化了 DAO 层的代码。以HolePost实体类为例Data TableName(hole_post) public class HolePost { TableId(type IdType.AUTO) private Long id; private String anonymousId; private String content; private String rawContent; private String imageUrls; // 实际用String业务逻辑中处理JSON转换 private String emotionTag; private Integer viewCount; private Integer likeCount; private Integer commentCount; private Integer status; private String auditRemark; TableField(fill FieldFill.INSERT) private Date createTime; TableField(fill FieldFill.INSERT_UPDATE) private Date updateTime; // 非数据库字段用于前端展示 TableField(exist false) private ListString imageUrlList; }这里有两个实用技巧TableField(fill FieldFill.INSERT)配合一个元对象处理器MetaObjectHandler可以在插入时自动填充createTime。同样INSERT_UPDATE会在插入和更新时填充updateTime。这避免了在每个业务代码里手动set时间。imageUrlList作为非数据库字段我们可以在 Service 层从imageUrls这个 JSON 字符串中解析出来方便业务逻辑使用。反之在存入数据库前需要将List序列化成 JSON 字符串。对应的HolePostMapper接口极其简洁Repository public interface HolePostMapper extends BaseMapperHolePost { // 自定义复杂查询可以在这里定义方法并在对应的XML中实现 ListHolePost selectPageByCondition(Param(page) PageHolePost page, Param(query) PostQuery query); }BaseMapperHolePost已经提供了insert,selectById,updateById,deleteById,selectPage等所有基础 CRUD 方法。Service 层我习惯使用“Service Impl”的模式在接口中声明业务方法在实现类中注入BaseMapper并组合使用 MyBatis-Plus 提供的IService和ServiceImplpublic interface HolePostService extends IServiceHolePost { PageResultPostVO getPostPage(PostQuery query); Long publishPost(PostPublishDTO dto); // ... 其他业务方法 } Service public class HolePostServiceImpl extends ServiceImplHolePostMapper, HolePost implements HolePostService { Override public PageResultPostVO getPostPage(PostQuery query) { PageHolePost pageParam new Page(query.getPageNum(), query.getPageSize()); // 调用自定义的Mapper方法 ListHolePost records baseMapper.selectPageByCondition(pageParam, query); // 将HolePost转换为前端需要的PostVO并处理imageUrls等字段 ListPostVO voList convertToVOList(records); return new PageResult(voList, pageParam.getTotal()); } // ... 其他方法实现 }这种结构清晰地将数据访问Mapper、通用服务IService、业务逻辑自定义Service分离开。3.3 自定义SQL与XML映射文件编写虽然 MyBatis-Plus 的条件构造器QueryWrapper非常强大但对于多表关联、复杂动态查询编写 XML 映射文件仍然是更直观和可控的选择。例如上面selectPageByCondition方法的实现在HolePostMapper.xml中?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.campus.hole.mapper.HolePostMapper select idselectPageByCondition resultTypecom.campus.hole.entity.HolePost SELECT * FROM hole_post where status 1 !-- 只查询已发布的 -- if testquery.emotionTag ! null and query.emotionTag ! AND emotion_tag #{query.emotionTag} /if if testquery.keyword ! null and query.keyword ! AND content LIKE CONCAT(%, #{query.keyword}, %) /if if testquery.startTime ! null AND create_time #{query.startTime} /if if testquery.endTime ! null AND create_time #{query.endTime} /if /where ORDER BY create_time DESC /select /mapper这里有一个非常重要的性能陷阱SELECT *在表字段多、数据量大时会带来不必要的网络和内存开销。最佳实践是明确列出所需字段尤其是当你的实体类中有TableField(exist false)的字段时SELECT *可能会导致 MyBatis 映射结果时出现不可预知的问题虽然不常见但值得警惕。应该写成SELECT id, anonymous_id, content, image_urls, emotion_tag, view_count, like_count, comment_count, create_time FROM hole_post另一个关键点是#{}和${}的区别这是 MyBatis 面试必考题。简单来说#{keyword}会被预处理成?是安全的参数占位符能有效防止 SQL 注入。${orderBy}会直接进行字符串替换。绝对不要用${}来拼接用户输入的可变条件值这等同于打开 SQL 注入的大门。${}仅可用于动态指定列名、表名等非用户输入的元数据例如ORDER BY ${orderByField}但即便如此也需要在代码层面对orderByField的值进行严格的白名单校验。4. 核心业务逻辑实现与避坑指南4.1 匿名身份体系的实现如何在不收集个人信息的前提下识别用户我们采用“设备指纹” “客户端存储”的方案。生成匿名ID前端App或H5在用户首次访问时生成一个唯一的clientId可以使用UUID。将这个clientId与一个服务器下发的固定盐值salt拼接进行 MD5 或 SHA256 哈希得到anonymousId。关键点盐值不要硬编码在客户端应由后端在首次访问时动态下发可定期更换增加逆向难度。// 后端生成并返回给前端的初始化信息 GetMapping(/init) public Result initClient() { String salt generateRandomSalt(); // 生成一个随机盐可存入Redis并设置过期时间 String token UUID.randomUUID().toString(); // 会话Token redisTemplate.opsForValue().set(client:token: token, salt, 2, TimeUnit.HOURS); return Result.success(new InitVO(salt, token)); }前端存储前端将clientId和token持久化存储在localStorage或AsyncStorage中。每次请求时用存储的clientId和从后端获取的当前有效盐值可通过token关联计算anonymousId并携带token在请求头中。后端验证后端根据请求头中的token从 Redis 中取出对应的盐值再结合请求体或 header 中传来的clientId重新计算anonymousId。这个计算出的anonymousId就是该用户在本系统的唯一匿名标识用于创建帖子、评论、点赞等所有关联操作。安全性考量token应有有效期如2小时过期后前端需重新调用/init接口。同一个anonymousId在短时间内如1分钟发布内容频率需做限制防止刷屏。对于极端恶意行为后台可以将某个anonymousId加入黑名单禁止其发布。这个方案平衡了匿名性、用户体验和基础的安全管控。它无法防止用户卸载重装App获取新身份但这在树洞场景下是可以接受的我们的主要目标是防止自动化脚本攻击和营造健康的社区氛围而非追求绝对的身份追踪。4.2 内容发布与敏感词过滤流程发布一条树洞帖子的后端流程是多个技术点的集合Transactional(rollbackFor Exception.class) // 开启事务 public Long publishPost(PostPublishDTO dto, String clientId, String token) { // 1. 验证token和计算anonymousId String salt redisTemplate.opsForValue().get(client:token: token); if (StringUtils.isEmpty(salt)) { throw new BusinessException(会话已过期请刷新); } String anonymousId DigestUtils.md5DigestAsHex((clientId salt).getBytes()); // 2. 频率限制 (使用Redis incr) String rateKey post:rate: anonymousId; Long count redisTemplate.opsForValue().increment(rateKey, 1); if (count ! null count 1) { redisTemplate.expire(rateKey, 1, TimeUnit.MINUTES); // 设置1分钟过期 } if (count 5) { // 限制1分钟内最多5条 throw new BusinessException(发布过于频繁请稍后再试); } // 3. 敏感词过滤 (DFA算法) String filteredContent sensitiveWordFilter.filter(dto.getContent()); if (filteredContent.contains(SensitiveWordFilter.REPLACEMENT)) { // 含有敏感词 // 可以记录日志或给内容打上“待审核”标签 // 本系统策略替换敏感词为***并标记为待审核 filteredContent filteredContent.replace(SensitiveWordFilter.REPLACEMENT, ***); } // 4. 图片处理上传到OSS或本地生成URL列表 ListString imageUrlList new ArrayList(); for (MultipartFile file : dto.getImages()) { String url fileStorageService.upload(file); imageUrlList.add(url); } String imageUrlsJson JSON.toJSONString(imageUrlList); // 5. 构建实体并保存 HolePost post new HolePost(); post.setAnonymousId(anonymousId); post.setContent(filteredContent); // 过滤后的内容 post.setRawContent(dto.getContent()); // 原始内容存入数据库供审核 post.setImageUrls(imageUrlsJson); post.setEmotionTag(dto.getEmotionTag()); post.setStatus(filteredContent.contains(***) ? 0 : 1); // 含敏感词需审核 baseMapper.insert(post); // 6. 异步调用内容安全API进行更深度的审核如图片鉴黄、暴恐识别 contentAuditService.asyncAuditPost(post.getId(), dto.getContent(), imageUrlList); return post.getId(); }避坑点事务边界整个发布流程应在同一个Transactional事务中。如果文件上传第4步是调用外部OSS服务它可能不受本地事务控制。要确保在文件上传成功后再执行数据库插入否则可能出现数据不一致。一种更稳健的做法是先插入一条状态为“上传中”的记录异步进行文件上传和内容审核成功后更新记录状态。敏感词过滤性能敏感词库可能很大DFA算法初始化后内存占用尚可但每次过滤都是遍历。务必在应用启动时就将词库加载到内存或Redis避免每次请求都读数据库或文件。对于超长文本可以考虑分段过滤。图片上传一定要限制文件大小、类型MIME Type并在服务端做二次校验如图片实际格式检测防止用户篡改文件后缀上传恶意文件。存储路径建议使用“日期/随机文件名”的方式避免文件名冲突和目录文件数过多。4.3 嵌套评论的查询与组装这是树洞系统的另一个技术亮点。我们使用“路径枚举”法存储查询时需要高效地组装成树形结构返回给前端。Mapper XML 中的查询select idselectCommentTreeByPostId resultTypecom.campus.hole.entity.HoleComment SELECT * FROM hole_comment WHERE post_id #{postId} AND status 1 ORDER BY path ASC, create_time ASC /selectORDER BY path ASC是关键它能保证查询结果严格按照评论的层级和创建顺序排列。例如id | path ---|----- 100| 100 101| 100-101 102| 100-101-102 103| 100-103 104| 104查询结果就是这个顺序非常利于后续在内存中组装成树。Service 层组装逻辑public ListCommentVO getCommentTree(Long postId) { // 1. 查询出该帖子下所有状态正常的评论按path排序 ListHoleComment commentList commentMapper.selectCommentTreeByPostId(postId); if (CollectionUtils.isEmpty(commentList)) { return Collections.emptyList(); } // 2. 使用Map来快速查找父节点并组装树 MapLong, CommentVO voMap new LinkedHashMap(); // 保持插入顺序 ListCommentVO rootComments new ArrayList(); // 最终返回的根评论列表 // 第一遍遍历将所有评论转换为VO并放入Map for (HoleComment comment : commentList) { CommentVO vo convertToVO(comment); vo.setReplies(new ArrayList()); // 初始化子回复列表 voMap.put(comment.getId(), vo); } // 第二遍遍历根据parentId构建树形关系 for (HoleComment comment : commentList) { CommentVO currentVo voMap.get(comment.getId()); if (comment.getParentId() null || comment.getParentId() 0L) { // parentId为0或null是根评论 rootComments.add(currentVo); } else { // 找到父评论VO将当前评论加入其replies列表 CommentVO parentVo voMap.get(comment.getParentId()); if (parentVo ! null) { parentVo.getReplies().add(currentVo); } else { // 理论上不会发生除非数据不一致。可以记录日志或将其作为根评论 rootComments.add(currentVo); } } } return rootComments; }这个算法的时间复杂度是 O(n)效率很高。前端拿到这个已经组装好的树形结构可以直接递归渲染出嵌套的评论UI。性能优化思考对于评论量巨大的帖子如“热帖”一次性查询所有评论可能压力大。可以考虑分页加载但嵌套评论的分页是个难题。常见的折中方案是首次只加载前N条根评论按热度或时间点击“查看更多回复”时再单独加载某个根评论下的所有子评论。这就需要调整查询和组装逻辑。5. 部署、监控与性能优化考量5.1 使用Docker进行容器化部署将 Spring Boot 项目打包成 JAR然后通过 Docker 部署能保证环境一致性。一个简单的Dockerfile# 使用官方OpenJDK镜像作为基础镜像 FROM openjdk:11-jre-slim # 维护者信息 LABEL maintaineryour-emailexample.com # 设置时区 RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime echo Asia/Shanghai /etc/timezone # 在容器内创建一个应用目录 WORKDIR /app # 将构建好的jar包复制到容器内重命名为 app.jar COPY target/campus-hole-0.0.1-SNAPSHOT.jar app.jar # 暴露端口与application.yml中server.port一致 EXPOSE 8080 # 启动命令 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]构建和运行命令# 构建镜像 docker build -t campus-hole:latest . # 运行容器映射端口挂载配置文件如果需要和上传文件目录 docker run -d -p 8080:8080 \ -v /path/to/your/upload:/app/upload \ --name campus-hole \ campus-hole:latest生产环境建议使用docker-compose来编排应用、MySQL、Redis 等服务并配置好网络和卷挂载。5.2 关键监控与日志应用健康Spring Boot Actuator 提供/actuator/health端点集成到监控系统。SQL监控Druid 内置了强大的监控页面可以查看 SQL 执行情况、慢查询等。需要在配置中开启。日志收集使用 Logback 或 Log4j2将日志按级别输出到文件并通过ELK(Elasticsearch, Logstash, Kibana) 或EFK栈进行集中管理和分析。特别要记录审核操作、敏感词命中、异常请求等安全相关日志。业务指标使用 Micrometer 集成 Prometheus暴露业务指标如每日发帖量hole.post.publish.count、接口响应时间http.server.requests等再通过 Grafana 制作看板。5.3 性能优化点数据库层面索引优化如前所述在post_id,status,create_time,path等字段上建立合适的索引。使用EXPLAIN分析慢查询。查询优化避免SELECT *只取需要的字段。对于评论列表如果不需要立即加载全部子评论可以考虑延迟加载二次查询。分库分表单表数据量过大如帖子数超过千万时考虑。按时间如年份分表是常见策略。缓存策略热点数据将首页帖子列表、热门帖子详情缓存到 Redis设置合理的过期时间如5分钟。计数器缓存帖子浏览量view_count的更新非常频繁可以先用 Redis 的INCR命令累加再定时如每10分钟同步回数据库避免频繁更新数据库。会话信息用户的匿名会话信息token-salt映射本身就存在 Redis。图片处理CDN加速如果使用 OSS务必开启 CDN 加速提升图片加载速度。缩略图上传时生成不同尺寸的缩略图列表页使用小图详情页再加载原图。懒加载前端实现图片懒加载当图片进入视口时才加载。异步处理内容审核调用第三方内容安全 API 可能耗时必须做成异步如使用Async或消息队列避免阻塞主发布流程。通知提醒如果有点赞、评论通知功能也应异步处理。这个基于 Spring Boot 和 MyBatis 的校园树洞系统从技术选型到细节实现涵盖了后端开发的多个核心环节。它不仅仅是一个 CRUD 应用更涉及了匿名体系设计、复杂查询、内容安全、性能优化等实战问题。在实际开发中每一个环节都可能遇到意想不到的“坑”例如 MyBatis 枚举类型映射、事务失效、Redis 缓存穿透、Docker 容器时区问题等。解决这些问题没有银弹需要不断调试、查阅文档和积累经验。希望这个详细的拆解能为你提供一个坚实的起点你可以基于此进行扩展比如加入私信功能、话题标签、情绪分析图谱等让这个“树洞”更加温暖和智能。本文还有配套的精品资源点击获取