企业官网建设流程全解析

简介：一份博客系统课程设计的完整工程包，基于Java Web技术开发，面向高校Java初学者和需要完成课程设计的学生，也适合想了解MVC分层架构的开发者。项目采用Eclipse与Myeclipse集成环境，后端使用Tomcat和MySQL，实现了博主、普通用户、管理员三类角色的权限划分，覆盖注册登录、文章发布与浏览、类别管理、评论管理、密码修改、在线统计等功能，业务逻辑完整。压缩包内共74个文件，以JSP动态页面、Java源代码和编译后的class文件为主，附带4份SQL数据库脚本、JPG与GIF图片素材、XML配置文件及课程设计报告文档，整体只有802KB，轻量易获取。文件按源代码、数据库、报告分层组织，方便对照学习。目前已有1323人下载学习，学习者导入Eclipse工程并执行SQL脚本即可快速部署，直观体验不同角色的操作流程，还可借助报告理清设计思路，为撰写课程设计文档提供参考。

1. 基于 Java web 的博客系统课程设计：交付的边界与门槛

把“基于 Java web 的博客系统（源码+数据库+报告）”这门课设真正做好，关键不只在于功能跑通，还在于交付物的组织方式。同一个题目，有人交上去被打回重改，理由是“登录没做权限控制”“SQL 脚本导不进去”“报告里连 ER 图都没有”；也有人用同样的时间拿到高分，差别只在于把源码、数据库和报告三件事各自做到了什么程度。

这个题目的本质，是用一个博客系统把 Java web 开发的基本流程完整串起来：注册登录、文章发布、列表分页、评论互动是功能主体；数据库提供表结构、索引和连接配置；报告负责把设计思路说清楚。大多数第一次做的人卡在三个位置：JDK 和 Tomcat 版本不匹配导致启动失败、数据库脚本书写不规范导致导入报错、代码与报告各写各的导致答辩一问就露怯。

下面这条路线适合课程设计场景，也适合想快速补一遍原生 Java web 的从业者：先确定版本组合和分层结构，再做数据库设计，然后写核心代码，最后用一套可复现的验证流程保证在任何机房机器上都能交付。

2. 博客系统技术选型：JDK 版本、Servlet 容器与分层包结构

2.1 JDK、Tomcat 与 Servlet API 的版本配套

做 Java web 博客系统，选型的第一原则不是“最新”，而是“环境能跑、资料好找、报告好讲”。课程设计最常见的做法是用 JSP + Servlet + JDBC 的原生组合，不引框架。理由很直接：运行时依赖只有一个 JDBC 驱动 jar；分层结构能覆盖课程设计要求的 Controller（Servlet）、业务逻辑、数据访问三层；答辩时评委对这套技术栈的提问难度也更可控。

版本组合建议按下表来定，这组搭配覆盖了从老机房到新装机的绝大多数情况：

很多同学在开始之前先在 Windows 上折腾 JDK 21 的下载安装和环境变量配置，这本身没有错，但要知道一个事实：JDK 版本只影响编译和运行，真正决定代码写法的是 Servlet API 版本。Tomcat 9 及以前的容器使用 javax.servlet 前缀，Tomcat 10 开始迁移到 jakarta.servlet，这是一个最常见的启动失败原因——代码明明编译通过，部署到 Tomcat 后却抛 ClassNotFoundException。我一般会在课程设计里选择 JDK 8 + Tomcat 9 的组合，因为网上现成的博客系统案例、过滤器写法、分页代码绝大多数都基于这一套；要是确认要用 JDK 21，就把所有import javax.servlet改成import jakarta.servlet，其余逻辑基本不用动。

2.2 分层架构：Servlet、Service、DAO 与实体类的分工

课程设计的评分点里，“分层是否清晰”往往比功能多寡更醒目。博客系统的常见分层是四层：Servlet 负责接收请求、调用服务、跳转页面；Service 承载业务流程；DAO 负责 SQL 语句和结果集映射；实体类对应数据库表记录。最典型的坏味道是把 JDBC 连接和 SQL 拼进 JSP 页面里，代码运行时一切正常，但报告里一画架构图就露馅。

