企业官网建设流程全解析

做这个项目的时候还在带毕业生开题，红色革命文物征集管理系统是那几年出现频率相当高的一个题目。表面看它只是个普通的“XX管理系统”，无非是增删改查那一套，但真动手做会发现，这个题目牵扯到的技术点比想象中多得多——SpringBoot的后端分层设计、Vue的前端组件化开发、MySQL的业务表结构设计、前后端分离之后的接口联调，再叠加文物图片上传、多条件检索、状态流转这类实际业务场景，一套走下来基本能把Java Web和前端的主要知识点串成一个完整闭环。这篇文章我就用这个项目做例子，把从架构选型、数据库建模，到后端核心接口、前端页面实现的完整链路都过一遍，最后再把那些文档里不会写、实际开发才会踩的坑一并交代清楚。

1. 项目到底在做什么：先把需求掰开揉碎

很多人拿到这类题目第一反应是直接开写，结果写了一半发现逻辑理不清。我建议第一步先把需求搞明白。所谓“文物征集”，通俗讲就是把散落在民间的革命文物线索收集上来，经过登记、鉴定、审核之后统一入库管理。系统要解决的核心问题有三块：第一，手工纸质登记效率低，信息容易丢；第二，征集进度不可控，谁在跟进、走到哪一步完全靠记忆；第三，数据查不到，想按地区、按类型、按征集时间筛一批文物出来特别费劲。

1.1 角色划分与核心业务流程

一个典型的管理系统通常有三种角色，这里也不例外：

业务流程其实是一条状态链：征集人员录入一条文物线索，状态是“待审核”；管理员复审通过后状态变成“已入库”；如果信息不完整或疑似有问题，就打回并给出修改意见，状态回到“待完善”。这套状态流转逻辑看起来简单，但它是整个系统的业务内核，数据库设计、接口设计都要围绕它来做。

1.2 为什么SpringBoot + Vue是这类项目的稳妥选择

说句实在话，毕设项目最重要的是“能完整跑通、能讲清楚、有东西可展示”。SpringBoot + Vue的组合在这一点上有天然优势。SpringBoot把Spring那套繁琐的XML配置基本消灭了，嵌入式Tomcat让部署变成一条命令，MVC分层结构又非常清晰，答辩的时候画个三层架构图就能把逻辑讲明白。Vue这边组件化开发适合前端页面反复复用，比如文物列表、审核弹窗、表单校验，抽成组件之后工作量能省一半。再加上MySQL是完全免费开源的，环境搭建成本低，对于学生来说这套技术栈基本不会卡在环境这一关。

提示：如果你是自己学习练手，不建议在这个阶段盲目引入微服务、Redis缓存、消息队列这些重型组件。管理类项目的核心价值是业务流程的完整性和代码结构的清晰度，先把SpringBoot + Vue + MySQL这套主链路吃透，比堆砌一堆中间件要实在得多。

2. 架构设计：MVC模式在前端和后端分别怎么落地

很多同学一听到MVC就以为是后端的事，其实在这个项目里，MVC是贯穿前后端的。后端是典型的Controller-Service-Mapper三层，前端Vue则用MVVM的思想去配合后端的MVC，两边通过RESTful接口衔接。理解清楚这一层，答辩的时候能加分不少。

2.1 后端三层架构的职责边界

后端的分层是我反复跟学生强调的重点，因为代码写得好不好，先看包结构乱不乱。一个干净的SpringBoot项目，包结构应该是这样的：

com.example.relic ├── controller # 接口层，只管接收参数、调用Service、返回结果 ├── service # 业务逻辑层，处理具体业务规则 │ └── impl # Service实现类 ├── mapper # 数据访问层，对应MyBatis的Mapper接口 ├── entity # 数据库实体类 ├── dto # 数据传输对象，用于前后端参数传递 ├── vo # 视图对象，用于返回给前端展示的数据 ├── common # 统一返回结果、异常处理、工具类 └── config # 配置类，如CORS跨域、拦截器注册

