企业官网建设流程全解析

一套完整的SpringBoot+Vue新闻资讯系统到底该怎么做？这篇文章我会从项目需求拆解、数据库设计、后端接口实现、前端页面联调、服务器部署、报告撰写和答辩准备这几个方面，按实际做项目的顺序给你完整捋一遍。包括每个环节为什么这么做、核心参数怎么定、实际部署时最容易踩的坑，以及答辩时导师最爱问的几个问题。内容都是基于我实际开发过的同类型项目整理出来的，适合正在做毕业设计、课程设计，或者想完整走一遍前后端分离项目的同学。

1. 项目整体拆解：需求、定位与技术选型

1.1 前后端分离的项目，为什么这套组合这么常见

先聊一个最基础的问题：做新闻资讯系统，为什么偏偏是Java + Vue + SpringBoot？这个组合几乎成了目前就业和毕业设计的标配，背后是有原因的。

从后端看，SpringBoot极大降低了Spring繁琐的XML配置成本。以前搭一个SSM项目要写一堆配置文件，找个bean都能翻半天。现在SpringBoot把大部分事情都自动配置好了，只需要关注业务代码本身。新闻资讯系统这类CRUD为主、附带一定业务逻辑的项目，用SpringBoot写起来非常顺手。

从技术生态看，Java的企业级生态太成熟了。数据库连接池、缓存、权限框架、分页插件，要什么有什么。尤其是配合MyBatis-Plus之后，单表的增删改查几乎不用手写SQL，开发速度非常快。

前端选择Vue的原因也很直接。新闻资讯系统需要同时包含用户浏览端和管理员管理端，如果不用前端框架，页面之间的状态管理、组件复用都是灾难。Vue的响应式机制、组件化开发、路由管理，加上基于Node的工程化工具链，让页面开发效率翻了几倍。

最核心的是，这套技术栈的学习资源多、社区活跃、薪资岗位多。做过这套项目的同学，简历上写"熟悉SpringBoot+Vue全栈开发"，面试官有得聊，你也有得讲，是性价比极高的组合。

1.2 功能模块怎么划分：用户端和管理端各做哪些事

新闻资讯系统的功能并不复杂，但是划分清楚模块边界，是项目是否"像样"的分水岭。很多同学一上来就写代码，写到后面发现功能互相纠缠，改一个地方崩三个页面，就是因为没有先做模块划分。

按角色划分，整个系统分为两种角色、两大端：

用户端（前台）面向的是普通浏览者，核心诉求是"看新闻"。拆解下来包含以下功能：

• 用户注册与登录：手机号或邮箱注册、明文密码至少要做MD5加盐处理
• 新闻分类浏览：按政治、经济、科技、体育等分类筛选新闻
• 新闻列表分页展示：支持按时间排序、按浏览量排序
• 新闻详情页：展示正文、发布时间、来源、浏览量
• 关键字检索：标题或内容模糊搜索
• 新闻评论：登录用户可以发表评论，评论按时间倒序展示
• 热门新闻推荐：按浏览量或评论数推荐

管理端（后台）面向的是管理员，核心诉求是"管内容"。功能包括：

• 管理员登录：独立的登录入口，和用户端登录入口分开
• 仪表盘统计：展示新闻总数、分类总数、今日新增等
• 新闻发布与编辑：用富文本编辑器录入新闻内容，支持上传封面图
• 新闻上下线与删除：控制新闻是否在前台可见
• 分类管理：新增、编辑、删除新闻分类
• 用户管理：查看注册用户列表、禁用或启用用户账号
• 评论管理：删除违规评论

这里有一个特别容易忽略的设计点：用户端和管理端虽然功能不同，但底层是同一套新闻表、评论表、用户表。千万别头脑发热给管理端单独建一套新闻表，否则后期数据同步会把你逼疯。

1.3 开发环境与工具版本规划

在做项目的第一步，先把开发环境定下来，避免后面因为版本不一致产生各种莫名其妙的问题。我的建议版本如下：

