企业官网建设流程全解析

手上正好在帮一位学员把一套“SpringBoot + Vue + MySQL 的当代作家信息管理系统”从选题一路折腾到答辩通过，这题目听起来就是标准的管理系统三件套，但真要做扎实、能过查重还能答得上盲审老师的问题，里面细节点非常多。这篇文章把核心的选型思路、表结构设计、前后端接口对接、部署上线的实操过程，以及我在辅导过程中踩过的坑、总结的排查清单都整理出来，给你一份可以“抄作业”也能“讲明白”的完整参考。

1. 项目整体设计与需求拆解

1.1 为什么这类管理系统适合做毕设

每年毕设选题季，管理系统类题目永远是最稳的选择。它的好处在于业务逻辑清晰、技术栈主流、工作量可视化强。一个作家信息管理系统，核心就是“增删改查 + 条件筛选 + 数据关联”，但把搜索、分页、图片上传、关联查询、权限控制这些点全部做到位，工作量足够撑起一篇合格的毕业论文。

从评审老师的视角来看，一个管理系统能否高分，看的不是功能多炫，而是数据表设计是否规范、前后端交互是否合理、是否有异常处理意识、部署是否真的跑通。所以这篇博文会围绕这四条线展开，让你从立项到答辩都有清晰的逻辑支撑。

“当代获奖知名作家”这个主题本身也有加分效果。它让系统不只是抽象的“学生管理”“图书管理”，而是有文化属性，筛选条件里可以加入“获奖类型”“作品体裁”“代表作品”等字段，显得更有设计感，也方便在论文里写出需求调研的过程。

1.2 技术选型的底层逻辑

SpringBoot + Vue + MySQL 这个组合是当前就业市场认可度最高的技术栈组合之一。选它，不只是因为资料多、问题好搜，更因为它贴近企业真实项目的分层思想。

后端用 SpringBoot，核心价值在于“约定大于配置”，一个注解就能搞定路由、依赖注入、事务管理，比起早年间的 SSH 架构写一堆 XML 配置，开发效率高了一个量级。前端用 Vue，核心价值在于组件化开发，页面上的搜索栏、作家卡片、表单弹窗都可以拆成独立组件，状态管理也清晰。MySQL 则是关系型数据库的常青树，对事务支持、对 SQL 标准的遵循都足够稳定。

三个人选型的理由要在论文里写清楚，答辩时也大概率会被问到。标准话术是：SpringBoot 提供自动配置与内嵌容器，降低部署成本；Vue 采用响应式数据绑定与组件复用，提升界面开发效率；MySQL 免费开源、性能稳定，适合中小型数据场景。

1.3 功能模块划分与优先级排序

这类系统的功能模块，我通常建议拆成四大块：

• 作家信息管理：姓名、出生日期、国籍、代表作、简介、头像等基础信息的维护
• 获奖信息管理：奖项名称、获奖年份、颁奖机构、获奖作品等
• 作品信息管理：作品名称、类型、出版年份、内容简介
• 系统辅助功能：用户登录、数据统计面板、按条件组合检索

做毕业设计最关键的一点是“控制范围”，千万别想着把社交、推荐、评论统统塞进去。功能越多，Bug 越多，论文主线越容易散。建议把“综合条件检索”和“多表关联展示”作为亮点来打磨，这两点技术含量足够，且演示效果好。

从数据关系看，作家和作品是一对多，作家和获奖记录也是一对多。这种关系如果处理得自然，数据库设计的亮点就出来了。后文会专门讲表结构。

2. 数据库设计：系统的地基工程

2.1 核心数据表结构设计与关系说明

数据库是管理系统的灵魂。很多毕设被老师质疑，问题就出在表设计不合理，要么字段冗余，要么缺少外键约束，要么时间字段类型选错。

这套系统我建议设计了五张核心表。

作家基本信息表（writer）：

