企业官网建设流程全解析

做了这么多年Java全栈项目，我越来越觉得图书馆管理系统就像技术圈里的"Hello World"——看起来满大街都是，真要做得像样，从业务建模到权限控制再到并发兜底，每个环节都有说不完的门道。最近刚好把一个基于SpringBoot+Vue的图书馆管理系统从零搭到上线，还配了完整的Java+MySQL+MyBatis源码。这篇就把整个设计思路、核心实现和踩坑过程一次性说透，给正在找完整项目练手、或者准备做毕设/课设的同学一份能直接照着做、也能讲清楚原理的参考。

先交代一下这套系统的技术底子：后端用SpringBoot 2.x + MyBatis + MySQL 8.0，前端用Vue 2.x + Element UI，前后端完全分离，通过RESTful接口通信。功能覆盖图书管理、读者管理、借阅归还、逾期罚金、分类统计、用户登录权限等图书馆日常经营的完整闭环。全文不贴那些"点击下一步"式的安装向导，重点讲业务怎么拆、表怎么设计、代码怎么写才能既跑得通又扛得住并发，最后分享几个我在写这套系统时差点被绕进去的坑。

1. 技术选型不是拍脑袋：为什么是SpringBoot+Vue+MySQL+MyBatis

1.1 后端选型：SpringBoot负责"少写配置"，MyBatis负责"SQL可控"

很多人一上来就问SpringBoot和SSM到底选哪个，我的答案很直接：既然做新项目，就直接SpringBoot。它最大的价值不是性能，而是把配置简化到近乎"零配置"。过去SSM要写一堆XML配置文件，数据源、事务、扫描、拦截器，每个都要手动装配，光这些就能劝退一大批新手。SpringBoot通过自动配置解决了这个问题，你只需要在application.yml里写上数据库连接串、端口号，加上@SpringBootApplication启动类，一个能跑起来的Web服务就成型了。

MyBatis在这个项目里则承担了一个非常关键的角色：它把SQL暴露给你，让你对每一句查询都有绝对的控制权。图书馆系统的查询场景很典型——图书多条件搜索、借阅记录分页、读者模糊查询、逾期列表统计，这些SQL的复杂度远超简单的CRUD，用JPA自动生成SQL反而要花更多精力去调优，而MyBatis允许手写SQL，配合动态<if>标签，能很自然地应对"用户填了几个条件就查几个条件"这种需求。这也是我坚持选MyBatis而不是MyBatis-Plus的核心理由：Plus虽然省了基础CRUD的代码，但如果你要靠它处理复杂联表查询，最终还是要回到手写SQL的思路上来，不如一开始就用原生MyBatis，把基本功练扎实。

1.2 前端选型：Vue在中小型管理系统的优势

管理后台这种"表格多、表单多、弹窗多"的应用形态，Vue的优势非常明显。它的核心是数据驱动视图：你在data里定义了一个bookList数组，页面表格就会自动渲染；修改了某个字段，表格那一行内容立刻更新。这种开发模式比JQuery时代的"手动操作DOM"高效太多，尤其是需要频繁刷新列表、联动选择框、根据状态切换按钮的场景，Vue的双向绑定能省掉大量重复代码。

Element UI则提供了现成的组件生态，表格、表单、分页、弹窗、日期选择器都是开箱即用。我的经验是，开发后台页面前先去Element UI文档里翻一遍组件列表，能改配置解决的就别自己写CSS和JS，这套组件库的坑早就被踩平了，从色彩、间距到交互细节都是现成的，你只需要把数据填进去就能得到一个观感不错、交互流畅的后台界面。

1.3 这套组合对"完整项目"场景的适配度

再说说为什么这个组合适合作为完整源码项目来学习或交付。SpringBoot+Vue前后端分离的模式，是目前企业里最常见的开发架构，你自己完整走一遍"数据库设计→后端接口→前端联调→打包装部署"的流程，等于把实际工作中的整套开发路径都模拟了一遍。

