企业官网建设流程全解析

简介：这份动漫网站设计与实现毕业论文文档面向计算机相关专业学生及具备基础Web开发经验的毕业设计参考者，围绕动漫类网站从需求分析到系统测试的完整开发流程展开，可帮助读者梳理选题、搭建论文结构并理解网站制作的关键环节。压缩包内仅含1个doc文件，约569KB，即一篇结构完整的Word版论文，便于直接查阅、摘录与格式参考。目前已有2170人学习下载。正文涵盖MyEclipse、Tomcat、B/S结构、ORACLE数据库、Dreamweaver、JavaScript与JSP等技术选型说明，并依次讨论需求分析与可行性分析、系统设计、数据库表描述与表间联系、总体功能模块设计，以及项目包部署、数据连接配置、前后台页面实现和系统测试等内容。读者可从中获得可借鉴的论文目录框架、技术方案表述与模块设计思路，适合用于毕业设计撰写、答辩准备或动漫类网站开发入门参考。

1. 站在"版面千篇一律"的反面：这套动漫网站设计与实现到底要交什么

很多同学接到"动漫网站的设计与实现"这个题目，第一反应是打开 IDE 挑框架，结果折腾三周还在纠结要不要上 MVC。我见过的翻车现场基本都不是框架选错，而是内容更新链路没想清楚：后台发一条新闻，前台首页、栏目页、详情页三处对不上；上传一集影片，播放路径写死在页面里，换台机器就打不开。这套方案要交付的东西其实很朴素——一个前台能看动漫新闻、杂谈、在线影片、留言互动，后台能对这几类内容做增删改的小型内容站。网站制作本身的入门门槛不高，难的是把"内容—数据—页面"这条线一次接通，让管理员在后台点一下保存，前台刷新就能看见。适合拿它交毕设、交课设，也适合要出一份完整 Web 交付方案的人照着改。

2. 技术选型与可行性论证：一次请求在 B/S 三层里怎么走完整链路

2.1 三层职责划分：浏览器只管渲染，容器负责生成，数据库只管存

这套系统采用的是 B/S 结构，浏览器/服务器模式。它跟 C/S 最大的区别在于客户端不需要安装任何东西，用户打开浏览器输入地址就能用，升级维护只发生在服务器一端。放到这个动漫站的具体场景里，一个普通访客点开"动漫在线"栏目，浏览器发出的是一个 HTTP 请求，请求被 Tomcat 接住，容器找到对应的 JSP 页面，JSP 在执行时通过 JDBC 去 Oracle 取影片列表，取回来的结果集被拼成 HTML 表格，最后整段 HTML 回写给浏览器。浏览器拿到的永远是成品页面，它不知道背后查了几张表。

这里有个细节值得在设计文档里写清楚，答辩时也常被追问：JSP 不是解释执行的脚本，它第一次被访问时会被容器翻译成一个 Servlet 源文件，再编译成 class，之后走的是编译后的缓存。所以第一次访问某个页面会明显慢半拍，第二次就正常了，这不是性能问题，是编译开销。理解这一点，后面排查"改了 JSP 但页面没变"这类问题时就有方向了——多半是容器里的旧 class 还在，重新部署一次即可。

三层各自的边界要提前定死，否则代码会越写越乱。浏览器端只做展示和最基本的非空校验，凡是涉及"这条数据能不能改""这个人是不是管理员"的判断，一律放在服务端。数据库端只负责存取，不在存储过程里写业务分支。我在做这类小型内容站时，习惯把"页面 → 控制 → 数据访问 → 数据库"这四段画在需求文档第一页，后面所有模块都往这张图上挂，谁越界一眼就能看出来。

2.2 工具链分工：每个工具只管一段，别让它越界

这套方案涉及的工具比较多，容易出现的误区是"哪个顺手就用哪个",最后同一段逻辑在三处重复。合理的分工是这样的：

这张表的价值在于划界。举个例子，"用户名不能为空"这句校验，JavaScript 里写一遍是为了用户体验，不用等提交就知道错了；服务端再写一遍是为了安全，因为浏览器端的校验可以被绕过。两处都写不是冗余，是各司其职。同理，列表分页的计算放在 JSP 里做也能跑，但一旦要复用到三个栏目，就得复制三份，这时候把它下沉到数据访问层才是对的。

