企业官网建设流程全解析

刚带完一个实习生做完这套前后端分离的图书管理系统，趁热把整个项目的落地过程整理出来。这套《SpringBoot + Vue + Element UI + MySQL》的组合，今天已经算是 Web 开发入门的经典套餐了，很多培训机构和毕设选题都在用，但它远不止一个练习项目那么简单：从数据库设计、后端接口规范、前端组件封装，到联调时的跨域和 Token 处理，一整条链路跑下来，你基本就摸清了现代 Web 工程的核心工作流。

这篇文章不是给你贴一堆官方文档，而是把我从零搭这个系统过程中踩过的坑、验证过的方案、最终的代码结构全部分享出来。如果你正准备做类似的单体管理系统，或者想系统地入门前后端分离开发，这篇内容可以直接当参考手册用。我会拆开讲清楚数据库怎么设计、后端接口怎么分层、前端页面怎么组织，以及在联调阶段最容易翻车的几个细节。

1. 项目核心需求与整体设计思路

1.1 图书管理系统到底要管什么

图书管理系统这个选题，看起来简单，但它是典型的“麻雀虽小，五脏俱全”。业务上最基础的需求就这几块：图书信息管理、图书分类管理、读者管理、借阅和归还操作，以及登录认证。你把这些功能做扎实了，普通的管理类系统无非就是在这几个模型上做加减法。

我当时拿到需求之后，没有急着写代码，先把功能模块拆了一遍。图书模块要考虑的是字段设计，书名、作者、ISBN、出版社、价格、库存数量、上架状态这些是必须的，还要考虑封面图存哪里、分类怎么挂。读者模块相对简单，但要注意读者编号的唯一性。借阅模块是最容易出逻辑问题的，一本书能不能被借出，要看库存是否大于 0；还书时要更新库存，还要记录借阅时间、应还时间、实际归还时间。

另外，系统必须有一个登录功能，否则谁都能往数据库里写数据，这在真实项目里是不可接受的。考虑到是管理系统，我没有做注册入口，而是直接在数据库里预置管理员账号，由管理员来创建读者账号。这样一个权限边界清晰，也避免了注册接口被刷的问题。

1.2 技术选型为什么是 SpringBoot + Vue + Element UI + MySQL

这个技术组合，放到今天的市场环境下依旧很能打。后端选 SpringBoot，是因为它对 Spring 生态做了大量自动配置，让你不用再去写一堆 XML 配置，内嵌 Tomcat，打包成 jar 就能跑。对于中小型管理系统，SpringBoot 的开发效率和稳定性都是第一梯队的。

前端选 Vue 2 + Element UI，我承认现在 Vue 3 和 Element Plus 已经是大趋势，但这套组合的存量项目实在太大了。很多企业内部的运营后台、管理平台，至今还是 Vue 2 + Element UI 的代码。从学习或者以后接手老项目的角度说，会用 Vue 2 依然是一项实用技能。Element UI 的组件库对表格、表单、弹窗、分页这些后台管理场景覆盖得很全，基本不需要自己写太多样式。

MySQL 就不用多说了，开源、稳定、资料多。图书管理系统这种事务性强、表关系清晰的项目，用 MySQL 非常合适。整条技术线下来，给人的感觉是：主流、好招人、好维护。把这一套吃透，你去看若依这类基于同一技术栈的快速开发框架，也会从容很多。

1.3 前后端分离的核心思路

前后端分离，说直白点就是前端代码和后端代码不再放在同一个工程里，而是各跑各的服务器，通过 HTTP 接口通信。前端只负责页面渲染和用户交互，通过 Ajax 请求后端接口获取 JSON 数据；后端只负责业务逻辑和数据处理，返回标准格式的 JSON，不关心数据在页面上长什么样。

这种架构有几个很实在的好处。前端开发和后端开发可以并行推进，只要提前约定好接口文档，两边互不阻塞。前端可以单独部署到 Nginx，后端可以独立横向扩展，部署更灵活。还有一点对团队很重要，前端的 Vue 代码和后端的 Java 代码彻底隔离，不会出现改了一个页面的样式，结果把后端代码也影响了这种尴尬情况。