Controller层要足够“薄”，只做三件事：接收参数、调用Service、封装返回值。业务判断逻辑不要写在Controller里，否则后期想复用业务方法就只能复制粘贴。Service层处理核心业务，比如审核文物时要判断当前用户的角色、更新文物状态、记录审核日志，这些操作必须在一个事务里完成，所以@Transactional注解要加在Service层方法上。Mapper层只做数据库交互，SQL写在XML里还是注解里都可以，我习惯用XML，因为复杂查询和动态SQL方便调整。

2.2 前端Vue如何呼应后端MVC

Vue本身不是MVC框架，它是MVVM模式，数据驱动视图变化。但咱们做前后端分离项目时，前端依然要讲究分层。标准做法是：页面组件（views）负责展示和交互，api目录统一封装请求，store（Vuex/Pinia）管理全局状态，router管理路由。这就相当于把后端Controller接收请求和返回响应的职责，在前端用路由和状态管理承担了起来。

前端有一个高频踩坑点：不要把请求逻辑直接写在页面组件里。比如文物列表页，不要在created里写一堆axios.get，而是先在src/api/relic.js里定义函数：

import request from '@/utils/request' export function getRelicList(params) { return request({ url: '/api/relic/page', method: 'get', params }) } export function addRelic(data) { return request({ url: '/api/relic', method: 'post', data }) }

页面组件里只需要调用这些函数，逻辑清晰，而且复用到其他页面时直接import就行。这样做还有个额外好处，如果后端接口地址变了，只需要改api目录里的url，不用每个页面都去翻。

2.3 RESTful接口设计规范

接口设计直接影响前后端联调效率，我见过不少项目接口写得很随意，比如“/queryRelicList”“/deleteRelicById”这种风格。RESTful风格更推荐这样的设计：

这里我统一用POST做分页查询，原因很简单：分页条件多，用GET会把URL撑得很长，而且POST传JSON对象在后端接收参数更方便。其他查询单条的用GET，修改和删除用PUT、DELETE，语义清晰。统一返回格式也要提前定好，我通常用这样的结构：

{ "code": 200, "message": "操作成功", "data": { ... } }

前端axios拦截器里统一判断code，如果不是200就弹错误提示，这样后端只需要把精力放在业务上，不用每个接口都去处理异常分支。

3. 数据库建模：文物信息怎么存才专业

数据库设计是这个项目里最容易暴露问题的地方。很多初学者上来就建一张大宽表，把所有字段塞进去，后期改需求的时候痛不欲生。文物征集系统涉及的用户、文物、征集记录、审核记录、日志，彼此之间是有业务关联的，合理的表结构设计不仅让代码好写，还能避免数据冗余。

3.1 核心表结构设计

我建议至少设计五张核心表：用户表、角色表、文物信息表、征集记录表、审核日志表。下面给出文物信息表的详细设计，这张表是整个系统的核心：

CREATE TABLE relic ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '主键ID', relic_name VARCHAR(100) NOT NULL COMMENT '文物名称', relic_type VARCHAR(50) DEFAULT NULL COMMENT '文物类型（文件/实物/照片等）', source_area VARCHAR(100) DEFAULT NULL COMMENT '征集地区', collector_name VARCHAR(50) DEFAULT NULL COMMENT '征集人姓名', collect_phone VARCHAR(20) DEFAULT NULL COMMENT '联系电话', relic_desc TEXT DEFAULT NULL COMMENT '文物描述', photo_url VARCHAR(255) DEFAULT NULL COMMENT '图片存储路径', status TINYINT DEFAULT 0 COMMENT '状态：0草稿 1待审核 2已入库 3已退回', create_by BIGINT DEFAULT NULL COMMENT '录入人ID', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '录入时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文物信息表';

几个细节需要特别说明。第一，状态字段用TINYINT而不是VARCHAR，用数字表示状态方便扩展，也别用0和1就完事了，多状态的字段建议在Java代码里定义一个枚举类去管理。第二，描述类字段用TEXT类型，不要用VARCHAR(255)，文物描述动辄几百字，VARCHAR很容易截断。第三，create_time用DATETIME，并且设置默认值，这样插入数据时不用手动赋值。第四，字符集必须用utf8mb4，很多老项目用utf8，遇到生僻字或者特殊符号就会乱码。

3.2 关联表与外键策略

