企业官网建设流程全解析

前阵子帮一家地方文化馆做了一套历史馆藏系统，从需求确认、数据库设计到最终部署上线，前后大概折腾了一个多月。这套东西在网上经常看到“历史馆藏系统【关注就送源码】”之类的标题，点进去要么是残缺的半成品，要么源码拿到手根本跑不起来。今天不聊那些虚的，直接把整套系统的设计思路、核心表结构、关键功能实现和踩坑过程摊开讲，给准备做类似系统的同学一个能直接参考的完整方案。

历史馆藏系统，说白了就是把馆藏文物、文献、档案这些历史资料从Excel表格和纸质台账里解放出来，统一数字化管理。它要解决的核心问题有三个：藏品信息集中管理、出入库流程可控可追溯、查询统计又快又准。这套系统做出来之后，馆里工作人员录入一件藏品只要几分钟，盘点时按库房和柜架筛选就能快速定位，借调外展也有完整的流转记录。对于计算机专业的学生来说，这又是一个非常适合拿来练手和做毕业设计的业务系统，业务逻辑清晰、功能模块完整、技术栈选择自由。

1. 历史馆藏系统到底要解决什么问题

1.1 馆藏管理的真实业务场景

我在对接需求之前，先跟着馆里的老师走了一圈库房。你以为的馆藏管理是“文物往架子上一摆就完事”，实际完全不是这样。

一件藏品从进馆开始，要登记基本信息（名称、年代、质地、尺寸、来源）、拍照片、定级别、分库房、放柜架、写入库单。日常还要做定期盘查、状态变更（比如从库房调到展厅、借给其他馆展览、送去修复）、修复记录归档、影像资料存档。这些事原来怎么干的？全在Excel里。分了好几个工作簿，一个管藏品信息，一个管出入库登记，一个管修复台账，数据之间没有关联，经常出现库里显示在库、实物其实在展厅的情况。

历史馆藏系统的第一目标，就是把这张“信息网”织起来。一件藏品只有一个唯一的编目号，所有跟它相关的操作都挂在这个编号下面。谁录入的、什么时候录的、状态是库藏还是外借、去过哪些地方、做过几次修复，全部可查。这就解决了纸质台账和Excel表格最大的痛点——信息孤岛和数据不一致。

1.2 为什么Excel不够用

很多小馆会反问：就几百件藏品，Excel不是挺好用的吗？这话得分情况看。藏品数量少、只有一个人管、流程也简单的时候，Excel确实够用。但一旦涉及多人协作和流程审批，Excel的毛病就全出来了。

多人同时编辑一份表格，很容易互相覆盖。馆里管理员给文物改了个存放位置，库管员那边打开的旧文件还在，一保存就把新数据覆盖了。另外一个问题是权限没法精细控制，编目员应该只能录入藏品信息，不能随便改出入库记录，Excel做不到这种粒度。再就是检索和统计，几百条数据还好，几千条的时候筛选起来越来越卡，想按年代、级别、材质三个条件交叉统计，公式写得头大。

这套系统上线后，这些痛点基本一扫而空。多人并发操作各看各的权限，数据实时统一，统计报表几秒钟就出结果。再加上操作日志功能，谁在什么时候改了什么字段都有记录，管理上有了抓手。这就是为什么我用Spring Boot加MySQL来做这套系统，而不是继续在Excel上打补丁。

1.3 系统模块设计与技术选型

系统拆了六大模块：藏品档案、库房位置、出入库管理、修复登记、检索统计、系统管理。每个模块再往下分，比如藏品档案包括新增、编辑、详情、图片上传、批量导入导出；出入库管理包括出库单、入库单、借调记录、在途状态跟踪；系统管理包括用户、角色、权限、操作日志。

技术选型上，后端我用的是Spring Boot加MyBatis，前端用Vue加Element UI，数据库MySQL 8.0，身份认证用JWT。为什么这么选？Spring Boot是目前中小型管理系统的主流选择，生态成熟、资料多，不管自己写还是拿给别人维护都方便。MyBatis做动态SQL很灵活，检索条件多的时候比JPA好控SQL。Vue加Element UI做后台管理界面，组件现成，表格、表单、弹窗、树形控件都有，开发效率高。这里多说一句，如果是放在内网运行的馆藏系统，用JSP加Bootstrap也不是不行，只是Vue的维护体验明显更好，组件化开发后期加功能轻松很多。

2. 数据库设计：把馆藏信息“建模建稳”

2.1 藏品主表：字段设计的关键取舍

