1. 先说说这套系统要解决的现实问题网上标注“Java Web线上历史馆藏系统源码”的项目并不少但很多就是对着视频教程敲了一遍增删改查真拿去给博物馆、纪念馆、文化馆用根本接不住业务。这次这套系统的情况不太一样需求方是一个地方文化单位库房里有两万多件藏品之前全靠Excel管每个人手里的表格式都不一样编号有的叫“藏字2019-012”有的叫“ZT-012”甚至同一件藏品在不同表格里录入的尺寸单位都不统一。平时查一件东西在哪个库房、什么状态、借给谁了翻表要翻半天。这套系统原本的目标很朴素把两万多件藏品的档案、状态、流转记录全部搬上线做到一次录入、随时可查、操作留痕。我最后选择了SpringBoot2 Vue3 MyBatis-Plus MySQL8.0这套技术栈不是说这套组合多“新”而是它恰好能把这类中小型业务系统的开发效率和后期维护成本做到一个比较舒服的平衡。如果你正准备做类似的馆藏管理、资产管理系统或者单纯想看一套SpringBoot2Vue3前后端分离项目是怎么从零落地的这篇内容会比较对路。我会把选型思路、数据库设计、后端接口实现、前端页面联调以及部署时踩过的坑都过一遍尽量做到你拿着这套逻辑可以复刻出自己的版本。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是核心。关键字段我列一下字段名类型说明idbigint主键自增collection_novarchar(50)藏品编号唯一索引namevarchar(200)藏品名称category_idbigint分类ID关联分类表dynastyvarchar(100)年代/朝代materialvarchar(100)质地size_descvarchar(200)尺寸描述weightdecimal(10,2)重量单位克levelvarchar(20)级别一级/二级/三级/未定级completionvarchar(50)完残程度statusvarchar(20)当前状态在库/出库/修复中/借展中locationvarchar(100)存放柜位/位置photo_urlvarchar(500)藏品照片地址descriptiontext藏品描述create_timedatetime创建时间update_timedatetime更新时间分类表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的窗口函数。我写过一条比较典型的SQLSELECT 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 ApiResultT { private Integer code; private String message; private T data; public static T ApiResultT success(T data) { ApiResultT result new ApiResult(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ApiResultT error(Integer code, String message) { ApiResultT 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拼装条件LambdaQueryWrapperCollectionItem 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、请求头、超时时间响应拦截器里统一处理codeservice.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-imageel-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_PASSWORD123456 \ -e TZAsia/Shanghai \ -v /data/mysql8/conf:/etc/mysql/conf.d \ -v /data/mysql8/data:/var/lib/mysql \ mysql:8.0这里有几个关键点-e TZAsia/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.sql6.3 连接串和驱动版本细节SpringBoot2.7.6搭配MySQL8.0驱动坐标要注意不能用旧版的com.mysql.jdbc.Driver而是用com.mysql.cj.jdbc.Driver。依赖坐标dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency连接串加上几个重要参数spring.datasource.urljdbc:mysql://localhost:3306/museum?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue spring.datasource.usernameroot spring.datasource.password123456 spring.datasource.driver-class-namecom.mysql.cj.jdbc.DriverallowPublicKeyRetrievaltrue这个参数很关键MySQL8.0默认认证插件有时会导致连接报错“Public Key Retrieval is not allowed”加上它一般就能解决。useSSLfalse则是开发环境关掉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-size10MB spring.servlet.multipart.max-request-size20MB同时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拼接逻辑十分钟就能搞定。这就是“结构习惯”带来的收益。第三文档不要等全部写完再补。我这次是边开发边把数据库设计说明和接口变更记在文档里虽然一开始麻烦一点但最后交付时几乎不用额外花时间整理而且文档和实际代码是一致的。等项目收尾再凭记忆补文档大概率会漏掉很多细节。我做这套系统最大的感受是技术本身没有太多炫技的地方真正的价值在于把馆藏业务里的状态流转、档案关联和操作留痕想清楚然后用一套不高不低、认真维护起来不费劲的技术栈把它扎实落地。如果你也正在规划类似的馆藏或资产管理系统希望这篇内容里的选型理由、表结构设计和踩坑记录能帮你少走几步弯路。