“静思书屋”这个项目是我去年花了大概两个月时间从零到一完整做出来的一个图书信息平台。当初启动它的目的很简单一是想把自己在Java Web方向上的知识系统梳理一遍二是确实需要一个能承载完整业务闭环的实战项目用来验证那些平时只在文档里见过的技术方案到底靠不靠谱。项目本身不复杂就是一个典型的图书管理系统包含图书检索、分类浏览、借阅管理、用户评论、热门排行这些模块但我在做的时候刻意没有把它做成那种“增删改查四件套”的演示项目而是从真实场景出发把性能、并发、缓存、部署这些平时容易被忽略的东西都认真地做了一遍。这篇文章想把整个项目的完整思路、技术选型背后的取舍、核心模块的实现细节以及我实际踩过的一些坑都原原本本分享出来。如果你正在准备Java Web方向的实战项目或者想把自己的CRUD项目往“高性能”方向升一档这篇内容应该能帮你少走不少弯路。1. 项目整体设计与技术选型1.1 核心需求与功能边界动手之前我先花了不少时间梳理需求。图书信息平台这类系统最核心的使用场景无非三个读者找书、管理员管书、系统本身能扛住一定的并发访问。我给自己定的目标是做一个能支撑数千人同时在线检索、日均请求量在十万级的小型平台而不是那种只有一个管理后台的玩具项目。功能上最终圈定了这几个模块图书检索支持按书名、作者、ISBN、分类进行组合查询支持拼音首字母检索。图书详情展示书目信息、馆藏状态、借阅历史、用户评论与评分。借阅管理用户在线借书、预约、续借管理员处理借还审核。用户体系注册、登录、密码加密存储、基于Token的会话管理。热门排行基于借阅次数和用户行为数据生成周榜、月榜。后台管理图书录入、上下架、分类维护、用户管理。有一件事我特别想强调功能边界一定要在开发前画清楚。我见过太多人做项目时边做边加需求最后代码里到处是补丁。我这次把所有模块列成一个清单标好优先级先把核心链路检索→详情→借阅跑通再做排行和后台这种辅助功能。1.2 技术栈选型与核心取舍技术选型上我采用的组合是典型的Java Web企业级开发栈层面选型选择理由后端框架Spring Boot 2.7生态成熟自动配置大幅降低搭建成本持久层MyBatis-Plus既有手写SQL的灵活性又有单表CRUD的便捷数据库MySQL 8.0稳定可靠事务支持完善索引能力足够缓存Redis 6.x高性能KV存储适合缓存热点数据和分布式锁前端Thymeleaf Bootstrap jQuery服务端渲染利于SEO前端交互复杂度可控构建工具Maven主流选择依赖管理方便部署Docker Nginx环境一致性高反向代理与静态资源分发效率好选这套组合核心思路是“主流优先、不过度设计”。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, 30MySQL需要先把前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 数据库连接池参数的调优过程数据库连接池是整个系统的性能命脉。我用的是HikariCPSpring 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核8GMySQL最大连接数允许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-age86400让浏览器缓存静态资源一天。这样用户刷新页面时大部分资源都从本地缓存加载只有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:MaxMetaspaceSize256m -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 GCG1GC能更好地控制停顿时间避免长时间STWStop The World导致请求延迟飙升。我的服务是接口响应类应用延迟比吞吐量更重要所以G1GC是合理选择。这里我还想分享一个必踩的坑容器内使用JDK时如果没有正确配置内存参数Java应用很容易出现OutOfMemoryError。我发现这个问题的方式很经典——服务运行了大半天后某个接口突然响应极慢日志中出现java.lang.OutOfMemoryError: insufficient memory。排查后发现是JVM的堆内存设置超过了容器的内存限制触发了容器内核的OOM机制。解决方式是严格控制Xmx的值并额外加上-XX:UseContainerSupportJDK 8u191以后默认开启让JVM感知容器内存限制。5.3 性能压测数据与瓶颈分析压测工具用了JMeter。我设计了三个典型的压测场景场景一图书检索接口模拟10个并发用户持续5分钟。场景二图书详情接口模拟50个并发用户持续5分钟。场景三综合混合场景模拟30个并发用户包含检索、详情、借阅操作持续10分钟。压测结果汇总如下场景并发数平均响应时间99%响应时间QPS错误率图书检索1068ms156ms1480%图书详情5085ms220ms5860%混合场景30132ms341ms3060.02%混合场景中那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_countJava实体类的属性是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 六条避坑经验总结项目做下来我总结了一些在实际中踩过坑才真正明白的经验数据库字段类型尽量跟Java类型一一对应不要图省事都用varchar否则后期各种类型转换问题会让人抓狂。缓存过期时间尽量加随机偏移量。固定过期时间会导致缓存同时失效引发缓存雪崩大量请求直接打到数据库。所有涉及金额、库存、数量的操作都必须用乐观锁或悲观锁保护起来单纯靠业务逻辑判断是挡不住并发的。Spring Boot项目升级依赖时一定要关注版本兼容性。尤其是MyBatis-Plus、Redis、Thymeleaf等组件的版本间配合不匹配会出现很多莫名其妙的报错。任何对外的接口都要做参数校验不要信任前端传过来的任何值。图书ID不存在的请求如果没做空值缓存很容易拖垮数据库。日志里不要打印敏感信息。用户密码脱敏、Token脱敏。这不是技术问题是职业习惯。7. 个人操作心得与后续扩展方向写到这里我想分享几个在整个项目过程中感受最深的事。第一技术选型真的要克制。这个项目最初我心动过要不要引入微服务、消息队列、Elasticsearch这些“大厂标配”组件。后来仔细评估发现系统当前的规模和复杂度根本用不上这些强行引入反而会增加部署难度和维护成本。图书检索用MySQL全文索引就够异步任务量也不大没有用消息队列的必要。好的架构不是炫技是在当前约束条件下最合适的方案。第二数据模型设计值得多花时间。我在数据库设计上投入的三天时间换来了后面写业务代码时的省心。尤其是冗余计数、索引设计这类小细节当时多花一点功夫后面一个月的开发都会顺很多。很多问题如果到开发中后期才意识到表结构设计不合理改起来成本极高甚至要推倒重来。第三性能测试必须前置。我是大体功能完成后才做的压测实际上这个节奏偏晚了。建议是每个核心模块完成后就顺手做一次小规模压测早点暴露性能问题后面集中调优时压力会小很多。最后说下这个项目后续还能怎么扩展。我目前计划中的方向包括引入Elasticsearch替代MySQL全文索引让检索能力更强加入Redis高级数据结构用ZSet实现更精确的排行榜把借阅流程改造成基于消息队列的异步模式进一步提高系统的吞吐能力同时用户评论功能可以拓展成简单的社区互动模块增加用户粘性。这些方向都是基于当前系统的痛点逐步演进而不是为了追新而盲目引入。静思书屋这个项目让我把Java Web技术栈从头到尾扎扎实实地过了一遍。从需求分析、数据库设计、后端开发、前端交互到部署上线、性能调优每一个环节都有实实在在的收获。如果你也在做类似的项目希望这篇分享能帮你避开一些我踩过的坑也欢迎根据你实际的技术栈和场景在这套方案的基础上做适合你自己的调整。