从部署角度来看，SpringBoot最终打成一个可执行的jar包，前端Vue构建后是一堆静态文件，二者可以分开部在服务器上，也可以用Nginx把前端静态文件和后端接口放在同一个域下反代，部署难度低。从数据库角度来看，MySQL社区版免费、跨平台，表结构直观，Navicat等工具还能帮你直观地看数据变化过程，特别适合开发和教学。这也是为什么很多课程设计和简历项目都采用这套"黄金组合"。

2. 需求拆解与数据库建模：把图书馆业务翻译成表和字段

2.1 角色与核心业务流：先画清楚谁在用什么

写代码前，我习惯先画一张"角色-操作"矩阵。这套系统里至少有三个角色视角：

• 图书管理员：负责书籍入库、修改、下架、盘点，处理借书和还书操作，查看逾期和罚金信息。
• 读者：浏览图书、查询库存、提交借阅请求、查看自己的借阅历史和罚金情况。
• 系统维护者：管理用户账号、重置密码、维护图书分类和基础参数。

有了这张矩阵，功能模块就自然浮出来了——图书管理模块、读者管理模块、借阅归还模块、罚金模块、统计报表模块、系统管理模块。每个模块再往下拆操作，比如"借书"这个操作背后其实是三件事：检查读者是否有逾期未还或借阅数量上限、检查该书是否有可借库存、生成一条借阅记录并扣减库存。把这三件事写到一个事务里，才算一个完整可用的"借书"功能。

2.2 核心数据表的结构与字段取舍

数据库设计是整个系统的地基，也是最容易返工的部分。我这套系统一共设计了6张核心表：图书表book、分类表category、读者表reader、用户表sys_user、借阅记录表borrow_record、罚金记录表penalty_record。下面挑重点说字段设计的逻辑。

图书表的字段设计看起来简单，但有几个地方需要考虑清楚：

