从 Spring Boot 养老企业知识库这个题目入手前后花了两周多时间从需求梳理、数据库建模、功能开发到本地调试和部署整个过程完整跑了一遍。很多朋友看到“知识库”三个字第一反应是“这不就是个文档管理系统吗”实际动手做的时候才发现养老行业的知识体系有自己的特殊性——护理操作规范、应急预案、政策法规、培训教材、常见问题FAQ每类知识的生命周期和权限要求都不一样。这个系统真正要解决的不光是“文档放哪”的问题还有“谁能看、怎么找、怎么保证版本不混乱”的问题。如果你正准备做 Spring Boot 相关的毕业设计、课程设计或者想用一套完整项目练手这篇内容应该能帮你少走不少弯路。我会把项目拆分到每一张表、每一个核心接口、每一个坑按实际开发顺序讲清楚最后再聊聊论文和课程设计说明书怎么组织让这套项目既能跑得起来也能写得出来。1. 项目定位与整体设计思路1.1 养老企业的知识管理到底缺什么很多养老机构、养老服务公司发展到一定规模后面临的知识管理问题非常典型。护理部的操作规范散落在各个护工的微信聊天记录和Excel里行政部的政策文件更新了却没办法通知到每一个人培训部的课件每年都在翻新但老版本和新版本混在同一个共享文件夹里根本分不清。我接触过不少小型养老企业的实际场景所谓“知识库”在他们那里往往就是一个堆满文件的NAS或者百度网盘找一份《老年人跌倒应急预案》要翻半小时更别提审计的时候拿不出完整的版本记录。所以做这个项目之前先把需求边界理清楚它不是一个通用的企业网盘而是一个面向养老服务场景的知识管理系统核心要解决的是知识的分类组织、全文检索、版本追踪和权限控制。比如护理操作规范这类内容普通员工只能查看护理主管可以编辑部门总监负责审核发布而行政部上传的政策法规只能由行政专员维护。这种按角色划分的操作边界才是知识库系统区别于普通文件管理的关键。1.2 角色权限与功能矩阵怎么定养老企业知识库的用户角色我最后定成了四类系统管理员、内容管理员、部门审核员、普通员工。系统管理员负责用户和角色维护、系统参数配置内容管理员负责知识条目的新增、编辑、上传附件、打标签部门审核员负责内容的审核发布和下架普通员工只拥有查询、浏览、收藏和下载权限。功能矩阵围绕这些角色展开主要模块包括仪表盘统计、知识分类管理、知识条目管理、全文检索、附件上传预览、审核流、版本记录、浏览日志、用户权限管理。这里有一个很容易被忽视的点——审核流。很多课程设计做知识库就只做增删改查但真实的养老企业知识库必须有“草稿-待审核-已发布”的状态流转因为护理操作规范一旦写错是会出安全问题的。所以我在设计阶段就坚持把审核功能加进去这也让整个项目的复杂度更接近真实业务论文里也有东西可写。1.3 为什么选 Spring Boot 做底座技术选型这一步我直接选了 Spring Boot没有犹豫。理由很实际第一Spring Boot 的自动配置和 Starter 机制能让项目快速跑起来对课程设计和中小团队来说效率非常高第二生态成熟MyBatis Plus、Redis、MinIO 这些周边都能无缝集成遇到问题一搜就有答案第三招人和学习成本低大部分 Java 方向的读者对它都不陌生。和传统 SSM 相比Spring Boot 省去了大量 XML 配置内置 Tomcat打包直接用 java -jar 启动这对部署调试是巨大的便利。和若依这类快速开发平台相比纯手写 Spring Boot 项目反而更能讲清楚每一个实现细节论文里的“系统实现”章节也有实打实的内容可以写。所以我坚持“从零搭建 合理引入组件”的方式而不是直接套一个前后端分离脚手架。2. 技术选型与工程骨架搭建2.1 核心依赖与版本搭配我的版本组合是 Spring Boot 2.7.18 JDK 8 MySQL 8.0 MyBatis Plus 3.5.3 Redis 6.x MinIO 8.5.x。为什么不追新用 Spring Boot 3因为 3.x 要求 JDK 17Jakarta 命名空间变化很大很多老教程和老依赖不兼容对做课程设计的同学来说踩坑成本太高。Spring Boot 2.7 还在社区维护周期内稳定资料多足够覆盖这个项目的全部需求。pom.xml 里几个关键依赖值得说一下spring-boot-starter-web提供 MVC 和内置 Tomcat是所有 Web 接口的基础。mybatis-plus-boot-starter增强 MyBatis提供分页插件、条件构造器、代码生成器能省掉大量 XML Mapper 手写工作。mysql-connector-javaMySQL 驱动版本要和数据库一致我用的是 8.0.33。spring-boot-starter-data-redis用来缓存热点知识条目和管理用户会话后面检索优化也要用它。minioJava SDK负责附件上传下载的对象存储操作。spring-boot-starter-thymeleaf服务端渲染方案配合 Bootstrap 做管理后台界面简单直接不需要额外部署前端服务。lombok减少实体类的 getter/setter 样板代码但提醒一句有的团队不习惯 Lombok如果论文里要贴代码建议把关键实体类写成完整 JavaBean更规范。2.2 包结构拆解与分层职责我习惯把工程按功能模块分包而不是按三层架构粗暴地分成 controller/service/mapper 三个大包。这个项目的包结构大致如下com.eldercare.kms启动类和通用配置。configMyBatis Plus 分页配置、Redis 序列化配置、MinIO 客户端配置、WebMvc 拦截器配置。controller按业务模块拆分admin、knowledge、category、file、log、auth 等。service / service.impl业务逻辑层接口和实现分离这是论文里体现“面向接口编程”的地方。mapperMyBatis Plus 的 BaseMapper 子接口复杂 SQL 用注解或 XML。entity数据库实体类。dto接收前端参数的请求对象和返回视图的对象避免实体类直接暴露给前端。vo页面展示用的视图对象比如知识条目列表需要返回分类路径、创建人姓名、审核状态这些组合字段。utilsJWT 工具、文件类型判断、树形结构组装工具等。这里想强调一个实操经验DTO 和 VO 的拆分看似多余但对后续维护非常重要。我在开发初期偷懒直接用实体类接收前端参数结果审核功能需要同时接收“审核意见”和“知识条目 ID”这个字段在表里根本不存在被迫在实体类里加了一个TableField(exist false) 的临时字段虽然能跑但代码很丑。后期还是老老实实拆了 DTO 和 VO规范之后代码清爽多了。2.3 文件存储选型为什么引入 MinIO养老企业知识库里大量内容不是纯文本而是 PDF 的护理制度、PPT 的培训课件、Word 的操作手册。如果直接在数据库里存 BLOB查询性能会非常差数据库备份也会变得很大。常规做法是把文件放在服务器本地磁盘或云存储然后数据库只保存文件路径。这个项目我选了 MinIO原因是它部署简单、兼容 S3 协议社区活跃而且支持 Docker 一键启动。MinIO 的典型用法是文件上传时后端拿到 MultipartFile生成一个唯一的 objectName比如 2025/04/13/uuid.pdf调用 MinIO 客户端存入指定 bucket再把 objectName 存到数据库的 file 表。文件下载时可以通过 MinIO 生成一个带签名的临时 URL有效期设成 5 分钟前端拿到这个 URL 就能直接下载或预览而不需要后端把整个文件流读进内存再转发。这个设计对系统内存和带宽都很友好。2.4 开发环境准备清单跑这个项目需要的环境我列一下都是免费工具JDK 8我用的是 1.8.0_202不要用太高版本和 Spring Boot 2.7 是绝配。Maven 3.6配置阿里云镜像加速依赖下载。IDEA 2021 或 Eclipse建议 IDEA对 Spring Boot 支持最友好。MySQL 8.0本地装一个 Navicat 或 DataGrip 管理数据库。Redis 6.xWindows 下可以用微软移植版macOS 直接 brew install redis。Docker Desktop可选用于快速启动 MinIO 容器。Postman 或 Apifox测试接口用。环境这块最容易出问题的是 Maven 镜像和编译版本。有时候 pom 引入了依赖但下载不动卡在 Resolving dependencies十有八九是没配镜像。我习惯在 settings.xml 里做好镜像配置确保整个项目克隆下来之后在同学电脑上也能跑通这也是“调试部署”环节是否顺利的前提。3. 数据库设计与建模细节3.1 核心业务表怎么拆数据库是整个知识库系统的地基设计得好不好直接决定后面功能开发是事半功倍还是事倍功半。我建了 8 张核心表用户表、角色表、知识分类表、知识条目表、知识版本表、附件表、标签表、操作日志表。另外还有用户收藏表和知识标签关联表一共 10 张左右既不过度设计也能完整支持业务。知识条目表是最核心的一张字段包括知识 ID、标题、摘要、正文内容、分类 ID、标签字符串、知识类型政策法规/护理规范/应急预案/培训资料/FAQ、当前状态草稿/待审核/已发布/已下架、浏览量、创建人 ID、创建时间、审核人 ID、审核时间、审核意见、是否置顶、删除标记。设计的时候要注意把知识本身和知识版本分开知识表只保存当前最新的内容每次编辑发布都往版本表里写一条快照这样审计时能追溯历史。3.2 分类树与权限如何建模知识分类是典型的树形结构比如“护理管理”下面有“基础护理”“老年康复护理”“慢病管理”“安全管理”下面有“跌倒/坠床”“噎食”“走失”。分类表用 parent_id 实现父子关系再加一个 path 字段记录祖先链例如 /1/3/8这样查询某个分类下的所有子孙分类时可以直接用 LIKE path/%比递归逐层查快得多。权限方面我没有做特别复杂的 RBAC 表模型而是保持简洁用户表带一个 role_id 外键四个角色直接映射一套操作权限。知识条目表存 create_by 和 audit_by审核员只能看见“待审核”状态的内容普通员工只能看到“已发布”状态的内容。这样做的好处是实现简单、好讲清楚对中小型养老企业也完全够用。如果你想把权限做得更漂亮可以引入 Spring Security 动态权限但要注意这会显著增加项目时长需要权衡。3.3 索引设计、初始数据与建库脚本索引设计我是按实际查询场景来的。知识条目表上建了状态索引和分类索引标题和正文的检索用全文索引或前缀 LIKE操作日志表上建了操作类型和时间索引用户表上 user_name 建唯一索引。另外所有关联表的关联字段都建了普通索引避免表连接时产生全表扫描。初始化数据很重要直接决定演示效果。我往里灌了大约 30 条知识条目分布在各个分类下覆盖文档、PPT、图片等多种附件类型还有几个用户账号admin管理员、editor内容管理员、auditor审核员、staff普通员工。这样一打开系统就能看到分类树、统计图表和列表都有数据不会显得空。建库脚本里还要把删除标记字段默认值设成 0状态字段设成 1草稿这些默认值如果不提前设好插入数据时容易踩“字段为 NULL 导致业务逻辑出错”的坑。4. 核心功能实现要点4.1 多级目录树的递归组装分类树的接口实现分两步第一步查出该用户有权访问的分类列表第二步用递归算法组装成树形结构。我写了一个通用的 listToTree 工具函数输入是带 pid 的平铺列表输出是嵌套的树节点核心逻辑是遍历列表把每个节点挂到父节点的 children 集合中。这一步有两个常见的坑。第一是死循环风险如果数据里存在两条记录互相把对方设为父节点递归会无限进行所以递归方法必须设置最大深度或校验数据合法性。第二是内存效率如果分类有几千个节点频繁在循环里调用 list.contains 会非常慢我实践下来是先转成 MapLong, Node 再用指针方式组装效率能提升好几个数量级。组装好的树用 Redis 缓存一份分类变更时主动删除缓存这样左侧目录树的响应速度可以做到毫秒级。4.2 检索模块的取舍LIKE 与全文索引知识库的核心价值就是把知识“找出来”。我第一版用的是 MySQL 的 LIKE %关键词% 查询标题和正文一起模糊匹配。数据量只有几十条时没问题一旦数据量涨到几万条LIKE 的 %关键词% 写法会导致索引失效查询时间显著上升。升级方案是 MySQL 自带的全文索引配合 ngram 全文解析器支持中文分词。建全文索引的语句类似 FULLTEXT KEY ft_knowledge_title_content (title, content) WITH PARSER ngram。查询时用 MATCH(title, content) AGAINST(护理 IN NATURAL LANGUAGE MODE)需要注意的是全文索引对短词不友好两个字符以内的词在 ngram 配置下要设置 token_size2 才能命中。考虑到课程设计场景我不会一上来就推荐上 Elasticsearch那会增加部署和学习成本。MySQL 全文索引在这类中小规模系统里完全够用论文里讲清楚“为什么在小数据量场景选 MySQL 而不是 ES”反而是很好的加分项。如果以后数据真的膨胀了再把这层检索逻辑单独抽出来对接 ES 或 OpenSearch架构上也不会伤筋动骨。4.3 附件上传与 MinIO 集成附件上传走的是标准流程前端用 form 表单或 AJAX 上传后端用 MultipartFile 接收校验文件后缀名和大小然后写入 MinIO。我在 MinIO 里建了一个 kms-file 桶桶的访问策略设为私有后端生成带签名的访问 URL 给前端。这个细节很重要桶要是设成公开读任何人都能拿着链接访问到内部培训资料这在养老企业里属于隐私信息肯定是不可接受的。文件类型判断方面我写了一个工具类根据文件扩展名做白名单校验可接受类型包括 pdf、doc、docx、xls、xlsx、ppt、pptx、jpg、png、mp4 等。大小限制默认 50MB超过的直接抛异常。文件上传完成之后往 file 表插入一条记录关联当前知识条目的 ID 和版本号。需要注意的一点是文件上传和知识条目保存的事务边界我的做法是在知识条目保存成功后再调用文件上传如果上传失败数据库里的知识记录允许存在但附件缺失前端会显示“附件上传失败”的提示而不是把两步绑在同一个大事务里因为网络 IO 不适合放进数据库事务会长时间占用连接。4.4 文档审核与版本控制审核流是这个项目里最具业务价值的部分。内容管理员创建知识时状态是“草稿”提交审核后变成“待审核”部门审核员查看内容后可以选择“通过”或“驳回”。通过则状态变为“已发布”同时往版本表里插入一条完整的内容快照驳回则状态回到“草稿”并记录审核意见返回给内容管理员修改。版本表设计的时候我保留了 title、content、file_ids、audit_opinion、version_no、create_time 这些字段。每次发布version_no 递增。历史版本列表可以在详情页里查看支持对比但不允许直接删除这是知识库审计的硬性要求。实际开发时还要注意版本快照里存 file_ids 时不能只存一个孤立的 ID 字符串我在 file 表里额外加了 knowledge_version 字段这样一个知识条目不同版本可以绑定不同附件下拉历史版本时能看到当时上传的文件列表。4.5 日志埋点与仪表盘统计操作日志模块设计和后端开发时我用一个简单的 AOP 切面拦截 controller 层的请求通过注解 LogAnnotation(VIEW_KNOWLEDGE) 标注需要记录的操作类型切面里读取当前登录用户、请求参数、耗时然后异步写入操作日志表。之所以用异步是因为日志写入不应该影响主流程的性能线程池直接复用 Spring 内置的 Async 线程池。仪表盘统计页面主要展示三块内容知识总量与分类分布用饼图、本周新增与审核通过趋势用折线图、热门知识 Top10按浏览量排序。数据接口在 service 层写聚合 SQL前端用 ECharts 渲染。这个页面虽然代码量不大但非常出效果答辩的时候老师最喜欢看到这种可视化页面。还有一点热门知识如果每次请求都实时跑 SQL数据库压力有点大我给它加了个 5 分钟的 Redis 缓存浏览量更新走增量计数定时任务每小时把计数刷回数据库。5. 开发调试与部署实录5.1 从源码到本地跑通的五个步骤拿到一套完整的源码怎么在全新环境里快速跑通这一步我摸索出了固定流程。第一步导入数据库。用 Navicat 执行项目里的 sql 脚本新建同名数据库确认表结构和初始数据都正常。第二步启动基础设施。先启动 MySQL 和 Redis再启动 MinIO——如果没有 Docker可以下载 MinIO 的 Windows/macOS 安装包启动命令是 minio server /data控制台端口默认 9001。第三步修改配置文件。打开 application.yml把数据库地址、用户名密码、Redis 地址、MinIO 的 endpoint 和 accessKey、secretKey 全部改成自己本机的值。第四步用 IDEA 导入项目等待 Maven 依赖下载完成然后启动 KmsApplication 主类。第五步浏览器访问 localhost:8080看到登录页后用 admin/admin123 登录。这里我踩过的坑是配置文件的密码加密。如果你用了 jasypt 加密数据库密码那么每台机器都要设置相同的加密密钥环境变量这对“换台机器跑不起来”的问题贡献不小。所以做课程设计的话配置文件里直接明文写密码就行或者使用简单的占位符论文里可以提一句“生产环境建议用加密配置本项目为演示方便使用明文”。5.2 配置文件里最容易被坑的三个点Spring Boot 项目启动不起来八成问题出在配置细节上。第一个是数据库连接参数。MySQL 8 的驱动类是 com.mysql.cj.jdbc.Driver不是老的 com.mysql.jdbc.DriverURL 里必须加上 useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai否则中文乱码且时间偏差 8 小时。还有一点MySQL 8 默认的认证插件是 caching_sha2_passwordJDBC 连接时偶尔会报 Public Key Retrieval is not allowed解决办法是在 URL 里加 allowPublicKeyRetrievaltrue。第二个是 Redis 相关配置。Spring Boot 2.x 默认的 Redis 客户端是 Lettuce连接超时参数 connect-timeout 不设置的话Redis 挂了接口会卡很久。我一般会设置 spring.redis.timeout5000ms 和 lettuce.pool 的连接池参数同时注意 Redis 序列化配置默认的 JdkSerializationRedisSerializer 会把 key 存成二进制肉眼根本看不到缓存键排障很痛苦。我改成 StringRedisSerializer Jackson 的组合这样在 Redis 客户端里能看到可读的 key。第三个是 MinIO 的 endpoint 配置。本地测试时 endpoint 是 http://127.0.0.1:9000服务部署到服务器后要改成服务器的内网或公网地址。这里有个细节如果前端浏览器直接访问 MinIO 签名 URLendpoint 不能配成 localhost否则别人打开页面时请求的是他自己电脑的 9000 端口。正确做法是配成局域网 IP 或服务器域名。5.3 打包与生产部署本地调试通过之后部署到服务器也是一套固定操作。在项目根目录执行 mvn clean package -DskipTests等构建完成target 目录下会生成一个可执行的 jar 包。然后把这个 jar 上传到服务器服务器上提前装好 JDK8、MySQL、Redis、MinIO配置文件用 --spring.config.additional-location 指向外部 application-prod.yml就可以用 java -jar kms-server.jar 启动。生产环境部署我习惯加两个东西一是用 systemd 写一个服务文件实现开机自启和自动重启万一进程崩溃能拉起来二是用 Nginx 做反向代理把 8080 端口代理到 80 端口同时配上静态资源的缓存策略这样页面访问体验更好。这个环节虽然和编程无关但做完之后“部署调试”这一章的内容就非常扎实了论文里的系统部署部分也有素材。5.4 数据库表结构变更的维护技巧开发过程中频繁改表结构几乎是必然的。一开始我直接改数据库表然后手动同步实体类结果有一次漏改了一个字段启动时 MyBatis Plus 直接报 mismatch排查了大半天。后来我学聪明了把数据库变更脚本统一放在项目里的 db/migration 目录文件名带日期和序号例如 20250411_add_view_count.sql每次改动先写脚本再执行并且顺手更新实体类。这样做的好处是换环境重搭数据库时直接执行整个目录的脚本就能还原最新结构而不是只能依赖最初的建库文件。还有一个实用技巧用 MyBatis Plus 的代码生成器反查数据库生成实体类和 Mapper能保证数据库和 Java 字段一一对应。生成之后再用 Lombok 简化 Getter/Setter效率非常高。6. 高频问题与避坑清单6.1 检索速度为什么越来越慢数据量增长以后检索慢是知识库最常见的性能问题。排查顺序我一般先看有没有走索引用 EXPLAIN 看执行计划重点看 type 是不是全表扫描key 是不是空。如果是 %关键词% 这种写法导致索引失效就要么改成全文索引要么换前缀匹配。再有就是看分页性能MyBatis Plus 分页插件默认会执行 count 语句数据量大时 count 也慢可以适当优化 count SQL 或者缓存总数。另一个非常隐蔽的问题是 MySQL 的查询缓存。8.0 版本已经移除查询缓存很多教程还在建议打开它这对新版 MySQL 没用。别把时间浪费在这种过时技巧上。6.2 上传文件名中文乱码和格式校验文件上传后存储到 MinIO 时我习惯用 UUID 作为 objectName原始文件名单独存入数据库 file_name 字段。这样做有两个好处一是避免中文文件名和特殊字符在 URL 传输时编码出问题二是防止不同用户上传同名文件时互相覆盖。前端的下载操作不要直接拼 URL 访问而是通过后端接口返回 Content-Disposition 头用 URLEncoder.encode 处理文件名这样浏览器下载的文件名始终是正确的原始名称。格式校验除了扩展名白名单之外还建议校验文件的 MIME 类型因为改扩展名绕过校验的情况在真实场景中很常见。可以用 Apache Tika 在服务端读取文件的真实类型白名单之外的直接拒绝上传这种细节写进论文是实打实的“安全考虑”。6.3 递归死循环和空指针分类树的递归死循环前面提过这里再说一个空指针场景新建知识条目时前端可能不传分类 ID后端如果直接 categoryService.getById(categoryId)然后 getId()空指针就来了。这种问题怎么防一是入参校验用 Spring 的 NotNull 注解在 Controller 层就挡掉二是从数据库查出来的对象不能想当然地认为一定不为空用 Optional 或者判空是基本素养。另外 MyBatis Plus 的条件构造器也容易踩坑Wrapper 里写的实体字段如果拼错了编译期不会报错运行期才发现。我的习惯是尽量少用字符串字段名多用 Lambda 写法比如 lambdaQuery().eq(Knowledge::getStatus, 2)这样 IDE 能帮你检查字段拼写重构字段时也会跟着改。6.4 前端页面与接口 404Thymeleaf 模板方案里页面 404 多半是路径映射问题。controller 返回字符串视图名时如果和 templates 目录下的文件路径对不上会出现 Whitelabel Error Page。排查时先确认模板文件确实在 templates 下并且返回的视图名是相对于 templates 的路径不带.html 后缀。接口 404 则要看 Controller 的 RequestMapping 路径是不是写错了或者类名被 RestController 注解漏掉了。这里有一个很容易忽视的场景同一个路径一个 GET 一个 POST前端用错了方法Spring MVC 会直接 405别问我是怎么知道的。所以前后端联调的时候约定好接口路径和方法出问题先抓浏览器的 Network 面板看请求方法是什么往往瞬间定位问题。6.5 如果要做成课程设计或毕设论文怎么组织论文这块标题写了“带论文文档 1 万字以上”可见对文档的要求不低。我建议按标准的软件工程套路组织章节安排如下第一章绪论写选题背景和意义、国内外研究现状、研究内容和方法。第二章相关技术介绍把 Spring Boot、MyBatis Plus、MySQL、Redis、MinIO 各写一节重点写清楚你为什么要选它。第三章需求分析画用例图、功能需求、非功能需求把角色权限矩阵放进表格。第四章总体设计写系统架构图、功能模块设计、数据库 E-R 图和表结构说明这一章是所有章节里最容易凑字数的每张表列字段名、类型、约束、说明10 张表写完就有 3000 字了。第五章详细设计与实现按模块贴核心代码配功能截图和界面截图。第六章系统测试写测试用例表至少 10 个用例覆盖登录、CRUD、审核流、上传下载、检索、权限越权测试。最后是总结和参考文献。写论文时最容易出问题的是把代码全文粘贴上去。有些学校查重严格代码贴太多会直接拉高重复率。我建议代码只放关键代码片段比如树形组装、MinIO 上传、全文索引查询每个代码块控制在 20-40 行配必要的文字说明这样既体现工作量又不会显得灌水。至于“界面截图”每个功能模块放 1 到 2 张标注清楚功能点答辩时也方便照着截图讲。实操之后的一点体会整套项目做下来我的感受是知识库这类系统看着简单真正做起来最耗时间的不是 CRUD而是那些边界情况状态流转的合法性、文件与版本的关联、权限的越权控制、检索的性能退化、部署环境的差异。这些边界情况恰恰是课程设计和毕设里最值得展开写的部分也是项目区别于“纯练手 Demo”的关键。后续如果想继续扩展比较自然的方向是给知识条目加一个 AI 问答入口把发布的规范文档作为知识来源让员工用自然语言提问或者做一个移动端 H5 方便护理人员现场查询。基础设施和数据库结构不用大改在这套项目上继续往上叠功能是很顺手的事。