尧图网页设计 
先把这个系统的底盘讲清楚。所谓“线上历史馆藏系统”本质就是给博物馆、档案馆、文化机构做一套藏品数字台账把纸质档案里的编号、年代、材质、尺寸、来源、图片这些信息搬进数据库再通过网页让管理员维护、让访客检索浏览。我拿到这种项目时习惯先定业务主线再动代码。这篇文章就按我实际做完一个 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 馆藏系统项目的流程来复盘从建库、接口、前端、联调部署到文档整理一条线讲透适合正在做毕业设计、课程大项目或者想入门管理系统开发的人参考。1. 项目整体架构与业务拆解1.1 业务需求与技术栈选型逻辑馆藏系统第一版需要覆盖的核心动作其实不多藏品的录入、编辑、删除分类维护图片上传还有查询检索。围绕这些动作业务上就两类核心对象藏品本身和它的附属信息。附属信息包括分类、封面图、详细描述、修复或借展记录这些可以拆表也可以先做成字段看项目规模灵活处理。我的经验是第一版尽量少做重设计能用一个字段表达的就不建表先把主线跑通后续再根据真实使用反馈补表。技术栈选型的逻辑标题基本已经给定但我还是说一下为什么这套组合值得用。SpringBoot2 的自动配置和开箱即用的 Starter省去了大量 XML 配置让后端项目十分钟内能跑起来。MyBatis-Plus 最大的价值是内置通用 Mapper单表 CRUD 零 SQL 实现配合条件构造器复杂的搜索条件也能链式拼接。Vue3 的组合式 API 把同一业务的状态和逻辑组织在一起代码可读性和维护性比 Vue2 的 Options API 好一个档次配合 Vite 的开发服务器热更新速度非常快。MySQL8.0 不用多说数据库事实标准窗口函数和 CTE 在后期做统计报表时非常顺手。这套组合在国内管理系统开发里基本是“标准答案”级别的存在原因就是它兼顾了开发效率和可维护性。前后端分离后后端只出 JSON 接口前端只关心页面交互并行开发互不阻塞。对答辩或演示来说效果也足够直观——跑起来就能看到漂亮的列表页、详情页、分页搜索技术点也有得讲。1.2 核心功能闭环与接口边界项目里我会把功能切成三个闭环。第一个是藏品管理闭环管理员录入藏品后写入数据库列表页能编辑和删除这是主干线。第二个是检索展示闭环访客输入关键词或选分类后端拼接条件分页查询前端渲染结果。第三个是系统管理闭环用户登录、权限校验、操作日志记录它不直接碰藏品数据但保证多人使用时的安全与可追溯。三个闭环的边界决定了接口怎么设计。藏品管理闭环对应一套完整的增删改查接口检索闭环意味着查询接口支持可选参数而不是为每种搜索组合单独写一个接口系统管理闭环需要登录态、拦截器和日志表。动手写代码前我会先列接口清单藏品相关接口、分类接口、登录接口、日志接口统一挂/api前缀。这套规划能省很多后期联调时间因为前端改页面时基本只动参数后端结构保持不变。2. MySQL8.0 数据库设计与建表细节数据库是管理系统的地基。很多新手上来就建表后期发现乱码、时间不对、字段不够用回头改表浪费的时间远超过当初多花半小时认真设计。建库时我建议字符集选utf8mb4排序规则选utf8mb4_0900_ai_ci。这俩不是可有可无的选项是必须做的。utf8mb4是utf8的超集能存 emoji 和生僻字博物馆藏品名称和描述里出现生僻字的概率非常高用旧字符集迟早出问题。排序规则选0900_ai_ci则是因为它对大小写不敏感中文排序也更符合检索习惯。另一个容易被忽略的是时区。MySQL8.0 默认时区可能与 Java 服务端不一致导致时间字段写入后相差 8 小时。连接 URL 里必须显式加上serverTimezoneAsia/Shanghai和useUnicodetruecharacterEncodingutf8这条配置能避免绝大多数时间和编码问题。我第一次做项目时没配时区日志记录全是 UTC 时间排查半天才发现是这里的问题。2.1 核心表结构设计藏品主表是系统里最重要的表我按实际设计习惯拆解一下字段思路。id用BIGINT自增简单可靠配合索引查询性能好。collection_no存业务编号也就是实际管理中的文物编号必须加唯一约束因为线下馆藏每件藏品都有唯一编号系统里不能重复。name存藏品名称category_id关联分类表source存来源era存年代material存材质size_desc存尺寸描述cover_image存封面图 URLdescription存详细描述最后加create_time和update_time。字段类型选择上有几个坑要注意。文本内容如果只是几百字用VARCHAR(500)而不是TEXT因为 VARCHAR 可以建索引而 TEXT 不行。图片 URL 字段给VARCHAR(255)足够。时间字段统一用datetime范围到 9999 年避免timestamp的 2038 年问题。布尔字段如果需要中间状态就不要用 tinyint 的 0/1而是用 varchar 存储枚举值比如藏品的保存状态可能是“良好、修复中、待修复”多个值。分类表很简单就是 id、名称、排序号、父分类 id支持两级分类就足够。用户表要包含用户名、密码、角色字段密码必须加密存储不要明文入库。操作日志表记录操作人、操作类型、操作对象和创建时间字段别做太重够用就行。2.2 初始化数据与导入要点项目第一次跑起来不能什么都没有。我习惯准备一份初始化 SQL 脚本包含分类数据和几件样例藏品这样前端列表页第一次打开就不至于空白。数据导入时注意 MySQL8.0 对ONLY_FULL_GROUP_BY等 SQL 模式的检查比 5.7 严格聚合查询里字段要写全尽量不要用select *加group by的写法。还有就是初始化脚本的执行方式。如果放在application.yml里通过spring.sql.init.modealways自动执行要记得在数据导入后改成never否则每次重启都会重新导入产生重复数据。这个坑我帮别人排查过好几次现象就是列表里突然多了几倍的数据时间还都一样基本就是这个原因。2.3 MyBatis-Plus 实体与表字段映射实体类设计要遵守 MyBatis-Plus 的命名约定表名和实体类名对应字段名和属性名对应默认按驼峰转下划线规则映射。只要命名规范绝大多数场景不需要写TableField注解。但有两个注意点。主键策略默认是雪花算法生成 Long 型 ID如果表里主键是自增的实体 id 字段要加TableId(type IdType.AUTO)否则插入时会用雪花 ID 覆盖自增值虽然不报错但主键完全不可控。时间字段我建议用LocalDateTime配合datetime数据库字段Java 侧不需要手动转换前端展示也方便。还要注意避开数据库关键字做字段名比如status、order、comment这些常见字段名可能命中关键字真要用就加反引号或者干脆改字段名我在设计表时就尽量用state代替status、用remark代替comment省后面一堆麻烦。3. SpringBoot2 MyBatis-Plus 后端实现后端搭建从 pom.xml 开始。核心依赖是spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-j和lombok。版本上注意 MyBatis-Plus 用 3.5.x 系列太老的版本 API 和新版本差异较大直接照新示例代码跑容易报错。启动类加了MapperScan扫描 Mapper 接口包后每个 Mapper 接口继承BaseMapperT单表 CRUD 方法直接可用。实体类写好之后Service 层调用baseMapper.insert(entity)就能完成新增MyBatis-Plus 会自动忽略 null 字段只把非空字段拼进 INSERT 语句。配合TableField(fill FieldFill.INSERT)还能在插入时自动填充创建时间少写很多重复代码。3.1 通用 CRUD 与条件构造器MyBatis-Plus 真正拉开和原生 MyBatis 差距的地方是条件构造器。比如按关键词模糊搜索和分类筛选原生写法要在 XML 里写动态 SQL用if标签拼接条件一多又乱又容易漏分支。用LambdaQueryWrapper就清爽很多LambdaQueryWrapperCollectionItem wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(keyword), CollectionItem::getName, keyword) .eq(categoryId ! null, CollectionItem::getCategoryId, categoryId) .orderByDesc(CollectionItem::getCreateTime);第一个参数是开关条件为 false 时条件自动忽略。前端传什么参数就拼什么条件不需要为每种搜索组合单独写接口。实测下来查询代码量能减少一半以上而且把参数校验和查询逻辑放在一起维护起来很清楚。我整理代码时会把复杂查询逻辑放在 Service 层Controller 只负责接收参数和返回结果。返回结构统一用ResultT包装里面包含 code、message、data 三个字段。这样前端响应拦截器只用判断一个 code 值不用为每个接口写不同的错误处理。3.2 分页插件的关键配置管理系统没有不分页的。MyBatis-Plus 的分页需要手动注册拦截器很多新手只引入了依赖跳过这一步结果分页方法返回的是全量数据还以为是框架 bug。配置方法如下Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(100L); interceptor.addInnerInterceptor(pagination); return interceptor; } }配置里把单页最大行数限制在 100防止有人恶意传一个很大的 pageSize 拖垮数据库。调用分页时传入new Page(current, size)返回的IPageT包含 records、total、current、size 四个字段前端分页组件要的值一次全齐。这个拦截器的顺序很重要如果项目同时用了别的插件比如乐观锁插件要注意拦截器的添加顺序不能乱。3.3 登录鉴权与操作日志的轻量实现馆藏系统第一版不需要接入 Spring Security 那种重量级框架我用轻量 token 方案。用户登录成功后生成一个 token存在 Redis 里后续请求带上 token拦截器校验通过就放行没有 token 返回 401。项目初期不引入 Redis 的话可以用 ConcurrentHashMap 代替但重启后所有登录状态都会失效只适合演示。既然对接的是管理系统我建议把 Redis 接进去成本很低体验差异明显。操作日志我在 Service 层统一处理比如删除藏品前先记录一条日志。可以用 AOP 做也可以手动调用日志 Service关键是养成记录习惯。真实运营中借展、修复记录频繁变更没日志出了问题根本查不到。日志表字段就是 id、操作人、操作类型、操作对象、创建时间简洁够用。3.4 事务处理与数据一致性藏品更新往往不是单表操作。比如修改一件藏品时可能还要更新分类统计或者插入操作日志任何一个步骤失败前面的写入都应该回滚。这时就在 Service 方法上加Transactional注解让数据库保证原子性。注意一个常见误区同类内部调用带事务的方法事务是不生效的因为走的是 this 调用而不是 Spring 代理对象。我踩过这个坑之后习惯把事务方法放到另一个 Service 里或者通过注入代理对象调用事务才能真正开启。4. Vue3 前端项目落地前端用 Vite 初始化很简单npm create vitelatest选 vue 模板几秒钟项目就能跑起来。Vite 的开发服务器热更新速度接近即时开发体验比 webpack 时代好太多。初始化后第一件事装 UI 组件库。Element Plus 是 Vue3 生态里很成熟的组件库组件覆盖全、文档中文特别适合管理后台。路由和状态管理分别用 vue-router 和 piniapinia 比 Vuex 写法更轻量TypeScript 支持也更好。很多从 Vue2 转过来的人会问组合式 API 到底好在哪。举个直观例子列表页里的搜索条件和表格数据Vue2 中一个在 data 一个在 methods互相关联的逻辑被拆到不同选项里Vue3 的script setup中可以写在一起状态、方法、计算属性都围绕同一业务组织多人协作时看代码更快。4.1 列表页与搜索表单的组件化列表页我拆成三块搜索表单区、表格区、分页区。搜索表单用el-form的 inline 模式放两三个字段就够比如藏品名称、分类、年代范围。表格用el-table封面图用el-image组件声明 lazy 属性就能懒加载图片多时性能提升明显。分页用el-pagination当前页和总数绑定到响应式变量上页码变化时重新调查询接口。这个部分的响应式要特别注意 Vue3 的规则用ref声明基本类型和数组用reactive声明对象。列表数据我用ref([])接口返回后直接整体赋值data.value response.data.records不要逐条 push那样容易造成响应式性能问题。如果表单对象需要动态增删字段建议用reactive并在初始时就声明好结构不然重置表单时容易出问题。4.2 Axios 封装与请求拦截前端对接后端接口我会把所有网络请求集中到一个 request 模块里统一封装。基础路径通过环境变量区分开发环境走 Vite proxy 代理生产环境走相对路径。请求拦截器从 localStorage 或 pinia 取 token 加到请求头响应拦截器统一判断返回状态码401 跳登录页其他错误弹提示。接口地址统一用 RESTful 风格GET /api/collections查列表、GET /api/collections/{id}查详情、POST /api/collections新增、PUT /api/collections/{id}修改、DELETE /api/collections/{id}删除。这种命名语义清楚前端调用时一眼就知道该用哪个方法。封装的好处是页面代码里基本不出现错误处理逻辑只管取数据渲染。4.3 表单校验与动态交互藏品编辑页最重要的就是表单校验。用 el-form 的 rules 配置必填、长度、数字范围规则非常直观。这里有一个 Element Plus 的细节form 绑定的对象用 reactive 声明表单项要加 prop 属性初始值必须提前声明好否则resetFields()不会生效。遇到过有同事在编辑页忘了声明一个新加的字段点重置后那个字段的值永远清不掉排查半天才知道是初始对象里没有这个 key。图片上传用 el-upload 配合后端上传接口上传成功后把返回的 URL 回填到coverImage字段。后端接收 MultipartFile 后保存到服务器目录并返回可访问的静态资源 URL。如果演示环境没有对象存储用本地目录就行但路径配置要写进文档不然部署到别人电脑上图片会全部 404。Vue3 面试题里经常考 watch 和 computed 的区别。在这个项目里我实际的用法是computed 处理搜索条件的拼接显示watch 监听分类下拉变化并联动刷新表格。computed 是基于已有状态算新值watch 是状态变化时执行副作用这两个 API 用多了自然就分清了。5. 联调、部署与高频踩坑实录前后端联调是我个人踩坑最多的环节。很多问题不是单个技术栈的问题而是两边协作边界不清。跨域是最常见的开发环境我用 Vite 的 proxy 把/api代理到http://localhost:8080浏览器看到的请求是同域的后端完全不用处理 CORS。有些人会在后端加全局 CORS 配置也能跑通但生产环境前后端都通过 Nginx 提供同域服务时后端 CORS 配置反而多余。时间格式是第二个联调痛点。后端LocalDateTime默认序列化成2024-05-01T10:00:00这种 ISO 格式而 Element Plus 的日期组件要的是2024-05-01 10:00:00。建议在后端统一配置全局 Jackson 时间格式化一劳永逸不然每个时间字段都要前端转换一遍肯定有遗漏。我在application.yml里配置了时间格式和时区效果稳定。5.1 权限菜单的动态控制馆藏系统至少要有管理员和编辑者两种角色。管理员能删除藏品编辑者只能新增和修改。前端菜单根据角色动态显示Vue Router 有两种做法一种是登录时后端返回该角色可访问的路由列表前端用addRoute动态注册另一种是所有路由都注册靠路由守卫根据角色拦截。第二种实现简单管理后台足够用面试能讲清楚为什么选它就行。实际开发中我还会在路由守卫里做登录态检查没有 token 就强制跳登录页登录后根据角色过滤可访问页面。这个逻辑放在全局 beforeEach 里页面组件不需要自己判断权限体验很干净。5.2 部署配置与资源处理部署这块我推荐“后端 JAR 前端静态文件 Nginx 反向代理”的模式。SpringBoot2 项目用mvn package打成 JAR服务器上java -jar跑起来监听 8080。前端npm run build生成 dist 目录交给 Nginx 托管然后把/api路径代理到后端 8080。对外只需要暴露一个域名没有跨域问题演示时访问体验很顺畅。如果要单机演示还有一招把前端构建产物直接复制到src/main/resources/static/目录下重新打包 JAR一个命令跑整个系统前后端在同一个 8080 端口。这适合答辩或交付缺点是想改前端必须重新打包但演示场景这个缺点可以接受。5.3 问题排查速查表把项目里容易出的问题按现象整理成一张表遇到类似情况直接照着排查比重新翻文档高效很多。现象原因解决方式控制台报 invalid bound statement (not found)Mapper 接口未被扫描或 XML namespace 错误检查 MapperScan 和 namespace 是否与接口全限定名一致分页查询 total 始终为 0分页插件未注册按上文配置 MybatisPlusInterceptor时间字段比实际少 8 小时连接串缺少 serverTimezone 参数URL 加上 serverTimezoneAsia/ShanghaiVue3 页面数据更新但视图不刷新数组索引赋值或未在初始号声明字段使用整体赋值或 splice文件上传成功但图片 404上传目录与静态资源映射不一致检查资源映射路径和磁盘目录是否对应数据库连接总失败端口不对或 MySQL 未启动用客户端手动测试连接MySQL8.0 连接报认证错误JDBC 驱动太旧升级驱动到 mysql-connector-j 8.0.x补充一个 MySQL8.0 独有的坑首次安装后 root 用户的认证插件是caching_sha2_password老版本 JDBC 驱动连接会报错。解决方式两种要么升级驱动要么改密码插件。我的建议是升级驱动到 8.0.x既然项目就是 MySQL8.0没必要为了旧驱动降级安全认证方式。6. 项目文档整理与二次开发建议标题里带了“含文档”文档质量往往是评分和后续维护的关键。我写项目文档的习惯是先把 README 写好里面包含项目是什么、如何启动、默认账号密码、目录结构然后是数据库初始化说明和接口列表。核心目标很简单让一个完全没接触过项目的人按文档操作就能把系统跑起来。6.1 文档里最该写清楚的内容启动文档按顺序写环境准备JDK、Maven、Node、MySQL 版本、初始化步骤建库、执行 SQL、改配置、启动、配置说明数据库地址、账号密码、上传目录、前端环境变量。这些信息对一个新人最有价值写太多业务介绍反而没人看。接口文档可以用 Knife4j 或 Swagger 自动生成也可以手写 Markdown 表格。对于中小型项目我倾向手写改动灵活转 PDF 也方便。每个接口标明请求方式、路径、参数、返回示例用截图加表格直观好懂。分类表和藏品表的初始化数据也写入文档别人拿到项目直接导入就能看效果。6.2 我个人建议优先扩展的三个方向第一是三维藏品展示。博物馆场景的线上化展示效果是重点。如果上传的是多角度图片前端可以用 Three.js 或简单的图片轮播展示效果明显比静态缩略图强。第二是借展管理和修复记录。真实馆藏系统中这两块业务非常高频数据模型不复杂扩展时也不用动现有表结构。第三是数据统计报表。MySQL8.0 的窗口函数能方便地统计藏品按年代分布、按分类分布等数据配合 ECharts 出几张图系统整体观感会提升不少。7. 项目复盘与个人心得整套项目做完再回头看最大的体会是“先理业务、再选技术、最后写代码”的顺序不能乱。从数据库建表到后端接口再到前端页面每一步决策都可以追溯到业务需求。这套 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 的组合虽然看起来都是最常规的东西但真实落地时覆盖了从建库、CRUD、分页、跨域、权限到部署的完整链路踩过的每一个坑都很有价值。我最大的收获其实是那些文档里不会写的细节分页插件忘了配置、时间差 8 小时、上传路径不匹配、事务内部调用失效每一个坑背后都是原理性的理解。如果你正准备做一个类似的管理系统项目不妨先把业务模型画出来再按这套技术栈一步步搭遇到问题直接查速查表能少走不少弯路。 SpringBoot2+Vue3+MyBatis-Plus馆藏系统开发全流程复盘
先把这个系统的底盘讲清楚。所谓“线上历史馆藏系统”本质就是给博物馆、档案馆、文化机构做一套藏品数字台账把纸质档案里的编号、年代、材质、尺寸、来源、图片这些信息搬进数据库再通过网页让管理员维护、让访客检索浏览。我拿到这种项目时习惯先定业务主线再动代码。这篇文章就按我实际做完一个 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 馆藏系统项目的流程来复盘从建库、接口、前端、联调部署到文档整理一条线讲透适合正在做毕业设计、课程大项目或者想入门管理系统开发的人参考。1. 项目整体架构与业务拆解1.1 业务需求与技术栈选型逻辑馆藏系统第一版需要覆盖的核心动作其实不多藏品的录入、编辑、删除分类维护图片上传还有查询检索。围绕这些动作业务上就两类核心对象藏品本身和它的附属信息。附属信息包括分类、封面图、详细描述、修复或借展记录这些可以拆表也可以先做成字段看项目规模灵活处理。我的经验是第一版尽量少做重设计能用一个字段表达的就不建表先把主线跑通后续再根据真实使用反馈补表。技术栈选型的逻辑标题基本已经给定但我还是说一下为什么这套组合值得用。SpringBoot2 的自动配置和开箱即用的 Starter省去了大量 XML 配置让后端项目十分钟内能跑起来。MyBatis-Plus 最大的价值是内置通用 Mapper单表 CRUD 零 SQL 实现配合条件构造器复杂的搜索条件也能链式拼接。Vue3 的组合式 API 把同一业务的状态和逻辑组织在一起代码可读性和维护性比 Vue2 的 Options API 好一个档次配合 Vite 的开发服务器热更新速度非常快。MySQL8.0 不用多说数据库事实标准窗口函数和 CTE 在后期做统计报表时非常顺手。这套组合在国内管理系统开发里基本是“标准答案”级别的存在原因就是它兼顾了开发效率和可维护性。前后端分离后后端只出 JSON 接口前端只关心页面交互并行开发互不阻塞。对答辩或演示来说效果也足够直观——跑起来就能看到漂亮的列表页、详情页、分页搜索技术点也有得讲。1.2 核心功能闭环与接口边界项目里我会把功能切成三个闭环。第一个是藏品管理闭环管理员录入藏品后写入数据库列表页能编辑和删除这是主干线。第二个是检索展示闭环访客输入关键词或选分类后端拼接条件分页查询前端渲染结果。第三个是系统管理闭环用户登录、权限校验、操作日志记录它不直接碰藏品数据但保证多人使用时的安全与可追溯。三个闭环的边界决定了接口怎么设计。藏品管理闭环对应一套完整的增删改查接口检索闭环意味着查询接口支持可选参数而不是为每种搜索组合单独写一个接口系统管理闭环需要登录态、拦截器和日志表。动手写代码前我会先列接口清单藏品相关接口、分类接口、登录接口、日志接口统一挂/api前缀。这套规划能省很多后期联调时间因为前端改页面时基本只动参数后端结构保持不变。2. MySQL8.0 数据库设计与建表细节数据库是管理系统的地基。很多新手上来就建表后期发现乱码、时间不对、字段不够用回头改表浪费的时间远超过当初多花半小时认真设计。建库时我建议字符集选utf8mb4排序规则选utf8mb4_0900_ai_ci。这俩不是可有可无的选项是必须做的。utf8mb4是utf8的超集能存 emoji 和生僻字博物馆藏品名称和描述里出现生僻字的概率非常高用旧字符集迟早出问题。排序规则选0900_ai_ci则是因为它对大小写不敏感中文排序也更符合检索习惯。另一个容易被忽略的是时区。MySQL8.0 默认时区可能与 Java 服务端不一致导致时间字段写入后相差 8 小时。连接 URL 里必须显式加上serverTimezoneAsia/Shanghai和useUnicodetruecharacterEncodingutf8这条配置能避免绝大多数时间和编码问题。我第一次做项目时没配时区日志记录全是 UTC 时间排查半天才发现是这里的问题。2.1 核心表结构设计藏品主表是系统里最重要的表我按实际设计习惯拆解一下字段思路。id用BIGINT自增简单可靠配合索引查询性能好。collection_no存业务编号也就是实际管理中的文物编号必须加唯一约束因为线下馆藏每件藏品都有唯一编号系统里不能重复。name存藏品名称category_id关联分类表source存来源era存年代material存材质size_desc存尺寸描述cover_image存封面图 URLdescription存详细描述最后加create_time和update_time。字段类型选择上有几个坑要注意。文本内容如果只是几百字用VARCHAR(500)而不是TEXT因为 VARCHAR 可以建索引而 TEXT 不行。图片 URL 字段给VARCHAR(255)足够。时间字段统一用datetime范围到 9999 年避免timestamp的 2038 年问题。布尔字段如果需要中间状态就不要用 tinyint 的 0/1而是用 varchar 存储枚举值比如藏品的保存状态可能是“良好、修复中、待修复”多个值。分类表很简单就是 id、名称、排序号、父分类 id支持两级分类就足够。用户表要包含用户名、密码、角色字段密码必须加密存储不要明文入库。操作日志表记录操作人、操作类型、操作对象和创建时间字段别做太重够用就行。2.2 初始化数据与导入要点项目第一次跑起来不能什么都没有。我习惯准备一份初始化 SQL 脚本包含分类数据和几件样例藏品这样前端列表页第一次打开就不至于空白。数据导入时注意 MySQL8.0 对ONLY_FULL_GROUP_BY等 SQL 模式的检查比 5.7 严格聚合查询里字段要写全尽量不要用select *加group by的写法。还有就是初始化脚本的执行方式。如果放在application.yml里通过spring.sql.init.modealways自动执行要记得在数据导入后改成never否则每次重启都会重新导入产生重复数据。这个坑我帮别人排查过好几次现象就是列表里突然多了几倍的数据时间还都一样基本就是这个原因。2.3 MyBatis-Plus 实体与表字段映射实体类设计要遵守 MyBatis-Plus 的命名约定表名和实体类名对应字段名和属性名对应默认按驼峰转下划线规则映射。只要命名规范绝大多数场景不需要写TableField注解。但有两个注意点。主键策略默认是雪花算法生成 Long 型 ID如果表里主键是自增的实体 id 字段要加TableId(type IdType.AUTO)否则插入时会用雪花 ID 覆盖自增值虽然不报错但主键完全不可控。时间字段我建议用LocalDateTime配合datetime数据库字段Java 侧不需要手动转换前端展示也方便。还要注意避开数据库关键字做字段名比如status、order、comment这些常见字段名可能命中关键字真要用就加反引号或者干脆改字段名我在设计表时就尽量用state代替status、用remark代替comment省后面一堆麻烦。3. SpringBoot2 MyBatis-Plus 后端实现后端搭建从 pom.xml 开始。核心依赖是spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-j和lombok。版本上注意 MyBatis-Plus 用 3.5.x 系列太老的版本 API 和新版本差异较大直接照新示例代码跑容易报错。启动类加了MapperScan扫描 Mapper 接口包后每个 Mapper 接口继承BaseMapperT单表 CRUD 方法直接可用。实体类写好之后Service 层调用baseMapper.insert(entity)就能完成新增MyBatis-Plus 会自动忽略 null 字段只把非空字段拼进 INSERT 语句。配合TableField(fill FieldFill.INSERT)还能在插入时自动填充创建时间少写很多重复代码。3.1 通用 CRUD 与条件构造器MyBatis-Plus 真正拉开和原生 MyBatis 差距的地方是条件构造器。比如按关键词模糊搜索和分类筛选原生写法要在 XML 里写动态 SQL用if标签拼接条件一多又乱又容易漏分支。用LambdaQueryWrapper就清爽很多LambdaQueryWrapperCollectionItem wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(keyword), CollectionItem::getName, keyword) .eq(categoryId ! null, CollectionItem::getCategoryId, categoryId) .orderByDesc(CollectionItem::getCreateTime);第一个参数是开关条件为 false 时条件自动忽略。前端传什么参数就拼什么条件不需要为每种搜索组合单独写接口。实测下来查询代码量能减少一半以上而且把参数校验和查询逻辑放在一起维护起来很清楚。我整理代码时会把复杂查询逻辑放在 Service 层Controller 只负责接收参数和返回结果。返回结构统一用ResultT包装里面包含 code、message、data 三个字段。这样前端响应拦截器只用判断一个 code 值不用为每个接口写不同的错误处理。3.2 分页插件的关键配置管理系统没有不分页的。MyBatis-Plus 的分页需要手动注册拦截器很多新手只引入了依赖跳过这一步结果分页方法返回的是全量数据还以为是框架 bug。配置方法如下Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(100L); interceptor.addInnerInterceptor(pagination); return interceptor; } }配置里把单页最大行数限制在 100防止有人恶意传一个很大的 pageSize 拖垮数据库。调用分页时传入new Page(current, size)返回的IPageT包含 records、total、current、size 四个字段前端分页组件要的值一次全齐。这个拦截器的顺序很重要如果项目同时用了别的插件比如乐观锁插件要注意拦截器的添加顺序不能乱。3.3 登录鉴权与操作日志的轻量实现馆藏系统第一版不需要接入 Spring Security 那种重量级框架我用轻量 token 方案。用户登录成功后生成一个 token存在 Redis 里后续请求带上 token拦截器校验通过就放行没有 token 返回 401。项目初期不引入 Redis 的话可以用 ConcurrentHashMap 代替但重启后所有登录状态都会失效只适合演示。既然对接的是管理系统我建议把 Redis 接进去成本很低体验差异明显。操作日志我在 Service 层统一处理比如删除藏品前先记录一条日志。可以用 AOP 做也可以手动调用日志 Service关键是养成记录习惯。真实运营中借展、修复记录频繁变更没日志出了问题根本查不到。日志表字段就是 id、操作人、操作类型、操作对象、创建时间简洁够用。3.4 事务处理与数据一致性藏品更新往往不是单表操作。比如修改一件藏品时可能还要更新分类统计或者插入操作日志任何一个步骤失败前面的写入都应该回滚。这时就在 Service 方法上加Transactional注解让数据库保证原子性。注意一个常见误区同类内部调用带事务的方法事务是不生效的因为走的是 this 调用而不是 Spring 代理对象。我踩过这个坑之后习惯把事务方法放到另一个 Service 里或者通过注入代理对象调用事务才能真正开启。4. Vue3 前端项目落地前端用 Vite 初始化很简单npm create vitelatest选 vue 模板几秒钟项目就能跑起来。Vite 的开发服务器热更新速度接近即时开发体验比 webpack 时代好太多。初始化后第一件事装 UI 组件库。Element Plus 是 Vue3 生态里很成熟的组件库组件覆盖全、文档中文特别适合管理后台。路由和状态管理分别用 vue-router 和 piniapinia 比 Vuex 写法更轻量TypeScript 支持也更好。很多从 Vue2 转过来的人会问组合式 API 到底好在哪。举个直观例子列表页里的搜索条件和表格数据Vue2 中一个在 data 一个在 methods互相关联的逻辑被拆到不同选项里Vue3 的script setup中可以写在一起状态、方法、计算属性都围绕同一业务组织多人协作时看代码更快。4.1 列表页与搜索表单的组件化列表页我拆成三块搜索表单区、表格区、分页区。搜索表单用el-form的 inline 模式放两三个字段就够比如藏品名称、分类、年代范围。表格用el-table封面图用el-image组件声明 lazy 属性就能懒加载图片多时性能提升明显。分页用el-pagination当前页和总数绑定到响应式变量上页码变化时重新调查询接口。这个部分的响应式要特别注意 Vue3 的规则用ref声明基本类型和数组用reactive声明对象。列表数据我用ref([])接口返回后直接整体赋值data.value response.data.records不要逐条 push那样容易造成响应式性能问题。如果表单对象需要动态增删字段建议用reactive并在初始时就声明好结构不然重置表单时容易出问题。4.2 Axios 封装与请求拦截前端对接后端接口我会把所有网络请求集中到一个 request 模块里统一封装。基础路径通过环境变量区分开发环境走 Vite proxy 代理生产环境走相对路径。请求拦截器从 localStorage 或 pinia 取 token 加到请求头响应拦截器统一判断返回状态码401 跳登录页其他错误弹提示。接口地址统一用 RESTful 风格GET /api/collections查列表、GET /api/collections/{id}查详情、POST /api/collections新增、PUT /api/collections/{id}修改、DELETE /api/collections/{id}删除。这种命名语义清楚前端调用时一眼就知道该用哪个方法。封装的好处是页面代码里基本不出现错误处理逻辑只管取数据渲染。4.3 表单校验与动态交互藏品编辑页最重要的就是表单校验。用 el-form 的 rules 配置必填、长度、数字范围规则非常直观。这里有一个 Element Plus 的细节form 绑定的对象用 reactive 声明表单项要加 prop 属性初始值必须提前声明好否则resetFields()不会生效。遇到过有同事在编辑页忘了声明一个新加的字段点重置后那个字段的值永远清不掉排查半天才知道是初始对象里没有这个 key。图片上传用 el-upload 配合后端上传接口上传成功后把返回的 URL 回填到coverImage字段。后端接收 MultipartFile 后保存到服务器目录并返回可访问的静态资源 URL。如果演示环境没有对象存储用本地目录就行但路径配置要写进文档不然部署到别人电脑上图片会全部 404。Vue3 面试题里经常考 watch 和 computed 的区别。在这个项目里我实际的用法是computed 处理搜索条件的拼接显示watch 监听分类下拉变化并联动刷新表格。computed 是基于已有状态算新值watch 是状态变化时执行副作用这两个 API 用多了自然就分清了。5. 联调、部署与高频踩坑实录前后端联调是我个人踩坑最多的环节。很多问题不是单个技术栈的问题而是两边协作边界不清。跨域是最常见的开发环境我用 Vite 的 proxy 把/api代理到http://localhost:8080浏览器看到的请求是同域的后端完全不用处理 CORS。有些人会在后端加全局 CORS 配置也能跑通但生产环境前后端都通过 Nginx 提供同域服务时后端 CORS 配置反而多余。时间格式是第二个联调痛点。后端LocalDateTime默认序列化成2024-05-01T10:00:00这种 ISO 格式而 Element Plus 的日期组件要的是2024-05-01 10:00:00。建议在后端统一配置全局 Jackson 时间格式化一劳永逸不然每个时间字段都要前端转换一遍肯定有遗漏。我在application.yml里配置了时间格式和时区效果稳定。5.1 权限菜单的动态控制馆藏系统至少要有管理员和编辑者两种角色。管理员能删除藏品编辑者只能新增和修改。前端菜单根据角色动态显示Vue Router 有两种做法一种是登录时后端返回该角色可访问的路由列表前端用addRoute动态注册另一种是所有路由都注册靠路由守卫根据角色拦截。第二种实现简单管理后台足够用面试能讲清楚为什么选它就行。实际开发中我还会在路由守卫里做登录态检查没有 token 就强制跳登录页登录后根据角色过滤可访问页面。这个逻辑放在全局 beforeEach 里页面组件不需要自己判断权限体验很干净。5.2 部署配置与资源处理部署这块我推荐“后端 JAR 前端静态文件 Nginx 反向代理”的模式。SpringBoot2 项目用mvn package打成 JAR服务器上java -jar跑起来监听 8080。前端npm run build生成 dist 目录交给 Nginx 托管然后把/api路径代理到后端 8080。对外只需要暴露一个域名没有跨域问题演示时访问体验很顺畅。如果要单机演示还有一招把前端构建产物直接复制到src/main/resources/static/目录下重新打包 JAR一个命令跑整个系统前后端在同一个 8080 端口。这适合答辩或交付缺点是想改前端必须重新打包但演示场景这个缺点可以接受。5.3 问题排查速查表把项目里容易出的问题按现象整理成一张表遇到类似情况直接照着排查比重新翻文档高效很多。现象原因解决方式控制台报 invalid bound statement (not found)Mapper 接口未被扫描或 XML namespace 错误检查 MapperScan 和 namespace 是否与接口全限定名一致分页查询 total 始终为 0分页插件未注册按上文配置 MybatisPlusInterceptor时间字段比实际少 8 小时连接串缺少 serverTimezone 参数URL 加上 serverTimezoneAsia/ShanghaiVue3 页面数据更新但视图不刷新数组索引赋值或未在初始号声明字段使用整体赋值或 splice文件上传成功但图片 404上传目录与静态资源映射不一致检查资源映射路径和磁盘目录是否对应数据库连接总失败端口不对或 MySQL 未启动用客户端手动测试连接MySQL8.0 连接报认证错误JDBC 驱动太旧升级驱动到 mysql-connector-j 8.0.x补充一个 MySQL8.0 独有的坑首次安装后 root 用户的认证插件是caching_sha2_password老版本 JDBC 驱动连接会报错。解决方式两种要么升级驱动要么改密码插件。我的建议是升级驱动到 8.0.x既然项目就是 MySQL8.0没必要为了旧驱动降级安全认证方式。6. 项目文档整理与二次开发建议标题里带了“含文档”文档质量往往是评分和后续维护的关键。我写项目文档的习惯是先把 README 写好里面包含项目是什么、如何启动、默认账号密码、目录结构然后是数据库初始化说明和接口列表。核心目标很简单让一个完全没接触过项目的人按文档操作就能把系统跑起来。6.1 文档里最该写清楚的内容启动文档按顺序写环境准备JDK、Maven、Node、MySQL 版本、初始化步骤建库、执行 SQL、改配置、启动、配置说明数据库地址、账号密码、上传目录、前端环境变量。这些信息对一个新人最有价值写太多业务介绍反而没人看。接口文档可以用 Knife4j 或 Swagger 自动生成也可以手写 Markdown 表格。对于中小型项目我倾向手写改动灵活转 PDF 也方便。每个接口标明请求方式、路径、参数、返回示例用截图加表格直观好懂。分类表和藏品表的初始化数据也写入文档别人拿到项目直接导入就能看效果。6.2 我个人建议优先扩展的三个方向第一是三维藏品展示。博物馆场景的线上化展示效果是重点。如果上传的是多角度图片前端可以用 Three.js 或简单的图片轮播展示效果明显比静态缩略图强。第二是借展管理和修复记录。真实馆藏系统中这两块业务非常高频数据模型不复杂扩展时也不用动现有表结构。第三是数据统计报表。MySQL8.0 的窗口函数能方便地统计藏品按年代分布、按分类分布等数据配合 ECharts 出几张图系统整体观感会提升不少。7. 项目复盘与个人心得整套项目做完再回头看最大的体会是“先理业务、再选技术、最后写代码”的顺序不能乱。从数据库建表到后端接口再到前端页面每一步决策都可以追溯到业务需求。这套 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 的组合虽然看起来都是最常规的东西但真实落地时覆盖了从建库、CRUD、分页、跨域、权限到部署的完整链路踩过的每一个坑都很有价值。我最大的收获其实是那些文档里不会写的细节分页插件忘了配置、时间差 8 小时、上传路径不匹配、事务内部调用失效每一个坑背后都是原理性的理解。如果你正准备做一个类似的管理系统项目不妨先把业务模型画出来再按这套技术栈一步步搭遇到问题直接查速查表能少走不少弯路。