用户表和角色表单独拆开，是为了权限控制更灵活。一个用户对应一个角色，角色表里存角色名和权限标识：

CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录账号', password VARCHAR(100) NOT NULL COMMENT '密码（BCrypt加密）', real_name VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', role_id BIGINT DEFAULT NULL COMMENT '角色ID', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这里要注意的是，密码字段长度至少100，因为BCrypt加密后的字符串是60位，用VARCHAR(50)会直接报错。另外，关联表之间我一般不建物理外键，只在逻辑上通过业务代码维护关联关系。原因有二：其一，物理外键在插入、删除时会带来额外的性能开销和约束限制；其二，很多公司开发规范里明确要求禁用物理外键，控制在应用层。你可以在表设计文档里画出ER图说明逻辑关系即可。

3.3 索引设计：别让查询拖垮系统

数据量小的时候索引问题不明显，但文物征集系统的数据一旦到了几万条，查询性能就会出现明显差异。我建议在下面几个字段上建索引：

特别提醒一点，不要给每个字段都建索引。索引会占用空间，并且每次插入更新都要维护索引树，索引太多写入性能反而下降。针对这个项目，三到五个索引足够了。

4. 后端关键实现：从Controller到Mapper的完整链路

这部分是项目的重头戏，我把登录鉴权、文物分页查询、审核状态流转三个核心功能拆开讲，每一个都会给出关键代码和踩坑点，你可以直接照着写。

4.1 登录鉴权：JWT如何做到无状态认证

管理系统一定需要登录认证，我用的是JWT方案。JWT的核心逻辑是：用户登录成功后，后端签发一个包含用户ID和角色信息的Token返回给前端；前端每次请求在header里带上这个Token；后端通过拦截器解析Token，拿到当前用户信息。用户表里存的密码是加密后的密文，用BCryptPasswordEncoder比对。

签发Token和解析Token的工具类大体长这样：

@Component public class JwtUtil { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private Long expire; public String createToken(Long userId, String username, String roleName) { return Jwts.builder() .claim("userId", userId) .claim("username", username) .claim("role", roleName) .setExpiration(new Date(System.currentTimeMillis() + expire)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); } }

写完这个工具类后，一定要记得在登录接口里把用户状态校验补上，很多项目只校验用户名密码，忘了校验status字段，导致被封禁的用户依然能登录成功。另外，JWT的密钥不要写在代码里面，放到application.yml里配置，不同环境用不同密钥，这点算是我交过学费之后才养成的习惯。

4.2 文物保护：登录拦截器与ThreadLocal传递用户信息

有了JWT工具类，拦截器负责在每个请求进来时验证Token。核心代码如下：

@Component public class JwtInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BusinessException(401, "未登录或登录已过期"); } try { Claims claims = jwtUtil.parseToken(token); UserContext.set(claims); } catch (Exception e) { throw new BusinessException(401, "Token无效或已过期"); } return true; } }

注意这里有个容易踩的坑：前端发起跨域请求时，浏览器会先发一个OPTIONS预检请求，如果不放行OPTIONS请求，会导致所有带Token的请求都报跨域错误。我在代码里显式判断了OPTIONS并直接放行。解析成功后，把用户信息放进ThreadLocal，后面任何一层Service想要知道当前登录用户是谁，直接从UserContext取即可，省得每个接口都把用户ID传来传去。但这个操作有个隐患——请求结束后必须清理ThreadLocal，否则线程池复用线程时会出现用户信息串号的问题。

4.3 文物分页查询：MyBatis动态SQL的实战应用

分页查询是管理系统的标配功能。这里我推荐使用MyBatis的PageHelper插件，它支持物理分页，使用起来也简单。更重要的是匹配多条件的动态查询能力，文物列表页一般有按名称模糊查询、按类型下拉筛选、按状态单选筛选、按时间范围查询这些条件。

对应的Service层核心逻辑：

public PageResult<RelicVO> pageQuery(RelicQueryDTO dto) { PageHelper.startPage(dto.getPageNum(), dto.getPageSize()); List<RelicVO> list = relicMapper.selectByCondition(dto); PageInfo<RelicVO> pageInfo = new PageInfo<>(list); return PageResult.build(pageInfo.getTotal(), pageInfo.getList()); }

