企业官网建设流程全解析

简介：这份资源是围绕“网站新闻管理系统”撰写的大学毕业论文设计文档，面向计算机相关专业学生及需要完成Web系统类课设或毕设的初学者。内容从系统总体设计、数据库设计到各功能模块详细实现均有完整论述，采用JSP+SQL Server 2000技术方案，基于B/S结构，并给出了公共模块、新闻浏览、发布、修改、删除及管理员验证等关键模块的设计思路与页面效果。资源仅包含1个doc文档，压缩包大小461KB，全文结构清晰，目录完整，可作为论文写作、系统功能规划和答辩讲解的参考模板。已有96人浏览学习。文档中还包含新闻文章表、用户表等数据库表设计以及运行效果发布说明，既能帮助理解新闻管理系统的整体开发流程，也能为同类信息管理系统的设计与实现提供可复用的思路和格式范本。

1. 新闻管理系统：毕业设计里最被低估的“工作量黑洞”

如果你以为新闻管理系统就是“后台发文章、前台看列表”，那这个毕设大概率会做到一半才发现坑比想象中多。新闻管理系统本科学位论文里出现频率极高，但它真正消耗时间的地方不在“增删改查”，而在栏目多级结构怎么存、审核流程怎么走、搜索怎么做、权限怎么分，以及这些设计能不能在论文里讲出逻辑闭环。适合谁做这套系统呢：想做 Web 开发方向、不想碰算法和深度学习、希望用一套完整业务系统展示工程能力的人。这篇笔记按我做过多个类似后台管理系统方案的经验，把架构、数据库、后台、前台、权限、排错和对答辩的准备一条线讲完，照着搭能省出至少两周的返工时间。

2. 先定架构再做系统：为什么我推荐 SSM 而非 Spring Boot 全家桶

2.1 技术栈选型的真实逻辑：不是为了老，是为了论文能写清楚

很多同学一上来就选 Spring Boot + Vue 前后端分离，觉得时髦。但做毕业设计，第一原则永远是“你能否讲清楚每一个组件存在的理由”。Spring Boot 自动配置太多，答辩老师问“你的拦截器是怎么注册的”“你的事务是怎么生效的”，如果你只能答“加了注解就行”，那这场答辩会很吃力。我一般建议本科毕设选 SSM（Spring + Spring MVC + MyBatis）做后端，前端用 JSP 或 Thymeleaf 做服务端渲染，数据库选 MySQL。这套组合的优点是分层非常明显：Spring 管业务对象，Spring MVC 管请求路由，MyBatis 管 SQL，每一层都能在论文架构图里对应到具体代码文件。反直觉的是，越“老”的技术栈，越容易在答辩时展示你理解得深。

前端方面，不建议上 Vue 全家桶。新闻管理系统的核心价值在内容管理和发布流程，前端交互并不复杂，服务端渲染能让搜索引擎抓到新闻页内容，也省去跨域和 Token 刷新的麻烦。Thymeleaf 和 JSP 选哪个都行，我更偏向 Thymeleaf，因为它的语法更接近 HTML，模板继承做公共头尾比 JSP 的 include 干净。

2.2 数据库怎么设计才能撑起论文的“系统分析”章节

数据库是新闻管理系统里最值得花时间的地方，因为论文里的 E-R 图、数据字典、范式分析全都要从这里出。先看最小可用表集合：用户表、栏目表、新闻表、评论表，再加一个操作日志表。如果做了审核流程，新闻表里加 status 字段就够了，不需要单独建审核表。

建表时有几个边界问题容易踩坑。第一个是栏目表的层级结构，我见过直接用 parent_id 做无限级分类的，简单但查询子树很痛苦。更稳的做法是同时配 parent_id 和 level 字段，level 存“1-2-3”这种路径字符串，查某个栏目下所有子栏目时用 LIKE '1-2-%'。第二个是新闻表必须单独存发布时间和更新时间，不要只用一个 create_time 混着来。第三个是评论表要冗余新闻标题字段，不要只存 news_id，否则后台评论管理列表每次都要 join 新闻表。

下面是一组可以直接抄的建表核心语句，按顺序执行就能把骨架搭起来：

CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, parent_id INT DEFAULT 0, level_path VARCHAR(100) DEFAULT '', sort_order INT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE news ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, category_id INT NOT NULL, summary VARCHAR(500), content MEDIUMTEXT, author_id INT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0草稿 1待审核 2已发布 3已下线', views INT DEFAULT 0, published_at DATETIME, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_category_status (category_id, status), INDEX idx_published_at (published_at) );

重点说两个参数：status 字段用 TINYINT 而不是 VARCHAR，因为状态流转是程序控制的有限集合，数字比字符串更省空间也更好写 switch 判断；idx_category_status 这个联合索引是新闻列表页的命脉，新闻系统 90% 的查询都带“某个栏目下已发布”的条件，索引如果漏建，数据量到几万条后列表页会明显变慢。published_at 单独建索引则是为了前台按时间排序的“最新新闻”模块。

2.3 Maven 工程结构和配置文件：把包名都规划好，论文不返工

包名规划直接决定论文里“系统实现”章节的截图和代码注释怎么写。我通常用 com.example.news 做根包，下面分 controller、service、mapper、entity、common 五个包。common 里放统一返回结果类、异常处理器、分页工具类。很多人忽略的是 resources 目录下的文件分层：mapper 目录放 MyBatis 的 XML 文件，static 目录放 CSS 和 JS，templates 放 Thymeleaf 模板。如果你用 JSP，那 templates 换成 webapp/WEB-INF/views。

配置文件里最需要关注的是 MyBatis 的驼峰映射，不打开这个配置，数据库的 created_at 字段映射到实体的 createdAt 就会全部是 null：

<configuration> <settings> <setting name="mapUnderscoreToCamelCase" value="true"/> <setting name="logImpl" value="SLF4J"/> </settings> </configuration>

关于数据源连接串，务必加上 useUnicode=true 和 characterEncoding=utf8 这两个参数，否则后期做全文搜索时中文分词会出乱码问题。连接池用 Druid，它的监控页面在答辩时是一个很好的加分演示点，能看到当前连接数、SQL 执行次数，属于“一屏展示系统运行状态”的实物证据。

2.4 依赖注入与事务：让论文里的 Spring 章节有真东西可写

Spring 的核心思想是控制反转，这个理论每个同学都会背，但落到代码里就是“你不在 service 里 new 一个 mapper”。写 controller 时通过构造器注入 service，写 service 时注入 mapper，这不仅是规范问题，更是为了让单元测试能方便地换 mock 实现。事务配置上，新闻系统真正需要事务的地方只有两个：发布新闻时同时更新栏目下的新闻计数；删除栏目时把该栏目下所有新闻的 category_id 置为 0。这两个操作都需要保持原子性。

在 SSM 里配置事务最简单的方式是 Spring 配置文件里开注解驱动事务，然后在 service 实现类的发布方法上加 @Transactional。需要注意的是，事务只对 RuntimeException 回滚，如果你在代码里 catch 了异常又没重新抛出，事务是不会回滚的。这个细节在答辩里被问到概率极高，建议你故意在代码里留一个测试用的 catch 块，也好解释。

3. 后台管理模块怎么落地：新闻发布、栏目管理、权限控制的完整套路

3.1 管理员登录与权限拦截：不是加个过滤器那么简单