CREATE TABLE `writer` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` varchar(50) NOT NULL COMMENT '作家姓名', `gender` tinyint DEFAULT NULL COMMENT '性别 1男 0女', `birth_date` date DEFAULT NULL COMMENT '出生日期', `nationality` varchar(50) DEFAULT NULL COMMENT '国籍', `avatar` varchar(255) DEFAULT NULL COMMENT '头像图片路径', `intro` text COMMENT '作家简介', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='作家信息表';

作品表（work）和获奖表（award）分别通过 writer_id 关联作家表：

CREATE TABLE `work` ( `id` bigint NOT NULL AUTO_INCREMENT, `writer_id` bigint NOT NULL, `title` varchar(120) NOT NULL COMMENT '作品名称', `type` varchar(30) DEFAULT NULL COMMENT '作品类型：小说/诗歌/散文/评论等', `publish_year` int DEFAULT NULL COMMENT '出版年份', `description` text COMMENT '内容简介', PRIMARY KEY (`id`), KEY `idx_writer_id` (`writer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `award` ( `id` bigint NOT NULL AUTO_INCREMENT, `writer_id` bigint NOT NULL, `award_name` varchar(100) NOT NULL COMMENT '奖项名称', `award_year` int DEFAULT NULL COMMENT '获奖年份', `award_org` varchar(100) DEFAULT NULL COMMENT '颁奖机构', `work_title` varchar(120) DEFAULT NULL COMMENT '获奖作品', PRIMARY KEY (`id`), KEY `idx_writer_id` (`writer_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

用户表和管理员表可以合并成一张 user 表，用 role 字段区分，减少表数量，登录认证逻辑也更简单。

这里有几个容易被忽略的细节：

• 字符集必须用 utf8mb4，因为要存作家简介里的特殊引号、书名号等字符，utf8 在某些场景下会报“ Incorrect string value ”错误。
• 时间字段能用 date 就别用 datetime，作家的出生日期只需要精确到天，用 date 占空间更小、语义更清晰。
• 关联字段一定要建索引，writer_id 这种高频查询字段，不加索引在数据量上来后会明显卡顿。

2.2 数据库初始化脚本与测试数据准备

数据库脚本是源码包里必须交付的东西。建议单独建一个sql文件夹，放一份init.sql包含建库建表语句，一份data.sql包含测试数据。

测试数据要准备得有讲究。别只插三条充数，建议准备 15 到 20 位作家，覆盖不同国籍、不同获奖年份、不同作品体裁。数据量太小，分页效果展示不出来；数据量太大，又会显得刻意。测试数据的文本内容要有区分度，方便验证模糊搜索。

我建议把作家的简介写得像真正的百科词条一样，这部分可以在论文的“数据来源与预处理”中说明，提高项目的可信度。测试数据的写法可以参考以下风格：这位作家的创作跨越多个文学阶段，其代表作以细腻的心理描写见长，多次获得国内外重要文学奖项。

2.3 多表联查的 SQL 设计思路

系统里最有技术含量的查询是“根据作家筛选条件同时带出作品数和获奖数”。有两种实现方式：

第一种是直接在作家查询 SQL 里做子查询：

SELECT w.*, (SELECT COUNT(*) FROM work WHERE writer_id = w.id) AS work_count, (SELECT COUNT(*) FROM award WHERE writer_id = w.id) AS award_count FROM writer w WHERE w.name LIKE CONCAT('%', #{keyword}, '%') ORDER BY w.id DESC LIMIT #{offset}, #{pageSize}

第二种是先在 Java 里查出作家列表，再根据 id 集合批量查作品数和获奖数，最后在内存里组装。两种方式各有优缺点，子查询方式简单直观，适合数据量小的场景；批量查询方式性能更好，但代码量多一点。毕设阶段用第一种完全足够，论文里把这个选择理由写出来，反而能体现你的思考。

这里有一个我在实际项目里总结的经验：不要把作家列表接口和作家详情接口做成同一个 SQL。列表接口要轻量，只返回核心字段和统计数；详情接口再一次性关联查询出作品列表、获奖列表。这样页面加载快，前端代码层次也更清楚。

> 提示：论文的数据库设计章节，一定要放 E-R 图。如果不会用什么专业工具，用 WPS 或 ProcessOn 画即可，重点是体现出“作家 1 : N 作品”和“作家 1 : N 获奖”的关系。

3. 后端服务：SpringBoot 核心实现与接口设计

3.1 项目结构分层与代码规范

后端项目结构我强烈建议按照标准的三层架构来组织，后面论文的“系统设计”章节可以直接引用。

com.example.writer ├── controller // 控制层，接收请求，返回结果 ├── service // 业务层，处理业务逻辑 │ └── impl // 业务实现类 ├── mapper // 数据访问层，基于 MyBatis ├── entity // 实体类，对应数据库表 ├── dto // 数据传输对象，封装前端请求参数 ├── vo // 视图对象，封装返回给前端的数据 ├── config // 配置类，跨域、拦截器等 ├── common // 公共类，统一返回结果、异常处理等 └── utils // 工具类

entity 里的类字段要和数据库表字段一一对应，用驼峰命名法。如果数据库字段是下划线命名，需要在配置里开启 map-underscore-to-camel-case，否则查询结果会全是 null。

controller 层只做参数接收和结果包装，不写任何业务逻辑。service 层处理业务规则。mapper 层只写 SQL。这样分层的好处是，后期如果想把业务逻辑替换或加缓存，只需要改 service 层，不会牵连其他代码。

3.2 统一返回结果与全局异常处理

前后端分离的项目，最忌讳的就是每个接口返回格式不一样。有的返回 JSON 对象，有的直接返回字符串，前端对接起来会疯掉。所以项目要想做得专业，第一步是设计统一返回结构。

public class Result<T> { private Integer code; // 200 成功，500 失败 private String message; // 提示信息 private T data; // 数据 }

所有接口返回Result，前端只需要统一判断code即可。成功返回Result.success(data)，失败返回Result.error("参数错误")。

全局异常处理用@RestControllerAdvice注解，配合@ExceptionHandler可以捕获所有 Controller 层抛出的异常，统一包装成 Result 返回。这样即使代码里忘了 try-catch，前端也不会收到一堆乱码或空的错误信息。

这里要特别注意空指针异常。做作家信息查询时，如果作家 id 不存在，查询结果是 null，直接执行 getBirthDate() 就会报空指针。建议养成习惯：查询结果先判断是否为 null，为空时抛出自定义的业务异常，全局异常处理器会统一返回“记录不存在”。

3.3 作家管理接口全流程实现

以一个“新增作家 + 上传头像”的组合接口为例，完整代码思路如下：

Controller 层接收 JSON 和文件参数：

@PostMapping("/writer") public Result<Boolean> addWriter(@RequestParam("file") MultipartFile file, @RequestParam("info") String info) { WriterDTO dto = JSON.parseObject(info, WriterDTO.class); return Result.success(writerService.addWriter(dto, file)); }

Service 层实现逻辑：

1. 先校验参数，姓名不能为空，简介长度不能超过限制
2. 上传文件，返回文件访问路径
3. 将路径和 dto 数据组装成 entity
4. 执行插入操作

文件上传的路径建议统一放到项目的upload目录，文件名用 UUID 拼接后缀，避免中文名乱码和文件名重复覆盖。

查询列表接口要支持分页和条件组合。参数可能包含：关键词、国籍、性别、获奖年份范围。用 MyBatis 的动态 SQL 来处理，比 Java 代码里拼条件更优雅：

<select id="selectWriterList" resultType="WriterVO"> SELECT * FROM writer <where> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="nationality != null and nationality != ''"> AND nationality = #{nationality} </if> <if test="gender != null"> AND gender = #{gender} </if> </where> ORDER BY id DESC </select>

分页我推荐使用 PageHelper 插件，轻量好用，一条startPage注解就能自动拼 LIMIT。要注意 PageHelper 的两个坑：第一是它必须放在查询语句的前一行，中间插了其他代码就会失效；第二是查询完要立刻拿结果，不要做其他数据库操作后再取 List，否则分页数据会被污染。

3.4 登录认证与拦截器配置

管理系统一般都需要登录功能。毕设阶段不需要把 JWT 玩得过于复杂，但也不能完全没有，因为论文里“系统安全设计”章节是要凑内容的。

我的方案是使用拦截器做登录校验。前端登录成功后，后端返回一个随机 token，存到 Redis 或者直接存到内存。后续请求在 Header 中携带 token，拦截器判断 token 是否存在、是否过期。

如果用内存存储 token，重启服务后所有用户都要重新登录，这是可以接受的。但如果想体现一点技术深度，可以考虑用 JWT。JWT 不需要服务端存储，token 本身带有过期时间，核心代码只有几行：

String token = Jwts.builder() .setSubject(username) .setExpiration(new Date(System.currentTimeMillis() + 3600_000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

写拦截器时要注意放行哪些路径。登录接口、文件访问路径要放行，静态资源路径要放行，其他接口一刀切进行登录校验。放行配置可以用excludePathPatterns指定。

3.5 后端自测技巧与 Swagger 集成

接口写完后，不要急着联调前端。先通过自测把基础问题扫掉，再用 Swagger 给前端或者答辩演示提供接口文档。

启动项目，访问http://localhost:8080/swagger-ui.html就能看到接口列表，直观展示每个接口的入参、出参和请求方式。答辩演示的时候直接打开 Swagger 页面点“Try it out”，比 Postman 截图更有说服力。

常见的自测场景包括：

• 不带 token 访问需要认证的接口，确认返回 401
• 传一个不存在的作家 id 更新信息，确认返回友好提示
• 上传一个超大头像文件，确认给出大小限制提示
• 传模糊关键词搜索，确认能正常走通 LIKE 查询

这部分的测试记录可以作为论文“系统测试”章节的素材。建议把每次测试的输入、预期结果、实际结果、是否通过做成表格，测试章节内容就非常充实了。

4. 前端搭建：Vue + Element UI 页面实现

4.1 前端项目初始化与路由设计

前端使用 Vue 2（配 Element UI）是大多数毕设的稳妥选择。Vue 3 配 Element Plus 也可以，但网上资料相对少一些，遇到问题排查成本更高。我建议如果对 Vue 不熟，优先选 Vue 2 生态。

使用 Vue CLI 创建项目后，安装以下依赖：

vue create writer-frontend npm install element-ui npm install axios npm install vue-router@3

前端页面结构建议按以下方式组织：

• /login：登录页
• /layout：后台主框架，嵌套以下子路由
• /layout/writer：作家列表页
• /layout/writer/detail：作家详情页
• /layout/dashboard：数据概览面板

主框架左侧是侧边栏菜单，顶部是退出按钮。使用 Element UI 的 Container 布局组件，几分钟就能搭好整体框架。

4.2 登录页与请求封装

axios 封装是前端项目规范度的分水岭。直接在每个组件里import axios然后发请求虽然能跑通，但代码冗余严重，而且没法统一处理错误提示。

我建议封装一个request.js：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { config.headers['token'] = localStorage.getItem('token') return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } else { Message.error('网络异常，请稍后重试') } return Promise.reject(error) } ) export default service

这里要做两件事：第一，所有请求自动携带 token，第二，统一判断返回码。后端返回 401 时自动跳转登录页，这样即使用户手动删掉 token，系统也不会白屏卡死。

前端的开发环境通过 Vite 或 webpack 的代理把/api开头的请求转发到后端地址，解决跨域问题。生产环境用 Nginx 做反向代理，后文会详细讲。

4.3 作家列表页：条件搜索 + 分页表格

列表页面是整个系统的脸面，也是答辩时最先展示的界面。设计要点如下：

搜索区使用表单 inline 布局，包含输入框、下拉选择器、搜索和重置按钮。这里要注意重置按钮不仅要清空表单数据，还要重新查询一遍，否则列表不会刷新。

表格列展示时，作家头像用缩略图加弹出层放大的方式，性别和获奖状态这类信息用 tag 标签展示，色彩区分度高。操作列放“详情”和“编辑”和“删除”按钮。

分页组件绑定三个关键参数：当前页、每页条数、总条数。切换页码和修改每页条数时，都要重新请求后端接口。这里我就踩过坑：只改了当前页，忘记把页码重置为 1，结果在第二页筛选时数据为空。正确的做法是任何搜索条件变化后，把页码置为 1。

4.4 作家编辑弹窗：动态表单与校验

新增和编辑功能共用一个弹窗组件，通过传入的 id 判断是新增还是编辑。表单校验使用 Element UI 的 rules 属性：

rules: { name: [{ required: true, message: '请输入作家姓名', trigger: 'blur' }], birthDate: [{ required: true, message: '请选择出生日期', trigger: 'change' }], intro: [{ required: true, message: '请输入作家简介', trigger: 'blur' }] }

头像上传组件使用 el-upload，要注意设置action指向后端上传接口，同时headers要携带 token。上传成功后回调里把返回的文件路径赋值给表单字段，这样提交时才能真正保存。

这里有一个前端细节处理技巧：编辑回显时，如果后端返回的头像路径是相对路径（如/upload/123.jpg），直接放到 img 标签的 src 里可能显示不出来，需要在路径前拼接后端的访问前缀。建议回显时统一处理：

if (row.avatar && !row.avatar.startsWith('http')) { row.avatar = 'http://localhost:8080' + row.avatar }

4.5 作家详情页：多数据关联展示

详情页是展示系统数据关联能力的好地方。页面布局建议采用上下结构：上半部分是作家基本信息卡片，包括头像、姓名、国籍、生日、简介；下半部分用标签页切换展示“作品列表”和“获奖记录”。

作品列表和获奖记录加载时，分别调用两个接口，只传递 writerId 参数。这里就能体现后端分层设计的好处：详情 Controller 只需要组合三个 Service 方法即可。

详情页还可以加一个打印功能，把当前的作家信息导出为 PDF。实现方案是用浏览器自带的 window.print()，配合 CSS 设置打印区域，工作量不大，但演示效果极好，评委看到会觉得项目完成度很高。

4.6 数据概览面板：让系统有“进行时”的感觉

很多毕设管理系统忽略了首页仪表盘，直接放一张静态图或者欢迎语，很可惜。用一个数据概览面板，展示全系统核心统计数据，系统立刻显得完整。

具体可以加如下统计卡片：

• 作家总数
• 作品总数
• 获奖记录总数
• 国籍覆盖数

下面再放一个简单的柱状图，统计每年获奖记录的数量分布，用 ECharts 实现。ECharts 的用法不复杂：

import * as echarts from 'echarts' const chart = echarts.init(document.getElementById('chart')) chart.setOption({ xAxis: { type: 'category', data: years }, yAxis: { type: 'value' }, series: [{ type: 'bar', data: counts }] })

后端提供一个统计接口返回年份和数量数组，前端直接塞给图表。这个功能代码量不大，但能显著提升系统的视觉效果，且论文里可以写“可视化分析模块”。

> 注意：ECharts 图表容器必须有明确的宽度和高度。如果容器在初始化时处于隐藏状态（如页面切换时）图表会渲染异常，建议在 mounted 周期使用 $nextTick 确保 DOM 渲染完成后再初始化。

5. 部署上线与配套文档整理

5.1 本地环境联调与跨域配置

开发阶段前后端分离，后端跑在 8080，前端跑在 8081，跨域问题避不开。解决方式有两种：

后端添加全局跨域配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(Registry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

前端配置代理更通用，以 Vue CLI 为例，在vue.config.js中：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

前端所有请求路径以/api开头，开发环境转发到后端。后端接口的 Controller 基础路径写/api前缀，这样生产环境只需要在 Nginx 中配一次代理即可，不用改代码。

在毕设答辩现场，由于网络环境常常不稳定，我建议准备一个“本地环境演示预案”：确保后端和 MySQL 都已在本地启动，前端已 build 为静态文件放入某目录，一旦外网不通，立刻用本地 URL 演示。

5.2 生产环境部署：Nginx + SpringBoot + MySQL

生产环境部署的核心是“前端静态文件交给 Nginx，后端接口通过 Nginx 反向代理”。先在后端打包：

mvn clean package -DskipTests

生成writer-system.jar，上传到服务器后执行：

nohup java -jar writer-system.jar --server.port=8080 > app.log 2>&1 &

MySQL 在服务器上导入 SQL 脚本：

mysql -u root -p < init.sql mysql -u root -p < data.sql

Nginx 配置核心内容如下：

server { listen 80; server_name your_domain; root /home/www/writer-frontend; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /home/www/upload/; } location / { try_files $uri $uri/ /index.html; } }

这里最关键的细节是try_files $uri $uri/ /index.html;。Vue 是单页应用，路由由前端控制，如果不加这条规则，刷新页面时就会出现 404。

5.3 部署文档、论文与演示视频准备

源码包里的“部署文档”要按以下大纲来写：

• 环境要求：JDK 1.8+，MySQL 5.7+，Node.js 14+
• 后端启动步骤：导入项目、修改数据库用户名密码、启动
• 前端启动步骤：安装依赖、配置代理、启动
• 生产部署：Maven 打包、Jar 运行、Nginx 配置
• 常见问题：端口占用、数据库连接失败、跨域报错

论文的结构按经典的五章走：

1. 绪论：背景、意义、国内外研究现状
2. 相关技术介绍：SpringBoot、Vue、MySQL、MyBatis
3. 系统分析：可行性分析、需求分析、用例图
4. 系统设计：总体架构、功能模块、数据库设计
5. 系统实现与测试：效果截图、核心代码、测试用例

论文的查重是很多人的坎，这里有个实在的建议：不要直接粘贴网上模板的句子，而是全部用自己的话重新描述，把每个模块的设计原因和实现过程结合起来写，既降低重复率，又提高论文的真实性。

演示视频建议用录屏软件完整走一遍流程：登录、查看概览、搜索、新增、编辑、删除、查看详情。每个操作停留 3 秒以上，鼠标操作不要太快，方便评委看清楚。

6. 常见问题与排查技巧实录

6.1 后端启动相关的常见故障

数据库连接失败，报Access denied for user。这就是用户名或密码错误，检查配置文件里的 spring.datasource.username 和 password。还有一种是时区问题，报The server time zone value is unrecognized，解决方案是在数据库连接 URL 后加上：

spring.datasource.url=jdbc:mysql://localhost:3306/writer_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8mb4

端口被占用，报Port 8080 was already in use。先查占用进程，用netstat -ano | findstr 8080找到 PID，然后taskkill /PID 进程号 /F。如果是服务器上，用lsof -i:8080配合kill -9。

Bean 创建失败，报Field xxxMapper in xxxService required a bean of type。基本就是 Mapper 接口没有被扫描到，检查启动类是否添加了@MapperScan("com.example.writer.mapper")。

6.2 前端页面常见的问题与排查路径

接口能通但页面一直在加载转圈：多半是后端返回的数据结构和前端预期不一致。打印 response 数据，检查 data 字段到底是数组还是对象，字段名是否匹配。这类问题我遇到很多次，每次都是因为前后端字段命名不一致，一个叫 publishYear，另一个叫 publish_year，前端自然取不到。

上传头像失败：检查是否携带了 token 请求头，检查后端配置的文件大小限制：

spring.servlet.multipart.max-file-size=10MB spring.servlet.multipart.max-request-size=10MB

跨域报错：如果开发环境做了代理还提示跨域，优先检查代理是否配置在正确位置。Vue CLI 的代理是配置在根节点的devServer下，和module.exports平级。如果缩进错误，代理根本不生效。

6.3 性能优化与答辩加分技巧

很多人以为毕设项目不需要考虑性能，其实不对。稍微做一点优化，答辩时讲出来，评委印象分会高很多。

列表接口加一个简单缓存，比如用 Caffeine 缓存热门查询条件下的列表数据，缓存 30 秒。查数据库之前先查缓存，没有命中再查库并回填缓存。

作家详情页的作品列表和获奖列表，可以合并成一个详情接口返回，减少网络请求次数。

前端表格数据量不大时开启virtual-scroll或分页，本身就是性能优化。在论文里写一句“前端通过分页降低 DOM 渲染压力”，就体现出工程意识了。

图片资源用压缩方案，头像限制 2MB 以内，长宽压到 200x200。上传时直接用 Java 自带 ImageIO 做缩放，不需要引入额外依赖。

> 提示：答辩时最容易被问的问题是“为什么用 MyBatis 而不是 JPA”。标准回答是：MyBatis 允许手写 SQL，复杂多表查询可控性强，同时兼容团队中更多熟悉 SQL 的开发者。

6.4 从“能跑”到“做好”的打磨建议

系统基本完成后，别急着交，按照以下清单自查一遍：

• 删除按钮是否有二次确认弹窗？没有的话，误删数据会很尴尬
• 所有表单提交是否有 loading 状态？防止用户连点提交导致重复数据
• 空数据场景是否有友好提示？比如搜索无结果时显示“暂无相关作家”
• 接口异常时前端是否提示了具体原因？不要让用户面对白屏
• 后端接口是否都有参数校验？直接传一个超长字符串会不会报错

按照这个清单打磨过的系统，功能和细节完成度会明显高出平均水平。很多毕设演示时都会出现“我明明在本地跑通了，怎么答辩就报错”的情况，原因基本都出在细节处理不够严谨。

最后说几句实在话

带过不少毕业设计，我的感受是这套“SpringBoot + Vue + MySQL 管理系统”的成败，往往不取决于用了多新的技术，而是取决于基础功扎不扎实。代码可以借鉴开源项目，但你必须清楚每一条 SQL 在做什么，每一个请求从前端到后端经过了哪些环节。如果老师临时问一个“作家列表的分页是怎么实现的”，你支支吾吾说不清，前面做得再好也白搭。

我更推荐的做法是：拿到源码之后，先完整跑通一遍，然后自己从零搭一个最简版本，哪怕功能砍到只剩查询和新增，这个过程带给你的理解要远比看十篇教程深刻。数据表自己建，接口自己写，页面自己调，把“别人的代码”变成“自己真懂的系统”，这才是毕业设计真正的收获。

如果时间实在紧张，至少要把部署文档、项目结构和核心表关系背熟，答辩时保持思路连贯。祝你把项目打磨利落，顺利过审，答辩场上从容应对。