我建议按以下职责切分：

• Servlet 层只做三件事：取参数、调 Service、决定跳转哪个 JSP。
• Service 层处理逻辑判断，例如用户名是否重复、密码校验是否通过。
• DAO 层使用 PreparedStatement 执行 SQL，返回实体对象或 List。
• entity 包中每个类的字段与表字段一一对应，类型用包装类更安全。

2.3 包结构与资源文件：源码、数据库脚本和报告分开归档

课程设计提交的是 zip 包，第一层的结构直接影响观感。常见的可靠布局如下：

blog-web/ ├── src/com/demo/blog/ │ ├── entity/ │ ├── dao/ │ ├── service/ │ ├── servlet/ │ └── util/ ├── WebContent/ │ ├── static/css/ │ ├── WEB-INF/lib/mysql-connector-j-8.0.33.jar │ ├── jsp/ ├── db/blog.sql └── doc/设计报告.md

WebContent 根目录下放 JSP 和静态资源，WEB-INF/lib 下放 MySQL 驱动；db 目录保存建库建表脚本；doc 目录放报告。这样分开有三个好处：源码打包时不混入冗余文件，数据库脚本能单独校验，报告的目录结构与实际代码一一对应。报告里画架构图时，直接引用这个包结构即可。

3. 博客系统六张核心表的设计：外键、索引与一条查询路径

3.1 用户、文章、评论与分类表的字段设计