后台系统的第一道门是登录。常见的做法是登录成功后把用户对象存进 Session，然后写一个 HandlerInterceptor 拦截所有 /admin/** 请求，判断 Session 里有没有用户。这个方案能跑通，但有个硬伤：浏览器关闭后 Session 就失效了，用户体验差。更好一点的做法是登录成功后生成一个 token，存到 Cookie 里，数据库记一条 token 记录，拦截器拿 token 查用户。毕设系统用 Session 就够了，但论文里关于会话管理的讨论可以提一句 Cookie 方案的优劣，显得你思考过。

权限控制上，新闻系统不需要做到 RBAC 那么重，两到三种角色就够：超级管理员、编辑、普通用户。超级管理员能管理用户和栏目，编辑能发布和审核新闻，普通用户只能浏览和评论。实现方式用拦截器加角色判断，在 HandlerInterceptor 里检查当前用户的 role 字段，不符合就重定向到无权限页面。下面是一个简化版拦截器，核心逻辑都在 preHandle 里：

public class AdminInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect(request.getContextPath() + "/admin/login"); return false; } if (!"ADMIN".equals(user.getRole()) && !"EDITOR".equals(user.getRole())) { response.sendRedirect(request.getContextPath() + "/403.jsp"); return false; } return true; } }

这里要解释两个容易忽略的参数：sendRedirect 的地址必须带 request.getContextPath()，否则项目部署在带应用名的路径下时，重定向会 404；角色判断用字符串 equals 而不是用整数比较，是为了代码可读性更好，你在论文里贴这段时不需要额外注释就能看懂。拦截器配置在 Spring MVC 配置文件里，要注意排除登录接口本身和静态资源路径，不然 CSS 和 JS 全被拦掉，页面直接裸奔。

3.2 新闻发布的完整流程：从表单到数据库的字段校验与状态流转

发布新闻是用户操作最频繁的功能，也是最容易写乱的部分。表单提交过来的数据包括标题、栏目、摘要、正文内容、封面图地址。第一步不是入库，而是校验：标题不能为空且长度小于 100 字，栏目必须存在，正文不能为空。用 Spring MVC 的 @Valid 注解做 Bean Validation 是最省事的，但要注意错误信息得在页面上回显，所以 controller 里要判断 BindingResult。

发布动作本身建议分成两个方法：一个处理“保存草稿”，一个处理“提交审核”。草稿不走状态机，提交审核才把 status 从 0 改成 1。这样做的好处是编辑写了一半的新闻不会因为误点“发布”直接上线。管理员审核通过后 status 变成 2，同时写入 published_at。整套状态流是 0 → 1 → 2 → 3，3 是下线状态，下线后还可以重新提审回到 2。

正文内容的存储和回显需要特别处理。如果用富文本编辑器，存的是 HTML，前台展示时需要原样输出而不能转义。Thymeleaf 里用 th:utext 而不是 th:text，JSP 里用 <c:out> 的 escapeXml="false" 属性。这里有个安全坑在避坑章节细说，先记住结论：富文本内容在存储前要做 XSS 过滤，最轻量的方案是只允许白名单标签。

3.3 栏目管理树的增删改查：递归算法的论文素材库

栏目管理是新闻系统另一个核心模块，也是论文里能写“算法”的地方。树形结构的展示和增删改查是经典递归题材，论文里画一张递归调用的流程图，比写十个页面截图都有说服力。实现上，先查出所有栏目放进 List，然后内存里组装成树，再递归拼成 JSON 给前端；查询子栏目时用 level_path 字段做前缀匹配，这条路径可以写在 MyBatis 的 XML 里：

<select id="selectByParentPath" resultType="com.example.news.entity.Category"> SELECT * FROM category WHERE level_path LIKE CONCAT(#{path}, '%') ORDER BY sort_order ASC </select>

删除栏目时不能直接 DELETE，因为可能还有子栏目和新闻挂在下面。标准做法是检查子栏目数量和新闻数量，有内容就提示不能删除；确认要删的话，把该栏目及其所有子栏目的新闻全部移到“未分类”栏目（category_id 设为 0）。这一步要用事务包起来，否则删了一半子栏目失败，数据就不一致了。

3.4 用 Redis 缓存热门新闻列表：性能优化怎么写进论文

本科毕设做缓存往往被当成炫技，但其实很有必要，因为新闻首页和栏目页会被高频访问，而这些数据实时性要求并不高。我一般用 Redis 缓存首页的“头条新闻”和“最新新闻”两个列表，key 分别是 news:headline 和 news:latest，value 用 JSON 数组存新闻 ID 和标题的映射。缓存更新策略用“主动更新”：发布或下线新闻时，在 service 里同步删除对应缓存 key，而不是等过期。这个策略比设置过期时间更可控，页面数据最多落后一次操作。

配置 Redis 时，序列化器用 StringRedisSerializer 存字符串，用 Jackson 序列化 Java 对象成 JSON，避免默认 JdkSerializationRedisSerializer 产生乱码。连接池参数方面，max-idle 和 max-active 按毕设规模设 10 和 50 就够，不需要学生产环境调几百。缓存命中情况可以打印日志，答辩时展示“Redis 缓存命中率 85%”这种数据，比空口说“用了缓存”有力得多。

4. 前台展示与搜索功能：把“能看”做成“能用”

4.1 首页渲染策略：服务端拼装还是前端异步拉取

新闻类网站对首屏速度有天然要求，首页既要展示头条又要展示各栏目最新几条。服务端渲染的典型做法是在 controller 里组装一个 IndexVO，把头条新闻、栏目列表、最新新闻分别查好塞进 Model，Thymeleaf 模板里循环渲染。这种方式的缺点是一旦栏目多，首页查询次数会膨胀，所以要用 3.4 里的缓存把高频数据挡住。

异步渲染的方式是前端只加载一个骨架，然后 fetch /api/news/headline 接口拿数据。这个方案适合前后端分离，但新闻系统这样做会影响 SEO，搜索引擎抓不到动态渲染的内容。如果你不追求搜索引擎收录，异步渲染的交互体验确实更好，页面切换栏目不用整页刷新。我的建议是：前台列表页用服务端渲染保底，栏目切换用局部刷新做增强。这样论文里既能写 JSP/Thymeleaf 模板引擎，又能写 AJAX 局部刷新，技术点更丰富。

4.2 搜索功能的三层递进：别一上来就上 Elasticsearch

很多同学觉得搜索就是“SELECT * FROM news WHERE title LIKE '%关键词%'”，做完发现慢得离谱。这个方案在小数据量下没毛病，但数据超过一万条时，LIKE 前置通配符会让索引失效。第一层优化是只针对标题做全文索引（MySQL 的 FULLTEXT），第二层是引入中文分词，第三层才考虑 Elasticsearch。毕设做到第二层就足够有深度了。

用 MySQL FULLTEXT 索引配合 ngram 分词器是最常见的落地方式，建表时给 title 和 content 加 FULLTEXT 索引，查询时用 MATCH AGAINST。注意 MySQL 5.7 以后 ngram 分词器需要设置 ngram_token_size 参数，默认是 2，代表按两个字符切分，对中文效果还行。

ALTER TABLE news ADD FULLTEXT INDEX ft_news_title_content (title, content) WITH PARSER ngram; SELECT id, title FROM news WHERE MATCH(title, content) AGAINST('大学 新闻' IN NATURAL LANGUAGE MODE) LIMIT 20;

这里有个边界情况要知道：MATCH AGAINST 对长度小于 ngram_token_size 的搜索词会返回空结果，所以搜索框要限制最小输入长度为 2。相关性排序默认按词频，如果你想让标题匹配的新闻排在前面，可以给标题字段的权重调高，做法是建两个全文索引分别查标题和内容，然后把结果集合并，标题命中的标记 rank=1，内容命中的 rank=2，ORDER BY rank。这个优化在论文里很好写，实现也不复杂。

4.3 新闻详情页与浏览量计数：并发下的“脏读”问题

详情页是最容易被忽略性能问题的地方。浏览量计数如果用“每次请求都 UPDATE news SET views = views + 1”，一万并发下 MySQL 会被写锁拖死。毕设不需要扛并发，但代码规范要有。常见做法是把浏览量先放 Redis 的 ZSET，每 5 分钟批量同步一次数据库。这个方案涉及定时任务，论文里又多一个可写的模块。

详情页的上下篇导航也容易写错。上一篇是“比当前新闻发布时间更早且最接近的一条”，SQL 是 SELECT * FROM news WHERE published_at < 当前时间 ORDER BY published_at DESC LIMIT 1，不能简单用 id 减 1，因为新闻可能被删除过，id 不连续。

5. 新闻系统的 5 个经典翻车现场：从数据库乱码到发布的新闻前台不显示

5.1 数据库中文乱码，页面显示问号

现象：后台录入新闻标题是中文，保存后数据库里变成“???”，前台页面显示乱码。 原因：数据库连接串没加 characterEncoding=utf8，或者数据库表本身的字符集不是 utf8mb4。常见于安装 MySQL 时默认字符集选了 latin1。 解决：修改连接串加参数，然后执行 ALTER TABLE news CONVERT TO CHARACTER SET utf8mb4；注意已经变成乱码的数据救不回来，只能删除重录。建库时直接写 CREATE DATABASE news_db DEFAULT CHARACTER SET utf8mb4，一劳永逸。

5.2 写好的拦截器把登录页也拦截了，死循环重定向

现象：访问后台登录页，浏览器提示“重定向次数过多”。 原因：登录接口路径在拦截器的排除列表里漏掉了，preHandle 判断用户为空就 sendRedirect 到登录页，而登录页本身又被拦截器拦，于是反复重定向。 解决：在 Spring MVC 配置里排除登录相关路径和静态资源，用 mvc:exclude-mapping 或者 interceptor 注册时指定 excludePathPatterns。这个坑诊断方法也简单：浏览器开发者工具看响应状态码，全是 302 基本就是这个原因。

5.3 发布的新闻在前台列表页看不到，数据库里 status 却是 2

现象：管理员审核通过后，新闻在后台能看到，但前台首页和栏目页都不显示。 原因：前台列表查询 SQL 的条件里漏了 status=2，或者多了一个deleted字段判断没赋值。另一种可能是查询走了 Redis 缓存，缓存里还是旧数据，新发布的新闻没触发缓存删除。 解决：先看前台列表接口的 SQL 日志，MyBatis 开启 logImpl 后控制台会打印完整 SQL。如果能查到数据但页面不显示，那就是模板渲染问题；如果 SQL 查不到，检查状态条件；如果 SQL 查到了且页面有数据，那就是浏览器缓存，强制刷新即可。针对缓存问题，把发布新闻的 service 方法里加上 redisTemplate.delete 操作。

5.4 富文本编辑器的 HTML 被转义，前台显示一堆标签

现象：新闻正文在后台编辑时是正常排版，前台页面显示

标签和 HTML 源码。 原因：模板渲染时用了转义输出，Thymeleaf 的 th:text 默认转义 HTML 实体，JSP 的 EL 表达式默认也是转义输出。 解决：正文内容改用 th:utext 输出，但要注意这样会带来 XSS 注入风险。安全做法是在存储前做白名单过滤，推荐用 Jsoup 的 clean 方法，只保留 p、br、strong、img 等标签。这个处理过程也能写进论文，属于安全模块的加分项。

5.5 搜索“新闻”两个字，结果全是空的

现象：搜索框输入两个字的词，查询结果为空；输入一个词反而能搜出来。 原因：ngram_token_size 设置过大，默认是 2，意味着索引按两个字符切词。搜索词长度等于 token_size 时，按理说应该能匹配，但如果输入的是“新闻”而索引里切的是“大学新闻”的“大学 新闻”，单字搜索反而不匹配。部分版本 MySQL 对短词默认不参与全文索引。 解决：把 ngram_token_size 调成 1，但会显著增大索引体积。或者搜索框限制最小长度 2，同时在 SQL 里对单字搜索退化为 LIKE 查询。我个人更倾向于后者，因为毕设数据量不大，LIKE 性能影响可忽略。

6. 最后 30 天怎么收尾：面向答辩的代码取舍与论文对应

系统能跑起来只是第一步，论文和系统代码要能一一对上才扛得住提问。我自己的习惯是给每个核心模块做一个“三件套”检查：数据库表、service 方法、页面操作三者能对应上。评审老师常问“你这个新闻状态是怎么流转的”，你要能当场打开数据库把 status 字段指给他看，再打开发布页面演示一次。因此，代码里的状态常量建议用枚举而不是裸数字，枚举名写着 DRAFT、PENDING、PUBLISHED，口头解释时也顺嘴。

演示环节有一个非常实用的准备：准备一套“预置数据”，包括不同栏目的新闻各 5 条，其中一条故意带图片、一条超长正文、一条含特殊字符。演示时先展示正常流程，发布一条新新闻，然后立刻在前台按发布时间倒序找到它。这个闭环演示比讲十分钟 PPT 都有说服力。答辩前把项目导出成 war 包放到 Tomcat 里跑一遍，确认不是只有在 IDEA 里才能启动。另外把 Redis 和 MySQL 的启动命令写进 README，避免答辩现场换机器后一脸懵。

关于论文的技术深度，我最后的建议是不要贪多。做透发布审核流程、栏目树、全文搜索这三个点，比堆砌 Shiro、Elasticsearch、RabbitMQ 却讲不出细节要稳得多。写文档时，每个功能模块配一张截图加一段核心代码，截图是前台页面的实际操作结果，代码只截关键方法，不要整页贴。终极检查项是：把论文里出现的每个技术名词都在代码里找到对应实现，找不到就删掉那个名词。这招帮我避开了至少三处“纸上谈兵”的硬伤，希望同样帮到你。

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