版本选择不是越新越好。比如很多同学一上来用SpringBoot 3.x + JDK 17，结果发现某些依赖不兼容、网上搜到的教程都是旧版写法，项目进度直接卡壳。我个人的经验是：如果是做毕业设计或课程设计，尽量用成熟稳定、资料多的版本组合，等真正工作了再追新完全来得及。

2. 数据库设计与后端核心实现

2.1 四张核心表是怎么设计出来的

数据库设计是新闻资讯系统的地基，地基没打好，后期SQL写得再花哨也是空中楼阁。我的设计思路是先梳理有多少实体，再分析实体之间的关联关系，最后落成表结构。

新闻资讯系统最终抽象出四个核心实体：用户、新闻分类、新闻文章、评论。对应四张表：

用户表（sys_user）：

新闻分类表（news_category）：

新闻文章表（news_article）——这是整个系统的核心表，字段最多：

评论表（news_comment）：

为什么新闻表要单独放一个category_id而不是直接用字符串存分类名？因为用ID关联可以保证数据一致性——分类改名时，新闻所属分类自动生效，不需要批量更新新闻数据。这就是数据库范式里的第二范式要求，也是答辩时导师经常问的一个点。

另外建议加索引：news_article表的category_id、create_time，news_comment表的article_id。加了索引之后，分页查询和评论查询在大数据量下性能会明显改善。这个细节写在报告里也是加分项。

2.2 后端工程结构划分与分层思想

拿到需求后不要急着写代码，先把包结构规划好。一个清晰的包结构，不仅自己开发时找文件方便，答辩时导师看代码也会留下好印象。

推荐的后端工程结构如下：

com.example.news ├── NewsApplication.java // 启动类 ├── common // 公共模块 │ ├── Result.java // 统一返回结果封装 │ ├── ResultCode.java // 返回码枚举 │ ├── JwtUtil.java // JWT工具类 │ └── GlobalExceptionHandler.java // 全局异常处理 ├── config // 配置模块 │ ├── CorsConfig.java // 跨域配置 │ ├── WebMvcConfig.java // 拦截器注册和静态资源映射 │ └── MybatisPlusConfig.java // MyBatis-Plus分页插件配置 ├── controller // 控制层：接收请求、返回结果 │ ├── AuthController.java │ ├── NewsController.java │ ├── CategoryController.java │ ├── CommentController.java │ └── AdminController.java ├── service // 业务逻辑层：处理业务规则 │ ├── NewsService.java │ ├── CategoryService.java │ ├── CommentService.java │ └── UserService.java ├── mapper // 数据访问层：MyBatis-Plus接口 │ ├── NewsMapper.java │ ├── CategoryMapper.java │ ├── CommentMapper.java │ └── UserMapper.java ├── entity // 实体类 │ ├── News.java │ ├── Category.java │ ├── Comment.java │ └── User.java └── dto // 数据传输对象：接收前端参数 ├── LoginRequest.java ├── NewsQueryRequest.java └── NewsSaveRequest.java

分层思想的核心是"各司其职"。Controller只负责接收参数和返回结果，不写业务逻辑；Service负责处理业务规则；Mapper只做数据读写。很多同学写项目喜欢在Controller里一把梭，既能收到请求又直接操作数据库，短期内确实快，但项目一复杂就完全没法维护。答辩时导师问"你的代码怎么解耦的"，答不上来就很尴尬。

2.3 统一返回格式与JWT登录鉴权

前后端联调阶段，最怕的就是接口返回格式不统一。一会儿返回一个map，一会儿返回一个json，前端解析起来要写一堆if判断。所以后端的第一个基础工作就是封装统一返回结果。

我的做法是定义一个泛型Result类：