CREATE TABLE `book` ( `id` bigint NOT NULL AUTO_INCREMENT, `isbn` varchar(20) DEFAULT NULL COMMENT 'ISBN号', `book_name` varchar(100) NOT NULL COMMENT '书名', `author` varchar(50) DEFAULT NULL COMMENT '作者', `publisher` varchar(100) DEFAULT NULL COMMENT '出版社', `category_id` bigint DEFAULT NULL COMMENT '分类ID', `location` varchar(50) DEFAULT NULL COMMENT '馆藏位置', `status` tinyint DEFAULT '0' COMMENT '状态 0可借 1已借出 2下架', `stock` int DEFAULT '1' COMMENT '库存总数', `borrow_count` int DEFAULT '0' COMMENT '已借出数量', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有一个我特别想强调的设计：book表里同时有stock（库存总数）和borrow_count（已借出数量），并没有在每笔借阅发生时去动态统计两张表。这样的冗余设计是否值得？我认为在中小型系统里是值得的。所有"这本书还有没有可借的"的查询都直接走stock - borrow_count，一次索引查询就能拿到结果，不用每次join借阅记录表再聚合。代价是每次借还操作都要同步更新borrow_count，但借还操作本身就是高频单点操作，同一时刻并发量在校园图书馆场景下完全可控，这个取舍是划算的。

借阅记录表borrow_record则要记录借出和归还两个时间点，同时存一本书的ID和读者ID：

CREATE TABLE `borrow_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `book_id` bigint NOT NULL COMMENT '图书ID', `reader_id` bigint NOT NULL COMMENT '读者ID', `borrow_time` datetime NOT NULL COMMENT '借阅时间', `due_time` datetime NOT NULL COMMENT '应还时间', `return_time` datetime DEFAULT NULL COMMENT '实际归还时间', `status` tinyint DEFAULT '0' COMMENT '状态 0借阅中 1已归还 2逾期未还', `renew_count` tinyint DEFAULT '0' COMMENT '续借次数', PRIMARY KEY (`id`), KEY `idx_reader` (`reader_id`), KEY `idx_book` (`book_id`), KEY `idx_status_due` (`status`, `due_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里应还时间due_time是一个必须提前算好并落库的字段，不要想着"每次查询时用借出时间加30天算出来"，因为续借会改变这个值，落库后只需要更新字段就够了，所有基于到期状态的查询（比如逾期列表）也能直接走索引。

2.3 为什么借阅状态不加"逾期"这个硬字段

这是我在设计时反复纠结过的一个点。借阅记录表里的status字段到底要不要维护一个"已逾期"的状态？我的最终方案是：状态只维护0借阅中和1已归还，逾期是查询时通过"status=0 AND due_time < NOW()"动态判断出来的，而不是在数据库里冗余一个status=2。为什么？因为逾期这个状态是随时间不断变化的，一本书今天还没逾期，明天就逾期了。你如果靠定时任务去扫库更新状态，要么延迟不实时，要么增加无谓的系统复杂度。动态判断就干净得多，所有需要"逾期"概念的查询（逾期列表、罚金计算）都带上due_time < NOW()条件即可。查询量上来以后，组合索引idx_status_due足够扛住。

3. 后端核心实现：借书还书背后的并发与事务问题

3.1 统一返回结构和全局异常处理的必要性

前后端分离的项目，接口约定是重中之重。我这里用了最常规但非常实用的方案：所有接口的返回结构统一为一个Result<T>对象，包含code、msg、data三个字段。

public class Result<T> { private Integer code; private String msg; private T data; // 成功/失败的静态方法 public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String msg) { ... } }

前端axios封装里会对code做统一判断，非200的直接弹出msg提示，不用每个页面重复写错误处理。在此基础上，后端再加一个全局异常处理类，用@RestControllerAdvice拦截业务异常和系统异常，统一包装成Result.error()返回。这样做的好处是Controller里的代码非常干净，只关注业务参数传递和调用Service，不含任何try-catch噪音。

3.2 借阅操作的并发问题：同一个库存怎么防超卖

图书馆系统最经典的并发问题就是：同一本书只剩1本库存，两个读者几乎同时提交借阅请求，如果代码先查库存再更新库存，那么两人都查到borrow_count=0，都判定"可借"，最后都插入了一条借阅记录，库存就变成了负数，这就是典型的超借问题。

解决思路借鉴了电商秒杀里的乐观锁思想：不要先查再改，而是把"库存足够"的判断直接写进UPDATE语句里，用受影响行数来判断是否更新成功。

@Transactional public Result<?> borrowBook(Long bookId, Long readerId) { // 1. 检查读者借阅上限和逾期情况（省略） // 2. 扣减库存：只有当前可借数量大于0时才更新成功 String sql = "UPDATE book SET borrow_count = borrow_count + 1 " + "WHERE id = #{bookId} AND stock > borrow_count"; int rows = bookMapper.updateBorrowCount(sql); if (rows == 0) { throw new BusinessException("本书暂无剩余库存"); } // 3. 插入借阅记录 borrowRecordMapper.insert(...); // 4. 日志记录 }

这条UPDATE语句将"判断可借"和"扣减库存"合并成了一个原子操作，stock > borrow_count这个条件被MySQL的行锁保护，同一时间只有一个事务能成功更新这一行的borrow_count。这就是我在这篇文章里最想传达的一个实战经验：并发控制的本质不是把代码写得复杂，而是把业务条件推进到SQL层面去解决。

3.3 还书流程：罚金计算用惰性策略

还书操作的业务逻辑就相对线性了：根据借阅记录ID查到记录，把return_time设为当前时间，status改为1，再把图书的borrow_count减1。但如果借阅已经逾期，还书时还要顺带生成罚金记录。

这里我选了惰性计算方案：不单独建一个"每天跑一次"的定时任务去计算应罚金额，而是在还书那一刻，根据due_time和return_time的时间差乘以每天罚金单价，一次性算出总罚金，插入到penalty_record表。

long overdueDays = Duration.between(dueTime.toInstant(), returnTime.toInstant()).toDays(); if (overdueDays > 0) { BigDecimal penalty = BigDecimal.valueOf(overdueDays).multiply(DAILY_PENALTY); penaltyRecordMapper.insert(...); }

定时任务能不用就不用，因为它引入了一个新组件和新的失败点，而且"实时更新罚金"这个需求在校园/企事业单位图书馆场景下根本不存在——用户只在还书时才需要知道要交多少钱，完全没有必要让系统每时每刻都去计算所有在借图书的逾期金额。

3.4 MyBatis动态SQL处理多条件图书检索

图书检索是一个典型的多条件组合查询：用户可能只输入书名，也可能"书名+作者+分类"一起输入，还可能一个条件都不输入直接看全量。MyBatis的<where>标签加<if>判断是解决这个问题最优雅的方式：

<select id="pageQuery" resultType="com.demo.entity.Book"> SELECT * FROM book <where> <if test="bookName != null and bookName != ''"> AND book_name LIKE CONCAT('%', #{bookName}, '%') </if> <if test="author != null and author != ''"> AND author LIKE CONCAT('%', #{author}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>

注意LIKE CONCAT('%', #{bookName}, '%')的写法，不要直接在XML里写LIKE '%${bookName}%'，那样会产生SQL注入风险。用#{}预编译参数，再用CONCAT拼通配符，既安全又灵活。这段代码是整个检索模块的精华，后面的前端表格无论怎么筛选条件，最终都会命中这一条SQL。

4. Vue前端实践：路由守卫、axios封装与页面骨架

4.1 登录态和角色权限的前端控制

后端接口做了权限校验，前端同样需要配合做"界面级"的控制。我这里用了最直接的方案：登录成功后后端返回一个token，前端存到localStorage，同时返回一个role字段标识当前登录者的角色。axios请求拦截器统一把token塞进请求头：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config })

路由守卫则负责页面跳转时的登录判断和角色判断，在router.beforeEach里检查要跳转的路由的meta.roles是否包含当前用户角色，不通过就重定向到登录页：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else if (to.meta.roles && !to.meta.roles.includes(store.state.role)) { next('/403') } else { next() } })

这个方案虽然不算最复杂（没有做动态路由生成），但对图书馆管理系统这种角色固定的后台来说足够用了，实现简单、易理解，也容易在答辩或代码审查时讲清楚。

4.2 表格+分页+弹窗表单的组件组合套路

图书管理页是最典型的后台页面形态，我每次做这类页面都遵循一套固定的组合模式：顶部放搜索条件表单，下面放el-table数据表格，底部放el-pagination分页，新增/编辑用el-dialog弹窗内嵌el-form表单。这套组合代码写起来非常统一，这里把核心的模板结构给出来：

<template> <div> <el-form :inline="true"> <el-form-item label="书名"> <el-input v-model="queryParams.bookName" placeholder="请输入书名" clearable /> </el-form-item> <el-form-item> <el-button type="primary" @click="handleQuery">查询</el-button> </el-form-item> </el-form> <el-table :data="bookList" v-loading="loading"> <el-table-column prop="bookName" label="书名" min-width="160" /> <el-table-column prop="author" label="作者" width="120" /> <el-table-column prop="statusText" label="状态" width="100" /> <el-table-column label="操作" width="180"> <template slot-scope="{ row }"> <el-button type="text" @click="handleEdit(row)">编辑</el-button> <el-button type="text" class="danger" @click="handleDelete(row)">删除</el-button> </template> </el-table-column> </el-table> <el-pagination :current-page="queryParams.pageNum" :page-size="queryParams.pageSize" :total="total" layout="total, prev, pager, next" @current-change="handlePageChange" /> </div> </template>

表格里的性别、状态、时间这些字段，我强烈建议在data里用字段映射处理，而不是直接在模板里写三元表达式。比如statusText: row.status === 0 ? '可借' : '已借出'，可以在取列表数据后统一转换。这样模板保持干净，也方便统一修改展示文案。

4.3 跨域联调：开发环境的proxy配置

前后端分离开发时，前端页面跑在localhost:8080，后端在localhost:9090，浏览器直接发请求必然遇到跨域。我推荐的联调方式是配置Vue的development server代理，让前端把接口请求转发到后端：

// vue.config.js module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

这样一来，前端所有请求都可以直接写/api/xxx，开发时由Webpack Dev Server转发到真实后端，浏览器视角下不存在跨域问题。生产环境则用Nginx统一处理静态资源和接口反代。这个配置看起来简单，但不少同学的第一步就卡在这——前端白屏、请求报错，十有八九是proxy没配对或pathRewrite写错了。

5. 联调阶段最容易翻车的几个细节

5.1 数据库连接串时区导致的时间偏移

MySQL连接串里有一个最容易被忽略的配置——serverTimezone。如果没配置对，你插入数据库的时间比实际时间少了8小时，或者从数据库查出来的时间比实际时间多了8小时。我的连接串是这样写的：

spring: datasource: url: jdbc:mysql://localhost:3306/library_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

Asia/Shanghai指定了中国时区。如果你用的是MySQL 8.0以上版本，驱动类要写成com.mysql.cj.jdbc.Driver，旧版本的com.mysql.jdbc.Driver会直接报错，这也是不少人导入旧项目后启动失败的原因。

5.2 JSON序列化时Long型ID精度丢失

这个坑我在好几个项目里踩过，值得单独拎出来说。前端JavaScript的Number类型安全整数范围在2^53以内，而数据库自增主键一旦超过这个范围（长期运行的高频表很容易），后端返回的Long型ID在JSON序列化时就会被截断，导致前端拿到的ID和数据库里实际ID不一致，进而导致"编辑时修改了别人"这种诡异问题。

解决方案很简单，在SpringBoot里统一对Long类型主键做ToString序列化：

@Bean public Jackson2ObjectMapperBuilderCustomizer longToStringCustomizer() { return builder -> { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; }

所有Long字段在传给前端时变成字符串，前端失去精度的问题就消失了。这个配置建议直接写到每个项目里，防止以后表数据量大了再踩。

5.3 图书封面/图片上传的处理思路

最开始我打算把封面图片以Base64字符串直接存数据库，后来发现这种方案会让单表数据膨胀好几倍，查询变慢且浪费空间。最终采用的做法是：图片上传接口把文件保存到服务器的指定目录（或者对象存储），数据库里只存访问路径。上传接口返回相对路径，前端用<img :src="baseUrl + coverPath">渲染。开发环境我直接通过Nginx的alias配置把/uploads映射到磁盘目录，干净利落。

6. 从"能跑"到"好用"：我在实战中总结的优化与避坑清单

6.1 初始化数据脚本的价值远比想象中大

一个图书馆管理系统跑起来演示，最怕的是什么？数据库里空荡荡的，没有一本像样的书，没有一条借阅记录，点开页面全是空白表格，观感和功能性大打折扣。我建议在项目的resources目录下放两个基础SQL文件：一个schema.sql负责建表，一个data.sql负责插入演示数据。演示数据至少要覆盖：10本左右不同类型的图书、5个读者测试账号、若干条借阅/归还/逾期记录。这样项目clone下来就能立刻看到完整的效果，无论自己调试还是给别人展示都省心。

我在data.sql里还刻意造了几条极端数据：一本库存为0的图书、一本即将逾期的借阅记录、一条已经产生罚金的记录。这些数据不是为了好看，而是为了验证不同状态在前端页面上的展示是否对应正确，也能逼着自己在开发阶段就把各种边界情况处理完。

6.2 密码存储不能明文，但也没必要上Spring Security

很多课程设计里直接明文存密码，同学答辩时也经常被问住。我的建议是：不引入Spring Security这一套重框架，自己写一个工具类做加盐哈希就够了。

public class PasswordUtil { public static String encode(String rawPassword) { // 生成随机盐，加盐后使用SHA-256迭代100次 String salt = UUID.randomUUID().toString().replace("-", ""); String hashed = DigestUtils.sha256Hex(rawPassword + salt); return salt + "$" + hashed; } }

加密方式讲得清楚，安全性也比明文强得多，还不至于为了做个后台管理项目引入一堆Security的配置和过滤器链。同理，登录认证我也没有上JWT框架，只用UUID生成token存到后端内存Map，接口过滤器校验token是否存在及是否过期。如果你需要更规范的权限框架，后续可以换成Spring Security + JWT，但作为"完整源码"项目来说，轻量级方案更容易让初学者通读全代码、理解认证逻辑。

6.3 统计报表模块：别用ORM，直接写聚合SQL

图书馆管理系统的报表需求无外乎：图书分类占比、每月借阅量趋势、逾期统计、读者借阅排行。这些统计如果用Java代码在内存里循环计算，不仅代码丑，而且效率低。我的做法是直接用SQL聚合，后端只需要把查询结果原样返回给前端。

SELECT category_name AS name, COUNT(*) AS value FROM book b LEFT JOIN category c ON b.category_id = c.id GROUP BY b.category_id;

这类SQL里最需要注意的是NULL值处理：如果一个分类下没有任何图书，LEFT JOIN后category_id可能是NULL，分组会出现一个空的分类名。处理办法是在SELECT里用IFNULL(category_name, '未分类')兜底。前端图表我用ECharts的饼图和柱状图展示，接口返回结构高度一致，所以一个fetchChartData函数就能驱动所有图表页面。

6.4 前端分页参数与后端PageHelper的字段对齐

分页是管理后台最基础的功能，但初学时很容易在"前端传的参数名"和"后端接收的参数名"对不上号这件事上浪费大量时间。我在前端统一用pageNum和pageSize作为分页参数，后端Controller也保持相同的字段名，然后通过PageHelper.startPage(pageNum, pageSize)开启分页，紧随其后的查询语句会被自动拦截并生成LIMIT语句。

@GetMapping("/page") public Result<?> page(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, BookQuery query) { PageHelper.startPage(pageNum, pageSize); List<Book> list = bookMapper.pageQuery(query); PageInfo<Book> pageInfo = new PageInfo<>(list); return Result.success(new PageResult<>(pageInfo.getTotal(), pageInfo.getList())); }

PageHelper的坑在于它基于ThreadLocal实现，所以startPage之后必须紧跟查询方法，中间一旦隔了别的数据库操作，分页效果就会错乱，而且线程池复用ThreadLocal还会导致分页参数串到别的查询里去。这里我给项目加了一个PageHelper.clearPage()的兜底调用，写在一段finally代码里，确保线程安全。

6.5 打包部署：jar包加前端静态文件的组合拳

整套系统最终的交付物是两部分：后端的jar包，以及前端npm run build后生成的dist目录。部署时最省事的方案是用Nginx托管前端静态文件，并把/api请求反向代理到后端的9090端口：

location /api/ { proxy_pass http://127.0.0.1:9090/; } location / { root /opt/library-web/dist; try_files $uri $uri/ /index.html; }

这里有个细节：proxy_pass http://127.0.0.1:9090/;末尾一定要保留斜杠，表示把/api前缀剥掉后转发。否则后端收到的请求路径里还会带着/api，需要额外处理跨域配置。生产环境如果不想装Nginx，也可以用SpringBoot把静态资源打包进jar，但那会导致前端每次更新都要重新打包后端，开发效率低。前后端分离部署，各改各的、各发各的，才是正常的工作节奏。

7. 写在最后：做完这套系统，我的几条实在建议

如果你准备拿这个项目当作课程设计或者简历项目，我建议不要满足于"跑通了、能演示了"。试着给它加一两个自己设计的小功能，比如图书批量导入、热门借阅榜、读者借阅证到期提醒，这些增量功能能帮你把"技术应用能力"从"照着代码敲"提升到"自己设计并实现"的层次。面试或答辩时，面试官不关心你复制了多少代码，他关心的是你能否讲清楚为什么这么设计、遇到并发该怎么处理、数据库字段为什么要这样冗余。

整条链路走下来，SpringBoot的自动配置、MyBatis的动态SQL、MySQL的索引与事务、Vue的组件化与路由守卫，这些知识点都会从"听过"变成"用过"。这套技术栈组合在后续实际开发中依然会被频繁使用，你现在踩过的每一个跨域坑、时区坑、分页坑，都会成为未来更复杂的分布式项目里最宝贵的第一手感。图书馆管理系统虽然是老题材，但它麻雀虽小五脏俱全，能完完整整走一遍需求分析、数据库设计、接口开发、前端联调和部署上线，本身就是极好的工程训练。