王杰岸“静思书屋”是我花了近两个月时间从零搭建并稳定运行的一个基于Java Web技术栈的高性能图书信息平台。这个项目最开始只是因为身边朋友开的小书屋被手工借阅登记搞得焦头烂额，图书找不到、库存对不上、逾期催还靠人肉打电话，后来我干脆把它当成一次完整的技术实践来做，不仅把借阅流程线上化，还把“高性能”作为硬指标去设计，前后经历过选型反复、慢SQL排查、缓存穿透和并发抢书等一系列问题。如果你正在做Java Web相关的项目，或者准备用JSP+Spring Boot这套组合交出实训/毕设作品，这篇对你会很有参考价值。
我会把整个项目从业务梳理、技术选型、数据库设计、性能优化到前端审批流落地都串起来讲，重点放在那些“上机课不会告诉你”的细节和取舍逻辑上。
1. 从柜台登记到信息平台：静思书屋到底需要什么
很多Java Web项目一上来就堆功能，结果做出来像大杂烩。静思书屋这个项目最大的不同在于，它的业务边界很清晰：一个线下的中小型书屋，想用一套信息平台替代手工登记，让读者能查书、预借、续借，也让管理员能处理入库、借还、催还和简单的审批。需求不复杂，但不代表实现简单，因为书屋的流量虽然没法跟电商比，但数据特点非常折磨人：图书总量几万册、热门书籍的借阅非常集中、查询条件杂乱，再加上借还需要非常严格的库存控制，一不留神就会做出一个“看起来能用、一上线就卡”的站点。
1.1 原有登记流程的四个真实痛点
我在做需求调研的时候，跟着门店伙计盯了一整天前台，总结下来的问题非常典型。
- 找书基本靠记忆。读者问“有没有讲Spring源码的书”，店员得跑到书架上一本本翻，翻不到就在本子上一页页查，体验极差。
- 库存数据等于摆设。系统里标着“可借”的书，可能在架位上早就不见了；被读者随手放错位置的书，两个月后才会有人发现。
- 借还登记靠手写。一本书被谁借走、什么时候该还，都记在纸质登记本上。书一多，经常漏记还书日期，逾期了也不知道该提醒谁。
- 热门书排队靠抢。一本新到的高并发/性能类图书，一天能有三四个人问，最后先到先得，其他人只能干等，没有任何预约机制。
这四个痛点决定了平台的核心定位：它不是一个纯做图书信息展示的网站，而是一个围绕“查询—预约—借还—逾期管理”的图书事务处理系统。
1.2 平台需要覆盖的核心业务链路
结合痛点，我把静思书屋的业务链路拆成了三段：
- 图书供给侧：管理员做新书入库、旧书下架、书目标签维护，每本书对应一个唯一的物理条码。
- 读者服务侧：读者检索图书、查看详情与库存、发起借阅申请、归还图书、续借、预约热门书。
- 后台管理侧：审批借阅/入库申请、处理逾期罚金、查看热门榜单、动态调整可借数量。
之前提的“审批流”，在静思书屋中主要体现在两块：普通读者借阅申请需要经过管理员审批（防止超借、超期未还的人继续借书），以及新书入库需要走过“录入—审核—上架”流程。
1.3 为什么“高性能”在这个项目里是硬指标
有人可能会说，一个小书屋能有多大的并发？还“高性能”？这是我一开始也有的想法，但实际做下来发现，中小型图书信息平台的瓶颈不在于总用户量，而在于三个人群集中的时段：每天午休、晚间和周末，读者会扎堆检索同一个关键词，比如“Java”这个词在考试季前后访问量会突然冲到平日的十几倍，首页轮播图和热门榜单接口极易被打爆。
再加上管理员会不停地刷新库存页面、读者端频繁提交预约请求，如果代码在SQL层面或缓存设计上偷懒，这台服务器会在最需要稳定的时候掉链子。因此，我在设计之初就定下了几个量化指标：首页响应时间不超过200ms，图书查询接口TP95响应时间不超过500ms，借阅申请提交高峰期的错误率不超过0.1%。后面所有技术选型、表设计和代码优化，都是围绕这几个数字展开的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型的弯路与定稿：Spring Boot+JSP这套组合为什么合适
技术选型是整个项目里最容易被忽视但实际上最值得复盘的部分。我在早期参考网上很多教程，差点把项目做成了Struts2+Spring+Hibernate的“古董组合”，后来冷静下来砍掉重来，才确定了一套兼顾教学、实现和运行效率的方案。
2.1 Struts2和Hibernate带来的教训
第一版我确实试过Struts2+Hibernate。Struts2的拦截器概念很经典，但放到今天，它的配置繁琐程度和社区活跃度已经不太适合新项目落地；Hibernate的ORM自动映射在表结构简单时很省事，但是静思书屋的图书表和借阅记录表之间存在大量动态统计查询，用Hibernate硬写HQL或Criteria反而别扭，遇到一次查询关联三张表、还要做动态条件拼接的情况，HQL的调试成本直线上升。
另一个坑是依赖冲突。Struts2和Spring整合时需要非常小心版本匹配，不然各种“ClassNotFound”会和你在生产环境里捉迷藏。折腾两周后，我做了一个很清醒的决定：既然项目不是老系统维护，没必要给未来的自己挖坑，干脆用目前Java Web领域更主流的Spring Boot + MyBatis组合。
2.2 定稿后的技术栈组成与理由阐述
最终技术栈如下：
| 层次 | 选型 | 选它的核心理由 |
|---|---|---|
| 开发框架 | Spring Boot 2.7 + Spring MVC | 自动配置减少大量XML，内置Tomcat，开发调试效率高 |
| ORM层 | MyBatis + 手写SQL | 复杂统计、动态SQL方便，SQL执行可控、可针对性优化 |
| 视图层 | JSP + JSTL + jQuery + Bootstrap | 服务端渲染首屏，前端只处理局部交互，开发门槛低 |
| 数据库 | MySQL 8.0 | 关系型数据模型清晰，全文索引和JSON类型都可用 |
| 缓存 | Redis | 处理热门榜单、图书详情热点数据，降低MySQL压力 |
| 前端资源 | jQuery + Ajax | 审批流、借阅状态等异步交互，代码简单粗暴但稳定 |
Spring Boot提供的能力恰好覆盖了我的所有需求：可以用一个@RestController快速暴露JSON接口，也可以用@Controller配合JSP做页面跳转。MyBatis则可以让我把精力放在SQL本身，而不是去猜框架到底生成了什么低效语句。
2.3 保留JSP渲染而不彻底前后端分离的原因
这个点我在知乎、掘金上都看到过很多争论。说实话，如果静思书屋面向公网海量用户，我会毫不犹豫地选择前后端分离，Vue或React + 后端纯API。但当我评估了项目的现实约束后，发现JSP服务端渲染反而更合适：
- 项目核心页面大多是图书列表、详情、用户借阅记录这类以内容展示为主的页面，首屏渲染用JSTL在服务端循环输出HTML，用户看到内容的耗时比先加载JS再发Ajax要