public class Result<T> { private Integer code; // 状态码，200成功，500失败，401未登录 private String message; // 提示信息 private T data; // 数据体 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } public static <T> Result<T> unauthorized(String message) { Result<T> result = new Result<>(); result.setCode(401); result.setMessage(message); return result; } // 省略getter/setter }

这样不管哪个接口返回，前端都可以统一通过res.code来判断状态。特别要强调：这些getter和setter不能省，前端序列化全靠它。

登录鉴权我用的是JWT方案。相比于传统的Session，JWT天然适合前后端分离项目。用户登录成功后，后端生成一个token返回给前端，前端把它存在localStorage里，之后每次请求在Header里带上Authorization字段。后端通过拦截器校验token，校验通过就放行请求。

JWT生成逻辑：

public String generateToken(Integer userId, String username, Integer role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

拦截器里解析并校验token，如果token过期或签名不对，直接返回401。HS256是对称加密算法，SECRET_KEY相当于密钥，开发时随便设一个字符串就行，上线后再放到配置中心。

为什么不用Session？因为浏览器Cookie在跨域场景下处理起来麻烦，而且传统Session在分布式部署时有会话同步问题，JWT是无状态的，后端随便扩展几个实例都不影响用户登录状态。这个理由讲清楚，答辩能加分不少。

2.4 新闻模块的业务逻辑与分页查询实现

新闻模块是整个系统的核心业务。管理端发布新闻，用户端消费新闻，这里的业务逻辑细节比较多，我逐一说明。

新闻分页查询是最常用的接口，它需要同时支持分类筛选、关键字搜索、排序方式切换。接口设计如下：

@GetMapping("/api/news/page") public Result<Page<News>> getNewsPage(NewsQueryRequest request) { // 参数：pageNum, pageSize, categoryId, keyword, sortType Page<News> page = new Page<>(request.getPageNum(), request.getPageSize()); LambdaQueryWrapper<News> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.isNotBlank(request.getKeyword()), News::getTitle, request.getKeyword()) .or() .like(StringUtils.isNotBlank(request.getKeyword()), News::getSummary, request.getKeyword()); if (request.getCategoryId() != null) { wrapper.eq(News::getCategoryId, request.getCategoryId()); } wrapper.eq(News::getStatus, 1); // 只查已发布新闻 if ("view".equals(request.getSortType())) { wrapper.orderByDesc(News::getViewCount); } else { wrapper.orderByDesc(News::getCreateTime); } return Result.success(newsMapper.selectPage(page, wrapper)); }

这里用到了LambdaQueryWrapper，这是MyBatis-Plus的特色，不需要手写SQL就能完成条件拼装。eq表示相等条件，like表示模糊匹配，StringUtils.isNotBlank是为了防止传入空字符串导致SQL异常。

有两个坑要特别提醒。第一个是关键词搜索时用了or连接，要注意括号优先级问题，否则很容易查出和关键词不匹配的数据。第二个是浏览量自增操作不要直接写成读取再加一，并发情况下会丢数据，正确写法是用SQL语句原子更新：

@Update("UPDATE news_article SET view_count = view_count + 1 WHERE id = #{id}") void increaseViewCount(Long id);

2.5 评论模块与图片上传的常见实现

评论模块的核心设计点在于：查询评论时的数据组装。评论表里存的是user_id，但前端需要展示用户昵称和头像。有两种方案，一种是查评论时关联查询用户表，另一种是查询时先查出评论列表，再根据user_id列表批量查用户信息然后组装。第一种方案SQL写起来简单，但是每一条评论都关联一次用户表查询，有性能隐患；第二种方案需要多写一步组装的代码，但性能更好。

我实际开发用的是第二种方案。核心代码大概是：

public List<CommentVO> getCommentList(Long articleId) { List<Comment> comments = commentMapper.selectList( new LambdaQueryWrapper<Comment>() .eq(Comment::getArticleId, articleId) .orderByDesc(Comment::getCreateTime)); if (comments.isEmpty()) { return Collections.emptyList(); } List<Long> userIds = comments.stream().map(Comment::getUserId).distinct().collect(Collectors.toList()); Map<Long, User> userMap = userMapper.selectBatchIds(userIds).stream() .collect(Collectors.toMap(User::getId, Function.identity())); return comments.stream().map(comment -> { CommentVO vo = new CommentVO(); BeanUtils.copyProperties(comment, vo); User user = userMap.get(comment.getUserId()); if (user != null) { vo.setNickname(user.getNickname()); vo.setAvatar(user.getAvatar()); } return vo; }).collect(Collectors.toList()); }

图片上传是新闻系统不可少的功能，管理员发新闻时可能需要上传封面图，富文本编辑器里也要上传正文插图。后端的实现思路是接收MultipartFile文件，把它保存到服务器本地目录，然后返回可访问的URL。

保存路径建议放在启动类所在目录之外的独立目录。比如我习惯配置一个/upload/目录在项目根目录下，然后通过WebMvcConfigurer映射成静态资源：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath = System.getProperty("user.dir") + File.separator + "upload" + File.separator; registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); }

这里的user.dir是JVM的系统属性，指的是java -jar命令启动时所处的目录。部署到服务器上之后，jar包在哪，upload目录就在哪，不会出现找不到路径的问题。图片上传时文件名不要用用户原始文件名，容易冲突也容易乱码，最好用UUID或者时间戳重命名，后缀从原始文件名中截取。

3. 前端Vue页面设计与联调要点

3.1 Vue工程结构和路由规划

前端工程我习惯用Vue CLI脚手架创建。创建完成后，src目录下的结构需要重新整理，下面是推荐做法：

src ├── api // 接口请求模块，一个文件对应一个后端Controller │ ├── request.js // axios实例封装 │ ├── news.js │ ├── category.js │ ├── comment.js │ └── auth.js ├── components // 公共组件 │ ├── NavBar.vue // 顶部导航栏 │ └── Pagination.vue // 分页组件 ├── views // 页面组件 │ ├── home/Home.vue │ ├── news/NewsList.vue │ ├── news/NewsDetail.vue │ ├── login/Login.vue │ └── admin/ │ ├── AdminLayout.vue │ ├── Dashboard.vue │ ├── NewsManage.vue │ ├── NewsEdit.vue │ └── CategoryManage.vue ├── router │ └── index.js // 路由配置 ├── store // 状态管理（Vuex或Pinia） │ └── user.js └── utils └── auth.js // token存取工具

路由规划是前端开发的第一步。用户端页面和管理端页面要做到路由分离，管理端需要一个父路由配上子路由的嵌套结构，还要加上路由守卫——没有管理员权限的用户不允许进入后台。

前端进度条和后端路由配置一样，我用的是懒加载模式，只在访问对应路径时才加载对应的js文件。比如：

const routes = [ { path: '/', component: () => import('@/views/home/Home.vue') }, { path: '/news/:id', component: () => import('@/views/news/NewsDetail.vue') }, { path: '/login', component: () => import('@/views/login/Login.vue') }, { path: '/admin', component: () => import('@/views/admin/AdminLayout.vue'), meta: { requiresAuth: true }, children: [ { path: '', component: () => import('@/views/admin/Dashboard.vue') }, { path: 'news', component: () => import('@/views/admin/NewsManage.vue') }, { path: 'news/edit/:id?', component: () => import('@/views/admin/NewsEdit.vue') }, { path: 'category', component: () => import('@/views/admin/CategoryManage.vue') } ] } ];

3.2 axios封装与请求拦截器

前端所有HTTP请求我都通过一个统一的axios实例完成。这一步非常关键，做完之后，你不需要在每个页面里重复写"请求头加token"、"响应401时跳登录页"这些逻辑。

request.js的核心封装思路如下：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: '/api', // 通过代理转发，避免跨域 timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.removeItem('token') router.push('/login') return Promise.reject(new Error('未登录')) } if (res.code !== 200) { Message.error(res.message) return Promise.reject(new Error(res.message)) } return res }, error => { Message.error('网络请求异常') return Promise.reject(error) } )

这里有一个联调环节最常见的坑：baseURL配的是/api，后端接口本来就没有api前缀，怎么办？两种做法。第一种是后端Controller统一加上/api前缀，我建议用这种方式，因为vben这种大型管理系统也是这么做的。第二种是使用axios的路径写法直接写全路径，不推荐，代码会很乱。

后端加上/api前缀的方法也简单，在Controller类上用@RequestMapping("/api/news")这种写法即可。这样前端的/api/news/page和后端的/api/news/page就能对上，联调非常顺畅。

3.3 管理端核心页面的实现思路

管理端页面是Element UI的主场。新闻管理页要包含搜索区、表格区、分页区三个区块。搜索区支持按标题模糊搜索、按分类下拉筛选；表格区展示新闻标题、分类、浏览量、发布时间、状态；操作列提供编辑、上下线、删除三个按钮。删除要加二次确认弹窗，这是基本的人机交互素养。

新闻编辑页比较复杂，因为涉及富文本编辑器。我用的组件是vue-quill-editor，功能足够、文档多、集成简单。要注意富文本内容保存到MySQL的text字段没有任何问题，但展示时一定要用v-html指令渲染，否则页面上会显示一堆html标签。

还有一个很隐蔽的坑：富文本编辑器的图片处理。默认情况下，粘贴进编辑器的图片会被转成base64编码存进content字段，一篇带十几张图的新闻，数据库字段会有几百KB的数据，查询会很慢。更好的方案是把粘贴的图片自动上传到后端，编辑器里存的是图片URL。这个功能需要额外配置Quill的imageHandler，如果项目时间紧张，可以直接在代码里重写imageHandler让图片上传到后端。

用户端首页的设计重点是布局和信息分层。我的做法是：顶部导航栏展示系统名称和分类菜单；主区域左侧展示最新新闻列表（带分页），右侧展示热门新闻排行榜（按浏览量倒序取前10条）。这样信息层级清楚，用户进来就能快速找到感兴趣的新闻。

新闻详情页有一个性能优化细节：正文加载是异步的，为了不白屏，可以在请求发出后先展示一个loading效果，数据回来后用v-html渲染。同时做一个"阅读数+1"的调用，这个调用不需要等待响应，前端直接fire-and-forget就行。

3.4 前后端联调注意事项

本地开发联调阶段，跨域是最大的拦路虎。我在开发环境用Vue CLI的devServer代理解决跨域问题：

// vue.config.js module.exports = { devServer: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这样配置之后，前端请求/api/news/page会被devServer转发到http://localhost:8080/api/news/page，浏览器的开发者工具里看到的请求地址始终是同源的，就不存在跨域问题了。后端其实可以不用配置CORS，但为了保险，我建议还是加上一个CORS配置，这样万一前端直接请求整个后端地址也不会出错。

联调时最浪费时间的往往不是接口逻辑错误，而是字段名不一致。比如后端返回的是createTime，前端写成了create_time，结果页面上时间显示不出来。建议联调前先拉一个mock数据列表，把返回字段都过一遍，再开始写页面交互逻辑，可以少走很多弯路。

4. 部署全流程：从本地到服务器

4.1 后端打包与服务器环境准备

本地开发完成后，部署上线是整个项目中"最接近真实工作"的环节。很多同学项目做完了但部署失败，或者部署起来但没有日志排查能力，最后演示时当场翻车。

后端打包直接用Maven命令。在项目根目录执行：

mvn clean package -DskipTests

打包完成后，target目录下会生成一个news-system.jar文件。这个jar就是可执行的后端程序。

然后准备服务器环境。我用的是Linux服务器（以CentOS 7为例），需要安装以下环境：

# 安装JDK 8 yum install java-1.8.0-openjdk -y # 安装MySQL 5.7（如果服务器上还没有数据库） # 建议直接用yum安装官方源或者使用docker部署

数据库初始化这一步要特别注意。不要直接在服务器上一行一行地敲建表语句，而是先在本地把表结构都建好、把测试数据都录好，然后用mysqldump导出SQL文件，再上传到服务器上通过source命令导入。这样数据的一致性有保证。

上传jar包到服务器之后，我习惯用一个shell脚本来维护启停，而不是直接用java -jar命令前台运行，否则一旦关闭SSH终端程序就会死掉。推荐使用systemd服务托管：

# /etc/systemd/system/news.service [Unit] Description=News System After=network.target [Service] Type=simple User=root ExecStart=/usr/bin/java -jar /opt/news/news-system.jar SuccessExitStatus=143 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

启动服务：

systemctl daemon-reload systemctl start news systemctl enable news

这样即使进程崩溃，systemd也能自动拉起。查看日志用journalctl -u news -f，排查错误时比直接看控制台输出方便得多。

4.2 前端打包与Nginx配置

前端打包命令在Vue项目根目录执行：

npm run build

构建完成后，dist目录就是前端静态文件。把它上传到服务器的/opt/news-web目录。

前端静态文件用Nginx托管。Nginx的配置是整个部署环节最容易出错的部分，我给出一个经过验证的完整配置：

server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /opt/news-web; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传文件访问 location /upload/ { alias /opt/news/upload/; } }