Mapper层的动态SQL是这样写的：

<select id="selectByCondition" resultType="com.example.relic.vo.RelicVO"> SELECT id, relic_name, relic_type, source_area, collector_name, status, create_time FROM relic <where> <if test="relicName != null and relicName != ''"> AND relic_name LIKE CONCAT('%', #{relicName}, '%') </if> <if test="relicType != null and relicType != ''"> AND relic_type = #{relicType} </if> <if test="status != null"> AND status = #{status} </if> <if test="startTime != null"> AND create_time &gt;= #{startTime} </if> <if test="endTime != null"> AND create_time &lt;= #{endTime} </if> </where> ORDER BY create_time DESC </select>

这里有个细节，MyBatis的动态SQL中，大于号小于号要用转义符号>和<，直接写>在XML里会解析出错。另外，模糊查询用CONCAT拼接而不是直接写'%${relicName}%'，因为${}是字符串拼接，有SQL注入风险，#{}才是预编译。

4.4 审核状态流转：事务与并发控制

文物审核这个功能最能体现业务逻辑的完整性。审核通过和退回不是一个update语句就完了，而是要同时做三件事：更新文物状态、写入审核日志、如果是退回还要记录退回原因。这三个操作必须在一个事务里，要么全部成功要么全部失败。

@Transactional(rollbackFor = Exception.class) public void auditRelic(AuditDTO dto) { Relic relic = relicMapper.selectById(dto.getRelicId()); if (relic == null) { throw new BusinessException("文物不存在"); } // 防止用户提交重复核心状态，使用状态字段更新比较 int rows = relicMapper.updateStatus( dto.getRelicId(), dto.getAuditStatus(), relic.getStatus()); // 待审核状态才允许更新 if (rows == 0) { throw new BusinessException("文物当前状态不允许审核"); } // 写入审核日志 auditLogMapper.insert(new AuditLog(dto.getRelicId(), dto.getAuditStatus(), dto.getAuditComment(), UserContext.get().getUserId())); }

这里我采用了一种乐观锁的写法：update的where条件里带上了当前状态值status，如果别人已经修改过状态，那么update影响行数为0，直接抛出异常。这种方法比先select再update更安全，能避免并发状态下两个人同时对同一条文物做审核操作。事务注解rollbackFor要显式声明为Exception.class，否则默认只回滚RuntimeException，遇到自定义的BusinessException时事务是不会回滚的。

4.5 图片上传：本地存储还是OSS

文物系统基本都要支持图片上传，这里我强烈建议在毕设阶段直接使用本地存储，不要一上来就接阿里云OSS。本地存储的实现非常简单，在配置文件中指定一个上传目录，然后用MultipartFile接收文件：

public String uploadImage(MultipartFile file) { if (file.isEmpty()) { throw new BusinessException("上传文件不能为空"); } String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); // 只允许图片格式 List<String> allowedSuffix = Arrays.asList(".jpg", ".jpeg", ".png", ".gif"); if (!allowedSuffix.contains(suffix.toLowerCase())) { throw new BusinessException("仅支持jpg、png、gif格式图片"); } String fileName = UUID.randomUUID().toString().replace("-", "") + suffix; try { file.transferTo(new File(uploadPath + fileName)); } catch (IOException e) { throw new BusinessException("文件上传失败"); } return "/uploads/" + fileName; }

文件名一定要用UUID重新生成，不要用用户上传的原始文件名，否则有两个风险：一个是文件重名互相覆盖，一个是中文名或特殊字符导致URL访问失败。另外文件大小限制也需要配置，SpringBoot默认最大单文件1MB，多文件10MB，如果图片超过1MB会被静默拦截，在application.yml里调大即可：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

上传后的图片要通过一个静态资源映射配置才能访问，需要在配置类里把本地的upload目录映射到URL路径：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceLocations("file:" + uploadPath); } }

这一步非常容易漏掉，很多同学上传成功后图片一直显示404，就是因为没有配置静态资源映射。

5. 前端Vue实战：从脚手架到页面联调

