Java Web实战：图书信息平台从设计到高性能部署全解析

“静思书屋”这个项目，是我去年花了大概两个月时间，从零到一完整做出来的一个图书信息平台。当初启动它的目的很简单：一是想把自己在Java Web方向上的知识系统梳理一遍，二是确实需要一个能承载完整业务闭环的实战项目，用来验证那些平时只在文档里见过的技术方案到底靠不靠谱。项目本身不复杂，就是一个典型的图书管理系统，包含图书检索、分类浏览、借阅管理、用户评论、热门排行这些模块，但我在做的时候，刻意没有把它做成那种“增删改查四件套”的演示项目，而是从真实场景出发，把性能、并发、缓存、部署这些平时容易被忽略的东西都认真地做了一遍。

这篇文章想把整个项目的完整思路、技术选型背后的取舍、核心模块的实现细节，以及我实际踩过的一些坑，都原原本本分享出来。如果你正在准备Java Web方向的实战项目，或者想把自己的CRUD项目往“高性能”方向升一档，这篇内容应该能帮你少走不少弯路。

1. 项目整体设计与技术选型

1.1 核心需求与功能边界

动手之前，我先花了不少时间梳理需求。图书信息平台这类系统，最核心的使用场景无非三个：读者找书、管理员管书、系统本身能扛住一定的并发访问。我给自己定的目标是做一个能支撑数千人同时在线检索、日均请求量在十万级的小型平台，而不是那种只有一个管理后台的玩具项目。

功能上，最终圈定了这几个模块：

• 图书检索：支持按书名、作者、ISBN、分类进行组合查询，支持拼音首字母检索。
• 图书详情：展示书目信息、馆藏状态、借阅历史、用户评论与评分。
• 借阅管理：用户在线借书、预约、续借，管理员处理借还审核。
• 用户体系：注册、登录、密码加密存储、基于Token的会话管理。
• 热门排行：基于借阅次数和用户行为数据，生成周榜、月榜。
• 后台管理：图书录入、上下架、分类维护、用户管理。

有一件事我特别想强调：功能边界一定要在开发前画清楚。我见过太多人做项目时边做边加需求，最后代码里到处是补丁。我这次把所有模块列成一个清单，标好优先级，先把核心链路（检索→详情→借阅）跑通，再做排行和后台这种辅助功能。

1.2 技术栈选型与核心取舍

技术选型上，我采用的组合是典型的Java Web企业级开发栈：

选这套组合，核心思路是“主流优先、不过度设计”。Spring Boot当然不是Java Web的全部，但它的生态确实能让你把精力集中在业务本身，而不是花大量时间在XML配置和组件装配上。可能有人会问，为什么不选Servlet + JSP这种更“原始”的Java Web方案？我的看法是，如果你目标是学习底层原理，那手写Servlet是有价值的；但如果你想做一个真正能部署、能承受一定压力的系统，Spring Boot是更合理的选择。我也在项目中保留了Servlet规范的底子，比如使用Filter实现登录拦截、编码过滤，这样基础的Web机制并没有被框架完全遮住。

另外一个关键取舍是前后端分离与否。我最终没有选择Vue + RESTful API这种前后端分离架构，而是用Thymeleaf做服务端渲染。原因很简单：图书检索类的业务，SEO有需求，服务端渲染更友好，而且项目规模不大，引入一套Node构建流程会增加不少维护成本。不过，在借阅操作、评论提交这些需要即时反馈的场景，我用jQuery发Ajax请求，搭配后端返回JSON数据，兼顾了交互体验和开发效率。这种混合模式在实际项目中很常见，也很实用。

2. 数据库设计与核心模块实现

2.1 数据模型设计思路

数据库设计是整个项目的地基。我用了三天时间反复推敲表结构，最终确定了这样几张核心表：

• users：用户表，字段包括id、username、password、salt、email、role、status、create_time。
• books：图书表，核心字段有id、title、author、publisher、isbn、category_id、summary、cover_url、total_count、available_count、borrow_count。
• categories：分类表，id、name、parent_id，支持多级分类。
• borrow_records：借阅记录表，id、user_id、book_id、borrow_time、due_time、return_time、status。
• comments：评论表，id、book_id、user_id、content、rating、create_time。
• hot_search：热搜词表，用于记录用户搜索关键词和频次。