当然，分离也带来了新的挑战，跨域问题就是最典型的。浏览器出于安全策略，会拦截跨域请求，解决办法通常是在后端配置 CORS。另一个问题是身份认证不再依赖传统的 Session 共享，而是通过 Token 机制处理。这两块我会在后面专门展开讲。

2. 数据库设计与开发环境搭建

2.1 数据表结构设计

数据库设计是整套系统的地基，地基歪了后面写多少代码都难受。我设计的库名就叫book_manager，采用 utf8mb4 字符集，排序规则用 utf8mb4_general_ci。为什么不用 utf8？因为 utf8 在 MySQL 里最多支持 3 个字节，一些生僻字和 Emoji 表情会存不进去，而 utf8mb4 是完整的 4 字节 UTF-8 实现。

主要设计了五张表：用户表、图书分类表、图书表、借阅记录表、还书记录表。分类表和图书表是一对多的关系，一本图书只能归属一个分类，但一个分类下可以有多本图书。借阅记录表和图书表、用户表是关联关系，记录每次借书的明细。我建表的时候把常用字段都统一处理了：id设为自增主键，create_time用DATETIME类型，逻辑删除标志位建索引。图书表的库存字段设置了默认值 0，防止插入数据时报空值。

建表有一个很容易踩的坑：时间字段的默认值。MySQL 5.7 以上版本可以直接设DEFAULT CURRENT_TIMESTAMP，但如果你用的是老版本或者某些云数据库，可能会报错。稳妥的做法是在创建时间字段时不设默认值，插入数据时由后端通过LocalDateTime.now()统一赋值，这样兼容性最好。

2.2 SpringBoot 项目初始化细节

创建 SpringBoot 项目，我推荐直接去 Spring Initializr 网站生成基础骨架，而不是在 IDEA 里新建。Spring Initializr 上可以直观地选择 Spring Boot 版本和依赖，我用的 Spring Boot 版本是 2.7.x，对应的 Java 版本是 1.8。注意这里有一个很多人会忽略的点：Spring Boot 3.x 强制要求 Java 17，如果你的电脑上装的是 JDK 8，那搞半天启动不了，多半就是版本不匹配的问题。

依赖方面我选择了 Spring Web、MyBatis、MySQL Driver、Lombok。MyBatis 是比较传统的持久层框架，SQL 由自己写，可控性强，适合这种业务明确的项目。很多同学纠结用 MyBatis 还是 MyBatis-Plus，我的建议是初学者先从原生 MyBatis 开始，把 SQL 写明白再去用增强框架，这样如果 SQL 优化出了问题，你能看懂底层在干什么。Lombok 这里要提醒一句：IDEA 里需要安装 Lombok 插件，否则编译运行时会出现找不到 getter/setter 方法的报错。

另外，application.yml里我习惯把端口设为 8080，并配上 context-path，比如/api。这样做的好处是前端在开发环境请求接口时，所有请求天然带/api前缀，后端再通过拦截器统一放行或拦截，条理会清晰很多。数据源配置里，时区参数serverTimezone=Asia/Shanghai一定要加上，不然连接 MySQL 8.x 时会报时区错误。

2.3 Vue 环境配置与项目创建

前端环境我用了 Vue CLI 来创建项目，安装命令是npm install -g @vue/cli。这里有个小经验，如果npm install的速度非常慢，多半是网络源的问题，可以用npm config set registry https://registry.npmmirror.com切换到国内镜像源。实测下来，切换之后下载速度是质的飞跃。

创建项目的命令是vue create book-manager-web，在交互式选项里选择 Manually select features，勾选 Router、Vuex，CSS 预处理器选择 SCSS。接着安装 Element UI，命令是npm i element-ui -S。注意在 Vue 2 的项目里，主流的 UI 库是 Element UI，不要装成 Element Plus，因为 Element Plus 是给 Vue 3 准备的，装错版本会发现组件全部渲染异常。