配置文件里的try_files $uri $uri/ /index.html至关重要。Vue Router默认使用history模式，用户直接访问http://your-domain.com/news/3时，Nginx找不到对应的物理文件，如果不加这一行，刷新页面就会404。加上之后，所有找不到的路径都会回退到index.html，由前端路由接管处理。

/api/的代理配置也有一点讲究。location是/api/，proxy_pass是http://localhost:8080（末尾不带斜杠），这样请求/api/news/page会被转发成http://localhost:8080/api/news/page，前缀保留。如果proxy_pass末尾带了斜杠，就变成http://localhost:8080/news/page，和后端接口对不上了，这个细节特别容易踩。

最后验证部署结果的时候，我在服务器上依次执行：

# 验证后端是否启动成功 curl http://localhost:8080/api/news/page # 验证前端是否正常返回 curl http://your-domain.com/ # 验证代理是否通 curl http://your-domain.com/api/news/page

三条命令都返回预期的数据，整个部署就完成了。

4.3 部署环节最常踩的四个坑

第一，端口没放行。云服务器安全组里没有开放80端口或8080端口，本地curl正常，外网访问不通。排查方式是先curl localhost看通不通，通的话就是安全组规则问题。

第二，MySQL连接不了。报错一般是Communications link failure。原因通常是root用户默认不允许远程连接，或者数据库没有设置正确时区。解决方法是创建专门的数据库用户并授权远程访问，JDBC连接串加上serverTimezone=Asia/Shanghai。