这里有几个设计细节值得展开讲讲。

第一个是图书表的available_count（可借数量）和borrow_count（累计借出次数）。一开始我图省事，想在借阅时实时count一下借阅记录表来得到可借数量，后来仔细一想，这个方案在并发场景下很容易出问题：几十个人同时查一本书，每次都去做统计查询，数据库压力会非常大。所以我最终采用了“冗余计数”的方式，在books表上直接维护可借余量，借书成功时available_count减一，还书时加一。这种用空间换时间的思路，在高并发读取场景下非常有效。

第二个是评论表的rating字段。评论区涉及用户打分，我需要存小数还是整数？最终选择存TINYINT类型，范围0-5分，避免浮点精度问题。查询平均分时在SQL里用AVG函数计算，后端的Java类型用Double接收，这样逻辑清晰也不会出错。

第三个是索引设计。这是一个非常关键的环节。我在books表的title、author、isbn字段上分别建立了普通索引，其中isbn还加了唯一约束，因为每本书的ISBN是唯一的。针对组合查询场景，我建了一个联合索引（category_id, title），这样按分类浏览时还能利用索引前缀进行排序，性能会比索引条件分散好很多。borrow_records表上则建了（user_id, status）联合索引，因为查询“某用户当前借了哪些书”是最频繁的访问路径。

2.2 图书检索模块的SQL优化实战

检索模块是平台的门面，用户进入系统第一件事就是搜书。我最初实现的检索逻辑很简单，直接用LIKE模糊匹配：