项目创建的另一个易错点是 Node 版本问题。Element UI 和 Vue CLI 4.x 对 Node 版本有一定要求，太新的 Node 版本可能报 OpenSSL 错误。遇到这种情况，一个比较简单的解决办法是在启动命令里加NODE_OPTIONS=--openssl-legacy-provider环境变量，或者干脆用 nvm 切换回 Node 14 或 16 这类稳定版本。我在实操中更推荐后者，因为老项目不只是启动时会出问题，依赖安装时也可能有兼容性坑。

3. 后端接口设计与核心业务实现

3.1 后端代码分层结构

后端代码结构我严格按照 Controller、Service、Mapper、Entity 四层来划分。Controller 层只负责接收请求、参数校验、调用 Service、返回统一结果，不应该写任何业务逻辑。Service 层存放核心业务逻辑，比如借书时要检查库存、扣减库存，这些操作都必须在这一层完成，保证事务的一致性。Mapper 层是 MyBatis 的接口层，配合 XML 文件写 SQL 语句。Entity 层是数据库表对应的实体类，字段和表字段一一对应。

接口返回格式我是统一处理的，定义了一个Result类，包含code、message、data三个字段。成功时code为 200，失败时code为 500，未登录或登录过期时code为 401。前端拿到返回结果后，只需要判断code是否为 200 即可，不用关心 HTTP 状态码。这样设计的好处是，即使业务上出错了，HTTP 层还是 200，前端的拦截器可以根据业务码统一跳转处理，逻辑非常清爽。

在实际编码中，很多人容易把 Mapper 层的异常直接抛给前端，这属于不合格的做法。比如查询一个不存在的图书 ID，直接报 SQL 异常，前端拿到的就是一堆英文报错，用户体验很差。正确做法是在 Service 层捕获异常，转成业务异常再抛出去，统一异常处理器会把异常信息转换成标准 JSON 格式返回给前端。我用了@RestControllerAdvice做全局异常处理，这个切面是后端规范化的关键一环。

3.2 图书与分类管理接口实现

图书相关接口我提供了分页查询、按条件搜索、新增、修改、删除、根据 ID 查询详情这几个。分页查询我用的是 PageHelper 插件，只需要在 Service 层调用PageHelper.startPage(pageNum, pageSize)，紧接着的查询就会自动带上 LIMIT 语句，非常方便。需要说明的是，PageHelper 只能在紧跟它的第一条查询语句上生效，如果你在调用前又多写了一行查询，那分页就失效了。

按条件搜索这里，我支持按书名模糊查询、按 ISBN 精确查询、按分类 ID 查询。条件组合用 MyBatis 的动态 SQL 来处理，核心是<where>标签和<if>标签。<where>标签的好处是，如果所有条件都为空，它不会生成多余的 WHERE 关键字；如果只有一个条件生效，它也能自动去掉多余的 AND。这种细节就是 MyBatis 相比 JDBC 原生编程省心的地方。

删除图书时我用了逻辑删除，也就是用一个deleted字段标记数据是否已删除，而不真正执行 DELETE 语句。这么设计的原因很简单：图书可能关联着借阅记录，如果物理删除图书，历史借阅记录里的图书名、ISBN 都没法溯源了。虽然逻辑删除会让后续的每次查询都要记得加deleted = 0条件，但为了数据的完整性，这笔账是划算的。

3.3 借阅归还流程的事务处理

借书和还书是两个典型的写操作，涉及多张表的变更。借一本书，要完成两件事：往借阅记录表插入一条数据，同时把图书表的库存减一。这两个操作必须放在同一个事务里，否则就会出现“借阅记录插进去了，但库存没减”的数据不一致问题。

