企业官网建设流程全解析

简介：基于JavaWeb的个人博客管理系统源码，面向正在学习Servlet、JSP与MVC开发的初学者及需要完成课程设计的在校生，以完整项目演示博客平台从用户认证、文章管理到评论交互的落地实现。压缩包共7154个文件、约54.01MB，除Java源码、class字节码和JSP页面外，还包含3716张PNG图片、1200余个JS脚本、745个HTML页面及CSS/SCSS样式，并配有SQL数据库脚本与配置文件，覆盖前端展示、后端逻辑与部署所需的主要构件。已有2357人学习下载，项目目录结构清晰，包含用户登录注册、文章增删改查、分类管理、评论回复等典型模块，可直接导入IDE运行，也适合对照源码梳理JavaWeb经典分层架构。对于想快速上手传统Servlet+JSP开发模式的开发者，是一份兼具参考与实战价值的课程设计资料。

1. JavaWeb个人博客管理系统源码，到底解决谁的诉求

又到了交课程设计和毕业设计的季节，很多人搜来搜去，最后落在这一个标题上：Javaweb个人博客管理系统源码。这东西说白了就是一个典型的 JavaWeb 全栈小项目——前台给别人看文章、按分类找内容、发评论，后台给自己发文章、管分类、审评论，数据老老实实存在 MySQL 里。标题里带着“源码”，意味着你要的不是一篇《从零搭建博客》的教程，而是一个能直接导入 IDEA、能跑起来、能改造成自己作品的完整工程。

它最擅长解决两类诉求：一是课程设计或毕业设计需要一个能演示、能答辩、能讲清楚原理的项目；二是刚学完 Servlet、JSP、JDBC，想用一个完整案例把这条技术链路串起来。但它的边界也明确，不追求高并发、不做前后端分离，UI 通常比较朴素，核心价值在于把 JavaWeb 的经典链路完整走一遍。拿到源码之后你要做的事就三件：看懂它、跑通它、把它改得不那么像模板。

2. 技术选型与数据模型：为什么这套博客源码长这样

2.1 JSP+Servlet还是Spring Boot：看清源码骨架再决定要不要

这类标题下的源码包，十有八九是 Servlet + JSP + MySQL 的结构，骨架看着老，但足够把 JavaWeb 课设要讲的技术点讲全。拿到手先判型：看工程根目录有没有 pom.xml，有说明是 Maven 工程，依赖可以自动拉；没有则多半是普通 Web 工程，jar 包全躺在 WEB-INF/lib 里。再找入口：有 WEB-INF/web.xml 并配置了一堆 servlet-mapping，或者类上直接标了 @WebServlet，就是传统 Servlet 风格；如果看到带 main 方法的启动类，那是 Spring Boot 工程，依赖管理、打包方式、运行环境完全是另一套逻辑。这两种骨架的区别，直接决定你后续的改造工作量。

为什么课设和毕设这么爱做 Servlet + JSP？核心原因是你答辩时要回答“一次 HTTP 请求是怎么从浏览器走到数据库再回页面的”这个问题。Servlet 生命周期、Request/Response、Session、Filter、JDBC 的 Connection 和 PreparedStatement，都是 Spring Boot 帮你封装好的黑匣子，碰上爱追问细节的老师容易被问倒。所以拿到源码先别嫌弃它老，先对照自己交的报告，看这套骨架能不能把技术点讲完整。如果你对照黑马那套 JavaWeb 笔记做复习，会发现这套源码里几乎所有包都能在笔记里找到对应概念，这反而是好事。

至于要不要换成 Spring Boot：如果你的题目明确是“基于 Spring Boot 的博客系统”，那找源码时直接找标题带 Spring Boot 的版本；如果题目就是“JavaWeb 个人博客”，Servlet + JSP 更顺理成章。最怕的是源码里混用了 Spring 全家桶又只用了部分接口，那种结构最难改，建议换一套干净的纯 Servlet 工程。

2.2 表结构设计：一个博客系统最少需要几张表

个人博客的数据模型非常典型：一对多加自关联。我一般建议核心表控制在五张左右：用户表、文章表、分类表、评论表、友链表。非要加标签系统，就再多一张文章标签关联表。表设计得越多，后期改起来越容易在 JOIN 里绕晕，课设阶段没必要。

