SpringBoot2+Vue3馆藏管理系统实战：从数据库设计到部署

1. 先说说这套系统要解决的现实问题

网上标注“Java Web线上历史馆藏系统源码”的项目并不少，但很多就是对着视频教程敲了一遍增删改查，真拿去给博物馆、纪念馆、文化馆用，根本接不住业务。这次这套系统的情况不太一样：需求方是一个地方文化单位，库房里有两万多件藏品，之前全靠Excel管，每个人手里的表格式都不一样，编号有的叫“藏字2019-012”，有的叫“ZT-012”，甚至同一件藏品在不同表格里录入的尺寸单位都不统一。平时查一件东西在哪个库房、什么状态、借给谁了，翻表要翻半天。

这套系统原本的目标很朴素：把两万多件藏品的档案、状态、流转记录全部搬上线，做到一次录入、随时可查、操作留痕。我最后选择了SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0这套技术栈，不是说这套组合多“新”，而是它恰好能把这类中小型业务系统的开发效率和后期维护成本做到一个比较舒服的平衡。

如果你正准备做类似的馆藏管理、资产管理系统，或者单纯想看一套SpringBoot2+Vue3前后端分离项目是怎么从零落地的，这篇内容会比较对路。我会把选型思路、数据库设计、后端接口实现、前端页面联调以及部署时踩过的坑都过一遍，尽量做到你拿着这套逻辑可以复刻出自己的版本。

1.1 馆藏业务里的三类关键角色

馆藏系统不是普通CRUD，它首先要满足三类角色的日常动作。

第一类是档案录入员。他们的工作是藏品建档，包括编号、名称、年代、质地、尺寸、重量、完残程度、级别、照片、存放位置、备注信息。录完还要时时修改，比如补充修复记录、调整存放柜位。

第二类是库房管理员。他们关心的是找东西快不快、盘点方不方便、出入库登记麻不麻烦。他们每天干得最多的事就是“提取藏品、归还藏品、生成出库单、生成归库单”，如果系统里每次出库入库都要填大表单，他们会很痛苦。所以这套系统在流转记录的设计上一定要精简，最好首页就有一个扫码或快速登记入口。

第三类是业务审批领导。他们不一定天天进去看，但需要能按年代、级别、质地、存放位置快速查统计报表，出一个“馆藏总量、三级以上藏品数量、借展中藏品清单”之类的汇总页面。

一个合理的线上历史馆藏系统，本质上是给这三个角色分别提供一套顺手的工具，同时把“人”和“物”的每一笔交互记录沉淀下来。否则那只是一个套了博物馆壳子的后台模板，上线也没人用。

1.2 六个核心业务模块的划分

顺着上面三类角色的场景，我最终把系统模块拆成了六块：藏品档案管理、分类字典管理、状态管理、出入库/借展流转管理、统计盘点、系统用户权限。藏品档案这块是主角，其余都是围绕它为业务服务的。

这几个模块之间不是简单的并列关系。藏品档案和流转记录是强关联的——一件藏品每一次出库、归库、借展、修复，都会在流转记录表里生成一条带状态变更的流水，同时回写藏品主表里的“当前状态”和“当前存放位置”。分类字典和状态字典则是标准数据源，前端下拉框的数据都是从这两张字典表读取，而不是硬编码在代码里，这样后续要加“待定级”“修复中”这类状态时，不用改代码只加数据就行。

用户权限模块我用了比较常规的做法：角色-菜单-按钮三级权限，管理员可以给不同账号分配不同菜单权限和按钮权限，避免档案录入员不小心点掉某个藏品档案。这部分在MyBatis-Plus的框架下做起来不复杂，而且后期维护明确，不用为权限设计付出太高学习成本。

2. 技术选型的真实理由：SpringBoot2、Vue3、MyBatis-Plus与MySQL8.0

选型这块我聊点实际的。现在网上充斥着“技术选型必须最新”的声音，好像不用SpringBoot3就觉得落伍，但真实项目里选型的决定因素往往是兼容性、生态成熟度和团队上手成本，而不是版本号的新旧。

2.1 后端框架：为什么用SpringBoot2而不是SpringBoot3

这套馆藏系统的实际运行环境是客户的一台服务器，上面已经有JDK8跑着的其他业务系统。SpringBoot3要求JDK17起步，如果我强行上SpringBoot3，就意味着服务器要同时维护JDK8和JDK17两套环境，运维负担直接翻倍。