在 SpringBoot 中，我直接在 Service 层方法上加@Transactional注解。这里分享一下事务回滚的细节：@Transactional默认只在遇到 RuntimeException 时回滚，如果你抛出的是受检异常，它是不会回滚的。所以我在代码里如果发现库存不足，会直接抛出RuntimeException的子类，这样能确保事务正确回滚。

还书流程略微复杂一点。用户归还一本书，后端要根据借阅记录表中的借书记录，计算出是否逾期。如果逾期，需要记录逾期天数。然后再更新图书库存加一，同时把借阅记录的状态改为已归还，并记录实际归还时间。这套逻辑完全在 Service 层内部完成，前端只需要提交一个借阅记录 ID，剩下的判断全部由后端处理，这样职责清晰，也不会让前端陷入复杂的业务逻辑中。

4. 前端页面实现与组件封装

4.1 前端项目目录结构

前端代码的组织方式，直接影响后续的维护效率。我的目录结构是这样的：api目录集中管理所有接口请求，每个模块对应一个文件；assets存放静态资源；components存放公共组件；router配置路由表；views存放页面组件；utils存放工具函数；App.vue是根组件，main.js是入口文件。

api目录是我比较想强调的部分。很多新手习惯在页面里直接写axios.get，但如果接口在多个地方需要复用，或者后期接口地址变了，你就要去每个页面里找，改起来非常痛苦。我一般会把每个接口封装成一个方法，比如getBookList(params)、addBook(data)，页面里只在需要的时候调用对应方法。这样做还有一个额外的好处，就是配合 IDE 的代码提示，不容易把参数名写错。

路由这块，我做了两级嵌套。最外层是Layout布局组件，包含左侧菜单栏和顶部导航；内层是真正的业务页面。用嵌套路由的好处是，菜单栏只需要维护一份，切换页面时布局不变，只刷新子页面区域。同时我配置了路由懒加载，让每个页面在访问时才加载对应的 JS 文件，首页加载速度会明显变快。

4.2 登录模块与 Token 处理

登录功能是我认为前后端分离项目中最能体现工程能力的地方。前端在登录页提交用户名和密码，后端验证成功后返回一个 Token，前端把 Token 保存到 localStorage，然后放进每次请求的请求头里，后端通过拦截器校验 Token 判断是否放行。

Token 的生成我用了 JWT（JSON Web Token）。JWT 的本质是一个包含用户信息和过期时间的加密字符串，服务端不需要存储 Session，因此天然适合前后端分离和水平扩展。生成 JWT 时，我在载荷部分放入了用户 ID、用户名、过期时间三个字段，然后用一个密钥做签名。校验时只要签名能通过，就认为这个 Token 是可信的。需要注意的是，密钥千万不要写在代码里明文暴露，应该放在配置文件中，并从环境变量读取，避免上传到 Git 仓库导致泄露。

前端的请求拦截器和响应拦截器是配合后端 Token 机制的关键。请求拦截器里，每次发送请求前都从 localStorage 取出 Token，加到请求头的Authorization字段里。响应拦截器里，如果后端返回 401 表示 Token 过期，就清空本地 Token，并跳转到登录页。这个看似简单的逻辑，却是保证系统安全性的重要防线。我在实际测试中发现，如果没有做 Token 过期跳转，用户会一直停留在页面里，点击任何按钮都报错，体验非常差。

4.3 图书列表页与表格分页

图书列表页是整个系统里使用频率最高的页面，我用 Element UI 的el-table组件来展示数据，配合el-pagination做分页。表格的列通过prop属性绑定数据字段，格式化时间列时用formatter函数处理。这里有一个小细节，后端返回的日期格式是LocalDateTime序列化后的标准格式，前端直接用时会显示太长，所以我在 formatter 里把它截断了一下，只保留年月日。

分页组件的设计，关键是要和后端接口参数对得上。页码pageNum、每页条数pageSize以及总条数total，这三个是最核心的参数。总条数是后端在分页查询时额外统计的，前端不能自己去猜，否则最后一页的数据显示就会出问题。页码切换时，触发一个事件重新请求接口，再把返回的列表数据赋给表格。整个过程说起来简单，但需要注意的一点是，切换页码时如果要保留搜索条件，必须把搜索表单里的值也一起带上，否则换页之后搜索条件就丢了。