用户表至少要有 user_id、username、password、role、create_time，password 必须是加密后的密文，明文存密码是硬伤。文章表至少要有 title、content、category_id、author_id、view_count、status、create_time、update_time，status 用 TINYINT 存草稿/发布/删除，比直接 delete 记录安全。分类表就是 category_id 加 category_name 两个字段。评论表是重点：comment_id、article_id、user_id、content、parent_id、create_time，parent_id 自关联本表的 comment_id，回复别人的评论就挂在父评论底下，一张表就能表达无限层级。友链表字段最简单，link_id 加 link_name 加 link_url，做前台底部互链。

近几年来参考的建库脚本常见写法是：

CREATE TABLE `blog_article` ( `article_id` INT NOT NULL AUTO_INCREMENT COMMENT '文章ID', `title` VARCHAR(200) NOT NULL COMMENT '标题', `content` LONGTEXT NOT NULL COMMENT '正文', `category_id` INT DEFAULT NULL COMMENT '所属分类', `author_id` INT DEFAULT NULL COMMENT '作者ID', `view_count` INT DEFAULT 0 COMMENT '浏览数', `status` TINYINT DEFAULT 1 COMMENT '1发布 0草稿', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`article_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

两个关键参数在这里值得专门说。ENGINE 选 InnoDB：课设阶段确实用不到复杂事务，但 MyISAM 在并发写和异常断电时容易出表损坏，没必要为省一点性能埋雷。CHARSET 选 utf8mb4 而不是 utf8，是因为 utf8 存不了 emoji，博客编辑器一旦支持表情，评论里出现一个 emoji 就会抛 Incorrect string value，这个错很隐蔽，排查起来特别玄学。字段注释 COMMENT 也值得保留，写课设文档时对着注释导出表结构说明，能省一大块时间。

建表还有一个取舍：外键。我的习惯是在数据库层面只保留逻辑外键，靠程序保证 article_id 和 parent_id 必须存在，不加物理 FOREIGN KEY。原因很现实，二次开发时一旦外键约束卡住，删除文章会引发一串连环报错，课设阶段用程序控制引用关系比数据库硬约束灵活得多。这个取舍在小项目里完全够用，答辩也不会被挑毛病。

2.3 MVC分层与请求流转：一篇文章发布出去要过几道门

拿到源码后我会先看一条最短链路：用户在前台填了一篇新文章，点发布，到页面重新刷出这篇文章，中间要过哪些文件。合格的源码必然这样走：JSP 页面把表单 post 给 ArticleServlet，Servlet 只做参数接收和视图跳转；业务规则放在 ArticleService；ArticleDao 负责拼 SQL 执行 JDBC；成功之后重定向到列表页，列表页用 JSTL 的 c:forEach 循环渲染。

每个包的位置也有规律：JSP 放在 webapp 目录，里面看不到 JDBC 代码；Servlet 在 controller 包，只做“取参数、调服务、定跳转”三件事；Service 放业务规则，比如草稿审核、评论层级校验；Dao 只写 SQL 和结果集封装。判断源码质量最粗暴的标准，就是打开每个 JSP 搜 import java.sql，只要 JSP 里有 SQL 和 JDBC，说明分层是摆设，后期改起来会很痛苦。

Servlet 层的编码细节也必须提。常见写法是 doPost 第一行先写 request.setCharacterEncoding("UTF-8")，再 getParameter。有些老源码只写了 doGet 逻辑，表单却用 method="post" 提交，所有参数全是 null，这类翻车事件在后面的排查章节会细讲。另外 @WebServlet("/article/add") 必须和表单 action 里的路径一致，一个叫 /addArticle 一个叫 /add，对不上就直接 404。这些小细节比框架本身更容易让人翻车。

3. 在IDEA里把源码跑通：数据库导入、jdbc配置与Tomcat启动

3.1 导入IDEA与初始化数据库：先确认库里有没有脚本

拿到源码的第一件事不是双击打开工程，而是先打开压缩包里的 README 或 sql 目录，确认有没有建库脚本。一套能正常交付的源码，必须带一个 blog.sql 或 init.sql，里面包含建库、建表、初始数据三件套；没有的话，大概率是残缺包，连导入都省了，直接换一套。这是看源码多年的血泪经验，没有初始数据的项目，跑起来后你连一条能展示的文章都找不到，整个演示现场都会变得很尴尬。

用 Navicat 或者命令行执行初始化，常见做法是直接在 MySQL 命令行分两步走：

CREATE DATABASE IF NOT EXISTS blog DEFAULT CHARACTER SET utf8mb4; USE blog; SOURCE /项目路径/sql/blog.sql

逻辑说明：先建库再导表。DEFAULT CHARACTER SET utf8mb4 这一句很关键，它决定整个库的默认字符集，避免导表时因会话字符集不一致而乱码或中断。SOURCE 路径里的斜杠，在 Windows 上也要写成 /，不要写反斜杠，这是命令行导入最常见的小坑。执行完刷新数据库，确认表都进去了，顺便看一眼初始数据里有没有 admin 账号——后面登录后台要用它，而且注意 password 字段应该是密文而不是明文。

IDEA 里导入工程：File → New → Project from Existing Sources，选中源码根目录。如果根目录有 pom.xml，选择 import as Maven project，等右侧 Maven 面板里的依赖刷新完；如果是普通 Web 工程，直接作为 IDEA 工程打开。打开后第一件事是检查 Project Structure：Project 里的 SDK 选 Java 1.8，Modules 里确认 src 被标记为 sources；如果工程里有 web 目录，确认它被识别成 Web 模块且 web.xml 路径正确。这几项配置直接决定后面 Tomcat 能否一键启动，是 IDEA 运行 JavaWeb 项目配置里最容易出问题的地方。

3.2 修改数据库连接参数：三个必改项

把库建好之后就要改连接配置。源码里的连接信息一般放在 src 根目录的 jdbc.properties 或 db.properties，也有的放在 WEB-INF/classes 下。不管放在哪里，核心都是一份 properties 文件，把参数替换成本地环境即可：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/blog?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=你的本机密码

这三个必改项背后各有讲究。jdbc.driver 是驱动类全限定名，MySQL 8 的驱动启用了新类名，旧类名只是为了兼容而保留，报错日志对新手极不友好。jdbc.url 里的 serverTimezone=Asia/Shanghai 解决 MySQL 8 的时区判断；allowPublicKeyRetrieval=true 配合 useSSL=false 解决 MySQL 8 默认认证插件导致的连接被拒；如果是 MySQL 5.7，allowPublicKeyRetrieval 可以删掉，但 characterEncoding=utf8 一定不要删，它负责告诉驱动按 UTF-8 传字符串，少了它中文就乱。jdbc.username 和 jdbc.password 不要带引号，properties 文件没有引号语法。

另外提醒一句：如果源码把连接信息硬编码在 DBUtil.java 里而不是 properties 文件，那就要改 Java 文件，优点是少一层文件读取，缺点是复用性差，属于架构不合但课设能用的状态。改完之后，顺手在 IDEA 里建一个快速测试类，用 DriverManager.getConnection(url, user, pass) 试连一次，能连上再启动 Tomcat。这一步能把“数据库问题”和“Web 服务问题”两个变量剥离开，排查效率立刻翻倍。

3.3 配置Tomcat并启动验证：控制台日志会告诉你答案

配置 Tomcat：Run → Edit Configurations → 左上角加号 → Tomcat Server → Local。Server 选项卡里把 Application server 指向本机 Tomcat 安装目录，Deployment 选项卡点加号，把当前 Module 的 war exploded 包挂上去，Application context 设为 /blog。这样访问地址就是 http://localhost:8080/blog/index.jsp。

启动前做两个预检动作：第一，确认 8080 端口没被占，Windows 上可以用 netstat -ano | findstr 8080 看一眼；第二，盯住控制台启动日志，查有没有异常堆栈，尤其看有没有 java.net.BindException 和 ClassNotFoundException。日志最后出现 INFO: Deployment ... has finished，才算真正部署成功。这个日志窗口是黑匣子唯一的窥视口，出问题先看它，别急着翻页面。

启动完成后在浏览器访问首页，正常的话前台文章列表就出来了；如果 404，先访问 http://localhost:8080 确认 Tomcat 本身活着，再用命令行验证：

curl -I http://localhost:8080/blog/index.jsp

返回 200 说明上下文路径正确，返回 404 说明 Application context 和实际访问路径对不上。常见做法是回到 Deployment 页面，把 URL 里的路径和设置的 context 对齐。IDEA 不会因为 artifact 改名就自动同步 context path，我在这上面栽过好几次，属于典型的 IDE 黑匣子行为。

4. 核心模块源码拆解：登录鉴权、文章分页、评论树

4.1 登录与Session鉴权：Filter把未登录请求挡在门外

个人博客管理后台必须有登录拦截，核心组件是 Session 加 Filter。常见流程是：登录表单提交到 LoginServlet，校验通过后把 user 对象存进 Session；再写一个 Filter 拦截 /admin/ 前缀的请求，Session 里有用户就放行，没有就重定向到登录页。

@WebFilter("/admin/*") public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; Object user = request.getSession().getAttribute("loginUser"); if (user != null) { chain.doFilter(req, resp); } else { response.sendRedirect(request.getContextPath() + "/login.jsp"); } } }

逻辑说明：Filter 是 JavaWeb 标准拦截组件，不需要额外引入依赖。核心代码三行——getSession().getAttribute("loginUser") 负责取登录态；chain.doFilter 放行表示已登录；sendRedirect 把未登录用户送回登录页。参数上最需要注意的是 @WebFilter 的 url 模式必须写 /admin/* 而不是 /admin，因为 /admin 只能匹配这一个精确路径，拦不住 /admin/list.jsp 这种子页面。

判断一套源码登录是否严密，额外看两点。第一，Session 的 key 是否全局统一：LoginServlet 放进去的 key 和 Filter 里取出来的 key 必须是同一个，中途改过一次名字，后台所有请求会瞬间全部重定向到登录页，而且只在运行期出现，极难定位。第二，后台 JSP 页面有没有做二次判断：做得稳的项目会在每个后台 JSP 顶部再判一次 ${sessionScope.loginUser} 是否为空，防止有人绕过 Filter 直接访问 JSP 路径。双保险虽然代码丑一点，但确实堵得住漏洞。

还要提醒密码问题。很多课程设计源码把密码明文存数据库，登录查询直接 select * from user where username=? and password=?。这种写法能跑，但安全底线几乎为零，组内同学用 SQL 注入就能直接登进后台。拿到源码后至少做一层 MD5+盐或者 BCrypt 改造，把密码换成密文存储。改动不复杂，答辩提分效果却非常明显。

4.2 文章分页查询：Dao层SQL与Servlet分页参数

博客前台列表永远不会一页塞下全部文章，分页查询是必须写好的核心方法。常见做法是 MySQL 的 LIMIT 加 OFFSET，配合 PreparedStatement 绑定参数：

public List<Article> queryPage(int pageNum, int pageSize) { String sql = "SELECT * FROM blog_article WHERE status=1 " + "ORDER BY create_time DESC LIMIT ? OFFSET ?"; try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, pageSize); ps.setInt(2, (pageNum - 1) * pageSize); ResultSet rs = ps.executeQuery(); // 遍历 ResultSet，把每行字段封装成 Article 对象加入 List，省略 } catch (SQLException e) { e.printStackTrace(); } return list; }

两个参数位直接决定分页结果。LIMIT 后面的第一个 ? 是 pageSize，表示一页多少条；OFFSET 后面的 ? 是偏移量，计算公式是 (pageNum - 1) * pageSize。pageSize 取 10 时，第一页是 LIMIT 10 OFFSET 0，第二页是 LIMIT 10 OFFSET 10，语义清晰。注意 pageNum 如果从 JSP 表单传来，前端传第 0 页会导致 OFFSET 为负，MySQL 直接报错，所以 Servlet 层要做 Math.max(1, pageNum) 的下限保护，这个细节加到代码注释里也不为过。

页面上还涉及总页数计算。想拿总数就得先执行 SELECT COUNT(*) FROM blog_article WHERE status=1，然后 totalPage = (total + pageSize - 1) / pageSize。这个公式是求上取整，避免了最后一条记录因为整除边界被吞掉。有些源码写成 total / pageSize，结果是最后一页原有的一两条记录凭空消失，答辩时一翻页就露馅。

分页参数在 JSP 里的来回传值也经常被忽略。点击“下一页”时 URL 必须带着 pageNum 和 pageSize 继续传给 Servlet，如果 Servlet 只从 request.getParameter 读 pageNum 而不读 pageSize，每页条数会在翻页后重置成默认值。参数闭环做齐之后，分页逻辑才算真正自洽。

4.3 评论回复：自关联表的递归加载与XSS过滤

评论回复是个人博客里最容易写出精致感也最容易埋雷的模块。表结构上 parent_id 自关联本表，每一条评论都可以被无限回复。展示的时候，常见做法是把全量评论查出来后，在内存里递归组装成树：

public void buildCommentTree(List<Comment> all, List<Comment> result, long parentId, int depth) { for (Comment c : all) { if (c.getParentId() == parentId) { c.setLevel(depth); result.add(c); buildCommentTree(all, result, c.getCommentId(), depth + 1); } } }

逻辑说明：all 是按文章一次性查出的全部评论，result 是组装后的有序列表，parentId 从 0 开始表示顶级评论；每找到一个子评论就把它加入 result，同时用当前评论的 commentId 作为新的 parentId 继续递归。depth 是一个展示参数，页面拿到 level 后乘以固定像素做缩进，视觉上形成层级。这个方案在评论量不大的博客里完全够用，但有两个硬伤：一是数据里不能出现循环引用，比如两条评论互相把对方设为 parent，递归会当场栈溢出；二是全量查询在评论量极大时内存和响应时间都不理想，课设阶段一般碰不到这个量级，不用提前优化。

XSS 是评论模块躲不开的问题。用户评论的 content 回到页面时如果原样输出，任何访客都能在当前页面执行脚本。最轻量的防御是在 Service 层做转义，把 < 转成 < 再入库，或者输出时用 JSP 的 c:out 配合 escapeXml 属性。再进一步是写一个 HtmlFilter 工具类，在评论入库前过滤 script、iframe 等标签。这套改造前后不复杂，属于一行就能演示的安全加固，写进课设报告反而让老师觉得你确实关注过生产环境的问题。

5. 常见问题排查：JavaWeb博客源码跑不起来的五个坑

5.1 端口8080被占用：Tomcat起不来的第一个元凶

现象：IDEA 控制台启动 Tomcat 时立刻抛 java.net.BindException: Port 8080 already in use，浏览器访问 localhost:8080 却打开了完全不相关的页面。

原因：8080 是 Tomcat 默认端口，本机有其他服务占了它。常见占用者包括之前调试没关干净的另一个 Tomcat 实例、Oracle 自带服务，以及一些软件内置的 Web 服务。有时只是上一次调试的进程没完全退出，IDEA 的 Run 面板里还挂着旧实例。

解决：优先改端口而不是杀进程，这样不干扰其他程序。打开 Tomcat 安装目录 conf/server.xml，找到 Connector 节点，把 port="8080" 改成 8081，同时回到 IDEA 的 Run Configuration，把 HTTP port 也改成 8081。两处必须同时改，只改一处会出现 Tomcat 实际端口和 IDEA 展示端口错位，日志显示成功但浏览器照样 404。改完访问地址也跟着换成 8081，这个细节最容易忘。

5.2 MySQL 8连接报Public Key Retrieval错误

现象：项目启动正常，但一登录或一查文章就抛 SQLNonTransientConnectionException，报错信息里有 Public Key Retrieval is not allowed for user。

原因：MySQL 8 默认认证插件是 caching_sha2_password，驱动第一次连接时要从服务端拉取 RSA 公钥来加密密码传输；如果 JDBC URL 里没有显式允许这个动作，连接就被中断。这本质是客户端与服务端安全握手失败，不是账号密码错误。

解决：回到 jdbc.properties 或 DBUtil.java 里的连接串，在末尾补上 allowPublicKeyRetrieval=true&useSSL=false，然后重启，问题就消失。注意补了之后如果还报 Access denied for user，那才是用户名密码或权限问题，不要和公钥问题混为一谈。MySQL 5.7 用户不需要这个参数，但网上很多教程直接把它贴在 5.7 配置里也不影响，因为 mysql_native_password 认证用不到 RSA 公钥拉取。

5.3 页面中文全部乱码：三层编码统一才是治本

现象：文章标题、分类名、评论全部变成问号或“锟斤拷”这类乱码，Tomcat 控制台日志里的中文也花掉。

原因：字符集在三个环节里至少断了一个。第一个环节是数据库连接串，缺少 characterEncoding=utf8 时驱动会按服务器默认字符集传参；第二个环节是 JSP 页面本身的 pageEncoding 和 contentType 不是 UTF-8；第三个环节是 Servlet 接收 POST 参数前没调 request.setCharacterEncoding。任何一环断了，最终落在页面上就是乱码。

解决：把三个环节一次校齐。数据库连接串加 useUnicode=true&characterEncoding=utf8；每个 JSP 头部 pageEncoding 改成 UTF-8，contentType 的 charset 也写 UTF-8；然后在 Filter 里统一加 request.setCharacterEncoding("UTF-8") 和 response.setCharacterEncoding("UTF-8")。放 Filter 而不是每个 Servlet，能覆盖全部请求，最省事。改完重启，先刷新库里旧的乱码数据，再测试新增数据，确保新数据不乱码才算解决。

5.4 404不是路径的锅：context path与部署结构双查

现象：Tomcat 启动正常，日志没有异常堆栈，但访问后台地址一律 404，前台首页偶尔也 404。

原因：最常见是 context path 问题。IDEA 里 Artifact 的 Application context 设成 /blog，但页面跳转写的是 /admin/list.jsp，少了 /blog 前缀，请求落到 Tomcat 根上下文自然找不到资源。第二种常见原因是部署结构不对：JSP 文件在 Artifact 的 Output Layout 里没被包含进去，或者 WEB-INF 下的 web.xml 没被正确加载。

解决：先看 404 报错的完整 URL，把 context path 和实际路径对一眼，跳转代码统一用 request.getContextPath() 拼前缀，写死的路径一律不留。再进 Project Structure → Artifacts，查 Output Layout 里有没有把 webapp/WebContent 目录挂进去，web.xml 是否在 WEB-INF 下。这两个动作做完，绝大多数 404 能当场定位。少数情况是 IDEA 缓存没刷新，点 Build → Rebuild Project 再重启 Tomcat 就好。

5.5 JSP页面取不到值：JSTL缺失和驼峰映射都要看

现象：数据库里明明有文章，Servlet 也执行到了，页面上的列表却是空的，或者 ${article.title} 输出空白。

原因：一是 JSTL 标签库的 jar 包缺失。页面用了 c:forEach，web.xml 也声明了 taglib，但 WEB-INF/lib 下没有 jstl.jar 和 standard.jar，JSTL 标签全部失效。二是数据封装时字段名对不上。MySQL 表字段习惯用下划线分隔（article_name），JavaBean 属性习惯用驼峰（articleName），如果 DAO 里的 ResultSet 映射没有写别名或自动映射，属性取不到值，页面自然空白。

解决：先补 JSTL 依赖，把 jstl.jar 和 standard.jar 放进 WEB-INF/lib，Maven 工程则在 pom.xml 加 jstl 依赖。再看 DAO 的映射代码，每次 rs.getXxx 后 new 对象时，setter 的参数名要和 Java 属性一致。页面空白但没异常时，优先查这两处，比在 JSP 里逐行加调试输出要快得多。

6. 源码拿到手之后：先做三步验证，再决定怎么二次开发

6.1 先核对功能清单，别被“完整系统”的说明迷惑

拿到任何一套源码，第一关是核对而不是信任。把“个人博客管理系统”拆成功能清单：前台能看文章列表、文章详情、分类筛选、发表评论；后台能登录、发文章、改文章、删文章、管理分类和评论；数据库带可复用的初始化脚本。对着清单逐项点一遍，缺哪块就在课设文档里补哪块。半小时的核对能避免一个尴尬场景：你精心改了一下午，答辩时才发现这套源码本来就没有删除评论的功能。

6.2 快速审查数据访问层和用户表，安全和质量一眼看穿

接手源码后我会做一次不编译的静态审查。重点看三处：DAO 层拼 SQL 是不是全程 PreparedStatement，如果看到字符串直接拼参数就该重写；用户表的 password 字段是不是明文，是明文就加盐哈希再入库；表里有没有 create_time 和 update_time，没有的话后期想做“近 30 天发文趋势”会很痛苦。这三条改起来不算重活，却能明显提升整套源码的可靠度。

6.3 三个可落地的二次开发方向

想让它更像自己的作品，我推荐三个改动方向。一是给文章加标签，建一张标签表和一张文章标签关联表，前台做一个标签云，难度低、展示效果好，是答辩里拿得出手的增量功能。二是把正文编辑区从 textarea 升级成轻量级富文本编辑器，注意保存时做 HTML 标签白名单过滤，别把安全又丢了。三是加一个“热门文章”列表，SQL 就是按 view_count 倒序取 10 条，改动极小，首页视觉丰富度立刻提升。三个里选一个做深就好，别贪多。

我的习惯是拿到源码先完整跑通，再手动重建一遍建库脚本，确认每一步都能独立复现之后才敢动手改。靠运气跑起来的项目，大概率在演示前两天出幺蛾子。希望这篇笔记能让你少踩几个坑，把时间留给真正想做的改动。

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