SELECT * FROM books WHERE title LIKE CONCAT('%', #{keyword}, '%') OR author LIKE CONCAT('%', #{keyword}, '%')

本地数据量只有几千条时，这个查询响应时间在50毫秒以内，完全没压力。但我用脚本灌了10万条测试数据后，发现这个查询慢得离谱，最差时达到1.8秒。问题出在LIKE前置通配符会让索引失效，MySQL只能全表扫描。

优化思路分三步走：

第一步，对关键词进行分词处理。我不去做复杂的语义分析，只做最简单的空格切分和去重，然后对每个词分别查询，再用布尔逻辑合并结果。比如用户搜“Java 并发编程”，我会拆成“Java”和“并发编程”两个关键词，分别匹配书名。

第二步，用全文索引替换LIKE。MySQL 8.0的InnoDB引擎支持中文全文索引，配合ngram分词器，效果比LIKE好很多。建索引的语句是：

ALTER TABLE books ADD FULLTEXT INDEX ft_index (title, author, summary) WITH PARSER ngram;

查询语句改写为：

SELECT * FROM books WHERE MATCH(title, author, summary) AGAINST(#{keyword} IN NATURAL LANGUAGE MODE)

实测10万条数据下，全文索引查询耗时从1.8秒降到了80毫秒左右，提升非常明显。

第三步，对全文索引的搜索结果做兜底。全文索引有个特点，用户输入特殊字符或者分词结果为空时，会查不到数据。所以我会先判断关键词是否包含空格或特殊字符，如果全文索引没有命中，再回退到LIKE查询。同时，把LIKE查询限制在title字段，避免author和summary参与全表扫描。

注意：MySQL全文索引的ngram分词器对中文的支持确实不错，但分词粒度需要根据业务调节。默认ngram_token_size是2，也就是按两字一组切分。搜索单字关键词时可能匹配不到结果，这时候需要在MySQL配置文件里调整参数，或者在应用层做单字兜底查询。

2.3 分页查询与深分页问题

图书列表和搜索结果都需要分页。一开始我用的是MyBatis-Plus自带的Page对象，简单方便，limit偏移量也顺手。但数据量大了以后，深分页问题就暴露出来了。

比如用户翻到第10000页，SQL会写成LIMIT 300000, 30，MySQL需要先把前30万条数据全部查出来再丢弃，这个代价非常大。我实测深分页查询耗时在2秒以上，完全不可接受。

解决方案是用“延迟关联”或者“游标分页”。延迟关联的思路是，先只查询主键id，再通过id关联回原表查询完整数据：

SELECT b.* FROM books b INNER JOIN ( SELECT id FROM books WHERE category_id = #{categoryId} ORDER BY borrow_count DESC LIMIT #{offset}, #{pageSize} ) t ON b.id = t.id ORDER BY b.borrow_count DESC

这样内层查询只需要扫描主键索引，数据量比扫描全行要小得多，效率提升非常明显。实测同样条件下，深分页查询时间从2秒降到了200毫秒以内。

如果数据量进一步增长，我觉得就该考虑游标分页了，也就是用“WHERE id > #{lastId} ORDER BY id LIMIT 30”这种方式，彻底告别offset。但游标分页有一个前提，就是排序字段必须是唯一且有序的。图书列表如果要按借阅次数排序，用游标分页就比较麻烦，需要额外记录上次位置的borrow_count值。我目前这个项目用延迟关联已经足够，游标分页可以作为下一步的优化方向写进技术方案里。

3. 高性能关键环节实践

3.1 数据库连接池参数的调优过程

数据库连接池是整个系统的性能命脉。我用的是HikariCP，Spring Boot 2.x默认集成的就是它，性能好，稳定性也可靠。但默认参数并不一定适合所有场景，我花了些时间做了针对性调整。

我的核心配置是这样的：

spring: datasource: hikari: minimum-idle: 10 maximum-pool-size: 30 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 pool-name: HikariPool-Book

这里有几个参数的工作原理我解释一下。maximum-pool-size是连接池上限，不是越大越好。每条连接都会占用数据库端的内存资源，连接数过高时，MySQL的线程切换反而会拖慢性能。30是压测之后得出的数值：机器是4核8G，MySQL最大连接数允许128，我设置了30，既保证了并发能力，又不会把资源耗尽。

minimum-idle设置为10，目的是避免突发流量时频繁创建连接。创建连接需要TCP握手、认证、建会话，整个过程大约那么几十毫秒，如果连接池里没有空闲连接，请求就只能排队等着。所以保持10个常驻连接，能让绝大多数请求直接复用。

还有一个非常容易踩的坑是connection-timeout和max-lifetime的配合。connection-timeout是客户端获取连接的最大等待时间，我调成30秒，是因为个别慢查询可能会占用连接较久，如果等待时间太短，并发尖峰时会出现大量获取连接超时。max-lifetime设置成30分钟，要确保小于MySQL服务器端的wait_timeout，不然连接被MySQL主动断开后，连接池还在继续使用，就会出现奇怪的异常。这是一个很典型的经验教训。

3.2 Redis缓存策略与缓存穿透处理

缓存设计是我在这个项目里觉得收获最大的部分。图书检索是一个典型的读多写少场景，热门书籍的详情被反复查看，如果每次都去查数据库，既慢又浪费资源。

我的缓存策略分两层：

第一层是热点图书详情缓存。用户查看书详情时，先从Redis读取，key设计为book:detail:{id}，缓存内容为图书信息的JSON字符串，过期时间设为30分钟，并加一个随机0-5分钟的偏移量，防止大量缓存同时过期造成雪崩。这样设计的核心指标是缓存命中率，我统计过，正常情况下命中率维持在85%以上。

第二层是分类列表缓存。用户按分类浏览时，同一分类的书单也会被反复查询，所以我把首页推荐位和热门分类的前20本图书也缓存到了Redis里，key为book:category:{categoryId}:top20，过期时间为10分钟。

缓存穿透是我重点防护的问题。所谓穿透，就是查询一个一定不存在的数据，比如用户手动构造一个不存在的图书ID去请求，每次都会绕过缓存直达数据库。防护方案是使用空值缓存：查询数据库后，如果返回null，我仍然在Redis里存一个空值标记，过期时间设短一些，比如3分钟。

public Book getBookDetail(Long bookId) { String cacheKey = "book:detail:" + bookId; String cached = redisTemplate.opsForValue().get(cacheKey); if (cached != null) { if ("EMPTY".equals(cached)) { return null; } return JSON.parseObject(cached, Book.class); } Book book = bookMapper.selectById(bookId); if (book == null) { redisTemplate.opsForValue().set(cacheKey, "EMPTY", 3, TimeUnit.MINUTES); } else { redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(book), 30 + RandomUtil.randomInt(5), TimeUnit.MINUTES); } return book; }

这段代码还需要配合布隆过滤器做前置拦截，但考虑到项目规模，空值缓存已经能挡住绝大多数恶意请求，布隆过滤器可以作为后续迭代方案记录下来。

3.3 借阅流程中的并发控制与分布式锁

借阅这个动作，本质是一个“读-判断-写”的事务流程：先检查图书可借数量是否大于0，如果大于0则执行借阅操作并把数量减一。这个流程在高并发下有一个经典的超卖问题：两个用户同时发起借阅，都读到available_count为1，都能通过判断，结果两个人都借成功了，但书只有一本。

解决思路从数据库和分布式锁两个层面来做。

数据库层面，我用了乐观锁机制，在books表中增加version字段（或者直接用条件和数量判断）。执行借阅时，SQL条件里带上数量限制：

UPDATE books SET available_count = available_count - 1, version = version + 1 WHERE id = #{bookId} AND available_count > 0

如果影响行数为0，说明可借数量已经为0，借阅失败。这种方式简单可靠，无需额外的锁服务。但有一个问题：如果借阅操作后还需要更新其他表（比如插入借阅记录），且这些操作需要保证原子性，那单纯靠这条update语句还不够。因为在并发情况下，可能出现两个请求都成功update了books表，其中一个随后插入borrow_records失败，导致数据不一致。

所以我在应用层加了事务，并用Redis分布式锁保护整个借阅流程。借助Redis的SETNX命令实现锁：

String lockKey = "lock:borrow:" + bookId; String requestId = UUID.randomUUID().toString(); boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, 10, TimeUnit.SECONDS); if (!locked) { throw new BizException("系统繁忙，请稍后重试"); } try { // 执行借阅事务 return borrowService.doBorrow(userId, bookId); } finally { // 释放锁时需要校验requestId，防止误删他人锁 String lockValue = redisTemplate.opsForValue().get(lockKey); if (requestId.equals(lockValue)) { redisTemplate.delete(lockKey); } }

Redis分布式锁虽然有效，但要注意锁的粒度。我按bookId加锁，意味着同一本书的借阅请求会被串行化，不同书的借阅可以并行，性能和正确性取得了平衡。锁的超时时间设置为10秒，正常情况下一次借阅事务在几百毫秒内就能完成，10秒是足够的。

注意：释放锁之前一定要校验value是否自己的requestId，否则可能因为超时释放了别人的锁，导致并发保护失效。这一点是用Redis实现分布式锁时最容易犯的错误。

4. 前端页面与交互实现

4.1 页面架构与Thymeleaf模板设计

前端的整体思路是“服务端渲染为主，局部异步更新为辅”。页面结构上，我做了三个基础模板片段：header（导航栏+搜索框）、footer（版权信息）、sidebar（热门排行+分类导航），用Thymeleaf的th:replace语法在多个页面中复用。

关于静态资源，我把CSS、JS和图片放在Spring Boot的static目录下，并启用Nginx对静态文件做独立处理，不经过Java应用。Nginx对静态文件的并发处理能力比Tomcat强得多，而且缓存命中后根本不访问磁盘，响应速度完全是另一个量级。生产环境中，Nginx直接负责css、js、images等静态资源的访问，只有动态请求才会反向代理到Tomcat。我实测了一下，启用静态资源缓存后，页面整体加载时间从500多毫秒降到了150毫秒左右。

Thymeleaf的一个使用技巧是：如果某个片段在页面中不是必备的，可以使用th:if延迟渲染。比如侧边栏的热门图书排名，数据从Redis中读取，如果Redis中没有缓存，我先把页面主内容渲染出来，再通过Ajax异步加载排名数据，这样首屏响应速度更快，用户体感也更好。

4.2 搜索框的自动补全与防抖处理

搜索自动补全是提升用户体验的一个细节功能。用户输入关键词时，前端会通过Ajax请求后端接口获取提示词列表。但这个功能有一个隐患：用户每输入一个字符就发一次请求，会造成大量无意义的请求，后端压力大，前端也会出现响应错乱。

解决方案是前端做防抖（debounce）处理。核心逻辑：用户停止输入300毫秒后，才发起Ajax请求；如果用户在这300毫秒内继续输入，则重置计时器。我用JavaScript实现了一个简单的防抖函数：

function debounce(fn, delay) { let timer = null; return function (...args) { if (timer) clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; } const fetchSuggestions = debounce(function (keyword) { if (!keyword.trim()) { $('#suggest-box').hide(); return; } $.getJSON('/api/search/suggest', { keyword: keyword }, function (data) { renderSuggestions(data); }); }, 300);

后端对应的接口是/api/search/suggest，通过Redis里维护的热搜词集合，结合数据库模糊查询，返回匹配度最高的前10个词。前端在渲染建议列表时，同步监听键盘上下键和回车键，让用户可以不脱离键盘完成搜索。

4.3 页面加载性能的细节优化

页面性能优化是一项需要抠细节的工作。我做了三件事：

第一，启用Gzip压缩。在Nginx配置中开启gzip，对html、css、js、json类型文件进行压缩。图书封面图虽然已经是压缩过的jpg，但页面结构文字的压缩率非常可观，整体传输体积减少了大约60%。

第二，利用HTTP缓存头。Nginx对静态资源添加Cache-Control: max-age=86400，让浏览器缓存静态资源一天。这样用户刷新页面时，大部分资源都从本地缓存加载，只有html文档需要重新请求。

第三，图片延迟加载。图书列表页有大量封面图，如果一次性全部加载，会占用大量带宽并阻塞渲染。我在页面中使用懒加载，只有当图片即将进入视口时才真正发起加载。实现方式是用浏览器原生的IntersectionObserver API，监听图片元素的可见性，代码简洁且性能高效。

这些优化叠加在一起的效果非常直观。优化前，列表页首屏加载需要约1.2秒，优化后压缩到300毫秒以内。对于图书信息平台这种以浏览为主的系统，页面加载速度直接影响用户留存率，这部分的投入是很值得的。

5. 部署上线与性能压测

5.1 Docker容器化部署与编排

部署方案上，我用Docker Compose编排了四个容器：MySQL、Redis、Java应用、Nginx。选择Docker的关键原因在于环境一致性：本地开发环境、测试环境、生产环境完全一致，彻底消除了“在我电脑上能跑”的尴尬。

docker-compose.yml的核心配置如下：

version: '3.8' services: mysql: image: mysql:8.0 container_name: book-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: book_db volumes: - ./mysql-data:/var/lib/mysql ports: - "3306:3306" healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s retries: 3 redis: image: redis:6.2 container_name: book-redis ports: - "6379:6379" app: build: . container_name: book-app depends_on: mysql: condition: service_healthy redis: condition: service_started environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/book_db SPRING_DATA_REDIS_HOST: redis ports: - "8080:8080" nginx: image: nginx:1.24 container_name: book-nginx depends_on: - app volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf - ./static:/usr/share/nginx/html/static ports: - "80:80"

这里有一个值得注意的编排技巧：MySQL容器一定要配置healthcheck，并且Java应用容器要使用depends_on的condition: service_healthy，这样能确保MySQL完全启动后Java应用才启动。否则MySQL容器虽然被启动了，但实际还在初始化阶段，Java应用连接数据库会报错，退出后Docker会不断重启容器，形成一个看起来很诡异的问题。

我的经验是在启动完成后，还要检查Java应用容器日志，确认“Started BookApplication”出现，才算真正部署成功。

5.2 JVM参数调优与内存问题排查

Java Web应用的高性能，离不开JVM的正确配置。我在Dockerfile中设置了容器内存限制，并针对JVM做了参数调整：

FROM openjdk:8-jdk-alpine EXPOSE 8080 ENV JAVA_OPTS="-Xms512m -Xmx512m -XX:MaxMetaspaceSize=256m -XX:+UseG1GC" COPY target/book-platform.jar /app.jar ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar /app.jar"]

JVM堆内存设置成固定的512m，而不是用默认策略，原因是容器内存上限通常是1g，如果让JVM自动管理堆内存，堆可能扩得很大，导致系统内存不足，触发OOM Killer把容器杀掉。固定堆大小能让JVM在启动时就把内存分配好，运行过程中不再动态申请大块内存，对容器环境更友好。

垃圾回收器选择了G1GC。这个决策虽然对性能的影响最不直观，但对服务响应时间却至关重要。相比默认的Parallel GC，G1GC能更好地控制停顿时间，避免长时间STW（Stop The World）导致请求延迟飙升。我的服务是接口响应类应用，延迟比吞吐量更重要，所以G1GC是合理选择。

这里我还想分享一个必踩的坑：容器内使用JDK时，如果没有正确配置内存参数，Java应用很容易出现OutOfMemoryError。我发现这个问题的方式很经典——服务运行了大半天后，某个接口突然响应极慢，日志中出现java.lang.OutOfMemoryError: insufficient memory。排查后发现，是JVM的堆内存设置超过了容器的内存限制，触发了容器内核的OOM机制。解决方式是严格控制Xmx的值，并额外加上-XX:+UseContainerSupport（JDK 8u191以后默认开启），让JVM感知容器内存限制。

5.3 性能压测数据与瓶颈分析

压测工具用了JMeter。我设计了三个典型的压测场景：

• 场景一：图书检索接口，模拟10个并发用户，持续5分钟。
• 场景二：图书详情接口，模拟50个并发用户，持续5分钟。
• 场景三：综合混合场景，模拟30个并发用户，包含检索、详情、借阅操作，持续10分钟。

压测结果汇总如下：

混合场景中那0.02%的错误率，来自借阅接口在高并发下的锁等待超时。实际排查后发现，是Redis连接池默认配置过小，导致部分请求在获取Redis连接时等待超时。我调大了lettuce连接池参数，并设置了合理的等待时间，错误率迅速降到了0。

压测给我最大的启发是：性能瓶颈往往是系统性的，需要从应用代码、数据库、中间件、JVM等多个层面综合分析。只调优一个环节，效果非常有限。比如单纯优化SQL，但如果数据库连接池太小，QPS还是上不去；单纯扩大连接池，但SQL本身有性能问题，连接池里的连接都会被慢查询占满。

6. 常见问题与排查技巧

6.1 开发期典型报错实录

这个项目开发过程中，我记录了一堆典型的报错，挑几个有代表性的分享。

第一个是数据源连接失败。启动Spring Boot时，控制台报错Cannot create PoolableConnectionFactory。我反复检查账号密码、数据库地址都没问题，最后发现是MySQL 8.0的驱动采用的是新版com.mysql.cj.jdbc.Driver，而当时pom.xml里引用的还是老版本驱动。升级驱动后问题解决。

第二个是MyBatis-Plus的字段映射问题。我在数据库表中定义了一个字段borrow_count，Java实体类的属性是borrowCount，按理说MyBatis-Plus会自动开启驼峰映射。但我发现查询结果里borrowCount始终是null。排查后发现问题出在我自定义的XML SQL文件里，手写的SQL中字段别名没有加上去，导致MyBatis无法映射。解决方式是给SQL查询列显式添加别名borrow_count AS borrowCount。

第三个是Thymeleaf模板解析异常。页面打开时报错org.thymeleaf.exceptions.TemplateInputException。原因是我在模板中使用了HTML5规范的标签，但Thymeleaf在解析时遇到未闭合标签或者不标准的属性写法会报错。我后来养成了一个习惯，任何模板修改后，先在编译阶段通过thymeleaf的templates目录扫描做校验，而不是等到运行时才发现问题。

6.2 线上问题的应急排查思路

有一次线上环境出现了一个诡异的问题：服务运行了大约五个小时后，某个接口突然变得很慢，重启后恢复，但过一段时间又复发。我一度以为是代码存在内存泄漏，反复检查之后发现不是。

通过查看GC日志，我注意到老年代内存一直在缓慢增长，增长趋势与该接口的慢请求时间线高度重合。进一步dump堆内存分析后，发现是Redis缓存中有大量用户验证码的临时数据，过期时间为30分钟，但有一个接口在存储验证码时把过期时间误传成了3000分钟，导致大量过期数据没有清理。虽然这只是测试数据留下了不少无效缓存，但它在Redis中占据大量内存，间接拖慢了整体性能。

另外一个排查经验是：遇到线上问题先看监控曲线，不要盲目看代码。我给项目接了一个简单的监控方案：Spring Boot Actuator暴露/actuator/health和/actuator/metrics接口，配合Nginx日志统计QPS和错误率。这样系统一旦异常，我可以通过监控曲线快速缩小问题范围——是入口流量波动，还是中间件瓶颈，或者是应用内部异常，再决定深入哪个方向。

6.3 六条避坑经验总结

项目做下来，我总结了一些在实际中踩过坑才真正明白的经验：

1. 数据库字段类型尽量跟Java类型一一对应，不要图省事都用varchar，否则后期各种类型转换问题会让人抓狂。

2. 缓存过期时间尽量加随机偏移量。固定过期时间会导致缓存同时失效，引发缓存雪崩，大量请求直接打到数据库。

3. 所有涉及金额、库存、数量的操作，都必须用乐观锁或悲观锁保护起来，单纯靠业务逻辑判断是挡不住并发的。

4. Spring Boot项目升级依赖时，一定要关注版本兼容性。尤其是MyBatis-Plus、Redis、Thymeleaf等组件的版本间配合，不匹配会出现很多莫名其妙的报错。

5. 任何对外的接口都要做参数校验，不要信任前端传过来的任何值。图书ID不存在的请求，如果没做空值缓存，很容易拖垮数据库。

6. 日志里不要打印敏感信息。用户密码脱敏、Token脱敏。这不是技术问题，是职业习惯。

7. 个人操作心得与后续扩展方向

写到这里，我想分享几个在整个项目过程中感受最深的事。

第一，技术选型真的要克制。这个项目最初我心动过要不要引入微服务、消息队列、Elasticsearch这些“大厂标配”组件。后来仔细评估，发现系统当前的规模和复杂度根本用不上这些，强行引入反而会增加部署难度和维护成本。图书检索用MySQL全文索引就够，异步任务量也不大，没有用消息队列的必要。好的架构不是炫技，是在当前约束条件下最合适的方案。

第二，数据模型设计值得多花时间。我在数据库设计上投入的三天时间，换来了后面写业务代码时的省心。尤其是冗余计数、索引设计这类小细节，当时多花一点功夫，后面一个月的开发都会顺很多。很多问题如果到开发中后期才意识到表结构设计不合理，改起来成本极高，甚至要推倒重来。

第三，性能测试必须前置。我是大体功能完成后才做的压测，实际上这个节奏偏晚了。建议是，每个核心模块完成后就顺手做一次小规模压测，早点暴露性能问题，后面集中调优时压力会小很多。

最后说下这个项目后续还能怎么扩展。我目前计划中的方向包括：引入Elasticsearch替代MySQL全文索引，让检索能力更强；加入Redis高级数据结构，用ZSet实现更精确的排行榜；把借阅流程改造成基于消息队列的异步模式，进一步提高系统的吞吐能力；同时，用户评论功能可以拓展成简单的社区互动模块，增加用户粘性。这些方向都是基于当前系统的痛点逐步演进，而不是为了追新而盲目引入。

静思书屋这个项目，让我把Java Web技术栈从头到尾扎扎实实地过了一遍。从需求分析、数据库设计、后端开发、前端交互到部署上线、性能调优，每一个环节都有实实在在的收获。如果你也在做类似的项目，希望这篇分享能帮你避开一些我踩过的坑，也欢迎根据你实际的技术栈和场景，在这套方案的基础上做适合你自己的调整。