SpringBoot2.x配合JDK8，是目前国内中小型项目里最稳的一套组合。它和旧系统的依赖冲突少，出问题能在搜索引擎里找到大量现成方案，一些老牌第三方库（比如某些文件服务器SDK）也只有在JDK8下才兼容得很顺畅。所以这套系统用SpringBoot2.7.x，不是因为它比3好，而是它在当前环境里是风险最低、收益最高的方案。

我建议你做类似项目前先问自己三个问题：服务器能不能装新JDK？团队原来熟悉哪个版本？第三方依赖是否兼容新版框架？这三个问题问完，选型基本就定了。

2.2 MyBatis-Plus带来的效率提升

MyBatis-Plus在这套系统里承担的是数据访问层的基础能力。你可以把它理解成“买了个精装房，水电、墙面、地板都有基础交付了，你只需要根据自己的户型做局部调整”。

用MyBatis-Plus的BaseMapper，我在Mapper层几乎不用写SQL就能拿到单表CRUD、分页查询、批量插入这些能力。馆藏系统里大部分业务都是单表操作加条件查询，比如按藏品名称模糊搜索、按分类筛选、按年代范围统计，这些用MyBatis-Plus的QueryWrapper和LambdaQueryWrapper可以很干净地完成。

但不要指望它包办一切。涉及两张表以上的关联查询，或者复杂的统计报表，我还是老老实实写自定义SQL放在XML里。馆藏统计里有一个“按年代段分组查藏品数量”的报表，因为要联动分类表和状态表，直接用Wrapper拼会比较别扭，XML里一条JOIN加GROUP BY就搞定了。

2.3 前端框架：Vue3比Vue2好在哪

这套系统前端选Vue3，配合Element Plus做后台管理界面。Vue3的Composition API在这次的开发里帮了大忙，尤其是藏品档案这种字段多、逻辑复杂的表单页。用Options API写的话，数据、方法、计算属性分散在data、methods、computed三个区域，页面一长就来回跳；用Composition API按功能域组织代码，比如把“藏品基础信息逻辑”放一块、“图片上传逻辑”放一块、“状态变更逻辑”放一块，可读性和维护性都明显更好。

我用ref和reactive管理页面数据时也踩了一些小坑，后面专门开一段说。总体来讲，Vue3配合Element Plus做这种后台管理项目，开发效率和代码可维护性都在线，而且生态现在已经相当成熟，遇到问题基本都能找到答案。

2.4 MySQL8.0的确定性与小坑

数据库选MySQL8.0，理由很直接：它已经是目前默认最优解，改进了排序规则和事务隔离级别，支持窗口函数这种实用特性。馆藏系统里要按某时间段做流水统计，用窗口函数一条SQL就写出来了，非常顺手。

但MySQL8.0有几个实际开发中容易忽略的细节，这里提前说：

• 身份认证插件默认是caching_sha2_password，一些旧版可视化工具连不上，需要改成mysql_native_password。
• 数据库字符集建议在建库时就明确指定utf8mb4和utf8mb4_unicode_ci，否则中文排序和表情符号可能出现问题。
• 如果服务器内存不大，MySQL8.0默认的buffer_pool_size偏大，需要手动调优。

这些不是特别深的问题，但遇到一个卡一个半天很影响心情，早踩早好。

3. 数据库设计：馆藏系统的表结构与字段细节

数据库设计是这套系统的地基。表建不好，后面写多少代码都会感觉别扭。我按照“主数据、字典数据、流水数据”三层来组织表结构，逻辑非常清晰，也方便后期扩展。

3.1 藏品主表、分类表和状态字典表

藏品主表collection_item是核心。关键字段我列一下：

分类表category设计成无限层级，用parent_id自关联，字段包括分类名称、排序号。这样一个分类可以支撑“陶瓷类-宋瓷-青釉瓷”这种多级结构，前端用树形组件渲染很舒服。

状态字典表status_dict则比较简单，就三个字段：状态编码、状态名称、是否启用。前端的状态下拉框从这里读，后端服务层判断状态合法性的逻辑也依据这张表的数据。

3.2 流转记录表和借展记录表的细节