新增和编辑图书，我用的是el-dialog弹窗加el-form表单。打开弹窗时，如果是新增，清空表单并置为初始值；如果是编辑，根据行数据回填表单内容。提交时做一次表单校验，校验通过后调用新增或编辑接口。Element UI 的表单校验规则是基于 async-validator 的，必填项用required: true，数字字段可以用type: 'number'限定类型。校验规则的触发时机我设置为blur，也就是输入框失焦时触发校验，用户还没填完就弹出一堆红字提示，会让人很烦。

4.4 图书分类管理页面要点

图书分类页面比图书页面简单，本质就是一个增删改查。但我还是用了treeTable的思路做了一点扩展，因为实际业务里分类可能有层级关系，比如“文学类”下面还有“小说”“散文”两个子分类。我在设计分类表时，字段里包含了parent_id，顶级分类的parent_id是 0，子分类的parent_id是对应父分类的 ID。

前端的分类页面，我使用了 Element UI 的el-table展示列表，然后把parent_id翻译成父分类的名称。这里有个处理技巧，因为分类数量通常不会很多，我在页面加载时一次性把全部分类取下来，在前端构建一个映射表，展示时直接查映射表得到父分类名称，避免了循环里反复发送请求的 N+1 问题。

新增和编辑分类时，父分类的下拉选择框里，要排除自己及自己的子分类，不然会出现循环引用。这个逻辑虽然简单，但很容易忽略。我最初就没有做排除处理，导致可以把某个分类的父级设置成它的子分类，数据瞬间乱套。后来在保存时加了递归校验，有关联就提示错误，这个问题才彻底解决。

5. 前后端联调与常见问题排查

5.1 跨域问题解决方案

前后端分离项目刚启动时，最常遇到的就是跨域报错。我用 Vue 开发服务器跑在 8081 端口，后端 SpringBoot 跑在 8080 端口，端口不同就产生了跨域。浏览器拦截的是非同源的请求，对于这种开发环境下的跨域，我用了两种方案结合来处理。

第一种方案是在 SpringBoot 后端写一个 CORS 配置类，实现WebMvcConfigurer接口，重写addCorsMappings方法，允许所有来源访问所有接口，允许所有请求头。这是后端的全局统一配置，一处生效，所有接口都能跨域访问。生产环境时，这里应该改成只允许你的实际前端域名，否则任何网站都能跨域请求你的接口，会带来安全隐患。

第二种方案是前端的代理配置。在 Vue CLI 项目的vue.config.js里配置 devServer 的 proxy，把/api开头的请求代理到http://localhost:8080。这样前端开发服务器接收到请求后，会转发给后端，浏览器看到的始终是同源的请求，自然不会触发跨域拦截。配置代理的好处是代码里不用写完整的后端地址，统一以/api开头，后续部署时再用 Nginx 做反向代理，前后端接口的切换成本很低。

5.2 前端请求封装与接口调试

前端所有接口请求，我都走一个统一的request.js封装，底层是 axios 实例。创建实例时可以设置基础路径和超时时间。我还为 axios 实例添加了请求拦截器和响应拦截器。这个封装的中心思想就是统一处理，防止每个页面都重复写 Token 拼接和错误提示。

接口联调阶段，我推荐在 Google Chrome 的开发者工具里重点看 Network 面板。打开 Network 面板，切换页面触发请求，点击某个请求就能看到请求头、请求参数和响应内容。最容易出现的问题有三个：404 往往是接口地址写错了，检查基础路径和拼接是否和 Controller 层一致；400 往往是参数类型不匹配，比如后端定义的是 Integer，前端传的是字符串；500 则是后端代码抛异常了，需要在后端控制台看堆栈信息。