第三，图片上传后无法访问。原因是Nginx没有配置/upload/目录的alias，或者alias指向的路径不对。这个建议在部署时就写好，别等演示时才发现。

第四，日志里有ClassNotFoundException。通常是因为本地JDK版本和服务器版本不一致，或者某些依赖没有打包进去。解决方法是确认服务器JDK版本不低于本地，pom.xml里确保打包插件是spring-boot-maven-plugin而不是maven-jar-plugin。

5. 项目报告撰写与答辩现场准备

5.1 高分开题报告和结题报告怎么写

很多同学技术做完了，但报告写得像流水账，评委看完毫无印象。报告的价值不只是记录过程，更是展示你"会思考"的证据。

标准的项目报告骨架如下：

第一章 绪论：项目背景与意义、国内外研究现状、主要工作内容 第二章 相关技术介绍：SpringBoot、Vue、MySQL、MyBatis-Plus的简介与选型理由 第三章 系统需求分析：功能性需求（用用例图）、非功能性需求（性能、安全、兼容性） 第四章 系统设计：系统架构图、功能模块划分、数据库ER图与表结构设计 第五章 系统实现：分模块展示核心代码和界面截图 第六章 系统测试：测试用例表格、测试结果分析 第七章 总结与展望：项目成果、不足与改进方向

