简介这是一套面向计算机专业课程设计与Java EE系统开发学习者的影视创作论坛项目包选题围绕影视资讯、幕后创作心得、观众观影体验与心得交流等场景展开可用于课程设计、毕业设计参考或Java Web综合实战练习。压缩包共142个文件以xml、rels等文档结构文件为主辅以png、jpeg等图像素材整体约54.95MB其中程序源代码便于运行调试与二次修改数据库对应后台数据建模论文教程则帮助理解需求分析、模块划分与实现过程。已有488人学习下载在同类影视社区类选题中具有一定参考价值。读者可从中了解论坛的功能划分、页面素材组织方式和数据库配套方案适合需要完成影视交流类Web项目、对照论文梳理开发流程并查漏补缺的开发者使用。1. 影视创作论坛选题落点为什么这套课程设计坚持走 JavaEE 原生路线做影视创作论坛这个计算机专业课程设计最容易出问题的地方是选题被“论坛”两个字带偏——很多人一上手就堆脚手架结果答辩时被追问“你的 JavaEE 到底体现在哪一层”当场答不上来。这套基于 JavaEE 的影视创作论坛把范围收得很清楚它是面向剧本、分镜、拍摄、后期、器材五类创作话题的垂直讨论社区核心是用户与角色、版块、主题帖、回帖、附件共享、后台审核这六个闭环模块走的是 Servlet 容器 JSP 视图 服务层 MySQL 的经典系统开发路线。它适合两类人一类是要交课程设计、需要结构完整且能逐行讲清楚的在校学生另一类是要拿一份可改可扩的论坛骨架去做二次开发的人。整套东西的重点不在技术新奇而在分层清楚、表结构能解释、每个功能都能当场演示。2. 需求拆解与数据模型六张核心表撑起剧本、分镜与回帖论坛这类系统需求看起来人人都懂真动手才会发现分歧全在细节附件要不要版本管理、回帖要不要支持楼中楼、版块删除了帖子怎么办。这些分歧如果不提前定下来写到一半改表结构前面的代码基本要重来。所以这套方案的第一步不是建工程而是把创作流程翻译成功能边界再翻译成表。2.1 从创作流程反推功能边界影视创作论坛和通用水吧的最大差别是内容载体不一样。通用论坛以纯文本为主影视创作话题里剧本是 docx 或 pdf分镜是成组的 jpg拍摄计划是表格调色参考是截图纯文字帖反而少。这决定了三件事附件必须是核心能力而不是附属功能帖子必须带“创作阶段”标签否则版块会被“求推荐器材”和“第三幕节奏怎么调”混在一起回帖必须支持引用楼层因为剧本讨论经常是“针对第 12 楼那句台词”。顺着这个逻辑把功能边界划死只做版块浏览、发帖回帖、附件上传下载、收藏、站内搜索、举报与后台审核。不做即时通讯不做视频在线转码不做复杂的关注关系链。课程设计的评分点从来不是功能数量而是你有没有把一条链路做透——发帖这条链路上参数校验、敏感词、审核状态、附件绑定、列表刷新能完整跑通并且每步都讲得出理由比堆十个半成品模块强得多。角色设计也要克制。四级足够游客只能浏览已发布内容注册会员可以发帖回帖、上传附件、收藏认证创作者额外拥有原创剧本区的发帖权限这个角色由管理员手工授予用来模拟社区的创作者认证版主负责本版块的置顶、加精、删帖管理员管用户、版块、敏感词和全站审核。四级角色的权限差异必须体现在后端拦截上而不是前端把按钮藏起来——这一点后面会专门讲。2.2 六张核心表与字段取舍表结构是整个方案的地基字段取舍要能解释给答辩老师听。用户表存盐值和摘要而不存明文这是底线帖子表冗余回帖数和最后回复时间是为了列表页不用每行都去 count附件表只存相对路径不存二进制是为了备份和迁移回帖表用 parent_id 加 path 两个字段同时表达父子关系和查询路径这是楼中楼能不能一把查出来的关键。-- 用户表密码只存盐 摘要role_code 与拦截器里的注解值一一对应 CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE COMMENT 登录名注册时校验唯一, password CHAR(64) NOT NULL COMMENT SHA-256(salt 明文) 的十六进制摘要, salt CHAR(16) NOT NULL COMMENT 每个用户独立随机盐, nickname VARCHAR(32) NOT NULL COMMENT 展示昵称可重复, role_code VARCHAR(16) NOT NULL DEFAULT MEMBER COMMENT MEMBER/AUTHOR/REVIEWER/ADMIN, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 正常 0 禁用, create_time DATETIME NOT NULL, KEY idx_role_status (role_code, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户; -- 版块表sort_no 控制前台顺序stage_code 用于和帖子标签做一致性校验 CREATE TABLE t_board ( id BIGINT PRIMARY KEY AUTO_INCREMENT, board_name VARCHAR(32) NOT NULL, board_desc VARCHAR(200) DEFAULT NULL, stage_code VARCHAR(16) NOT NULL COMMENT SCRIPT/STORYBOARD/SHOOT/POST/EQUIP, sort_no INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1, UNIQUE KEY uk_board_name (board_name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT版块; -- 主题帖表reply_count 与 last_reply_time 是刻意冗余供列表页直接读取 CREATE TABLE t_topic ( id BIGINT PRIMARY KEY AUTO_INCREMENT, board_id BIGINT NOT NULL, user_id BIGINT NOT NULL, title VARCHAR(60) NOT NULL, content MEDIUMTEXT NOT NULL, stage_code VARCHAR(16) NOT NULL, status TINYINT NOT NULL DEFAULT 2 COMMENT 0草稿 1待审 2已发布 3驳回 9已删除, is_top TINYINT NOT NULL DEFAULT 0, is_essence TINYINT NOT NULL DEFAULT 0, view_count INT NOT NULL DEFAULT 0, reply_count INT NOT NULL DEFAULT 0, last_reply_time DATETIME DEFAULT NULL, create_time DATETIME NOT NULL, KEY idx_board_list (board_id, status, is_top DESC, create_time DESC), KEY idx_user (user_id, create_time DESC) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT主题帖; -- 回帖表path 形如 0/12/45/既能拼楼层又能一次查出整棵子树 CREATE TABLE t_reply ( id BIGINT PRIMARY KEY AUTO_INCREMENT, topic_id BIGINT NOT NULL, parent_id BIGINT NOT NULL DEFAULT 0 COMMENT 0 表示直接回复主题, user_id BIGINT NOT NULL, content TEXT NOT NULL, floor INT NOT NULL COMMENT 主楼层号楼中楼继承父楼层, path VARCHAR(255) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 正常 9 已删除, create_time DATETIME NOT NULL, KEY idx_topic_page (topic_id, status, floor), KEY idx_path (topic_id, path) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT回帖; -- 附件表只存相对路径物理文件放在独立的 upload 根目录 CREATE TABLE t_attachment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, topic_id BIGINT DEFAULT NULL COMMENT 发帖前为 NULL发帖成功后绑定, reply_id BIGINT DEFAULT NULL, user_id BIGINT NOT NULL, origin_name VARCHAR(200) NOT NULL COMMENT 原始文件名下载时还原, store_path VARCHAR(255) NOT NULL COMMENT yyyy/MM/dd/uuid.ext, file_size BIGINT NOT NULL, file_ext VARCHAR(16) NOT NULL, download_cnt INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL, KEY idx_topic (topic_id), KEY idx_user_unbound (user_id, topic_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT附件;字段里有两个地方值得单独说明。一是t_topic.reply_count这种冗余字段很多人第一反应是“反范式不优雅”但论坛列表页一屏二十条帖子如果每条都去t_reply做一次 count列表页就是二十次聚合查询数据量一上来直接拖垮首屏。冗余的代价是回帖时必须同步更新这在事务里一行 update 就解决属于典型的拿写入换读取。二是t_reply.path这个设计。只存 parent_id 的邻接表写法查整棵子树要递归MySQL 里没有现成的递归语法早期版本只能在 Java 里一层层查N1 问题躲不掉。加上 path 字段后查某个楼层下的全部楼中楼只要一句WHERE path LIKE 0/12/%一次查询拿全前端自己拼树。代价是插入时要先查父节点的 path 再拼接这点开销完全可以接受。2.3 索引与冗余字段让版块列表页不打满数据库索引不是建得越多越好课程设计里最常见的错误是给每个字段都挂一个 KEY结果插入变慢、执行计划还乱。这套方案里真正必要的索引只有四个t_topic上的(board_id, status, is_top DESC, create_time DESC)服务于版块列表顺序不能改因为最左前缀必须从 board_id 开始(user_id, create_time DESC)服务于“我的帖子”t_reply上的(topic_id, status, floor)服务于帖子详情页的分页t_attachment上的(user_id, topic_id)服务于发帖时把游离附件绑定到新帖。分页本身也有个容易翻车的点。LIMIT 10000, 20这种深翻页在帖子量上万后会明显变慢因为它要扫描前一万行再丢弃。课程设计的量级通常到不了但答辩时被问到要有话说可以改成基于create_time的游标分页前端传上一页最后一条的时间戳SQL 变成WHERE create_time #{lastTime} ORDER BY create_time DESC LIMIT 20配上联合索引就是稳定的索引扫描。这个改动不大但能明显体现你考虑过数据量增长。提示is_top DESC这种写法在部分 MySQL 版本里对联合索引的利用不理想如果发现置顶帖排序走了 filesort把置顶单独拆成一次查询再在前端合并比强行调索引更省事。3. 分层架构与权限设计三层职责边界与四级角色的拦截落地架构这一章最怕写成“表示层、业务层、持久层各司其职”这种谁都会说的话。真正需要交代清楚的是哪些逻辑必须放在服务层哪些校验放在控制器就够了权限判断为什么一定要在后端做一次而不是靠隐藏按钮。3.1 包结构与三层职责边界工程按功能分包而不是按技术分层分到最细是这套方案的一个取舍。按controller / service / mapper / domain / common五个顶层包组织每个包里再按业务分user、board、topic、reply、attach、admin好处是改一个功能时相关文件集中在一处不用在三个大包里来回找。职责边界定三条硬规矩。第一控制器只做三件事接收参数、调用服务、选择视图或返回 JSON不写业务判断尤其不写 SQL 拼装。第二服务层负责事务边界、状态机流转、跨表操作凡是涉及两张以上表的写操作一律加Transactional(rollbackFor Exception.class)并且明确指定回滚异常类型不要用默认值——默认只对运行时异常回滚受检异常照样提交这是血泪经验。第三持久层只做单表或少表查询复杂的关联查询写在 XML 映射里并保证结果集字段和实体一一对应不在 Java 里做二次拼装。// 服务层典型写法事务边界 状态机 跨表同步三件事都在这一层收口 Service public class ReplyService { Resource private ReplyMapper replyMapper; Resource private TopicMapper topicMapper; Resource private SensitiveWordHolder sensitiveWordHolder; /** * 发表回帖写回帖、拼 path、维护主题帖冗余字段三步必须同一事务 * param topicId 主题帖主键必须已发布状态 * param parentId 父回帖主键0 表示直接回复主题 * param content 正文长度与敏感词在此校验 * param user 当前登录用户从会话取禁止由前端传入 */ Transactional(rollbackFor Exception.class) public void reply(long topicId, long parentId, String content, LoginUser user) { Topic topic topicMapper.selectForUpdate(topicId); // 行锁防止楼层号并发重复 if (topic null || topic.getStatus() ! TopicStatus.PUBLISHED) { throw new BizException(主题不存在或尚未通过审核); } Reply parent parentId 0 ? replyMapper.selectById(parentId) : null; int floor parent null ? topic.getReplyCount() 1 : parent.getFloor(); String path parent null ? 0/ : parent.getPath() floor /; Reply reply new Reply(); reply.setTopicId(topicId); reply.setParentId(parentId); reply.setUserId(user.getUserId()); reply.setContent(content); reply.setFloor(floor); reply.setPath(path); reply.setStatus(1); reply.setCreateTime(new Date()); replyMapper.insert(reply); // 冗余字段同步只更新计数与最后回复时间不整行更新 topicMapper.increaseReplyCount(topicId, reply.getCreateTime()); if (sensitiveWordHolder.hit(content)) { replyMapper.markPending(reply.getId()); // 命中敏感词转人工复审不直接拒绝 } } }这段代码里有三个参数值得说清楚。parentId传 0 表示直接回复主题此时楼层号取主题帖当前回帖数加一传具体回帖 id 时楼层号继承父节点这样楼中楼在视觉上不会打乱主楼层顺序。path的拼接规则是父节点路径加上当前楼层号再加斜杠根路径固定为0/这个约定让后续查询子树的 LIKE 条件变成固定模式。第三处是selectForUpdate的行锁不加锁的话两个用户同时回帖会拿到相同的楼层号前端就会出现两个“3 楼”这种问题在演示时特别显眼。3.2 登录态方案Session 集中管理与会话刷新登录态用 Session 还是 Token课程设计里经常被拿来讨论。这套方案选 Session理由很实在容器本身就管会话生命周期JSP 页面直接能取不需要额外引入令牌签发和校验的复杂度答辩时也容易讲清楚。代价是横向扩展麻烦但课程设计是单机部署这个代价不存在。会话里存的东西要克制。只存一个精简的LoginUser对象id、昵称、角色编码、头像路径不要把整个用户实体塞进去——实体里往往带着密码摘要和盐一旦会话序列化出问题或者被误打到日志里就是安全事故。用户修改资料后要么同步刷新会话里的副本要么在拦截器里按 id 回查一次缓存两个做法都有前者省查询但容易忘记刷新后者多一次查询但永不脏数据。我一般选后者配上本地缓存一次请求最多一次缓存命中。// 登录校验与写入会话只放必要字段避免会话膨胀和敏感信息外泄 public LoginUser login(String username, String rawPassword) { User user userMapper.selectByUsername(username); if (user null || user.getStatus() ! 1) { throw new BizException(账号或密码错误); // 不区分“用户不存在”和“密码错”防止枚举 } String digest DigestUtils.sha256Hex(user.getSalt() rawPassword); if (!digest.equalsIgnoreCase(user.getPassword())) { throw new BizException(账号或密码错误); } LoginUser session new LoginUser(); session.setUserId(user.getId()); session.setNickname(user.getNickname()); session.setRoleCode(user.getRoleCode()); session.setLoginTime(System.currentTimeMillis()); return session; }注意错误提示的处理。很多同学会写“该用户不存在”和“密码错误”两条不同提示看起来友好实际给了撞库的人一个免费的账号枚举接口。统一成一句模糊提示是这类系统最基本的安全习惯答辩时主动说出来是加分项。3.3 权限矩阵与注解式拦截器权限如果不落在拦截器上就等于没有。前端把按钮隐藏只能防住正常用户手动改个请求地址照样能删帖。所以这套方案把权限判断做成方法级注解由拦截器统一处理控制器代码里看不到一句 if 判断角色。操作游客会员认证创作者版主管理员浏览已发布帖子允许允许允许允许允许发帖 / 回帖禁止允许允许允许允许上传附件禁止允许允许允许允许在原创剧本区发帖禁止禁止允许允许允许置顶 / 加精 / 删本版帖禁止禁止禁止允许允许审核待审内容禁止禁止禁止允许允许用户封禁 / 版块管理禁止禁止禁止禁止允许// 方法级权限注解value 是允许的角色集合任一命中即放行 Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); } // 拦截器先判登录再判角色最后放行异常路径统一跳登录页或 403 页 public class RoleInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod hm (HandlerMethod) handler; RequireRole anno hm.getMethodAnnotation(RequireRole.class); if (anno null) { anno hm.getBeanType().getAnnotation(RequireRole.class); } if (anno null) { return true; // 未标注即公开接口如版块列表 } LoginUser user (LoginUser) req.getSession().getAttribute(LOGIN_USER); if (user null) { resp.sendRedirect(req.getContextPath() /login?redirect encode(req.getRequestURI())); return false; } for (String role : anno.value()) { if (role.equals(user.getRoleCode())) { return true; } } resp.setStatus(HttpServletResponse.SC_FORBIDDEN); req.getRequestDispatcher(/WEB-INF/views/error/403.jsp).forward(req, resp); return false; } }拦截器里有个顺序问题必须注意先判登录再判角色。如果反过来游客访问一个需要版主权限的接口会先得到一个 403这等于告诉他“这个接口存在但你没权限”而正确做法是先引导他去登录。另外redirect参数一定要做白名单校验或只接受站内相对路径否则就是一个现成的开放重定向漏洞。4. 核心模块实现发帖状态机、附件存储与回帖树到这一层方案要回答的是“具体怎么写”。三个模块最有讲头发帖为什么要引入状态机而不是简单的已发布/已删除两态附件为什么只存相对路径回帖列表的排序和分页怎么兼顾主楼层和楼中楼。4.1 发帖链路参数校验、敏感词与审核状态机两态设计已发布、已删除在演示阶段够用但只要加上举报和审核就撑不住了被举报的帖子该是什么状态版主驳回的帖子作者能不能改所以这套方案用五态草稿 0、待审 1、已发布 2、驳回 3、已删除 9。合法流转只有四条草稿到待审、待审到已发布、待审到驳回、已发布到已删除。驳回的帖子允许作者编辑后重新提交待审这条回流路径让作者不至于白写一篇。状态值统一放在一个常量类里前后端都引用同一套编码不要在前端硬编码数字。Service public class TopicService { private static final int TITLE_MIN 4; private static final int TITLE_MAX 60; private static final int CONTENT_MAX 20000; Resource private TopicMapper topicMapper; Resource private AttachmentMapper attachmentMapper; Resource private SensitiveWordHolder sensitiveWordHolder; /** * 发布主题帖先落库拿到主键再把发帖前上传的游离附件绑定上来 * param form 前端表单含版块、标题、正文、阶段标签、附件 id 列表 * param loginUser 会话中的当前用户作者身份由此确定不接受表单传 userId * return 新帖主键供前端跳转详情页 */ Transactional(rollbackFor Exception.class) public long publish(TopicForm form, LoginUser loginUser) { String title form.getTitle() null ? : form.getTitle().trim(); if (title.length() TITLE_MIN || title.length() TITLE_MAX) { throw new BizException(标题长度需在 4 到 60 字之间); } if (form.getContent() null || form.getContent().trim().isEmpty() || form.getContent().length() CONTENT_MAX) { throw new BizException(正文不能为空且不超过 20000 字); } // 版块与阶段标签必须一致避免“器材交流”版里出现剧本贴 Board board boardMapper.selectById(form.getBoardId()); if (board null || board.getStatus() ! 1 || !board.getStageCode().equals(form.getStageCode())) { throw new BizException(版块与创作阶段不匹配); } int status sensitiveWordHolder.hit(title form.getContent()) ? TopicStatus.PENDING : TopicStatus.PUBLISHED; Topic topic new Topic(); topic.setBoardId(board.getId()); topic.setUserId(loginUser.getUserId()); topic.setTitle(title); topic.setContent(form.getContent()); topic.setStageCode(form.getStageCode()); topic.setStatus(status); topic.setCreateTime(new Date()); topicMapper.insert(topic); // 附件绑定放在同一事务内绑定失败则整帖回滚不留下无主附件 if (form.getAttachmentIds() ! null !form.getAttachmentIds().isEmpty()) { int bound attachmentMapper.bind(topic.getId(), form.getAttachmentIds(), loginUser.getUserId()); if (bound ! form.getAttachmentIds().size()) { throw new BizException(部分附件不存在或不属于当前用户); } } return topic.getId(); } }这段代码有三处设计说明。版块与阶段标签的一致性校验看起来多余实际是数据质量的第一道闸门——如果不校验前端只要改个下拉框就能把剧本贴发进器材版运营两天就乱了。敏感词命中后转待审而不是直接拒绝是因为创作讨论里天然会出现一些擦边词汇比如影评里引用台词一刀切拒绝会误伤大量正常内容转人工复审是更负责的做法。附件绑定的返回值校验是关键bind语句里带了user_id #{userId}和topic_id IS NULL两个条件如果返回条数和传入数量不一致说明这批附件里有别人的或者已经绑定过的直接抛异常让整帖回滚。4.2 附件上传白名单、分目录与访问路径解耦附件是影视创作论坛的灵魂也是最容易埋雷的地方。三个原则后缀白名单而不是黑名单物理路径按日期分目录数据库只存相对路径。黑名单永远列不全今天禁了 exe明天来个 jsp 就够呛单目录存几万个文件ls都能卡住存绝对路径换台机器部署就全盘失效。// 附件落盘白名单校验 大小限制 日期分目录 UUID 重命名 private static final SetString ALLOW_EXT new HashSet(Arrays.asList( jpg, jpeg, png, gif, pdf, doc, docx, xls, xlsx, zip, txt)); private static final long MAX_SIZE 50L * 1024 * 1024; public String save(MultipartFile file, long userId) throws IOException { String origin StringUtils.cleanPath(file.getOriginalFilename()); String ext origin.contains(.) ? origin.substring(origin.lastIndexOf(.) 1).toLowerCase() : ; if (!ALLOW_EXT.contains(ext)) { throw new BizException(不支持的文件类型 ext); } if (file.getSize() MAX_SIZE) { throw new BizException(单个附件不能超过 50MB); } String datePath new SimpleDateFormat(yyyy/MM/dd).format(new Date()); String storeName UUID.randomUUID().toString().replace(-, ) . ext; Path dir Paths.get(uploadRoot, datePath); Files.createDirectories(dir); file.transferTo(dir.resolve(storeName).toFile()); return datePath / storeName; // 入库只存这一段相对路径 }StringUtils.cleanPath这一步不能省它会清理文件名里的../这类路径穿越片段否则攻击者构造一个..%2f..%2fweb.xml的文件名就能把文件写到应用目录里去。uploadRoot从配置文件读指向容器之外的独立目录这样重新部署 war 包时附件不会跟着被清空——这是很多人第一次部署时踩的坑本地开发好好的一上服务器传的图全没了。下载环节也要绕一道。不能把上传目录直接暴露成静态资源路径否则任何人猜到文件名就能下载包括还没通过审核的帖子里的附件。标准做法是走一个下载接口先校验帖子状态和当前用户权限再以流的方式输出同时把download_cnt加一。文件名用Content-Disposition还原成origin_name中文名要做 URL 编码否则下载下来是一串乱码。4.3 回帖树与列表分页path 字段与覆盖索引回帖列表要同时满足两个看似矛盾的诉求主楼层按时间或热度排序楼中楼必须紧跟在父楼层下面。用 path 字段的排序就能一次解决所有回帖按path升序排列同一主楼下的楼中楼因为 path 前缀相同自然聚在一起而主楼层之间按楼层号升序。-- 帖子详情页分页先按 path 把同一主楼的楼中楼聚在一起再限制条数 SELECT r.id, r.parent_id, r.floor, r.path, r.content, r.create_time, u.nickname, u.role_code FROM t_reply r JOIN t_user u ON u.id r.user_id WHERE r.topic_id #{topicId} AND r.status 1 ORDER BY r.path ASC, r.id ASC LIMIT #{offset}, #{size}; -- 主题帖列表页走 idx_board_list 覆盖索引不回表取 content 大字段 SELECT id, title, user_id, stage_code, reply_count, view_count, is_top, is_essence, last_reply_time FROM t_topic WHERE board_id #{boardId} AND status 2 ORDER BY is_top DESC, last_reply_time DESC LIMIT #{offset}, #{size};第一条 SQL 里有个现实问题分页是按行数切的如果主楼层 3 楼有 40 条楼中楼一页 20 条就会把楼中楼从中间截断。解决办法是分页只对主楼层生效楼中楼单独查先按parent_id 0分页查出当前页的主楼层再用WHERE path LIKE CONCAT(#{floorPath}, %)一次性把这一页所有主楼层的楼中楼全部捞出来在 Java 里按 parent_id 分组挂上去。这样一页最多两次查询既不会截断也不会 N1。第二条 SQL 特意没有SELECT *因为content是 MEDIUMTEXT列表页根本用不到。把大字段排除掉配合联合索引就能做到索引覆盖不用回表读数据页。浏览量加一这种高频写操作也不要每次都 update 主表——view_count可以先进本地缓存累加定时批量刷回或者干脆用UPDATE ... SET view_count view_count 1保证原子性但接受行锁开销量小的时候后者更简单。5. 常见问题排查编码、附件、孤儿数据这五处最容易翻车下面这五个问题几乎每一届都有人踩现象各不相同根因都能归到“某一层没对齐”上。把它们提前摆出来比调试到凌晨三点再发现要划算得多。5.1 编码类中文全变问号或方块现象表单提交的中文进数据库变成???或者页面显示成方块乱码但用数据库工具直接查又是正常的。原因字符集没对齐链路上有三个位置各自独立——JSP 页面声明的pageEncoding、请求体的解码方式、数据库连接串里的characterEncoding再加库表本身的 charset。任何一处不一致中文就会在那一环被替换掉。解决把四个位置统一到 utf8mb4。页面头部声明% page contentTypetext/html;charsetUTF-8 pageEncodingUTF-8 %在过滤器里统一设置request.setCharacterEncoding(UTF-8)和response.setCharacterEncoding(UTF-8)注意这个过滤器必须配在最前面连接串加上useUnicodetruecharacterEncodingutf8建库建表显式指定DEFAULT CHARSETutf8mb4。用 utf8mb4 而不是 utf8是因为后者只支持三个字节遇到 emoji 或者某些特殊汉字会直接写入失败。5.2 附件类上传成功了重启后文件不见了现象上传附件返回成功页面上也能预览但重新部署一次应用全部变成 404。原因uploadRoot指向了容器内的临时目录或者 war 包内的相对路径重新部署时整个目录被替换掉文件自然消失。解决把上传根目录配成容器之外的绝对路径开发和生产用配置文件区分。同时加一条启动检查应用启动时如果根目录不存在就自动创建并在日志里打一行根目录的绝对路径方便出问题时第一时间确认位置。相对路径只存数据库拼绝对路径这件事只在一个工具类里做不要在每个下载接口各写一遍。5.3 数据一致性删了版块帖子全成了孤儿现象后台删除一个版块后前台首页某些帖子点进去报错或者列表里出现空白条目。原因物理删除和逻辑删除混用。版块表用物理 delete帖子表还留着旧的board_id关联查询查不到版块名页面渲染就断了。解决只做逻辑删除所有删除操作统一改成把status置为 9前台查询一律带status 1或status 2的条件。如果真的要做物理清理必须先做一次级联检查该版块下是否还有未删除的帖子有就拦下来提示“请先迁移或删除帖子”。这套逻辑写成一个独立的服务方法不要在控制器里直接调 mapper 的 delete。5.4 计数类回帖数明明 15 条页面显示 12现象帖子里实际能看到 15 条回帖但列表页显示的reply_count是 12越用差得越多。原因两种可能。一是回帖时更新冗余字段的语句漏了条件比如删除回帖时没减一二是并发下两个事务同时读到旧的计数值各自加一后互相覆盖。解决计数更新一律用原子语句UPDATE t_topic SET reply_count reply_count 1 WHERE id #{id}绝不先查后写。删除回帖时用减一并加AND reply_count 0保护。再加一个对账脚本定期用真实 count 修正一遍冗余字段跑一次就能发现哪条更新语句漏了。5.5 会话类改了昵称右上角还是旧名字现象用户中心修改昵称成功数据库也更新了但页面头部的昵称还是老的退出重登才变。原因登录时把用户信息快照放进了会话修改资料时只更新了数据库没有同步会话里的副本。解决有两个做法。简单的是修改成功后手动session.setAttribute覆盖一次更稳的是会话里只存 userId 和角色昵称头像每次从缓存取缓存随修改失效。前者改动小后者不会漏。我通常选后者因为漏刷新的场景实在太多靠人记不如靠结构。6. 验收与答辩一份能当场跑通的验收清单功能写完不等于能交。真正决定分数的是那二十分钟里你能不能在评委面前把系统跑出“有设计”的感觉。我一般会提前准备一张验收清单逐项勾选勾完才允许自己打包。验收项检查方法通过标准角色隔离用游客直接访问发帖接口地址跳转登录页不产生脏数据权限拦截用普通会员访问后台审核接口返回 403 页面不泄露数据状态机发一条含敏感词的帖子进入待审前台列表不可见后台可审附件闭环上传 docx→发帖绑定→审核→下载文件可下载文件名还原为原始名回帖树主楼发 3 条楼中楼翻页查看楼中楼不被分页截断冗余一致发帖→回帖→删回帖对比计数列表页计数与真实条数一致部署复现换目录重新部署后查看历史附件附件仍可正常访问演示顺序也有讲究。不要一上来就点后台管理那是最没技术含量的部分。先用游客身份浏览版块列表说明索引和分页再登录发一个带附件的帖子停在审核状态切到版主账号审核通过然后回前台展示附件下载和楼中楼回帖最后打开数据库客户端当场展示t_reply.path字段和t_topic.reply_count的实际值把设计意图讲出来。这条动线把“设计—实现—验证”串成了一个完整故事比按菜单顺序点一遍强太多。答辩提问高频集中在三处为什么用 JavaEE 而不是别的框架回答就落在课程设计要考察 Servlet 规范、JSP 视图和容器的会话管理这套结构把这些暴露得更彻底附件为什么存路径不存数据库回答是备份、迁移和大字段查询性能并发下楼层号会不会重复回答是行锁加事务并且能说清楚锁的粒度。三个问题准备透了基本不会冷场。从那以后我每次做这类设计都会在打包前把这张验收清单原样跑一遍一项不勾完绝不提交——因为翻车从来不是因为不会写而是因为写完了没验。希望帮到你。本文还有配套的精品资源点击获取