调试接口时还有一个小技巧，在 Network 面板里找到请求，右键可以复制为 cURL 命令，直接在终端里跑一遍就能复现请求。想测试后端接口又不想写前端代码时，我会直接用 Postman 或 Apifox 这类接口测试工具，设置好请求头和请求体，就能快速验证接口的正确性。Apifox 的支持做得更全面，可以直接从 Swagger 或 Apifox 的文档同步接口定义。

5.3 常见问题速查与解决实录

我整理了一份联调过程中最常遇到的问题清单，按频率排序，对号入座基本能解决 80% 的问题是没什么问题的。

中文乱码问题我单独说一下。MySQL 8.x 默认字符集已经是 utf8mb4，但 SpringBoot 连接 MySQL 时，如果连接串里没有characterEncoding=utf8，插入的中文可能会变问号。这个是我在批量导入图书数据时发现的，几百条图书记录全部乱码，后来在数据库连接池配置里加上了这个参数，重启项目后重新导入才恢复正常。

后端返回 JSON 字段为 null，经常出现在查询返回的实体字段与表字段不一致时。比如表字段是book_name，实体类属性是bookName，MyBatis 默认是无法直接映射的。解决办法有两个：一个是在application.yml里开启map-underscore-to-camel-case: true全局配置，另一个是在 SQL 里用别名改字段名。我推荐用第一种，因为它是全局生效的，以后不管写什么查询，都不用额外费心。

启动项目时如果报端口被占用，在 Windows 命令行输入netstat -ano | findstr :8080查看占用进程的 PID，然后到任务管理器结束该进程。这个方法同样适用于 MySQL 3306 端口或前端 8081 端口，是排查端口问题的通用手段。

还有一次比较奇怪的报错是，SpringBoot 启动时报数据源初始化失败，原因是 MySQL 服务没有启动。这种情况通常出现在电脑重启之后，MySQL 服务不会自动开启，需要到 Windows 服务管理里把 MySQL 服务的启动类型改为自动。有些同学把 MySQL 装成了压缩包免安装模式，那就更要留意服务是否在运行。

5.4 打包部署与生产环境配置

开发完成后，项目要部署到服务器上才有实际价值。前端部署比较简单，执行npm run build，生成一个dist目录，里面是纯静态文件。把 dist 目录里的文件上传到 Nginx 的 html 目录，配置好 server 块即可。这里有一个必须处理的问题，前端采用了 history 路由模式，刷新非首页路由时会 404，所以 Nginx 配置里要加一条 try_files 规则，将所有的路径请求都指向 index.html。

后端打包用 Maven 的 package 命令，生成一个可执行 jar 包。启动命令是java -jar book-manager.jar，生产环境可以设置 JVM 参数，比如-Xms256m -Xmx512m限制内存占用。还有一个比较实用的做法，是把端口和数据库连接等配置放到application-prod.yml里，打包后用--spring.profiles.active=prod参数指定使用生产配置，开发和生产环境彻底分离。

关于部署后的接口地址，前端的request.js里如果写的是相对路径/api，那 Nginx 需要配置反向代理把/api请求转发到后端的 8080 端口。如果前端写的是绝对地址指向后端服务器，那存在跨域问题又得处理一遍。我的建议是始终使用相对路径，由 Nginx 统一做转发。这样前端代码在执行npm run build时不需要修改任何环境变量，一次打包，多环境部署，省心省力。

6. 安全防护与性能优化经验

6.1 后端接口安全校验

后端接口的安全，不止是登录验证那么简单。我在系统中做了三层防护。第一层是用户认证，通过 JWT Token 拦截器验证用户身份，除登录接口外，所有接口都要校验 Token 是否有效。我实现了一个 HandlerInterceptor，重写 preHandle 方法，从请求头取出 Token，校验合法性后把用户信息放入 ThreadLocal，后续业务方法中可以直接获取当前操作用户。

第二层是参数校验和异常处理。在 Controller 层，我用@Validated注解配合实体类字段上的校验注解，如@NotBlank、@NotNull，这样传入参数为空时会直接抛出异常，再由全局异常处理器统一包装返回。比如新增图书时，书名不能为空、库存不能为负数，这类检查放在 Controller 入口比在 Service 层逐行判断要整洁得多。