流水数据是馆藏系统和普通CRUD系统的最大区别。每一件藏品发生状态变化，都必须留一条记录。我设计了两张流水表：stock_flow_record用于入库、出库、归库，exhibition_record用于借展管理。

stock_flow_record关键字段包括：藏品ID、操作类型（入库/出库/归库）、操作前状态、操作后状态、仓库地点、经办人、操作时间、备注。这里的操作类型我放在程序里用枚举控制，而不是直接塞字符串，主要是为了防止录入员随便填出“出库”“出 库”“出库单”这种五花八门的值。

exhibition_record则多几个字段：借展单位、借展开始时间、预计归还时间、实际归还时间、借展押金、审批状态。借展的流转比较特殊，它不是简单在库与出库之间切换，而是“在库→借展中→在库”的闭环，中间还要经过领导审批环节。所以借展记录表里单独存了审批状态，避免和普通出入库混淆。

3.3 用MySQL8.0的窗口函数写统计报表

馆藏系统经常要出“某年内入库藏品数量按月份分布”这种报表。传统写法是GROUP BY MONTH(create_time)，但如果你还想在同一个结果集里看到累计值，就得靠MySQL8.0的窗口函数。

我写过一条比较典型的SQL：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, COUNT(*) AS monthly_count, SUM(COUNT(*)) OVER (ORDER BY DATE_FORMAT(create_time, '%Y-%m')) AS cumulative_count FROM collection_item WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31' GROUP BY month ORDER BY month;

这条SQL对MyBatis-Plus的通用Wrapper来说写不出来，但放XML自定义SQL后效果非常直观，一次查询出月度入库量和累计入库量，前端直接画折线图或者柱状图都行。窗口函数这类能力，是MySQL8.0很实在的收益。

4. 后端实现：SpringBoot2 + MyBatis-Plus的业务代码落地

框架选好了，表结构也定了，接下来是最核心的编码阶段。这里我把整个项目的落地过程拆成几块来讲。

4.1 项目骨架与统一结构

后端项目我按常见的分层结构组织：controller、service、mapper、entity、dto、vo、config、common。

common包下面放了统一返回结果类ApiResult，所有接口统一返回{code, message, data}结构。这样做前端Axios拦截器处理起来特别省事，不管成功失败就检查code，再也不用一个接口一种返回风格。代码大概是这样的：

@Data public class ApiResult<T> { private Integer code; private String message; private T data; public static <T> ApiResult<T> success(T data) { ApiResult<T> result = new ApiResult<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> ApiResult<T> error(Integer code, String message) { ApiResult<T> result = new ApiResult<>(); result.setCode(code); result.setMessage(message); return result; } }

统一异常处理用@RestControllerAdvice，业务异常、参数校验异常、系统异常分别捕获，返回友好提示给前端。这一步虽然代码不多，但能让后期联调少操很多心。

4.2 通用CRUD的写法

馆藏系统的CRUD接口占了大半。藏品管理、分类管理、字典管理、流转记录查询都是标准的增删改查。

Mpper接口继承BaseMapper后，Service层我选择直接用MyBatis-Plus的IService和ServiceImpl基类，这样连基础的save、updateById、removeById、page方法都有现成实现，只写自己需要的业务方法。比如藏品列表查询，我用LambdaQueryWrapper拼装条件：

LambdaQueryWrapper<CollectionItem> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(query.getName()), CollectionItem::getName, query.getName()) .eq(query.getCategoryId() != null, CollectionItem::getCategoryId, query.getCategoryId()) .eq(StringUtils.hasText(query.getStatus()), CollectionItem::getStatus, query.getStatus()) .orderByDesc(CollectionItem::getCreateTime);

这段最实际的收益是“省掉了一堆XML的selectByCondition写法”，而且条件拼接用Lambda表达式不会因为字段改名导致运行时错误，编译期就能发现。分页查询配合Page对象传current和size就行。

4.3 藏品状态流转的服务层实现

状态流转是馆藏系统的业务重点，我专门写了一个CollectionFlowService，负责出库、入库、借展、归还等操作。这里有一个关键设计：所有状态变更都走独立的服务方法，而不是在Controller里随手updateById改个字段。原因很简单——状态变更必须伴随流水记录和校验，散落在Controller里容易漏。

举个例子，出库操作的核心逻辑：