藏品主表是一张核心表，几乎所有模块都围绕它转。我设计的表结构里，最重要的几个字段是藏品编号、名称、分类ID、年代、质地、级别、来源、当前状态、库房位置ID、入库时间、录入人、数量、尺寸重量、描述。

藏品编号是整个系统的业务主键，格式建议统一，比如“藏字+年份+流水号”，像“GZ-2024-0001”。这个编号印在实物标签上，也用在系统里做关联，所以一旦生成不允许修改。我自己在表里还单独设了一个自增ID做主键，藏品编号另加唯一索引，这样既保证磁盘存储和性能，又保证业务编号不重复。

级别字段也别用简单字符串，用字典表或者枚举。一般文物分一级、二级、三级和未定级，用数值存（1/2/3/0），查询筛选更快，前端展示的时候再做映射。质地也一样，金属、陶瓷、纸质、木质、织繡这些，分类用代码存，不要把中文到处写。

下面是我简化后的建表语句，实际项目在此基础上加了更多业务字段，比如完残状况、保存环境要求、是否孤品等：

CREATE TABLE cangpin ( id BIGINT AUTO_INCREMENT PRIMARY KEY, cangpin_code VARCHAR(50) NOT NULL COMMENT '藏品编号', name VARCHAR(200) NOT NULL COMMENT '藏品名称', category_id BIGINT COMMENT '分类ID', dynasty VARCHAR(50) COMMENT '年代/朝代', material VARCHAR(50) COMMENT '质地', level TINYINT COMMENT '级别 0未定级 1一级 2二级 3三级', source VARCHAR(200) COMMENT '来源', status TINYINT DEFAULT 0 COMMENT '状态 0在库 1出库 2外借 3修复 4注销', location_id BIGINT COMMENT '库房位置ID', entry_date DATE COMMENT '入库日期', entry_user VARCHAR(50) COMMENT '录入人', quantity INT DEFAULT 1 COMMENT '数量', size_desc VARCHAR(200) COMMENT '尺寸重量描述', description TEXT COMMENT '藏品描述', version INT DEFAULT 0 COMMENT '乐观锁版本号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_cangpin_code (cangpin_code) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='藏品信息表';

2.2 状态流转表：改状态不能只改一个字段

很多初学者做状态管理，就在藏品表里直接UPDATE一个status字段，从0改成1，完事了。这样做问题很大，因为“谁在什么时候把藏品从库房调到了展厅”这个历史信息就丢了，审批流程也没法追溯。

我的做法是单独建一张出入库记录表，也就是状态流转表，每次状态变化都插入一条完整记录。表里字段包括：藏品ID、操作类型（入库/出库/借出/归还/移库）、变更前状态、变更后状态、经办人、审批人、目的地/接收单位、预计归还日期、实际归还日期、备注。

配合藏品表里的当前状态字段，查询当前在库情况走主表，追踪历史轨迹查流转表，互不干扰，用起来非常顺手。比如有馆领导问“去年那批借给外地博物馆的展品还回来没有”，一条SQL按藏品编号过滤流转表，曾经借出的记录一目了然。

这里有个细节：出库单和入库单建议各建一张单据主表，记录单据编号、经办人、日期、审批状态，然后单据明细表关联藏品。借调场景更复杂一些，出库时填写接收单位和预计归还日期，归还时登记实际归还日期和归还时状况。不要图省事把所有情况都塞进一张表，后面统计报表会很难写。

2.3 分类、位置与多级联动

分类和位置都是典型的树形结构。分类可能是“书画”“陶瓷”“青铜器”“家具”这样的大类，大类下面还有二级分类；位置则是“东库房1-3排-左起第2格”这种层级关系。

我在数据库里用了邻接表设计，一张分类表一张位置表，都带parent_id字段指向父节点：

CREATE TABLE category ( id BIGINT AUTO_INCREMENT PRIMARY KEY, parent_id BIGINT DEFAULT 0 COMMENT '父分类ID 0为根', name VARCHAR(100) NOT NULL COMMENT '分类名称', sort INT DEFAULT 0 COMMENT '排序', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='藏品分类表';

位置表类似，只是多了库房、排、列、层等层级代号字段。前端用Element UI的Cascader级联选择器或者el-tree树形控件加载，后端提供两套接口，一套返回整棵树的嵌套结构，一套按父节点查子节点。数据量不大的时候直接返回嵌套结构更省事，递归组装好JSON一次性给前端。

多级联动还有个好处是盘点特别方便。选一个库房节点，所有这个库房下的藏品自动全部筛出来，不用再手工拼条件。做盘点单的时候，按库房范围生成盘点清单，逐件核对打钩，效率比按档案盒翻快得多。

2.4 修复与保护台账

文物修复这类业务在普通进销存系统里没有，但馆藏系统必须有。它和出入库记录不同，修复不是简单的“换位置”，而是涉及保护行为的过程记录，包括修复日期、修复类型、经办人/修复单位、修复前状况、修复后状况、使用材料、费用。

我当时建了一张repair_record表，关联藏品ID。每次修复完成录入。后期做统计的时候可以按年份、修复类型、修复单位汇总，馆里申报保护经费时直接拉数据出来用，非常省事。

这里有个实际操作经验：修复前务必让修复人员在系统里传修复前后的对比照片，路径存在数据库里，文件存到服务器文件目录。照片是修复工作的重要凭证，后面做项目验收或者写工作报告时需要用到，到时候再补拍就来不及了。

3. 核心功能实操：从检索到文件管理

3.1 多条件组合检索的实现思路

馆藏系统最常用的功能就是检索。工作人员经常会按某个条件组合查藏品，比如“一级文物、陶瓷类、宋代”“纸质类、清朝、保存状况差需要关注的”。用MyBatis写动态SQL，根据前端传过来的条件动态拼接查询语句。

这里有几个容易踩的坑。第一个是模糊查询别用LIKE '%关键字%'扫全表，藏品编号或者名称前缀匹配用LIKE '关键字%'可以走索引，模糊匹配字段多的时候要考虑用全文索引。第二个是注意参数判空，尤其是年代、级别、材质这些可选项，前端没传就不能拼进SQL。第三个是分页，我用的PageHelper插件，传页码和每页条数就行，不用手写LIMIT。

示例代码如下，节奏很清晰：

<select id="searchCangpin" resultType="com.example.model.CangpinVO"> SELECT cp.*, c.name AS category_name, loc.full_path AS location_path FROM cangpin cp LEFT JOIN category c ON cp.category_id = c.id LEFT JOIN location loc ON cp.location_id = loc.id <where> <if test="keyword != null and keyword != ''"> AND (cp.name LIKE CONCAT('%', #{keyword}, '%') OR cp.cangpin_code LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="dynasty != null and dynasty != ''"> AND cp.dynasty = #{dynasty} </if> <if test="level != null"> AND cp.level = #{level} </if> <if test="material != null and material != ''"> AND cp.material = #{material} </if> <if test="status != null"> AND cp.status = #{status} </if> <if test="locationId != null"> AND (cp.location_id = #{locationId} OR cp.location_id IN (SELECT id FROM location WHERE parent_id = #{locationId})) </if> </where> ORDER BY cp.id DESC </select>

检索结果的列表页要支持导出Excel，这个功能我放在了列表查询接口同一层，查询条件共用一套逻辑，返回List后直接写入Excel。后端分页查询和导出共用同一套动态SQL，保证了“你看到的列表就是导出的数据”，不会出现两边条件不一致的问题。

3.2 批量导入Excel的正确姿势

实际录入过程中，肯定有不少老台账数据要一次性导入，这个功能太关键了。

我用的是EasyExcel（阿里开源的Excel处理库），对比传统Apache POI，EasyExcel内存占用小，大文件处理更快，API也更友好。导入流程分三步走，每步都不能省。

第一步，下载模板。系统提供一个Excel模板，字段和系统里的录入表单一一对应，包括藏品编号、名称、年代、级别、材质、来源、尺寸等。模板里设好下拉框，比如级别列只能选一级、二级、三级、未定级，这种预校验能极大减少后续错误。

第二步，上传校验。用户上传Excel，后台逐行读取并校验数据。校验规则很多，比如编号不能重复、名称不能为空、级别必须在枚举范围内、日期格式必须正确。校验不通过就收集错误信息，格式是“第X行：藏品名称为空；第X行：级别格式不合法”，最后返回给前端展示。一次性导入几千行的时候，这个功能能帮工作人员省下大量改数据的时间。

第三步，事务导入。所有数据校验全部通过后，开启事务批量插入。插入过程中如果遇到数据库异常，比如唯一键冲突，整个事务回滚，一条数据都不会插进去，保证数据一致性。批量插入用MyBatis的批量执行，不要一行一行insert，几千条数据秒级完成。

下面是一段核心的校验逻辑，按行遍历：

for (int i = 0; i < rows.size(); i++) { CangpinExcelDTO row = rows.get(i); List<String> rowErrors = new ArrayList<>(); if (StringUtils.isBlank(row.getCangpinCode())) { rowErrors.add("藏品编号不能为空"); } if (StringUtils.isBlank(row.getName())) { rowErrors.add("藏品名称不能为空"); } if (isDuplicateCode(row.getCangpinCode())) { rowErrors.add("藏品编号在系统中已存在"); } if (!rowErrors.isEmpty()) { errors.add("第" + (i + 2) + "行：" + String.join("；", rowErrors)); } }

3.3 图片与PDF等数字资源的存储方案

藏品照片、鉴定证书扫描件、修复前后对比图、视频影像，这些数字资源在馆藏系统里很常见。存储方案我建议遵循一条原则：数据库存路径或URL，文件本体放文件系统或对象存储。

为什么不能把图片直接转成Base64塞进数据库？数据库体积会迅速膨胀，备份恢复慢，查询性能也会受影响。正确做法是在服务器上建一个upload目录，按日期分子目录，文件名用UUID加原始扩展名重命名，避免重名。数据库里存相对路径，比如/upload/2024/06/ab12cd34.jpg。

如果是公网部署、图片访问量大，可以考虑用阿里云OSS或者腾讯云COS，文件传上去之后拿URL存数据库。内网系统部署，本地NAS或服务器磁盘更实在，还省流量费。

图片上传之后还有一个细节：生成缩略图。列表页不需要加载原图，不然一次展示20个藏品，每个图片2MB，页面会卡到爆。我用Thumbnailator库在服务端生成宽200像素的缩略图，列表页展示缩略图，点击弹窗放大看原图，这样响应速度快很多。

后端设置静态资源映射也很关键，Spring Boot默认只映射/static/**，像我这里自定义的upload路径要手动加配置：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + fileUploadPath); } }

这一步不配置，前端<img src="/upload/xxx.jpg">永远显示不出来，而且不报错只显示裂图，排查起来很费时间。

3.4 权限控制与操作日志

馆藏系统涉及单位内部管理，权限控制不能太随便。我用了经典的RBAC模型，三张核心表：用户表、角色表、用户角色关联表，如果再细化菜单按钮权限再加角色菜单关联表。

角色分四类比较合理：系统管理员管账号和配置；编目员负责藏品信息的录入、编辑和图片上传；库管员负责出入库操作和盘点；普通用户只读，可以查藏品、看统计报表。每个角色的菜单和按钮权限都不一样，前端根据接口返回的权限列表渲染可用菜单，后端接口再用拦截器做二次校验。

权限之外，操作日志是对账的底气。我用Spring AOP做了一个切面，拦截所有带@Log注解的Controller方法，自动记录操作人、操作时间、操作类型（新增、修改、删除、导出等）、请求参数、IP地址。比如有人把一件藏品的级别从二级改成了三级，日志里能查到是哪个账号在什么时间改的，之前的值和之后的值都记录清楚。这个功能对馆方管理者来说价值很大，出了问题能定位责任人。

操作日志表结构比较简单，就是常规的日志表字段。但要注意一点，记录参数时不能把文件上传的二进制内容记进去，否则日志表会被撑爆，我一般只记录文件路径和文件名。

4. 开发过程中的踩坑复盘

4.1 项目搭建与工期安排

这套系统从零开始，一个人开发的话大概需要一个半月左右。我实际排期供参考：第一周做需求梳理和数据库设计，第二周做项目骨架、登录认证和系统管理模块，第三到第四周做藏品档案模块和检索统计，第五周做出入库和修复台账，最后一周做导入导出、优化和部署。

搭建骨架阶段重点把事情做扎实：统一返回结果类、统一异常处理、全局跨域配置、JWT登录拦截。这些基础工作做完，后面写业务接口就是体力活。不少新手一上来就写业务代码，写到后面发现返回格式不统一、异常没法统一处理，返工成本很高。

另外说一句源码管理，全程用Git版本控制，每天提交一次。导出Excel的功能写崩了，一条git checkout就能回到上个可用版本，这是给自己留的后路。

4.2 5个典型问题与解决方案

第一个是中文乱码。现象是前端传过来的中文在数据库里变成问号，或者页面显示乱码。排查下来是三个地方的问题：数据库连接串没加characterEncoding=utf8，MySQL表默认排序规则不是utf8mb4，前端请求头没带Content-Type: application/json;charset=UTF-8。三处都修正后乱码彻底解决。

第二个是EasyExcel时间字段解析问题。Excel里的时间的格式多种多样，有的单元格是“2024-06-01”，有的是“2024年6月1日”，有的干脆存的是Excel序列号。这个坑比较隐蔽，因为模板是系统里下的，用户为了省事自己手打了一遍，格式就变了。我的解决办法是自定义转换器，读取时先判断单元格类型，数字类型先转成日期，字符串类型再尝试多种日期格式解析，解析失败就报错提示用户检查格式。

第三个是图片上传后访问404。这个前面提过，静态资源映射没配置，请求/upload/xx.jpg直接打到DispatcherServlet，找不到Controller就404。配置好WebMvcConfigurer之后恢复。还有一个间接原因是操作系统权限，Linux服务器上文件写入目录没有写权限，上传接口报IOException，这个排查很久才想明白，直接把目录按755权限设好。

第四个是检索卡顿。藏品数据到两万条左右，不带条件的列表查询越来越慢。分析执行计划发现是分类表关联查询走了全表扫描，还有ORDER BY id DESC没有利用索引。优化思路是给外键字段加索引、分页打深的时候用游标分页代替OFFSET分页、避免SELECT *只查需要的字段。优化完查询时间从1.8秒降到了200毫秒以内。

第五个是并发更新冲突。两个管理员同时操作同一件藏品，A把位置改成东库房1排3格，B同时把状态改成修复中，后提交的覆盖了先提交的，A的修改丢失。解决方案是加乐观锁，在cangpin表加了version字段，更新SQL里带上WHERE version = #{oldVersion}，执行结果返回0就说明被并发修改了，提示用户重新加载数据再提交。

4.3 常见问题速查表

整理一下开发中容易被遗漏的排查项，做成表格方便对照：

5. 往远处想：这套系统还能怎么扩展

5.1 对接RFID盘点

库房盘点一直是馆藏管理的痛点。传统盘点是打印纸质清单，拿手电筒一件一件找实物打钩，工作量大还容易错。现在很多馆在推RFID方案，给每件藏品贴RFID标签，手持盘点机在库房走一圈就能扫描读取标签信息，自动和系统里的在库清单比对。

做这套系统的时候，我把盘点模块的接口预留出来了，包括盘点单创建、盘点结果导入、盘盈盘亏报表。如果后续要接RFID，核心就是写一个数据对接接口，把盘点机读到的标签编码批量上传到系统，然后系统自动比对数据库中该库房应有藏品和盘点结果，差异自动生成待核查清单。这里建议RFID标签编码直接用藏品编号，不要额外建关联表，省去一层映射关系，后续维护成本低很多。

5.2 数据可视化大屏

馆方领导很关注的一个点是整体情况，比如现藏总量多少件、一级文物多少件、季度新增多少件、各分类占比情况、最近出入库记录。这些信息用文字表格展示不如大屏直观。

我做过一版统计聚合接口，按分类统计藏品数量、按级别统计数量、按月统计新增趋势、最近30天出入库动态，后端一条接口返回聚合数据，前端用ECharts渲染柱状图、饼图和滚动列表。部署的时候找一个竖屏电视，或者干脆用一块平板挂在走廊里，数据自动刷新。这套大屏方案成本低、见效快，而且不影响主系统功能。

5.3 多馆协同与数据交换

如果后面要多个文化馆之间共享展览信息，或者向上级单位上报数据，就需要考虑接口对接。我的建议是单独做一个开放API模块，把数据同步字段固定下来，提供按时间增量查询接口，其他系统通过AppKey调用。比如上级单位每月要辖区馆藏统计表，可以直接用API定时拉取，不用像以前那样手工收集表格。

在这个阶段重点做两件事：一是统一藏品编目字段规范，保证各个系统对“一级文物”“质地”这些定义一致；二是接口安全，签名校验、IP白名单、调用频次限制都要有。多馆协同的终极目标是搭建一个区域性馆藏资源共享平台，但我建议一步到位，先把单馆系统做扎实，再逐步开放互通。

做完整套历史馆藏系统，我最大的体会是：技术层面的难度其实不高，无非Spring Boot加MyBatis加Vue的常规组合，真正花时间的是把业务流程搞清楚，把数据模型设计好。网上那些“关注就送源码”的项目包我也看过，很多代码写得随意、表结构设计粗糙，跑起来容易但真要改动或者上线投入业务使用，问题一堆。如果你是拿来学习，建议拿到源码后照着本文的思路，亲手把表结构和核心流程梳理一遍，改造成适合自己的版本，这样学到的东西远比代码本身值钱。最后再分享一个小技巧：不管最终做成什么样，先把馆里现有的Excel数据清理干净、统一格式，再上线导入，这一步做好了，系统上线当天就会顺利得多。