前端部分我按Vue 2 + Element UI技术栈来写，这套组合经典稳定，教程也多，毕设阶段完全够用。如果你对Vue 3更熟，逻辑是一样的，区别不大。

5.1 项目初始化与路由设计

使用Vue CLI创建项目后，我习惯把目录调整成这样：

src ├── api # 接口请求封装 ├── assets ├── components # 公共组件 ├── router # 路由配置 ├── store # 状态管理 ├── utils # 工具类（axios封装、token管理） ├── views # 页面组件 │ ├── login.vue │ ├── relic │ │ ├── list.vue │ │ ├── edit.vue │ │ └── audit.vue │ └── user └── App.vue

路由配置需要区分哪些页面需要登录才能访问，这里用Vue Router的全局前置守卫实现：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() } else { if (!token) { next('/login') } else { next() } } })

这个守卫逻辑很简单，但很实用。我见过不少项目把登录判断写在每个页面组件的created里面，代码重复度极高，统一用路由守卫是最优雅的方式。

5.2 axios封装：拦截器统一处理Token和错误码

axios封装是整个前端项目的基座。所有请求都要统一带上Token、统一处理响应错误码、统一处理401跳转登录页。封装好的request工具类如下：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动携带token 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 !== 200) { Message.error(res.message || '请求失败') if (res.code === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(new Error(res.message)) } return res.data }, error => { Message.error(error.message || '网络异常') return Promise.reject(error) } ) export default request

封装完成之后，所有api目录下的函数返回的都是响应对象里的data部分，这样页面组件里拿数据特别干净，比如const list = await getRelicList(params)拿到的直接就是数组或分页对象。

5.3 文物列表页：表格 + 分页 + 搜索表单

列表页是整个系统使用频率最高、也最能体现组件化思路的页面。我通常把搜索表单、表格、分页器三个区域组合在一起，核心交互是：输入搜索条件点击查询，table数据刷新，分页器页码变化也会重新拉取数据。

搜索区的典型实现：

<el-form :inline="true" :model="queryParam" @submit.native.prevent> <el-form-item label="文物名称"> <el-input v-model="queryParam.relicName" placeholder="请输入名称" clearable /> </el-form-item> <el-form-item label="文物类型"> <el-select v-model="queryParam.relicType" placeholder="请选择类型" clearable> <el-option label="文件" value="文件" /> <el-option label="实物" value="实物" /> <el-option label="照片" value="照片" /> </el-select> </el-form-item> <el-form-item label="状态"> <el-select v-model="queryParam.status" placeholder="请选择状态" clearable> <el-option label="草稿" :value="0" /> <el-option label="待审核" :value="1" /> <el-option label="已入库" :value="2" /> <el-option label="已退回" :value="3" /> </el-select> </el-form-item> <el-form-item> <el-button type="primary" @click="handleSearch">查询</el-button> <el-button @click="handleReset">重置</el-button> </el-form-item> </el-form>

表格列定义里，状态列不要直接显示数字，而是通过formatter或tag组件转换成对应的文案和颜色，这样页面看起来专业很多。在操作列上，要根据当前行的状态判断是否显示“审核”“删除”按钮，比如只有状态为“待审核”时才显示审核按钮。这类按钮级的权限控制我建议直接在前端判断状态值，不需要刻意调用后端权限接口，毕竟前端只是控制展示，真正的校验在后端Service里。

5.4 审核功能实现：弹窗里的独立逻辑

审核操作通常做成一个弹窗，里面包含审核结果的单选按钮（通过或退回）、审核意见的文本域。提交时调用审核接口，成功之后刷新列表并关闭弹窗。这里有一个交互上的细节：弹窗内的表单需要做校验，退回时必须填写理由，通过时理由选填。Element UI的表单校验规则可以这样配：

rules: { auditStatus: [{ required: true, message: '请选择审核结果', trigger: 'change' }], comment: [{ validator: (rule, value, callback) => { if (this.auditForm.auditStatus === 3 && !value) { callback(new Error('退回时必须填写原因')) } else { callback() } }, trigger: 'blur' }] }

这种条件校验很常见，退款、请假、审批类功能都会用到。记住自定义validator里面不能直接用this，要提前把auditForm赋值到一个局部变量，或者用箭头函数保证this指向。