报告的重中之重是第四章。数据库ER图要画清楚四张表以及表之间的关联关系，架构图要体现前后端分离的思想，模块划分图要和代码中的包结构对应上。

这里我强烈建议画一张时序图，描述"用户访问新闻详情页"这个场景从点击到展示的完整流程：浏览器发起GET请求→Nginx反向代理→SpringBoot控制器→Service层→Mapper查询数据库→数据返回→Vue组件渲染。这张图能非常直观地向导师展示你懂整个请求链路。

第二章的技术选型理由也值得认真写。每个技术选型都说出两三条理由加对比，比如"为什么用MyBatis-Plus而不是MyBatis：单表CRUD无需写SQL，开发效率提升约30%；分页插件内置，避免手写分页逻辑"。这些内容在答辩提问阶段都是加分项。

5.2 演示路线怎么设计才不容易翻车

答辩现场演示是整个流程的临门一脚，设计好演示路线能掩盖很多开发时的不足。

我的推荐演示路线如下：

第一步，展示首页布局：导航栏分类、最新新闻列表、热门新闻排行。 第二步，点击一篇新闻进入详情页，展示正文、浏览量、评论列表。这个过程中特别注意展示URL的变化，体现前端路由。 第三步，演示搜索功能，输入关键词搜索。 第四步，演示用户注册登录。注册一个测试账号，登录后发表一条评论，刷新后评论仍在。 第五步，登出，切换到管理员登录。 第六步，进入后台，先展示仪表盘统计，再发布一篇新新闻。这一步建议提前准备好素材和文字，做到发布过程一气呵成。 第七步，前台刷新，看到刚才发布的新新闻，形成闭环。

