大学四年攒下来的旧书堆在宿舍墙角吃灰毕业时论斤卖给废品站运气好能换杯奶茶。可另一边学弟学妹正照着书单在新书区原价下单一本薄薄的专业课教材动不动四五十块。这中间的落差值得做一个系统来填平——这也是我这次分享的项目背景基于SSM的校园旧图书共享系统。这套系统核心面向两类人一类是想要清空书架顺便回点血的大四学生另一类是能省则省、想低价收书的低年级同学。相比闲鱼等综合平台它能做到更贴合校园场景限制在校师生身份、按校区或宿舍区简化交易半径、支持站内信沟通而不用留个人手机号。技术栈用的是经典的 Java EE 组合 SSM即 Spring SpringMVC MyBatis前端做了一套响应式后台管理页面同时留了微信小程序端接入的接口设计。对于正在准备毕业设计、或者想在公司内部做一套闲置物品流转工具的同学来说这套系统的业务模型和技术骨架都能直接参考。整套系统的价值不只是“把书挂上去”这么简单。旧书交易天然有三个痛点需要解决一是书的品相信息很难标准化九成新和五成新根本是两个价格体系二是交易的信任半径有限跨校区寄快递的成本甚至比书价还高三是书籍的流转周期跟学期强相关开学季和毕业季的需求完全不同。我在设计系统时把这三个痛点拆解成了对应的产品功能和数据结构下面挨个拆开讲。1. 内容整体设计与思路拆解1.1 从“跳蚤市场”到“共享系统”的产品逻辑做校园旧书共享系统最忌讳的就是把它做成一个普通的商品列表页。图书跟衣服、数码产品的差别在于内容高度标准化——同一本书有 ISBN、有固定的书名作者出版社这决定了数据建模可以复用“书目信息”而不是每本书都当成独立商品来录入。所以我的第一层设计决策是把系统分成“图书信息库”和“流通实例”两层。图书信息库存的是《高等数学第七版》这种基础元数据书名、作者、ISBN、出版社、封面图、分类。流通实例则是具体某位同学手里的那一本它有几成新、有没有笔记划线、想卖多少钱、挂在哪个校区、当前状态是“在售”、“已预定”还是“已售出”。这样做最直接的好处是发布流程短。卖家只需要扫一下书背面的 ISBN系统自动从书库匹配出书名封面省去手动录入一大串信息的功夫。如果书库里还没有这条记录那就先触发一次书目创建再继续发布。这个设计思路对标的是豆瓣读书加转转的混合体而不是单纯学闲鱼。1.2 为什么是 SSM 而不是 Spring Boot现在的毕业设计和课程项目大都是 Spring Boot 一把梭可我还是选了 SSMSpring SpringMVC MyBatis作为这次项目的主干。原因有几个层面。第一SSM 是理解 Java Web 演进史的绝佳样本。Spring Boot 之所以“省事”是因为它把组件装配、自动配置、内嵌服务器全包了但很多人用了两年 Spring Boot 都没搞明白请求是怎么从 DispatcherServlet 走到 Controller、再通过 SqlSession 落库的。SSM 需要你亲手把 Spring 的 context 配置文件搭起来把 SpringMVC 的注解驱动打开把 MyBatis 的 mapper 扫描配好。这一套走下来对 IoC、AOP、ORM 的理解会是另一个深度。第二很多学校的毕业设计选题库和企业的老项目维护还在用 SSM。如果未来走外包或接私活遇到老项目的概率并不低。能在简历上写“基于SSM架构独立完成模块开发”比只会对着 Spring Initializr 勾依赖更能体现底子。第三SSM 在资源的占用上更轻。一台 2G 内存的云服务器跑 SSM Tomcat比跑 Spring Boot 全家桶加一堆 starter 稳得多。旧书共享这种低并发、事务简单的系统用 SSM 绰绰有余没必要上太重的装备。1.3 小程序端与后台的分工边界标题里同时提到了 Java 和小程序。我在设计时没有让小程序直接访问后台的 MySQL而是走了一套标准的 HTTP API。后端是 SpringMVC 的 Controller 层暴露 JSON 接口小程序端负责页面展示和交互。核心的任务分工是后台管理端PC 网页管理用户、审核图书、查看订单、管理公告、数据统计。这个端的使用者是系统管理员。小程序端微信学生用户登录后浏览书库、发布闲置、下单求购、私信沟通。这一端的体验优先保证操作轻快所以接口设计做了不少面向移动端的瘦身比如列表接口只返回当前页必需的字段详情接口才带完整描述。这种前后端分离的设计也为后面扩展别的端留了口子。比如将来想接一个公众号 H5或者做一个大屏可视化展示图书流通数据只需要继续复用现成的 API 就好。2. 核心细节解析与实操要点2.1 数据库设计中的平衡点数据库是整个系统的地基。我设计的主要数据表包括user用户表。除了常规的账号密码额外加了学号/工号字段、角色字段学生/管理员、校区字段以及状态字段正常/禁言/封禁。book_info图书元数据表。存 ISBN、书名、作者、出版社、分类ID、封面URL。为了支持模糊搜索给书名和作者都建了普通索引。book_instance图书流通实例表。关联 user 和 book_info存品相描述、笔记标注情况、期望售价、原价、所在校区、状态0在售/1已预定/2已售出/3下架。order订单表。买家下单后生成订单包含卖家ID、买家ID、实例ID、成交价格、订单状态待付款/待交接/已完成/已取消。favorite收藏表记录用户收藏了哪些在售实例。message站内信表支持买卖双方在平台上沟通。category图书分类表比如“公共基础课”、“计算机类”、“外语类”等。notice公告表管理员发布系统通知用。feedback反馈表用户可以举报违规图书或留言反馈。这套表结构有两个地方容易拍脑袋出错我特意花了心思。第一个是“一本同名的书可能对应很多个在售实例”。如果不拆book_info和book_instance直接把书名价格写在一条记录里就会出现大量重复的冗余数据而且没办法回答“这本书全校有多少本在流通”这类统计问题。第二个是订单状态的流转不能只靠一个状态字段硬切。实际场景里有几个分支买家下单后卖家可能反悔下架买家付款后可能一直不约时间取书卖家还可能临时改价这时候需要支持订单变更记录。最简单的做法是加一张order_log表记录操作流水方便出纠纷时回溯。2.2 登录与权限体系的实现思路安全这块在校园系统里容易被人忽视但实际写代码时踩过的坑不少。我采用HandlerInterceptor 注解的方式做登录鉴权和权限控制。用户表里除了 role 字段区分 admin 和 student我还在设计上引入了“状态机”概念新注册用户默认是“未激活”状态必须通过学号邮箱验证或者管理员手动审核后才能发布图书。这样做可以极大减少小号刷垃圾信息的问题——买家注册即看卖家需要激活后才能挂牌。Controller 层通过自定义注解RequireLogin和RequireAdmin做细粒度控制拦截器统一解析请求头里的token。缓存方面选用了 Redis 存登录态key 的设计是login:token:{token}value 是userId过期时间跟微信小程序的session_key有效期做了对齐避免频繁重新登录。2.3 书籍品相标准化从“描述”到“可筛选”旧书买卖最大的阻力之一是“品相”这个模糊概念。同一个“九成新”有人理解成“看过一遍没有笔记”有人理解成“封面略微磨损”。如果直接把品相做成文本域让卖家填后期买家筛选时根本没法比较。我在产品设计阶段就定了规则品相这块必须结构化。最终实现是把品相拆成三个维度新旧程度五成新以下、五到七成新、七到九成新、九成新以上。笔记情况无任何笔记、少量划线、笔记较多、封面或扉页有签名。瑕疵描述勾选“封面破损”、“书脊开裂”、“水渍”、“缺页”等标签支持自定义补充。每个维度在发布表单里都是选项而不是输入框这样列表页就可以做组合筛选只看“七成新以上 无笔记 无破损”的书。事实证明买家搜索效率提升明显纠纷率也下降不少。这套思路同样适用于其他闲置物品交易场景甚至在公司内部的设备领用系统里也能迁移。3. 实操过程与核心环节实现3.1 从零搭建 SSM 工程骨架先说明一个硬性的环境前提JDK 8 Maven 3.6 Tomcat 8.5 MySQL 5.7开发工具我用的是 IDEA。这套组合是 SSM 项目最经典也最不容易出兼容性问题的版本搭配。工程结构按 maven 多模块的思想拆但考虑到大家做毕设时不喜欢过度设计最后收敛成了一个单模块多 package 的工程com.campus.bookshare ├── controller // 控制层接收请求 ├── service // 业务层接口实现 ├── dao/mapper // MyBatis 数据访问接口 ├── entity/model // 实体类 ├── dto // 前端交互的数据传输对象 ├── common // 统一返回结果、常量、异常处理 ├── config // 拦截器、监听器配置 ├── interceptor // 登录拦截器 └── utils // 工具类关键配置我放在三个文件里spring-context.xml管 Service 层和 DAO 层的 Beanspring-mvc.xml管 Controller 层的组件扫描和视图解析器mybatis-config.xml放 MyBatis 的全局配置。特别注意一点Spring 的扫描要避免把 Controller 扫进 service 容器否则事务注解会失效。我在搭建阶段踩过的经典坑忘记在pom.xml里引入javax.servlet-api的 provided 依赖结果 Tomcat 启动直接报ClassNotFoundException: javax.servlet.http.HttpServletRequest。这个问题不大但排查浪费时间建议大家一开始就把依赖清单理清楚。3.2 核心业务代码的设计样本选一个最有代表性的核心接口来说发布图书。发布图书串联了图书元数据、流通实例、用户积分等多个模块接口方法签名大致如下public ResultVOLong publishBook(BookPublishRequest request, Long userId) { // 1. 检查用户是否有发布权限状态是否正常、是否认证 User user userMapper.selectByPrimaryKey(userId); if (user null || user.getStatus() ! 1) { return ResultVO.error(用户不存在或已被限制操作); } // 2. 查询或创建图书元数据 BookInfo info bookInfoMapper.selectByIsbn(request.getIsbn()); if (info null) { info new BookInfo(); info.setIsbn(request.getIsbn()); info.setBookName(request.getBookName()); info.setAuthor(request.getAuthor()); info.setPublisher(request.getPublisher()); info.setCoverUrl(request.getCoverUrl()); bookInfoMapper.insertSelective(info); } // 3. 创建流通实例 BookInstance instance new BookInstance(); instance.setBookInfoId(info.getId()); instance.setSellerId(userId); instance.setDegree(request.getDegree()); instance.setNoteLevel(request.getNoteLevel()); instance.setPrice(request.getPrice()); instance.setCampus(request.getCampus()); instance.setStatus(0); // 默认在售 bookInstanceMapper.insertSelective(instance); // 4.返回发布成功的实例ID return ResultVO.success(instance.getId()); }代码看着不复杂但实际开发中每一步都有边角情况。比如步骤2里如果 ISBN 不存在一些第三方 API 可以通过 ISBN 反查详细书目信息这样连书名封面都不用用户手填。我实现时接了一个开放的书目数据源启动时缓存一份到本地查询不到再走用户手动补充的兜底逻辑。另外一个关键点是不要在 Controller 里直接塞业务代码。很多人图省事直接在 controller 方法里写十几行业务逻辑。前期挺爽后期要加个“发布图书送积分”的功能时就痛苦了——你找不到哪个地方该插代码。这次我把积分发放逻辑放在 service 层的 publish 方法里用 Spring 的Transactional确保和发布动作同生共死。3.3 订单流程中状态机的正确实现图书从挂牌到成交中间的状态切换是系统里最容易出 bug 的部分。我的状态机设计如下在售(0) - 已预定(1) - 已售出(2) 在售(0) - 已售出(2) // 买家直接拍下并线下付款 在售(0) - 下架(3) // 卖方主动撤销 已预定(1) - 在售(0) // 预定的买家取消释放锁定 已预定(1) - 已售出(2) // 完成交易数据库层面我用了一个version字段做乐观锁每次更新状态时where version #{oldVersion}。这样即使两个用户同时对同一本书下单最终也只有一个人能成功另一个会收到“该书已被预定”的提示。很多人在实现订单状态机时会漏掉一件事下单后需要短暂锁定书籍否则会出现“买家下单了但还没有付款另一个买家看到还在售又下了单”的情况。我的策略是买家点击“我要买”后书籍状态立刻从“在售”改为“已预定”同时创建一条待支付订单并给订单设置30分钟的有效期。如果30分钟内未付款定时任务自动把状态释放回“在售”。这个逻辑从产品形态上更接近真实交易体验。下面是这个流程中订单表核心表结构的精简 DDLCREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单编号用时间戳随机数生成, book_instance_id bigint(20) NOT NULL, seller_id bigint(20) NOT NULL, buyer_id bigint(20) NOT NULL, price decimal(10,2) NOT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待付款 1待交接 2已完成 3已取消, expire_time datetime DEFAULT NULL COMMENT 待付款订单过期时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_instance_id (book_instance_id), KEY idx_buyer_id (buyer_id), KEY idx_seller_id (seller_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意order是 MySQL 的保留字建表时必须加反引号。我第一次建表时没注意写 SQL 一直报语法错误找了半小时才意识到是表名的问题。这种细节对老手来说稀松平常但新手很容易卡壳写出来给大家提个醒。3.4 小程序端的关键交互与实现小程序端我从零搭了一个原生框架没有用 uni-app。原因是原生微信小程序对 SSM 后端接口的调试和发布流程最直接而且原生框架在体积和启动速度上有优势。小程序页面结构按 tabBar 分成三个主界面首页图书流 分类筛选、发布中间按钮快速拍照扫码发布、我的订单、收藏、站内信。核心页面交互首页请求/api/book/list翻页条件是“加载更多”。卡片展示封面、书名、售价、校区、品相标签。点击进入详情页。详情页展示实例的完整描述、卖家信用目前只是注册天数还没做评价体系、底部按钮“我要买”和“私信卖家”。发布页先通过wx.scanCode扫 ISBN获取到编码后再调后台/api/book/info/isbn查询书库查到就直接显示书名封面查不到需要手动输入基本信息。订单列表区分“我买到的”和“我卖出的”订单卡片上显示状态、成交价、交接方式支持取消订单和确认完成。小程序的登录态处理值得单独说。微信官方现在的推荐方式是wx.login获取code然后后端拿code调微信的code2Session接口换openid。但毕设项目往往没有企业认证的小程序并没有开放获取手机号等高级能力。我的方案是在小程序端登录后引导用户额外绑定一次学号后端把openid 学号做绑定后续就不需要每次都登录了。对于标题里提到的很多同学关心的“小程序获取登录后的微信用户失败”我当时的报错原因是后端接收的code被前端做了一次 encodeURIComponent导致微信端code2Session校验时提示 code 无效。解决办法是前端传 code 前不要做任何编码处理保持原始字符串。3.5 校园场景下的数据看板与分析这次标题里还有大屏可视化、大数据分析的字眼。虽然一个校园旧书系统离真正的大数据十万八千里但合理的数据统计功能确实能提升系统的价值感。我实现了一个后台的数据看板不是炫酷大屏的形态而是管理端报表页图书发布趋势按周统计新增闲置图书的数量曲线能看出开学季和期末季的波峰。热门图书分类比例用饼图展示当前流通图书的分类占比方便运营人员了解哪个类目的书籍需求旺盛。交易转化漏斗从“浏览详情 → 收藏 → 下单 → 成交”的漏斗数据能直接反映产品体验的短板。当时我们惊讶地发现从下单到成交的流失率极高排查后才知道是买卖双方因为校区不同、线下交接不便导致订单取消。后来增加了“按校区筛选”功能转化率明显提升。滞销图书列表超过30天未售出的书籍清单方便管理员引导卖家降价或下架。这些统计 SQL 基本都靠GROUP BY和DATE_FORMAT实现不需要引入重型计算框架。但在做数据可视化的选型时我并没有直接引 ECharts 到 JSP 页面里而是用 AdminLTE 自带的图表组件减少前端资源的加载体积。如果确实需要大屏效果建议单独部署一个 Vue ECharts 的页面只读后端开放的统计 API和 SSM 管理后台解耦。4. 常见问题与排查技巧实录4.1 数据库中文乱码问题这类问题几乎每个 SSM 项目都会遇到而且乱码的位置各有不同。我这次踩的位置在 MySQL 连接串。原来的配置是jdbc.urljdbc:mysql://localhost:3306/bookshare?useUnicodefalse导致写入的中文到数据库里变成???。改用下面这个之后解决jdbc.urljdbc:mysql://localhost:3306/bookshare?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai同时要确保三处编码一致数据库连接串、MySQL 数据库本身字符集utf8mb4、Tomcat 的 URIEncoding在 server.xml 里配置URIEncodingUTF-8。另外还要检查前端页面和 controller 之间的编码如果使用了request.setCharacterEncoding(UTF-8)过滤器最省事的方法是在 web.xml 里配置 Spring 提供的CharacterEncodingFilter别自己写。4.2 MyBatis 的#{}和${}引发的 SQL 注入风险新手非常容易在动态排序、动态查询条件里直接用${}因为它能解决“字段名不能作为占位符”的问题。比如if testorderBy ! null ORDER BY ${orderBy} /if这样写确实方便但${}会直接拼接字符串如果前端传入id; DROP TABLE user; --后果不堪设想。我在这个项目里做了两种处理固定排序列白名单后台把允许排序的字段名放在常量列表里前端传入的任意字符串必须经过白名单校验后才允许拼接。模糊查询统一用CONCAT(%, #{keyword}, %)坚决杜绝字符串拼接查询条件。写白名单校验的时候有句话想叮嘱大家永远不要相信前端传进来的任何字段名和表名。系统在大学校园里跑用户都是同龄人你根本预测不到谁会拿 sqlmap 扫你的接口。4.3 部署到服务器后图片无法显示开发时图片上传到本地磁盘用虚拟路径映射可以显示。部署到服务器后每次重启 Tomcat 图片就丢或者反向代理配置不对导致图片404。这个问题的根源是不应该把用户上传的图片和应用部署目录耦合在一起。我的解决方法是使用独立的上传目录规划/data/bookshare/upload/cover/2025/06/xxx.jpg /data/bookshare/upload/avatar/2025/06/xxx.jpg项目里存放的不是图片本身而是相对于上传根路径的 URL 字符串比如/upload/cover/2025/06/xxx.jpg。在 Tomcat 的 server.xml 的 Host 节点下配置Context docBase/data/bookshare/upload path/upload reloadabletrue/这样图片请求会直接指向服务器磁盘目录应用重新部署也不受影响。如果用了 Nginx 做反向代理再加上一条静态资源 location 规则会更稳妥。4.4 常见问题速查表现象可能原因排查思路与处理启动 Tomcat 报 BeanCreationExceptionSpring 扫描到了多个同名 Bean 或依赖缺失检查 spring-context.xml 的 component-scan 是否误扫了 ControllerInvalid bound statement (not found)Mapper 接口与 XML 文件没有绑定检查 mapper XML 的 namespace 是否对应接口全限定名且 XML 是否在 resources 目录下访问接口响应 404SpringMVC 拦截了静态资源请求或 URL 映射不对检查 web.xml 的 servlet-mapping 是不是/以及是否配置了静态资源放行事务不起作用Service 方法被同类内部调用Spring AOP 代理失效需要将内部调用拆分到另一个 Service 或使用AopContext.currentProxy()微信小程序请求后台接口失败后台未配置 HTTPS 合法域名本地调试可勾选开发者工具“不校验合法域名”生产必须使用备案过的 HTTPS 域名两个用户同时下单同一本书缺少并发控制使用乐观锁 version 字段或数据库层面的select ... for update4.5 开发阶段的心得与避坑总结做这类系统最大的工作量往往不在“把功能写出来”而在“把边界情况想清楚”。比如发布图书时是否允许填 0 元我的处理是不允许必须大于0。虽然理论上可能存在“免费送”的情况但一旦引入免费赠送订单流程里的支付闭环就打不通了而且容易滋生恶意下单。如果后面真想支持赠送可以加一个独立的模块不要跟交易流程混在一起。再比如用户发布的图书长时间没人买怎么办我的后台加了一个简单的定时任务每天扫描超过30天仍在售的实例自动给卖家推送一条站内信建议降价或者补充品相描述。这个功能代码量很小但能让用户感觉到系统有“运营”的味道对留存率帮助很明显。还有一点是关于测试数据。做演示或者给导师跑验收时空荡荡的页面非常没有说服力。我建议提前生成一批模拟数据但不要只用1、2、3这种敷衍的名字。真实一点的数据比如《数据结构C语言版》、严蔚敏著、清华大学出版社会让整个系统看起来可信得多。当时我写了一个 Python 脚本通过豆瓣读书 API 拉了一批真实书目信息再随机生成用户、随机生成价格和品相刷了大概 300 条在售记录演示效果比手动造数据好太多。再说说版本管理。这个项目从第一天开始我就用 Gitee 做代码托管每完成一个功能模块就写一次 commit message。这样做带来的直接好处是改坏代码时可以精确回到上一个可用版本。我见过不少同学写到后半程系统突然跑不起来了但因为从没提交过版本只能对着几千行代码干瞪眼。哪怕只是一个人做毕设也一定要用 Git。最后想分享一个让系统“活起来”的小技巧图书共享是个强学期属性的业务光是做网页是不够的一定要在关键时间节点做运营活动。我在设计后台时特意支持了“置顶书籍”和“首页轮播图管理”运营人员在开学季可以把热门专业课教材置顶在毕业季可以配置“学长学姐赠书专区”。这些功能开发成本很低但在答辩演示时它展示的是你对业务场景的理解深度而不只是对增删改查的熟练度。好的毕设项目技术亮点固然重要但让评委觉得“这个系统确实能落地用起来”往往更能拿高分。 基于SSM的校园旧图书共享系统：从业务建模到落地实践
大学四年攒下来的旧书堆在宿舍墙角吃灰毕业时论斤卖给废品站运气好能换杯奶茶。可另一边学弟学妹正照着书单在新书区原价下单一本薄薄的专业课教材动不动四五十块。这中间的落差值得做一个系统来填平——这也是我这次分享的项目背景基于SSM的校园旧图书共享系统。这套系统核心面向两类人一类是想要清空书架顺便回点血的大四学生另一类是能省则省、想低价收书的低年级同学。相比闲鱼等综合平台它能做到更贴合校园场景限制在校师生身份、按校区或宿舍区简化交易半径、支持站内信沟通而不用留个人手机号。技术栈用的是经典的 Java EE 组合 SSM即 Spring SpringMVC MyBatis前端做了一套响应式后台管理页面同时留了微信小程序端接入的接口设计。对于正在准备毕业设计、或者想在公司内部做一套闲置物品流转工具的同学来说这套系统的业务模型和技术骨架都能直接参考。整套系统的价值不只是“把书挂上去”这么简单。旧书交易天然有三个痛点需要解决一是书的品相信息很难标准化九成新和五成新根本是两个价格体系二是交易的信任半径有限跨校区寄快递的成本甚至比书价还高三是书籍的流转周期跟学期强相关开学季和毕业季的需求完全不同。我在设计系统时把这三个痛点拆解成了对应的产品功能和数据结构下面挨个拆开讲。1. 内容整体设计与思路拆解1.1 从“跳蚤市场”到“共享系统”的产品逻辑做校园旧书共享系统最忌讳的就是把它做成一个普通的商品列表页。图书跟衣服、数码产品的差别在于内容高度标准化——同一本书有 ISBN、有固定的书名作者出版社这决定了数据建模可以复用“书目信息”而不是每本书都当成独立商品来录入。所以我的第一层设计决策是把系统分成“图书信息库”和“流通实例”两层。图书信息库存的是《高等数学第七版》这种基础元数据书名、作者、ISBN、出版社、封面图、分类。流通实例则是具体某位同学手里的那一本它有几成新、有没有笔记划线、想卖多少钱、挂在哪个校区、当前状态是“在售”、“已预定”还是“已售出”。这样做最直接的好处是发布流程短。卖家只需要扫一下书背面的 ISBN系统自动从书库匹配出书名封面省去手动录入一大串信息的功夫。如果书库里还没有这条记录那就先触发一次书目创建再继续发布。这个设计思路对标的是豆瓣读书加转转的混合体而不是单纯学闲鱼。1.2 为什么是 SSM 而不是 Spring Boot现在的毕业设计和课程项目大都是 Spring Boot 一把梭可我还是选了 SSMSpring SpringMVC MyBatis作为这次项目的主干。原因有几个层面。第一SSM 是理解 Java Web 演进史的绝佳样本。Spring Boot 之所以“省事”是因为它把组件装配、自动配置、内嵌服务器全包了但很多人用了两年 Spring Boot 都没搞明白请求是怎么从 DispatcherServlet 走到 Controller、再通过 SqlSession 落库的。SSM 需要你亲手把 Spring 的 context 配置文件搭起来把 SpringMVC 的注解驱动打开把 MyBatis 的 mapper 扫描配好。这一套走下来对 IoC、AOP、ORM 的理解会是另一个深度。第二很多学校的毕业设计选题库和企业的老项目维护还在用 SSM。如果未来走外包或接私活遇到老项目的概率并不低。能在简历上写“基于SSM架构独立完成模块开发”比只会对着 Spring Initializr 勾依赖更能体现底子。第三SSM 在资源的占用上更轻。一台 2G 内存的云服务器跑 SSM Tomcat比跑 Spring Boot 全家桶加一堆 starter 稳得多。旧书共享这种低并发、事务简单的系统用 SSM 绰绰有余没必要上太重的装备。1.3 小程序端与后台的分工边界标题里同时提到了 Java 和小程序。我在设计时没有让小程序直接访问后台的 MySQL而是走了一套标准的 HTTP API。后端是 SpringMVC 的 Controller 层暴露 JSON 接口小程序端负责页面展示和交互。核心的任务分工是后台管理端PC 网页管理用户、审核图书、查看订单、管理公告、数据统计。这个端的使用者是系统管理员。小程序端微信学生用户登录后浏览书库、发布闲置、下单求购、私信沟通。这一端的体验优先保证操作轻快所以接口设计做了不少面向移动端的瘦身比如列表接口只返回当前页必需的字段详情接口才带完整描述。这种前后端分离的设计也为后面扩展别的端留了口子。比如将来想接一个公众号 H5或者做一个大屏可视化展示图书流通数据只需要继续复用现成的 API 就好。2. 核心细节解析与实操要点2.1 数据库设计中的平衡点数据库是整个系统的地基。我设计的主要数据表包括user用户表。除了常规的账号密码额外加了学号/工号字段、角色字段学生/管理员、校区字段以及状态字段正常/禁言/封禁。book_info图书元数据表。存 ISBN、书名、作者、出版社、分类ID、封面URL。为了支持模糊搜索给书名和作者都建了普通索引。book_instance图书流通实例表。关联 user 和 book_info存品相描述、笔记标注情况、期望售价、原价、所在校区、状态0在售/1已预定/2已售出/3下架。order订单表。买家下单后生成订单包含卖家ID、买家ID、实例ID、成交价格、订单状态待付款/待交接/已完成/已取消。favorite收藏表记录用户收藏了哪些在售实例。message站内信表支持买卖双方在平台上沟通。category图书分类表比如“公共基础课”、“计算机类”、“外语类”等。notice公告表管理员发布系统通知用。feedback反馈表用户可以举报违规图书或留言反馈。这套表结构有两个地方容易拍脑袋出错我特意花了心思。第一个是“一本同名的书可能对应很多个在售实例”。如果不拆book_info和book_instance直接把书名价格写在一条记录里就会出现大量重复的冗余数据而且没办法回答“这本书全校有多少本在流通”这类统计问题。第二个是订单状态的流转不能只靠一个状态字段硬切。实际场景里有几个分支买家下单后卖家可能反悔下架买家付款后可能一直不约时间取书卖家还可能临时改价这时候需要支持订单变更记录。最简单的做法是加一张order_log表记录操作流水方便出纠纷时回溯。2.2 登录与权限体系的实现思路安全这块在校园系统里容易被人忽视但实际写代码时踩过的坑不少。我采用HandlerInterceptor 注解的方式做登录鉴权和权限控制。用户表里除了 role 字段区分 admin 和 student我还在设计上引入了“状态机”概念新注册用户默认是“未激活”状态必须通过学号邮箱验证或者管理员手动审核后才能发布图书。这样做可以极大减少小号刷垃圾信息的问题——买家注册即看卖家需要激活后才能挂牌。Controller 层通过自定义注解RequireLogin和RequireAdmin做细粒度控制拦截器统一解析请求头里的token。缓存方面选用了 Redis 存登录态key 的设计是login:token:{token}value 是userId过期时间跟微信小程序的session_key有效期做了对齐避免频繁重新登录。2.3 书籍品相标准化从“描述”到“可筛选”旧书买卖最大的阻力之一是“品相”这个模糊概念。同一个“九成新”有人理解成“看过一遍没有笔记”有人理解成“封面略微磨损”。如果直接把品相做成文本域让卖家填后期买家筛选时根本没法比较。我在产品设计阶段就定了规则品相这块必须结构化。最终实现是把品相拆成三个维度新旧程度五成新以下、五到七成新、七到九成新、九成新以上。笔记情况无任何笔记、少量划线、笔记较多、封面或扉页有签名。瑕疵描述勾选“封面破损”、“书脊开裂”、“水渍”、“缺页”等标签支持自定义补充。每个维度在发布表单里都是选项而不是输入框这样列表页就可以做组合筛选只看“七成新以上 无笔记 无破损”的书。事实证明买家搜索效率提升明显纠纷率也下降不少。这套思路同样适用于其他闲置物品交易场景甚至在公司内部的设备领用系统里也能迁移。3. 实操过程与核心环节实现3.1 从零搭建 SSM 工程骨架先说明一个硬性的环境前提JDK 8 Maven 3.6 Tomcat 8.5 MySQL 5.7开发工具我用的是 IDEA。这套组合是 SSM 项目最经典也最不容易出兼容性问题的版本搭配。工程结构按 maven 多模块的思想拆但考虑到大家做毕设时不喜欢过度设计最后收敛成了一个单模块多 package 的工程com.campus.bookshare ├── controller // 控制层接收请求 ├── service // 业务层接口实现 ├── dao/mapper // MyBatis 数据访问接口 ├── entity/model // 实体类 ├── dto // 前端交互的数据传输对象 ├── common // 统一返回结果、常量、异常处理 ├── config // 拦截器、监听器配置 ├── interceptor // 登录拦截器 └── utils // 工具类关键配置我放在三个文件里spring-context.xml管 Service 层和 DAO 层的 Beanspring-mvc.xml管 Controller 层的组件扫描和视图解析器mybatis-config.xml放 MyBatis 的全局配置。特别注意一点Spring 的扫描要避免把 Controller 扫进 service 容器否则事务注解会失效。我在搭建阶段踩过的经典坑忘记在pom.xml里引入javax.servlet-api的 provided 依赖结果 Tomcat 启动直接报ClassNotFoundException: javax.servlet.http.HttpServletRequest。这个问题不大但排查浪费时间建议大家一开始就把依赖清单理清楚。3.2 核心业务代码的设计样本选一个最有代表性的核心接口来说发布图书。发布图书串联了图书元数据、流通实例、用户积分等多个模块接口方法签名大致如下public ResultVOLong publishBook(BookPublishRequest request, Long userId) { // 1. 检查用户是否有发布权限状态是否正常、是否认证 User user userMapper.selectByPrimaryKey(userId); if (user null || user.getStatus() ! 1) { return ResultVO.error(用户不存在或已被限制操作); } // 2. 查询或创建图书元数据 BookInfo info bookInfoMapper.selectByIsbn(request.getIsbn()); if (info null) { info new BookInfo(); info.setIsbn(request.getIsbn()); info.setBookName(request.getBookName()); info.setAuthor(request.getAuthor()); info.setPublisher(request.getPublisher()); info.setCoverUrl(request.getCoverUrl()); bookInfoMapper.insertSelective(info); } // 3. 创建流通实例 BookInstance instance new BookInstance(); instance.setBookInfoId(info.getId()); instance.setSellerId(userId); instance.setDegree(request.getDegree()); instance.setNoteLevel(request.getNoteLevel()); instance.setPrice(request.getPrice()); instance.setCampus(request.getCampus()); instance.setStatus(0); // 默认在售 bookInstanceMapper.insertSelective(instance); // 4.返回发布成功的实例ID return ResultVO.success(instance.getId()); }代码看着不复杂但实际开发中每一步都有边角情况。比如步骤2里如果 ISBN 不存在一些第三方 API 可以通过 ISBN 反查详细书目信息这样连书名封面都不用用户手填。我实现时接了一个开放的书目数据源启动时缓存一份到本地查询不到再走用户手动补充的兜底逻辑。另外一个关键点是不要在 Controller 里直接塞业务代码。很多人图省事直接在 controller 方法里写十几行业务逻辑。前期挺爽后期要加个“发布图书送积分”的功能时就痛苦了——你找不到哪个地方该插代码。这次我把积分发放逻辑放在 service 层的 publish 方法里用 Spring 的Transactional确保和发布动作同生共死。3.3 订单流程中状态机的正确实现图书从挂牌到成交中间的状态切换是系统里最容易出 bug 的部分。我的状态机设计如下在售(0) - 已预定(1) - 已售出(2) 在售(0) - 已售出(2) // 买家直接拍下并线下付款 在售(0) - 下架(3) // 卖方主动撤销 已预定(1) - 在售(0) // 预定的买家取消释放锁定 已预定(1) - 已售出(2) // 完成交易数据库层面我用了一个version字段做乐观锁每次更新状态时where version #{oldVersion}。这样即使两个用户同时对同一本书下单最终也只有一个人能成功另一个会收到“该书已被预定”的提示。很多人在实现订单状态机时会漏掉一件事下单后需要短暂锁定书籍否则会出现“买家下单了但还没有付款另一个买家看到还在售又下了单”的情况。我的策略是买家点击“我要买”后书籍状态立刻从“在售”改为“已预定”同时创建一条待支付订单并给订单设置30分钟的有效期。如果30分钟内未付款定时任务自动把状态释放回“在售”。这个逻辑从产品形态上更接近真实交易体验。下面是这个流程中订单表核心表结构的精简 DDLCREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单编号用时间戳随机数生成, book_instance_id bigint(20) NOT NULL, seller_id bigint(20) NOT NULL, buyer_id bigint(20) NOT NULL, price decimal(10,2) NOT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待付款 1待交接 2已完成 3已取消, expire_time datetime DEFAULT NULL COMMENT 待付款订单过期时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_instance_id (book_instance_id), KEY idx_buyer_id (buyer_id), KEY idx_seller_id (seller_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意order是 MySQL 的保留字建表时必须加反引号。我第一次建表时没注意写 SQL 一直报语法错误找了半小时才意识到是表名的问题。这种细节对老手来说稀松平常但新手很容易卡壳写出来给大家提个醒。3.4 小程序端的关键交互与实现小程序端我从零搭了一个原生框架没有用 uni-app。原因是原生微信小程序对 SSM 后端接口的调试和发布流程最直接而且原生框架在体积和启动速度上有优势。小程序页面结构按 tabBar 分成三个主界面首页图书流 分类筛选、发布中间按钮快速拍照扫码发布、我的订单、收藏、站内信。核心页面交互首页请求/api/book/list翻页条件是“加载更多”。卡片展示封面、书名、售价、校区、品相标签。点击进入详情页。详情页展示实例的完整描述、卖家信用目前只是注册天数还没做评价体系、底部按钮“我要买”和“私信卖家”。发布页先通过wx.scanCode扫 ISBN获取到编码后再调后台/api/book/info/isbn查询书库查到就直接显示书名封面查不到需要手动输入基本信息。订单列表区分“我买到的”和“我卖出的”订单卡片上显示状态、成交价、交接方式支持取消订单和确认完成。小程序的登录态处理值得单独说。微信官方现在的推荐方式是wx.login获取code然后后端拿code调微信的code2Session接口换openid。但毕设项目往往没有企业认证的小程序并没有开放获取手机号等高级能力。我的方案是在小程序端登录后引导用户额外绑定一次学号后端把openid 学号做绑定后续就不需要每次都登录了。对于标题里提到的很多同学关心的“小程序获取登录后的微信用户失败”我当时的报错原因是后端接收的code被前端做了一次 encodeURIComponent导致微信端code2Session校验时提示 code 无效。解决办法是前端传 code 前不要做任何编码处理保持原始字符串。3.5 校园场景下的数据看板与分析这次标题里还有大屏可视化、大数据分析的字眼。虽然一个校园旧书系统离真正的大数据十万八千里但合理的数据统计功能确实能提升系统的价值感。我实现了一个后台的数据看板不是炫酷大屏的形态而是管理端报表页图书发布趋势按周统计新增闲置图书的数量曲线能看出开学季和期末季的波峰。热门图书分类比例用饼图展示当前流通图书的分类占比方便运营人员了解哪个类目的书籍需求旺盛。交易转化漏斗从“浏览详情 → 收藏 → 下单 → 成交”的漏斗数据能直接反映产品体验的短板。当时我们惊讶地发现从下单到成交的流失率极高排查后才知道是买卖双方因为校区不同、线下交接不便导致订单取消。后来增加了“按校区筛选”功能转化率明显提升。滞销图书列表超过30天未售出的书籍清单方便管理员引导卖家降价或下架。这些统计 SQL 基本都靠GROUP BY和DATE_FORMAT实现不需要引入重型计算框架。但在做数据可视化的选型时我并没有直接引 ECharts 到 JSP 页面里而是用 AdminLTE 自带的图表组件减少前端资源的加载体积。如果确实需要大屏效果建议单独部署一个 Vue ECharts 的页面只读后端开放的统计 API和 SSM 管理后台解耦。4. 常见问题与排查技巧实录4.1 数据库中文乱码问题这类问题几乎每个 SSM 项目都会遇到而且乱码的位置各有不同。我这次踩的位置在 MySQL 连接串。原来的配置是jdbc.urljdbc:mysql://localhost:3306/bookshare?useUnicodefalse导致写入的中文到数据库里变成???。改用下面这个之后解决jdbc.urljdbc:mysql://localhost:3306/bookshare?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai同时要确保三处编码一致数据库连接串、MySQL 数据库本身字符集utf8mb4、Tomcat 的 URIEncoding在 server.xml 里配置URIEncodingUTF-8。另外还要检查前端页面和 controller 之间的编码如果使用了request.setCharacterEncoding(UTF-8)过滤器最省事的方法是在 web.xml 里配置 Spring 提供的CharacterEncodingFilter别自己写。4.2 MyBatis 的#{}和${}引发的 SQL 注入风险新手非常容易在动态排序、动态查询条件里直接用${}因为它能解决“字段名不能作为占位符”的问题。比如if testorderBy ! null ORDER BY ${orderBy} /if这样写确实方便但${}会直接拼接字符串如果前端传入id; DROP TABLE user; --后果不堪设想。我在这个项目里做了两种处理固定排序列白名单后台把允许排序的字段名放在常量列表里前端传入的任意字符串必须经过白名单校验后才允许拼接。模糊查询统一用CONCAT(%, #{keyword}, %)坚决杜绝字符串拼接查询条件。写白名单校验的时候有句话想叮嘱大家永远不要相信前端传进来的任何字段名和表名。系统在大学校园里跑用户都是同龄人你根本预测不到谁会拿 sqlmap 扫你的接口。4.3 部署到服务器后图片无法显示开发时图片上传到本地磁盘用虚拟路径映射可以显示。部署到服务器后每次重启 Tomcat 图片就丢或者反向代理配置不对导致图片404。这个问题的根源是不应该把用户上传的图片和应用部署目录耦合在一起。我的解决方法是使用独立的上传目录规划/data/bookshare/upload/cover/2025/06/xxx.jpg /data/bookshare/upload/avatar/2025/06/xxx.jpg项目里存放的不是图片本身而是相对于上传根路径的 URL 字符串比如/upload/cover/2025/06/xxx.jpg。在 Tomcat 的 server.xml 的 Host 节点下配置Context docBase/data/bookshare/upload path/upload reloadabletrue/这样图片请求会直接指向服务器磁盘目录应用重新部署也不受影响。如果用了 Nginx 做反向代理再加上一条静态资源 location 规则会更稳妥。4.4 常见问题速查表现象可能原因排查思路与处理启动 Tomcat 报 BeanCreationExceptionSpring 扫描到了多个同名 Bean 或依赖缺失检查 spring-context.xml 的 component-scan 是否误扫了 ControllerInvalid bound statement (not found)Mapper 接口与 XML 文件没有绑定检查 mapper XML 的 namespace 是否对应接口全限定名且 XML 是否在 resources 目录下访问接口响应 404SpringMVC 拦截了静态资源请求或 URL 映射不对检查 web.xml 的 servlet-mapping 是不是/以及是否配置了静态资源放行事务不起作用Service 方法被同类内部调用Spring AOP 代理失效需要将内部调用拆分到另一个 Service 或使用AopContext.currentProxy()微信小程序请求后台接口失败后台未配置 HTTPS 合法域名本地调试可勾选开发者工具“不校验合法域名”生产必须使用备案过的 HTTPS 域名两个用户同时下单同一本书缺少并发控制使用乐观锁 version 字段或数据库层面的select ... for update4.5 开发阶段的心得与避坑总结做这类系统最大的工作量往往不在“把功能写出来”而在“把边界情况想清楚”。比如发布图书时是否允许填 0 元我的处理是不允许必须大于0。虽然理论上可能存在“免费送”的情况但一旦引入免费赠送订单流程里的支付闭环就打不通了而且容易滋生恶意下单。如果后面真想支持赠送可以加一个独立的模块不要跟交易流程混在一起。再比如用户发布的图书长时间没人买怎么办我的后台加了一个简单的定时任务每天扫描超过30天仍在售的实例自动给卖家推送一条站内信建议降价或者补充品相描述。这个功能代码量很小但能让用户感觉到系统有“运营”的味道对留存率帮助很明显。还有一点是关于测试数据。做演示或者给导师跑验收时空荡荡的页面非常没有说服力。我建议提前生成一批模拟数据但不要只用1、2、3这种敷衍的名字。真实一点的数据比如《数据结构C语言版》、严蔚敏著、清华大学出版社会让整个系统看起来可信得多。当时我写了一个 Python 脚本通过豆瓣读书 API 拉了一批真实书目信息再随机生成用户、随机生成价格和品相刷了大概 300 条在售记录演示效果比手动造数据好太多。再说说版本管理。这个项目从第一天开始我就用 Gitee 做代码托管每完成一个功能模块就写一次 commit message。这样做带来的直接好处是改坏代码时可以精确回到上一个可用版本。我见过不少同学写到后半程系统突然跑不起来了但因为从没提交过版本只能对着几千行代码干瞪眼。哪怕只是一个人做毕设也一定要用 Git。最后想分享一个让系统“活起来”的小技巧图书共享是个强学期属性的业务光是做网页是不够的一定要在关键时间节点做运营活动。我在设计后台时特意支持了“置顶书籍”和“首页轮播图管理”运营人员在开学季可以把热门专业课教材置顶在毕业季可以配置“学长学姐赠书专区”。这些功能开发成本很低但在答辩演示时它展示的是你对业务场景的理解深度而不只是对增删改查的熟练度。好的毕设项目技术亮点固然重要但让评委觉得“这个系统确实能落地用起来”往往更能拿高分。