5.5 前端与后端的跨域问题

前后端分离开发时，前端跑在8080端口，后端跑在8081端口，直接请求必然遇到跨域问题。解决办法有两个：后端配置CORS跨域，或者前端用开发服务器代理。我推荐在前端vue.config.js里配置代理，这样后端代码不用做任何特殊处理，生产环境部署时还能通过Nginx统一配置代理：

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

配置完成后，前端代码里的/api/relic/page就会自动代理到http://localhost:8081/api/relic/page，浏览器就不再报跨域错误了。这个方案在后端不需要额外处理，是我比较推荐的方式。

6. 联调与部署阶段的坑：每一行代码都掉过坑

项目开发最痛苦的不是写功能，而是联调和部署阶段那些说不清道不明的环境问题。我把最常见的几类问题整理成表格，再逐个展开讲排查思路，你在毕设冲刺阶段能少走很多弯路。

6.1 环境与依赖问题排查表

6.2 MySQL 8.x版本驱动的坑

现在很多人的本机装的是MySQL 8.x，和传统的MySQL 5.7在驱动类上有区别。8.x的驱动类是com.mysql.cj.jdbc.Driver，连接URL里必须带上时区参数serverTimezone=Asia/Shanghai，否则启动时会报时区错误。另外，如果项目还沿用5.x的com.mysql.jdbc.Driver，虽然大多数情况下也能连上，但会在控制台打印一堆警告，建议直接用新驱动类。

SSH连接MySQL时如果遇到SSL错误，可以在连接URL后面加上useSSL=false&allowPublicKeyRetrieval=true，前者关闭SSL，后者解决公钥检索失败问题。这个在本地开发时完全没问题，不用过度担心安全性。

6.3 Maven依赖冲突的排查思路

SpringBoot项目常见的一个景象是启动时报NoSuchMethodError或ClassNotFoundException，但代码明明写着没问题。这大概率是依赖冲突了。排查手段很简单，执行：

mvn dependency:tree

看依赖树里是否有同一个库的不同版本。比如项目中同时引入了commons-io的2.4和2.11版本，运行时类加载器可能加载了旧版本的类，然后方法调用失败。解决办法是在pom.xml里用<exclusion>排除旧版本，或者统一在父pom里锁定版本号。

我在这个项目里遇到最多的是hutool和fastjson同时存在时，JSON序列化方法互相干扰。所以建议不要同时引入多个JSON处理库，统一用一个，要么Jackson（SpringBoot默认自带），要么Fastjson，项目里混着用迟早出问题。

6.4 前端接口联调时的几个典型问题

联调阶段最常见的报错是“404”和“500”。404通常是接口路径不对，我先在浏览器控制台看Network里请求的URL，再对比后端的@RequestMapping路径，排查是不是少了/api前缀，这个前缀不一致的问题频率极高。500则有两种常见原因：后端数据库查询字段映射不上导致空指针，以及前端传参类型对不上，比如后端方法要求Long类型，前端传了个字符串，框架会自动转换但某些复杂对象会直接反序列化失败。

还有一个经验是：前端联调时一定要打开浏览器开发者工具的Network面板，看到红色报错先看响应体里的message，后端统一返回的{"code":500,"message":"具体原因"}比看控制台里的堆栈要直观得多。后端同学也不要只在控制台打印日志，把异常信息放进统一返回的message里，两边联调效率直接翻倍。

6.5 打包部署：Vue打包后如何塞进SpringBoot

很多同学的部署姿势还是前端打完包扔给后端，后端再跟前端联调。其实最省事的方案是把Vue打包后的dist目录直接放进SpringBoot的resources/static下，然后后端启动后访问http://localhost:8081就能直接打开前端页面了。这样部署起来就是一个jar包，特别适合毕设演示。

具体做法分三步：第一，前端项目里把静态资源路径改成相对路径，在vue.config.js里设publicPath: './'，否则打包后资源文件引用绝对路径会找不到；第二，执行npm run build生成dist目录；第三，把dist里的所有文件复制到src/main/resources/static下。后端打包的时候这些静态文件会一起被装进jar，启动后自动映射。