演示时这些细节把控很关键：提前清空浏览器缓存，确保所有图片能正常加载；提前在后台准备两到三条新闻作为展示数据；如果演示环境是本地，务必先把后端和前端都启动起来，切莫现场开项目；涉及输入的地方尽量提前输入或使用自动填充，减少现场打字时间。

5.3 答辩必问问题与回答思路

我整理了答辩现场导师提问频率最高的几个问题，每个都给出参考回答方向：

第一个问题："为什么选择前后端分离架构？"

回答要点：前后端分离让前端专注于页面渲染和交互，后端专注于数据处理和接口服务；开发和部署都可以独立进行，前端产物是静态文件可以由Nginx托管，后端是Java服务独立运行；联调只要约定好接口格式即可，团队协作效率高。

第二个问题："JWT和Session有什么区别？为什么选JWT？"

回答要点：Session是服务端会话状态，需要占用服务器内存，分布式场景下要同步会话；JWT是无状态的身份凭证，服务端只需要解析token即可认证，天然适合前后端分离和水平扩展。JWT自带过期时间，能有效控制登录态时长。

第三个问题："你的数据库有哪些索引？为什么？"

回答要点：新闻表的category_id用于分类筛选查询，create_time用于按时间排序；评论表的article_id用于查询某篇新闻下的评论列表。这些都是高频查询字段，加了索引之后检索效率明显提高。索引的底层数据结构是B+树，查找时间复杂度是O(logN)。

第四个问题："系统如果用户量大了，哪个环节会先成为瓶颈？"

回答要点：如果新闻数据量大，数据库查询是瓶颈，可以用Redis缓存热门新闻列表、新闻详情，减少数据库压力；如果并发高，可以把Nginx和jar包做成多实例部署，前面加负载均衡；图片这类静态资源可以迁移到对象存储，Nginx只做反向代理。

这些问题提前准备，答辩时就不会慌。注意回答的时候不要死记硬背，要把问题的本质理解透，用自己的话讲出来，才能应对各种延伸提问。

6. 常见问题排查与避坑记录

6.1 开发阶段的疑难杂症