@Transactional(rollbackFor = Exception.class) public void outbound(StockOutboundDto dto) { CollectionItem item = collectionMapper.selectById(dto.getCollectionId()); if (item == null) { throw new BizException("藏品不存在"); } if (!"在库".equals(item.getStatus())) { throw new BizException("只有状态为在库的藏品才能出库"); } // 更新主表状态 item.setStatus("出库"); item.setLocation(dto.getTargetLocation()); collectionMapper.updateById(item); // 插入流转记录 StockFlowRecord record = new StockFlowRecord(); record.setCollectionId(item.getId()); record.setOperationType("出库"); record.setBeforeStatus("在库"); record.setAfterStatus("出库"); record.setOperator(dto.getOperator()); record.setRemark(dto.getRemark()); stockFlowRecordMapper.insert(record); }

@Transactional是必须的，因为状态更新和流水记录插入要保证要么都成功要么都失败。如果这两步只成功一半，数据库里的状态历史和实际状态对不上，后面查账全是乱。这个方法在真正现场调试里帮我省了不少事。

4.4 图片上传与静态资源映射

藏品档案里图片是刚需，而且一个藏品往往有多张图。我的处理方式比较简化：前端用Element Plus的上传组件把图片传到后端的/api/file/upload接口，后端把文件保存到服务器指定目录，路径存进数据库。多图则用逗号分隔存在photo_url字段里，前端再按逗号split出来预览。

上传接口关键点是校验文件类型和大小。我只允许jpg、png、webp，单文件不超过5MB。存文件时用UUID重命名，防止重名覆盖，也防止文件名里的中文在跨平台时乱码。

静态资源映射在SpringBoot2里需要加一个配置类：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceHandler(ResourceUtils.FILE_URL_PROTOCOL + uploadPath + "/"); }

不然前端页面能访问接口但访问不到图片，这种“接口通了图片裂了”的坑，我猜不少人遇到过。

5. Vue3前端实现：从Composition API到Element Plus页面

前端部分占据了整个项目的半壁江山。后台管理的核心页面是藏品列表、藏品表单、流转记录、分类树、统计看板。这里我重点说几个实操中容易出错或值得优化的地方。

5.1 项目初始化和目录组织

前端我用的Vite创建Vue3项目，目录结构按功能模块组织：

• views/collection：藏品档案相关页面
• views/flow：出入库/借展流转页面
• views/category：分类管理页面
• views/dashboard：统计看板
• api/：接口请求封装
• layout/：后台布局

路由用Vue Router，布局用侧边栏菜单加顶栏，菜单项就是前文说到的权限模块配置的。整个布局代码不算多，但Element Plus的el-menu组件要配成动态渲染，根据用户角色返回的菜单数组循环生成。

5.2 藏品列表页的搜索、分页与状态标签

藏品列表页是全系统使用频率最高的页面，设计上我做了三个细节：

• 搜索区用折叠面板收纳，默认展示藏品编号、名称、分类、状态四个主查询条件，其他条件点到“高级搜索”再展开。
• 表格里状态字段用el-tag渲染，不同状态不同颜色，在库绿色、出库橙色、借展中蓝色、修复中红色，视觉上扫一眼就知道哪些藏品是被借走的。
• 分页组件必须和后端Page对象对接好，传current和size，拿回total和records。

这里有个经验：列表页的查询条件如果有多种组合，强烈建议把查询参数做成响应式对象，搜索、重置、分页变化都操作同一个对象，避免各写一套导致查询条件丢失。

const queryParams = reactive({ current: 1, size: 10, name: '', categoryId: null, status: '' }) const loadList = async () => { const res = await getCollectionList(queryParams) tableData.value = res.data.records total.value = res.data.total }

为什么推荐用reactive而不是多处ref？因为查询条件字段多，用reactive可以让它们作为一个整体被管理，逻辑更聚合，也减少模板里queryParams.name这类写法的额外复杂度。

5.3 Axios拦截器与后端联调

联调阶段最容易出问题的是请求封装不统一。我封装了一个Axios实例，统一设置baseURL、请求头、超时时间，响应拦截器里统一处理code：

service.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { ElMessage.error(error.message || '网络异常') return Promise.reject(error) } )

这样做的好处是前端业务代码里只需写const data = await getList(params)，不需要每次判断成功失败，弹错误提示也统一了。看板页和列表页共用一个封装的体验，比每个页面写一遍try-catch舒服太多。