需要注意一点，SpringBoot的Controller如果定义了/api/**的接口，静态资源路径/**会被Controller拦截吗？实际上SpringBoot对静态资源和@Controller路径有优先级设定，Controller中的具体路径优先于静态资源匹配，所以只要接口路径带/api前缀，就不用担心和静态资源冲突。这个方案不适合大型项目（静态文件要重新打包），但毕设场景下足够稳妥。

7. 项目代码规范与答辩建议

最后聊点代码规范的事。这个项目如果作为毕设，代码质量会直接影响答辩评分。我自己带学生时，评审老师看代码通常会关注三点：分层是否清晰、命名是否规范、敏感信息是否硬编码。每一点都能提前准备。

7.1 命名规范与常量管理

类名用大驼峰（RelicController）、方法名用小驼峰（getRelicById）、常量用全大写下划线（DEFAULT_PAGE_SIZE），这些是基本功。重点说说常量和魔法值的问题。比如状态字段，不要在代码里到处写if (status == 2)，而是定义一个枚举类：

public enum RelicStatusEnum { DRAFT(0, "草稿"), PENDING(1, "待审核"), APPROVED(2, "已入库"), REJECTED(3, "已退回"); private final Integer code; private final String desc; RelicStatusEnum(Integer code, String desc) { this.code = code; this.desc = desc; } public static String getDescByCode(Integer code) { for (RelicStatusEnum item : values()) { if (item.code.equals(code)) { return item.desc; } } return ""; } }

这样代码阅读起来一目了然，修改状态含义时只需改枚举类，全局自动生效。类似地，角色类型、文件类型枚举都建议这么做。

7.2 日志与异常处理的习惯

项目中不要用System.out.println打印调试信息，统一用SLF4J的Logger。异常处理方面，我习惯在Service层抛出业务异常，然后在全局异常处理器中统一捕获并返回错误信息。全局异常处理器的实现很简单，在@ControllerAdvice类里定义异常处理方法：

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BusinessException.class) public Result<Void> handleBusinessException(BusinessException e) { return Result.error(e.getCode(), e.getMessage()); } @ExceptionHandler(Exception.class) public Result<Void> handleException(Exception e) { log.error("系统异常", e); return Result.error(500, "系统繁忙，请稍后重试"); } }

这样做的价值在于，业务代码里只需要throw new BusinessException("xxx")，完全不需要在每个接口里try-catch，代码清爽，错误信息又能统一格式返回给前端。

7.3 答辩时的系统演示思路

演示系统的时候，我建议按一个完整的业务闭环来走，而不是东点一下西点一下。先以征集人员账号登录，录入一条新的文物信息，故意不传图片，让前端校验弹提示，然后补传图片提交，状态变为待审核。退出登录，换管理员账号登录，在待审核列表里看到刚才的数据，点击审核按钮，选择通过并填写意见，状态更新为已入库。最后再演示用户管理、数据统计这些辅助功能。这样一条线走完，既展示了前后端交互、状态流转、文件上传、权限区分，又体现了你的逻辑思维能力，比你零散地展示十个页面要有效得多。

在讲技术方案的时候，主动说出“为什么这么设计”特别加分。比如说到数据库表设计，你提前想清楚为什么状态字段用数字不用字符串、为什么不用物理外键；说到事务，你能讲清楚为什么审核操作要加@Transactional；说到并发，你能说出用乐观锁防止重复审核。这些“为什么”才是答辩时真正能打动评委的东西。

写在最后

这个项目我前前后后带过不少学生做过，自己也完整重写过好几版，每次都有新收获。最让我觉得值得分享的一点是：管理类系统的技术难点从来不在某一个孤立点上，而在于把所有细节串成一个闭环——从数据库字段的类型选择，到接口返回格式的统一，再到前端拦截器的处理，每一环看似小事，不处理好却会让整个项目显得很不专业。如果你正在做类似的项目，建议按这个顺序推进：先把数据库表建好，再写后端接口，接口用Postman自测通过后，再开始写前端页面，最后联调打包。这个流程能让你少走至少一周的弯路。遇到报错先看日志定位，不要急着怀疑框架有问题，绝大多数问题都是环境配置和细节疏忽，耐心排查下来都能解决。