博客系统的数据库设计通常以四张表为起点：用户表、分类表、文章表、评论表。这里给出一个课程设计够用、又不显得单薄的建表脚本：

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password CHAR(64) NOT NULL, nickname VARCHAR(50), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_article ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, category_id INT NOT NULL, title VARCHAR(200) NOT NULL, content TEXT NOT NULL, view_count INT NOT NULL DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_article_user FOREIGN KEY (user_id) REFERENCES t_user(id), CONSTRAINT fk_article_category FOREIGN KEY (category_id) REFERENCES t_category(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE t_comment ( id INT PRIMARY KEY AUTO_INCREMENT, article_id INT NOT NULL, user_id INT NOT NULL, content VARCHAR(500) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_comment_article FOREIGN KEY (article_id) REFERENCES t_article(id), CONSTRAINT fk_comment_user FOREIGN KEY (user_id) REFERENCES t_user(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

说明一下字段选择：用户名的 UNIQUE 约束保证注册时不产生重复账号；密码定义成 CHAR(64)，对应 SHA-256 摘要后固定 64 位字符串；文章表加外键约束并默认使用 InnoDB，是为了体现关系型数据库的完整性；时间字段用 DEFAULT CURRENT_TIMESTAMP 可以省略 Java 侧的显式赋值。字符集统一使用 utf8mb4，避免插入 emoji 表情或生僻字时出现乱码。

外键在这个规模下的作用是合理的。有人会建议“生产环境不用外键”，但课程设计要展示对关系的理解，保留外键并配合事务处理，报告里可写的内容更扎实。注意 MySQL 外键要求两个字段类型完全一致，INT和BIGINT混用会在建表时直接报错。

3.2 索引设计：分页列表和文章详情分别是两条路径

博客系统的高频查询有两类：首页文章列表需要按分类过滤、按时间倒序、分页返回；文章详情需要一次取正文、一次查评论。在这两类路径上，索引设计是不同的。

第一类路径的检索条件是category_id，排序条件是created_at，所以建议在 t_article 上建组合索引：

ALTER TABLE t_article ADD INDEX idx_category_time (category_id, created_at);

第二类路径的入口是文章主键 id，主键本身就是聚簇索引，不需要额外建索引；评论查询通过article_id关联，应在 t_comment 上建单列索引：

ALTER TABLE t_comment ADD INDEX idx_comment_article (article_id);

组合索引的列顺序有讲究。(category_id, created_at)能直接支撑“按分类查并按时间排序”的查询，无需额外 filesort；如果反过来建成(created_at, category_id)，同样的查询就享受不到前缀匹配，性能没收益。对一个小型博客系统来说，性能差异在数据量小时完全感知不到，但报告里能讲清这一点，属于典型的加分项。

3.3 从首页列表到文章详情的连续查询接线

需求拆分下来是三次查询：先查当前页文章列表，再按文章 id 取正文，再按 article_id 查评论列表。SQL 写法如下：

-- 1. 首页文章列表，按分类过滤并分页 SELECT a.id, a.title, a.created_at, u.nickname, c.name AS category_name FROM t_article a JOIN t_user u ON a.user_id = u.id JOIN t_category c ON a.category_id = c.id WHERE a.category_id = ? ORDER BY a.created_at DESC LIMIT ?, ?; -- 2. 文章详情，用主键直接取单条 SELECT a.id, a.title, a.content, a.view_count, a.created_at FROM t_article a WHERE a.id = ?; -- 3. 文章底部的评论列表，按时间正序 SELECT cm.content, cm.created_at, u.username FROM t_comment cm JOIN t_user u ON cm.user_id = u.id WHERE cm.article_id = ? ORDER BY cm.created_at ASC;

这里两个 LIMIT 参数的含义分别是偏移量和页大小。第一页用LIMIT 0, 10，第二页用LIMIT 10, 10。在 DAO 层通过 PreparedStatement 传入时，两个参数都必须用setInt绑定，绝对不能直接拼接到 SQL 字符串里，否则会有注入风险。详情页要顺手做一个阅读量自增，一般做法是在取详情之前执行UPDATE t_article SET view_count = view_count + 1 WHERE id = ?，这样每次刷新页面计数都增加。

4. 登录、文章发布与评论的代码实现：从 DAO 到 Servlet 的串接

4.1 用户登录与会话处理：不依赖框架时的权限控制

登录逻辑由 DAO 查用户、Servlet 建会话两层完成。第一步是 DAO 层查出用户密码摘要，典型的 JDBC 写法如下：

public User findByUsername(String username) throws SQLException { String sql = "SELECT id, username, password FROM t_user WHERE username = ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, username); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { User u = new User(); u.setId(rs.getInt("id")); u.setUsername(rs.getString("username")); u.setPassword(rs.getString("password")); return u; } } } return null; }

这段代码的逻辑并不复杂：try-with-resources 确保连接、语句、结果集全部自动关闭；PreparedStatement 解决了 SQL 注入问题和参数类型转换问题——第一个 setString 给占位符绑定用户名，后续比对密码时在 Service 层再做一次 SHA-256 摘要计算。注意不要在 DAO 里直接比较明文密码，很多博客系统的数据泄露都是从这里开始的。

获取到用户后，Servlet 层负责把用户身份放进会话：

HttpSession session = request.getSession(); session.setAttribute("loginUser", user); session.setMaxInactiveInterval(30 * 60);

setMaxInactiveInterval设定 30 分钟无操作自动过期。后续每个需要登录的页面，在 Servlet 里先取 session 中的loginUser，如果为 null 就重定向到登录页。更规范的做法是写一个LoginFilter过滤器统一拦路径，但课程设计里只要每个受保护 Servlet 都做了这个判断，功能上就满足要求。

4.2 文章发布与分页：总数、页大小与 LIMIT 参数的绑定

发布文章是典型的三层调用链：Servlet 接收 title、content、category_id 参数，Service 校验非空，DAO 执行插入。插入本身简单，分页列表才是容易写糙的地方。分页必须与总数配套，否则 JSP 上画不出页码。以下两个方法可以放在同一个 ArticleDAO 中：

public int count() throws SQLException { String sql = "SELECT COUNT(*) FROM t_article"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { rs.next(); return rs.getInt(1); } } public List<Article> findByPage(int offset, int pageSize) throws SQLException { String sql = "SELECT id, title, content, user_id, category_id, created_at " + "FROM t_article ORDER BY created_at DESC LIMIT ?, ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, offset); ps.setInt(2, pageSize); // 遍历 ResultSet 封装为 Article 对象后加入 List 返回 } }

分页的核心参数是 offset 和 pageSize。offset 的计算公式是(当前页 - 1) * pageSize，pageSize 一般取 5 或 10，由常量定义。如果页码从前端传来时是非数字，Servlet 要做异常兜底，默认当成第 1 页处理；如果 offset 大于数据总量，查询结果为空，页面要提示“没有更多文章”，而不是报数组越界或空指针。这里两个 setInt 的顺序必须与 SQL 中?的顺序一致，第一个是 offset，第二个是 pageSize。

4.3 评论写入与文章删除：事务边界的正反两个例子

发表评论和删除文章都需要事务参与，但事务的写法取决于外键设置。删除文章时，如果 t_comment 的外键定义了ON DELETE CASCADE，那么一条 DELETE 语句就能同时清掉该文章下的评论，无需显式事务；如果没有级联，就必须先删评论再删文章，两步操作要用同一个连接包在一个事务里。

评论数目的维护是另一个常见事务场景。如果在 t_article 表里增加了 comment_count 冗余字段，那么发表评论需要执行两条语句：插入评论、更新文章评论数。这时必须保证要么都成功，要么都回滚。典型的事务写法如下：

Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); String insertComment = "INSERT INTO t_comment (article_id, user_id, content) VALUES (?, ?, ?)"; // 1. 插入评论 try (PreparedStatement ps = conn.prepareStatement(insertComment)) { ps.setInt(1, articleId); ps.setInt(2, userId); ps.setString(3, content); ps.executeUpdate(); } String updateCount = "UPDATE t_article SET comment_count = comment_count + 1 WHERE id = ?"; // 2. 更新文章表的评论数 try (PreparedStatement ps = conn.prepareStatement(updateCount)) { ps.setInt(1, articleId); ps.executeUpdate(); } conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); DBUtil.close(conn); }

这段代码的关键是setAutoCommit(false)之后，连接上的所有操作都进入同一事务，直到commit()才落库；中途任何一步抛异常都会执行rollback()。关于事务边界，需要区分清楚：事务应该开在 Service 层还是 DAO 层？常见做法是开在 Service 层，因为一个业务方法可能调用多个 DAO 方法，事务跨度覆盖整个业务操作。如果把事务开在 DAO 方法内部，多条 DAO 分别提交，就失去了事务意义。

5. 交付前验证与报告三张图：把博客系统演练成稳定路径

5.1 冷启动验证：从建库到访问的固定顺序

每次拿到新机器、新环境，都要按同一个顺序验证系统：导入数据库、启动 Tomcat、访问首页。下面的命令假设 MySQL 和 Tomcat 已经装好：

# 1. 导入数据库脚本，确认无外键报错 mysql -uroot -p < db/blog.sql # 2. 启动 Tomcat，观察 logs/catalina.out 是否有异常 sh bin/startup.sh # 3. 检查进程监听端口 curl -I http://localhost:8080/blog/

建议三个步骤依次核对结果：导入脚本后执行SHOW TABLES;，确认四张表都在；启动后打开http://localhost:8080/blog/，确认返回 200；再走一遍“注册→登录→发文→评论→登出”的主流程。机房演示时最容易翻车的环节是 MySQL 密码不一致导致 DAO 层连接被拒，所以DBUtil里的连接信息不要写死在代码里，用db.properties放在 src 根目录，演示前只需修改一个文件。

5.2 报告里的三张图和 zip 打包建议

报告写作最忌讳代码截图堆砌。课程设计报告里至少要出现三张图：系统架构图，画清楚 Servlet、Service、DAO、MySQL 之间的调用关系；数据库 ER 图，把四张表的主外键关系画出来；页面原型图或截图，把登录、首页、详情三个关键页面各截一张。三张图对应了源码结构、数据库设计、功能演示三个评分维度。

最后一步是打包。zip 里应该同时包含源码目录、db 目录、doc 目录和一份 README，README 写明 JDK 版本、Tomcat 版本、MySQL 版本和启动步骤。常见做法是压缩时排除掉编译产物，只保留源码和资源文件：

zip -r 学号_姓名_web博客课程设计.zip src WebContent db doc README.md -x "*/target/*" -x "*/classes/*"

这样交出去的包，不依赖 IDE，不依赖个人电脑的既有配置，任何一台满足版本要求的机器都能按 README 还原运行环境。

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