做这个项目的过程中，我几乎把新手能踩的坑都踩了一遍，列几个最有代表性的：

第一个是前端访问接口报跨域错误。浏览器的报错信息里写着CORS policy，但其实不是后端没配跨域的问题，而是请求路径打错了。比如后端接口是/api/news/page，前端却用了/news/page，走了Vue的history路由，打到devServer后找不到对应的代理规则，就返回了404。排查的办法很简单，打开浏览器的Network面板看请求URL到底是什么，和后端实际接收路径对一下，基本一眼就能发现问题。

第二个是后端修改代码后，前端调用还是旧的结果。这个问题多出在idea开发时SpringBoot没开自动编译，或者浏览器有缓存。idea里我习惯把Build Project Automatically打开，并且用devtools做热重启；如果还不行，就手动强刷浏览器缓存Ctrl+Shift+R。

第三个是富文本编辑器保存中文乱码。乱码的根源几乎都是连接串缺了characterEncoding=utf8或者数据库表本身就是latin1字符集。MySQL 5.7建库时务必写CREATE DATABASE news_db DEFAULT CHARACTER SET utf8mb4;，连接串写jdbc:mysql://localhost:3306/news_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，这两个地方对了，中文就不会乱。

第四个是Maven依赖下载慢或者直接失败。国内环境我建议把Maven中央仓库镜像配成阿里云镜像，在settings.xml里加入mirror配置。这一步能省下大量的等待时间。

6.2 上线阶段的故障实录

我记忆最深的一次部署翻车经历，是前端history路由没有配置try_files，用户直接访问某一篇新闻详情页时Nginx返回404。当时在答辩前一个小时才发现，立刻修改了Nginx的location配置并reload，问题解决。如果当时没准备这个排查经验，演示就翻车了。

还有一次是后端服务莫名挂掉，排查发现是JVM默认内存设置过小，而新闻接口在某种场景下创建了大量对象导致OOM。后来在systemd服务里加上JVM参数：

ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar /opt/news/news-system.jar

问题再也没有出现过。

6.3 问题排查方法论总结

当你遇到任何一个Bug，我建议按这个顺序排查，效率最高：

第一，看现象和报错。浏览器Network面板的红色请求、后端控制台红色的堆栈，先定位是哪一端的问题。 第二，确认请求参数和响应格式。用Postman直接调后端接口，如果Postman能通而页面不通，就是前端传参问题；如果Postman也不通，就是后端逻辑问题。 第三，看日志。后端日志是最重要的线索来源，有日志就能还原现场。没有日志就别说自己在做项目。

这套方法论对做任何项目都通用，不局限在这个新闻系统里。

7. 写在最后：这类项目的延伸思路

新闻资讯系统的核心价值在于它包含了一个完整业务系统几乎所有的要素：用户认证、权限控制、内容管理、数据展示、前后端交互。做完这个项目，你的收获远不止一篇代码。

如果做完基础版本想继续进阶，可以沿着这些方向扩展：

• 给新闻加上标签体系，实现标签聚合和推荐
• 引入Redis缓存热门新闻、新闻阅读量，体验缓存对性能的提升
• 用Elasticsearch替换MySQL的模糊搜索，实现全文检索
• 后台增加日志审计功能，记录管理员操作行为
• 前端用Vite替代Vue CLI，体验新一代构建工具的速度
• 部署时使用Docker容器化，配置nginx + jar + mysql三个容器

这些都是面试时可以拿出来讲的亮点。我个人在这些项目的反复开发中最大的体会是：项目本身不难，难的是把整个链路想清楚再做。先设计再动手，比先动手再返工省三倍时间。数据库表结构多想十分钟，后期改写的成本可以省一天。这些经验，写代码写得多了自然会有体会。

如果你正卡在某个环节，不妨回到文章里的对应章节对照排查一遍，大多数问题都是细节没对齐。项目顺利跑起来的那一刻，你学到的这套全栈开发流程，才真正是你自己的。