第三层是数据库层面的安全。这里有一个很实用的点：拼接 SQL 时，MyBatis 的#{}占位符是预编译的，能有效防止 SQL 注入；而${}是直接拼接字符串，存在注入风险，只在动态排序等特殊场景使用，而且要严格校验传入的值。很多初学者没有意识到这两者的区别，看到 ${} 里传了用户输入，就相当于把 SQL 注入的大门打开了。

6.2 数据查询与前端加载优化

图书列表页在数据量上来之后，如果每次都把全部数据加载到内存中，页面会越来越卡。我做了两个改进。第一个是后端严格使用分页查询，每页只返回 10 条或 20 条数据，不会一次性把几万条数据全部传过去。第二个是给常用查询字段加了索引，比如图书的 ISBN、分类 ID，索引能让查询从全表扫描变成索引查找，响应时间会从秒级降到毫秒级。

前端加载速度方面，我做了几件很有效的事。使用路由懒加载，首屏只加载当前页面的代码，而不是把全部页面的 JS 都打包在一起。在打包时通过vue-cli-service build配置了代码压缩，生产环境的 JS 文件明显变小。另外，Element UI 我改成了按需引入，配合 babel-plugin-component 插件，只打包用到的组件，而不是引入整个组件库。

有一说一，这个图书管理系统的数据量通常不会太大，不会真正达到性能瓶颈。但把分页、索引、懒加载这些优化手段用上去，一是让系统实操更跟手，二是让你在面试中聊到优化时有底气，能讲出自己做过什么、为什么这么做。这些细节上的功夫，往往能拉开两个候选人之间的差距。

6.3 项目扩展方向思考

这个系统的业务逻辑相对简单，所以很适合用来做扩展练习。我个人比较推荐的扩展方向有两个：一是接入 Redis 做图书热门榜单缓存，减少数据库压力；二是做文件上传功能，把图书封面从 URL 字符串扩展为真正的文件存储，可以用本地磁盘，也可以用对象存储服务。

如果你想把权限模型做完整，可以引入 Spring Security 或 Shiro，加入角色和菜单权限，实现不同管理员登录后看到不同菜单。这个扩展思路如果基于若依框架来做，会有很多现成的模块可以参考，但对学习来说，自己动手从零加一套权限体系，收获会更大。

前端这边也可以深化，比如把 Vue 2 迁移到 Vue 3 + Element Plus 和 Pinia，把构建工具换成 Vite，体验一下现代前端工程的构建速度。你在理解了这个项目的全流程之后，再去接触这些新工具，就不是从头学起，而是插拔式的迁移，难度会低很多。

7. 从零到一的项目实操总结

到这里，这个图书管理系统的完整开发链路已经梳理完了。回头看整个项目，它的价值不在于功能多花哨，而在于把一个现代 Web 工程的完整流程走了一遍：从数据库建模、后端分层开发、接口设计，到前端组件化开发、前后端联调，再到打包部署和常见故障排错。这一整套流程放到任何一个小型管理系统上，思路都是通用的。

如果你想自己动手复现一遍，我给个实操建议：不要照着我的代码一行一行抄，而是先自己设计接口文档和数据库建表语句，再写后端接口，最后做前端页面。遇到跨域、Token、日期格式化这些问题时，先自己想办法排查一遍，实在不行再回头看经验帖。

我最初做这个项目时，为了处理 JWT Token 刷新和前端响应拦截的联动，折腾了一个晚上，后来发现只是响应拦截器里对 401 状态码的判断写得不够严谨。这些坑，只有自己踩过，印象才最深刻。这套项目做完之后，你对 SpringBoot 的自动配置、MyBatis 的映射原理、Vue 的组件通信、axios 的拦截机制，都会形成一套自己的认知框架，不再只是停留在会调接口的层面。