5.4 跨域问题与Vite代理配置

前后端分离开发时，跨域是必踩的坑。Vue3项目里有两个解决方式：第一是后端加@CrossOrigin或者全局CORS配置，第二是前端Vite配置代理。开发环境我建议第二种，因为它不改后端代码，生产环境用Nginx反向代理也可以参考同一思路。

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

后端接口统一以/api开头，前端所有请求都走/api相对路径，这样Vite代理就能把请求转发到后端服务，浏览器看到的始终是同源请求，开发阶段完全不用处理CORS头。等到上线部署，Nginx里也配一条location /api { proxy_pass http://后端地址; }，逻辑一模一样。

5.5 图片预览与表单校验细节

藏品表单的字段很多，校验主要分三类：必填、格式、业务约束。藏品编号必填且不能跟已有编号重复，这个唯一性校验我前端的做法是“失焦时调后端接口查一次”，后端用count计数判断，返回存在则提示。名称和尺寸必填。年代和质地这两项我用下拉选择器，数据从字典表来，既减少打字又避免脏数据。

图片上传预览那块我用了Element Plus的el-upload配合el-image，el-upload里用http-request覆盖默认上传行为，手动调后端文件上传接口，拿到返回的URL后存入表单的photoUrlList数组。表单提交时把数组转成逗号分隔字符串，编辑回显时再拆回数组。前端虽然少用了一个现成组件能力，但可控性高很多，出错也好定位。

6. MySQL8.0环境搭建与初始化

数据库装不上或者连不上，往往是项目启动时最让人火大的问题。这块我讲讲实际操作中的两种方式和注意事项。

6.1 本机安装还是Docker安装

对于馆藏系统这类中小型项目，我个人推荐直接用Docker跑MySQL8.0。原因很简单：本机安装要下载安装包、处理依赖、改配置、设置服务开机自启，不同系统步骤还不一样；Docker一条命令就能拉镜像、跑容器、做端口映射，开发环境和生产环境的表现一致。

Docker跑MySQL8.0的命令：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ -e TZ=Asia/Shanghai \ -v /data/mysql8/conf:/etc/mysql/conf.d \ -v /data/mysql8/data:/var/lib/mysql \ mysql:8.0

这里有几个关键点：

• -e TZ=Asia/Shanghai时区必须设置，否则MySQL默认UTC时间，数据库里存的create_time和本地时间差8小时，日志排查会被搞得一头雾水。
• 数据目录挂载出来，容器删了数据不丢。
• 如果服务器内存紧张，初始化后可以调整buffer_pool_size，在挂载的配置文件里加一行innodb_buffer_pool_size = 256M。

6.2 初始化SQL的编写和执行

表结构建好后，需要准备一份初始化SQL。我习惯在建表语句里把所有字段注释都写清楚，以后接手的人看建表语句就知道每列什么意思，不用翻代码。同时连同必要的字典数据、默认管理员账号一起初始化。

执行初始化SQL建议直接用命令行工具，避免可视化工具的坑：

mysql -h127.0.0.1 -uroot -p123456 < init_db.sql

6.3 连接串和驱动版本细节

SpringBoot2.7.6搭配MySQL8.0，驱动坐标要注意不能用旧版的com.mysql.jdbc.Driver，而是用com.mysql.cj.jdbc.Driver。依赖坐标：

<dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <version>8.0.33</version> </dependency>

连接串加上几个重要参数：

spring.datasource.url=jdbc:mysql://localhost:3306/museum?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true spring.datasource.username=root spring.datasource.password=123456 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

allowPublicKeyRetrieval=true这个参数很关键，MySQL8.0默认认证插件有时会导致连接报错“Public Key Retrieval is not allowed”，加上它一般就能解决。useSSL=false则是开发环境关掉SSL握手，减少不必要的开销。

7. 部署上线阶段的操作与问题排查

前面所有开发工作的最终目标是让系统能稳定跑起来。部署阶段我整理几个经验点。

7.1 前后端分离部署结构和打包要点

后端是SpringBoot项目，直接mvn package打成Jar包，服务器上java -jar museum-system.jar启动。前端Vue3项目npm run build生成dist目录，把静态文件放到Nginx的web目录，配置一个反向代理把接口请求转到后端端口。

Nginx的关键配置片段：

server { listen 80; server_name museum.example.com; location / { root /opt/dist; index index.html; try_files $uri $uri/ /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; } }

try_files那行是Vue3路由History模式必需的，否则你直接访问/collection/list这样的地址会返回404。

7.2 文件上传大小限制的坑

如果文物照片比较多、单张比较大，部署后可能出现“文件上传失败”或“图片加载不出来”的情况。这是因为SpringBoot的默认上传大小限制是1MB，需要在配置里调大：

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

同时Nginx端也可能默认限制了客户端请求体大小，要在http或server块里加上：

client_max_body_size 20m;

我见过太多人本地开发好好的，部署到服务器后图片一上传就失败，查半天发现是Nginx默认1MB限制在作怪。这个坑值得单独记一笔。

7.3 上线前的数据库备份与恢复策略

馆藏数据属于不可再生资源，备份必须认真对待。我建议至少每天做一次逻辑备份，保留最近7天；每周再做一次物理备份归档。

MySQL8.0逻辑备份命令：

mysqldump -uroot -p123456 museum > /backup/museum_$(date +%Y%m%d).sql

恢复时用：

mysql -uroot -p123456 museum < /backup/museum_20240801.sql

恢复前要确认目标库是空的，或者用--force让它跳过重复表，否则容易报错。

8. 系统文档与后续扩展的思考

项目交付时，除了源码还配了一套文档，包括需求说明、数据库设计文档、接口文档、部署手册。这里说几个我觉得比较值得做好的点。

8.1 接口文档怎么沉淀

这套系统的接口数量目前大概五十个左右，不算特别多，但如果没有一个统一出口，后期加需求很容易前后端对不上。我选择用Swagger/OpenAPI的自动生成方案，加上必要的中文注释，前端同事看接口文档的时候一目了然。

要注意的是，Controller里的参数对象建议用DTO而不是直接用Entity接收。比如出库操作只允许传藏品ID、目标位置、备注、经办人四个字段，如果用Entity接收，前端传个status字段也能直接改掉状态变成非正常的流转路径，非常危险。接口文档里把DTO字段约束写明，前后端协作效率会高不少。

8.2 这套系统的扩展方向

做完当前这版馆藏核心功能后，这套架构还有几个很自然的扩展方向。一个是增加二维码/条码标签打印功能，库房管理员给每件藏品打印一张带编号的标签，扫码就能查询藏品信息和状态，能大幅提升日常盘点效率。另一个是对接Nacos配置中心或更多微服务化改造，但对这类体量的馆藏系统来说不是最优先事项。

我个人认为最有价值的是“盘点模块”和“藏品修复档案管理”的扩展。盘点模块可以做成周期性盘点任务，操作员按库房或柜位批量核对藏品是否在位，盘点结果自动对比主表数据生成差异报告。修复档案则可以记录每次修复的日期、修复单位、修复方案、修复前后对比照片，形成一件藏品的完整履历，这在馆藏业务里是很有分量的功能。

8.3 实际维护中的几条建议

最后分享几条我做这套系统后沉淀下来的维护经验。

第一，馆藏系统的字段状态变化一定要优先走独立服务方法，不要在Controller里直接改字段。因为状态一变，往往意味着要有流水、要有审批、要有消息通知，散落在Controller里次数多了，总有一处漏掉。

第二，前端列表页的查询条件封装成统一对象后，后续加字段成本变得很低。现在想加“按完残程度筛选”就只需在查询对象里加一个属性，加上表单项和后端Wrapper拼接逻辑，十分钟就能搞定。这就是“结构习惯”带来的收益。

第三，文档不要等全部写完再补。我这次是边开发边把数据库设计说明和接口变更记在文档里，虽然一开始麻烦一点，但最后交付时几乎不用额外花时间整理，而且文档和实际代码是一致的。等项目收尾再凭记忆补文档，大概率会漏掉很多细节。

我做这套系统最大的感受是，技术本身没有太多炫技的地方，真正的价值在于把馆藏业务里的状态流转、档案关联和操作留痕想清楚，然后用一套不高不低、认真维护起来不费劲的技术栈把它扎实落地。如果你也正在规划类似的馆藏或资产管理系统，希望这篇内容里的选型理由、表结构设计和踩坑记录能帮你少走几步弯路。