Tomcat 作为容器，还有个常被忽略的点：它默认的部署方式是解压式部署，把项目文件夹扔进 webapps 目录就行；也可以打成 war 包放进去，容器启动时自动解压。前者适合开发阶段反复改，后者适合交付。毕设答辩时用哪种都行，但要知道自己用的是哪种，被问到"你的项目怎么发布"时能答上来。

2.3 数据库连接与配置：先把"能跑起来"这件事钉死

在写任何业务代码之前，我一般先把连接配置独立成一个文件，而不是把账号密码硬编码在每个 DAO 里。原因很现实：答辩现场换一台机器演示，数据库地址一变，硬编码的写法要改十几个文件。

# db.properties —— 放在源码根目录，编译后随 class 一起进 WEB-INF/classes jdbc.driver=oracle.jdbc.driver.OracleDriver jdbc.url=jdbc:oracle:thin:@127.0.0.1:1521:anime jdbc.user=anime jdbc.password=anime

public final class DBUtil { private static String url; private static String user; private static String pwd; // 静态块只在类加载时执行一次，避免每次取连接都读文件 static { Properties p = new Properties(); InputStream in = null; try { in = DBUtil.class.getClassLoader().getResourceAsStream("db.properties"); if (in == null) { throw new IllegalStateException("db.properties 未找到，检查是否编译进 classes 目录"); } p.load(in); Class.forName(p.getProperty("jdbc.driver")); // 注册驱动 url = p.getProperty("jdbc.url"); user = p.getProperty("jdbc.user"); pwd = p.getProperty("jdbc.password"); } catch (Exception e) { // 配置错就直接让应用起不来，比运行到一半报错好排查 throw new ExceptionInInitializerError("数据库配置初始化失败：" + e.getMessage()); } finally { if (in != null) { try { in.close(); } catch (IOException ignore) { } } } } public static Connection getConn() throws SQLException { return DriverManager.getConnection(url, user, pwd); } // 统一关闭顺序：结果集 -> 语句 -> 连接，反序关闭 public static void close(Connection c, Statement s, ResultSet r) { if (r != null) { try { r.close(); } catch (SQLException ignore) { } } if (s != null) { try { s.close(); } catch (SQLException ignore) { } } if (c != null) { try { c.close(); } catch (SQLException ignore) { } } } }

这段代码有两个设计取舍值得说。第一，配置加载放在静态块里，类只加载一次，配置也只读一次，避免每个请求都做一次磁盘 IO。第二，配置缺失或驱动加载失败时直接抛ExceptionInInitializerError，让应用在启动阶段就崩掉。这看着粗暴，实际上省事——总比用户点了半天页面、最后在某个 DAO 里冒出一句空指针要好定位。

参数上要注意jdbc:oracle:thin:@127.0.0.1:1521:anime这串里，thin表示纯 Java 的瘦驱动，不需要在客户端装额外的库；1521是监听端口；最后的anime是数据库实例名，不是用户名，这两者经常被搞混。如果换成本机之外的一台机器，只改 IP 那一段即可，其余代码不动。

2.4 可行性论证：写清楚边界，别写成空话

可行性分析这一节在很多毕设里被写成三段套话，其实它是评委最容易挑刺的地方。按我自己的写法，至少要把三件事落到具体数字上：

经济性上，服务端用开源容器加一个现成的数据库实例，客户端零安装，浏览器直接访问，开发和部署阶段没有额外的授权成本。技术性上，所选技术都是成熟的 Web 开发组合，社区资料充足，出问题能查到解决方案。运行基线上，把最低配置写清楚：处理器 1.8GHz 以上、内存 1GB 以上、操作系统覆盖常见的 Windows 桌面与服务器版本、数据库版本明确到 10g、浏览器以 IE6 及以上为基准、页面按 1440×900 分辨率做最佳适配。

最后这条分辨率基线特别值得写。因为这类站的首页一般是三栏布局，1440 宽度下刚好排满，如果用户用 1024 的屏幕打开，右侧栏就会被挤到下面，视觉上直接散架。在文档里主动写出这个限制，比被评委现场问出来要体面得多。通常的做法是给主体内容区设一个固定宽度加居中对齐，两侧留白自适应，这样在多数分辨率下都不会崩。

3. 需求分析与模块划分：前台六个入口、后台七项管理的边界怎么切

3.1 前台模块拆解：每个入口对应一组页面和一组动作

前台是整个站的脸面，拆模块的时候我习惯按"用户从哪里进来、进来后能干什么"来切，而不是按数据库表来切。这套方案的前台包含六块：

动漫首页是起点，承担的是"整体风格展示 + 各栏目摘要"的职责，通常放轮播图、最新新闻三五条、最新上架影片的封面墙。动漫新闻模块是列表加详情的两级结构，列表页只出标题、发布时间、点击量，点进去才是正文。动漫杂谈跟新闻结构几乎一样，区别在于内容偏评论和随笔，发布频率更低但篇幅更长，所以详情页要预留富文本的展示空间。

动漫在线是这套系统里最特别的一块。它的列表页展示的是影片封面和名称，详情页要先展示简介，再提供播放入口。这里的设计要点是"一部动漫对应多集"，所以数据上必须有一张主表存动漫本身，另一张表存每一集的更新记录，靠动漫编号关联。留言本是唯一的双向模块，未登录只能看，登录后才能写，写入的内容按时间倒序排，最新的在最上面。热门链接模块最轻，本质上就是一组外部网址的集合，但它对用户留存有实际作用，很多同类站把这块做成硬编码，结果每加一个链接就要改页面，正确做法是同样入库、同样走后台维护。

把这六块列清楚之后，还要补一句每个模块的页面数量，因为这直接决定工作量估算。首页 1 个、新闻列表与详情 2 个、杂谈列表与详情 2 个、动漫列表与详情与播放 3 个、留言本 1 个、链接页 1 个，前台一共 10 个页面左右，这是一个人能在一个学期内做完的合理体量。

3.2 后台模块与权限边界：登录是唯一的大门

后台承担的是内容维护，模块划分比前台更讲秩序：登录、动漫新闻管理、动漫杂谈管理、动漫在线管理、管理员信息修改、返回前台、退出登录，七项。前三项是增删改查的重复劳动，可以套同一套模板；真正需要单独设计的是登录和权限。

登录这一块，关键在于"登录成功后把身份存在哪"。我一般存在 Session 里，后续每个后台页面进来第一件事就是判断这个 Session 还在不在。

// AdminLoginServlet 的 doPost 核心逻辑 String name = request.getParameter("adminName"); String pwd = request.getParameter("adminPwd"); AdminDao dao = new AdminDao(); Admin admin = dao.login(name, pwd); // 账号密码一起作为查询条件，查不到返回 null if (admin == null) { request.setAttribute("msg", "账号或密码不正确"); // 用 forward 保留提示信息，地址栏不变，用户可以直接重试 request.getRequestDispatcher("/admin/login.jsp").forward(request, response); return; } // 登录成功：写入 Session，后续后台页面统一读这个 key session.setAttribute("admin", admin); session.setMaxInactiveInterval(30 * 60); // 30 分钟无操作自动失效 // 用重定向而不是转发，避免用户刷新页面时重复提交登录表单 response.sendRedirect(request.getContextPath() + "/admin/newsList.jsp");

这段代码里两个跳转方式的区别值得讲透。失败时用forward，因为要把错误提示带到登录页，地址栏保持不动，用户按 F5 是重新提交一次登录，符合直觉。成功时用sendRedirect，浏览器会重新发起一次 GET 请求，地址栏变成后台首页，这样用户刷新的是列表页而不是登录表单，不会出现"刷新一次又登录一次"的怪现象。这是我在实际项目里踩过的坑，当时没在意，演示时被连续刷新搞得很尴尬。

权限边界还有一层：管理员和普通注册用户不是一套体系。后台账号存在管理员表里，前台用户存在用户表里，两者的登录入口、Session 的 key 名都分开。混用的后果是前台注册一个号就能进后台，这类漏洞在小项目里特别常见，写的时候多花十分钟分开，比事后补救划算。

3.3 数据操作清单：把"要写哪些方法"提前列出来

模块划分完之后，我会再补一张数据操作清单，把每个模块要用到的查询和写入方法列全。这一步看着笨，实际能省很多返工。这套系统的清单大致是：按栏目编号和页码做分页查询、按栏目编号统计总条数、按发布时间倒序取集合、按主键取单条详情、新增一条记录、按主键更新、按主键删除、取最近发布的若干条、取点击量排名靠前的集合。

前四条是分页列表的标配，缺一不可。统计总条数这条容易被漏掉，结果就是分页控件算不出总页数，只能写死显示"下一页"。排行榜那条对应首页的"热门推荐"区域，实现上就是按点击量倒序取前 N 条，N 一般取 5 到 8，再多首页就放不下了。

写入类操作里，删除要特别小心。论坛这种有主贴和回帖的结构，删主贴时必须先删它下面的所有回帖，再删主贴本身，顺序反了就会被外键约束挡住。这套动漫站里，一部动漫下面挂着多集内容，删动漫时同理，先清子表再清主表。这条规则最好在设计阶段就写进文档，别留到编码时临时想。

3.4 IPO 图与数据字典：用两张表把设计说清楚

设计文档里如果只剩两张表值得画，我会选这两张。IPO 图说明每个处理环节吃什么、吐什么：

数据字典则把系统的基本信息固定下来：系统名称、编写人（用代称即可）、编写日期、被调用的表清单、输入输出说明、处理说明。这张表在答辩时的作用是让评委一眼看到你梳理过全貌，而不是想到哪写到哪。我一般会在表头下面直接列十张表的表名，跟后面的数据库设计章节一一对应，形成闭环。

4. 数据库设计与数据访问实现：十张表、外键约束与分页脚本落地

4.1 用户与论坛域：四张表撑起注册、发帖、回帖、等级

用户表是整套系统的地基，存的是前台注册用户的基础信息和状态。字段设计上，编号做主键、自增或由序列生成；用户名和密码都是必填；姓名、头像、出生日期、注册日期、性别、等级依次排列。等级字段是个整数，它不直接存"几级"，而是存等级编号，真正的等级名称放在等级表里，这是典型的用外键替代表内冗余的写法。

主贴表里那几个字体相关的字段——字号、颜色、是否粗体、是否斜体、是否下划线——看着像凑数，其实是为了支持发帖时的简单排版。这类设计在早期论坛系统里很常见，代价是字段偏多，好处是不用引入富文本存储。如果重做一版，我可能会把它们合并成一个样式字符串，但对毕设来说，拆开写反而更容易讲清楚每个字段的作用。

回帖表的结构和主贴表高度相似，差别在于它多了一个主贴编号作为外键，少了一个板块编号。这个差别决定了查询方式：取某个主贴下的所有回帖，条件是TOPICID = ?，按发布时间升序排，让对话顺序自然呈现；取某个板块下的主贴列表，条件则是BOARDID = ?，按发帖时间倒序，最新的讨论排在最前。

等级表只有两个字段，等级编号和等级名称，看起来可有可无。它的价值在于把"积分到等级的换算"从代码里挪到数据里。用户积分涨到某个阈值，等级跟着变，对应的操作权限也变——比如低等级不能上传头像、不能发带链接的帖子。阈值写死在代码里，改一次要重新编译；放在表里，后台改一行数据就生效。这是小设计里的实用主义。

4.2 动漫内容域：一部动漫、多集内容、若干张图

动漫这块的核心矛盾是"一个作品对应多个更新集数"，所以必须拆成主表和明细表。动漫表存作品本身：编号、名称、封面图路径。内容表存每一集：编号、标题、更新时间、所属动漫编号、集数序列。影片表结构类似，区别是多了简介字段，因为影片详情页要展示剧情介绍。漫画图片表则单独存放每一页的图片路径，靠内容编号关联。

集数序列那个字段（原文叫 countid）值得单独说。它的作用是排序和展示"第几话"，通常由数据库序列生成，只增不减。为什么不直接用更新时间排序？因为批量导入历史内容时，更新时间可能全被写成导入当天，顺序就乱了。用序列排，天然稳定。列表页展示时按序列倒序，最新更新的自然排在最前面，符合用户预期。

封面图和内容图分开存路径而不是存二进制，是这类系统的通用做法。图片文件放在 Web 目录下的一个固定文件夹里，数据库里只存相对路径，页面渲染时拼上上下文路径。这样做的好处是数据库体积小、备份快，坏处是文件和记录可能不同步——删了记录忘了删文件，或者挪了文件夹路径全失效。这一点在后面排查章节还会提到。

4.3 下载资源域与表间联系：外键走向决定查询写法

资源相关的两张表结构简单：类别表存类别编号和类别名称，资源表存资源编号、类别编号、简介、更新时间、序列、下载次数。它跟动漫域是并列关系，服务于"有些用户想下载下来看"这个需求。

表间联系是整个数据库设计里最需要画图的部分。论坛域这条线是：用户表通过用户编号外连接到主贴表和回帖表；主贴表通过板块编号外连到板块表；回帖表通过主贴编号外连到主贴表。动漫域这条线是：动漫表通过动漫编号外连到内容表和影片表；内容表通过内容编号外连到图片表。资源域这条线是：类别表通过类别编号外连到资源表。

外键约束要不要在数据库层面真正建起来，这里有个取舍。建了，删数据时会被拦住，逼着你按正确顺序操作，数据一致性有保障；不建，删除自由，但很容易留下孤儿记录。我的建议是主外键关系明确的表都建，尤其是主贴与回帖、动漫与内容这两组，它们的数据量会随使用增长，孤儿记录一旦积累很难清理。板块表里表示父板块的字段比较特殊，因为序列从 1 开始，用 0 表示"没有父级"是安全的，这个约定要写进注释。

4.4 建表脚本与分页查询实现

下面这段是核心几张表的建表语句，省略了部分重复字段，保留了约束和索引：

-- 用户表：编号由序列生成，用户名唯一 CREATE TABLE users ( userid NUMBER(8) PRIMARY KEY, username VARCHAR2(20) NOT NULL, userpwd VARCHAR2(20) NOT NULL, head VARCHAR2(20), birthday DATE, regtime DATE NOT NULL, sex NUMBER(1), intergal NUMBER(8) DEFAULT 0 ); CREATE UNIQUE INDEX uk_users_name ON users(username); -- 主贴表：boardid 指向板块，userid 指向发帖人 CREATE TABLE topic ( topicid NUMBER(8) PRIMARY KEY, title VARCHAR2(255) NOT NULL, userid NUMBER(8) NOT NULL, boardid NUMBER(8) NOT NULL, publishtime DATE NOT NULL, replycount NUMBER(8) DEFAULT 0, clickcount NUMBER(8) DEFAULT 0, CONSTRAINT fk_topic_user FOREIGN KEY (userid) REFERENCES users(userid), CONSTRAINT fk_topic_board FOREIGN KEY (boardid) REFERENCES board(boardid) ); -- 影片表：animeid 指向作品，countid 是集数序列 CREATE TABLE film ( filmid NUMBER(8) PRIMARY KEY, filmbrief VARCHAR2(255), updatetime DATE NOT NULL, animeid NUMBER(8) NOT NULL, countid NUMBER(8) NOT NULL, playurl VARCHAR2(255) NOT NULL, CONSTRAINT fk_film_anime FOREIGN KEY (animeid) REFERENCES anime(animeid) ); CREATE INDEX idx_film_anime ON film(animeid, countid);

索引的选择有讲究。users表在用户名列上建唯一索引，是因为登录查询就是按用户名精确匹配，而且注册时要防止重名，一个索引同时解决两件事。film表建的是复合索引(animeid, countid)，因为最常见的查询是"某部动漫的全部集数，按集数排"，这个索引能让数据库直接顺着索引取，不用额外排序。不要给每个字段都建索引，写入时会拖慢，小项目里得不偿失。

分页查询用 Oracle 这套写法，两层嵌套是为了先排序再截取：

public List<Topic> findByBoard(int boardId, int page, int size) { List<Topic> list = new ArrayList<Topic>(); // 外层限定结束行号，内层限定起始行号并完成排序 String sql = "SELECT * FROM (" + " SELECT t.*, ROWNUM rn FROM (" + " SELECT topicid, title, userid, publishtime, replycount, clickcount " + " FROM topic WHERE boardid = ? ORDER BY publishtime DESC" + " ) t WHERE ROWNUM <= ?" + ") WHERE rn > ?"; Connection conn = null; PreparedStatement ps = null; ResultSet rs = null; try { conn = DBUtil.getConn(); ps = conn.prepareStatement(sql); ps.setInt(1, boardId); ps.setInt(2, page * size); // 结束行 = 当前页 * 每页条数 ps.setInt(3, (page - 1) * size); // 起始行之前，即上一页末尾 rs = ps.executeQuery(); while (rs.next()) { Topic t = new Topic(); t.setTopicId(rs.getInt("topicid")); t.setTitle(rs.getString("title")); t.setPublishTime(rs.getDate("publishtime")); t.setReplyCount(rs.getInt("replycount")); list.add(t); } } catch (SQLException e) { throw new RuntimeException("按板块分页查询主贴失败", e); } finally { DBUtil.close(conn, ps, rs); } return list; }

三个参数的关系必须理清：page从 1 开始计数，size是每页条数，结束行号等于page * size，起始行之前的值等于(page - 1) * size。以第一页、每页 10 条为例，结束行是 10，起始之前是 0，取到的就是第 1 到第 10 条。这组算式写错一位，翻页时就会出现重复条目或者漏掉一条，而且不容易一眼看出来，属于典型的血泪经验。

模糊搜索只需要改内层条件，把WHERE boardid = ?换成WHERE title LIKE ?，参数传"%" + keyword + "%"。要注意两点：一是%拼接必须发生在 Java 侧传参，不能直接把用户输入拼进 SQL 字符串，否则就是注入漏洞；二是当关键词为空串时，应该直接跳过这段条件，而不是拼一个%%去全表扫，数据量一大就能明显感觉出来。

5. 上线前的排查清单：这套动漫站最容易翻车的五个地方

5.1 中文乱码：从表单到数据库有三道关口

现象是后台刚发的一条新闻标题里带中文，前台详情页打开变成一串问号或者方块。原因往往不是一处，而是三处任意一处没对齐：第一处是请求体编码，表单用 POST 提交时，服务端读取参数前必须声明字符集；第二处是响应编码，页面输出的 Content-Type 里要写明字符集；第三处是数据库连接的字符集，建库时的字符集和驱动通信时用的字符集不一致，数据进去就已经坏了。

解决办法是三层都定死成同一种编码。请求处理的第一步加一句request.setCharacterEncoding("UTF-8")，注意这句必须写在读取任何getParameter之前，写在后面对已经解析过的参数无效。响应端在页面顶部声明pageEncoding与contentType。数据库那边，URL 连接串里补上字符集参数，建表时字符集也统一。如果用的是 GET 方式传中文，还要在容器的连接器配置里补上 URI 编码声明，否则走的是容器默认编码，跟前两处对不上。

排查顺序我一般是从后往前：先直接在数据库里查这条记录，如果库里就是乱码，问题在写入端；如果库里正常而页面乱码，问题在读出来之后的输出端。这样能一次定位到关口，不用来回改。

5.2 后台能登录但改不动数据：Session 校验漏了一个页面

现象是管理员登录成功，进了列表页，点编辑保存，结果跳回登录页或者提示无权限。原因是后台页面有十来个，但 Session 校验只加在了首页和登录页上，其他页面直接访问也能打开，而保存这类写操作在服务端又确实在判断 Session，两边不一致。

更隐蔽的一种情况是取 Session 的方式不对。登录时写的是session.setAttribute("admin", admin)，其他页面判断时却写成request.getSession().getAttribute("user")，key 名不一致，永远取到 null。这类问题在代码里看着都正常，只有跑起来才暴露。

解决办法有两个层次。省事的做法是每个后台页面的最上方统一加一段判断，取不到会话就重定向回登录页。规范的做法是写一个过滤器，把后台路径全部纳入拦截范围，只放行登录和静态资源，新增页面时自动受保护，不用一个个补。我倾向后者，因为人总会忘，而过滤器不会。

5.3 删除主表报外键错：级联顺序反了

现象是后台删一部动漫，页面弹出一段数据库异常，内容大致是违反外键约束。原因是这部动漫下面还挂着若干集内容，子表记录还在，数据库不让删父表。这不是数据库在找麻烦，是它在帮你兜底——直接删掉父表，子表那些记录就变成孤儿，永远也查不到、删不掉。

解决办法是按从下往上的顺序删：先删这部动漫下的所有集数记录，再删它关联的图片记录，最后删动漫本身。三步要放在同一个事务里，中途失败就整体回滚，避免出现"子记录删了、父记录还在"的半吊子状态。代码上我习惯在 DAO 里写一个按动漫编号删除的方法，内部依次执行这三条语句，外部只调一次，把顺序封在方法内部，别人想用错也错不了。

还有一种情况是前台用户删自己的帖子，只删了主贴没删回帖，表面上帖子没了，实际上回帖还在库里占着，而且因为外键约束没建全，删除居然成功了。这类问题爆发得晚，等到统计回帖数时才会发现对不上。

5.4 分页总数和列表对不上：统计语句少了条件

现象是分页控件显示"共 3 页"，翻到第 2 页却是空的，或者列表有 25 条，分页只算出 20 条。原因是统计总条数的 SQL 和查询列表的 SQL 用的过滤条件不一致，一个带板块编号，一个不带，两边的结果自然对不上。数据少的时候看不出来，数据一多就露馅。

解决办法是把两条 SQL 的条件部分抽出来共用，或者至少保证它们在同一段代码里相邻书写，改一个的时候眼睛能扫到另一个。参数绑定也要同步，列表查询绑了boardId，统计查询就不能漏绑。测试的时候别只用一页数据测，至少造出三页以上的量，把首页、中间页、末页、越界页都点一遍。末页和越界页最容易出问题，前者可能多出一条，后者可能抛异常而不是显示空列表。

5.5 在线播放打不开：路径拼接漏了上下文

现象是本地开发时影片能播，部署到另一台机器或者改了项目名，播放窗口就是一片空白。原因是播放地址写成了以斜杠开头的绝对路径，部署后项目的上下文路径变了，请求打到了错误的位置。图片、CSS、JS 也是同一个道理，表现是样式全丢，页面裸奔。

解决办法是所有资源路径一律用上下文路径做前缀拼接，不在页面里手写以斜杠开头的地址。存数据库时只存相对路径，比如影片文件相对于某个固定目录的路径，取出来渲染时再拼上前缀。这样换环境、换项目名，只要目录结构一致，全站资源都能正常加载。

还有一个容易忽略的点：文件名里带空格或者中文。浏览器编码之后，服务端拿到的路径可能和实际文件名对不上，表现同样是打不开。上传时统一把文件名重命名成编号加英文扩展名，能一次性绕开这个坑，也顺便解决了同名覆盖的问题。

6. 测试与答辩：用一张用例表把这份毕设验收下来

验收这件事，我一般不看代码写得多漂亮，只看一张表能不能跑通。这套动漫站的验收用例至少要覆盖四类：正常流程、边界值、权限越界、异常输入。正常流程就是"后台发一条新闻 → 前台首页出现摘要 → 点进详情看到全文"这条链，以及"后台传一集影片 → 前台列表出现 → 点进去能播"这条链，两条链路走通，核心功能就算立住了。

边界值这块，分页是重灾区。用例要写清：只有一条数据时总页数显示几页、正好是每页条数的整数倍时会不会多出一个空页、页码传 0 或负数时怎么处理、页码超过总页数时返回什么。模糊搜索的边界是关键词为空、关键词只有一个字、关键词包含特殊字符这三种情况。这些点我都在答辩现场被问过，答不上来很尴尬，答上来就是加分项。

答辩演示有个顺序上的技巧：不要从后台开始讲，要从用户视角开始。先在首页浏览一遍，让评委看到完整形态；再点进新闻详情、影片详情、留言本，把前台走完；然后切到后台，现场发一条新闻，再切回前台刷新，让那条新闻出现在列表最上面。这一来一回，等于把"数据从后台流到前台"这条主线当场演示了一遍，比口头解释十遍都管用。演示前记得手动造几条看起来真实的数据，空列表的页面是最没有说服力的。

从那以后我每次交方案前，都强制走一遍"前台看—后台改—前台再看"这条最小闭环，不管时间多紧都不跳过。因为翻车往往不在复杂逻辑上，而在这种最基础的链路上。希望帮到你。

本文还有配套的精品资源，点击获取