简介一份基于微信小程序的二手物品交易平台SSM毕业论文适用于计算机专业毕业生或正在设计类似课设的开发者可帮助解决从选题到系统实现的完整写作与设计参考。资源是单个doc文档大小约1.5MB已有77人学习。文档结构完整从绪论切入项目背景、意义与研究内容围绕SSMSpring、SpringMVC、MyBatis框架、MySQL数据库和微信小程序端展开技术选型分析涵盖用户、物品、交易等核心数据表设计并涉及安全性与性能优化等关键环节。后续章节还包含系统设计原则、模块划分、前后端接口设计与具体实现步骤附有摘要、目录和关键词。读者可借助文档快速搭建同类交易平台的论文框架理解前后端交互及数据库实现要点适合用于毕业论文撰写参考和毕业设计项目梳理。1. 从毕业论文标题到可交付的系统这个课题的难点在哪“基于微信小程序的二手物品交易平台 ssm”这类题目在毕业论文里出现频率很高但多数实现停留在“商品 CRUD 登录注册”的层面。真正让它区别于普通管理系统的地方在于交易闭环商品从发布、浏览、联系、下单到确认收货每一步都涉及状态变更和权限校验而这些恰恰是 SSM 框架最容易写出隐患的部分。SSM 本身是经典教学组合资料多、部署简单、答辩时容易讲清楚适合作为课题的技术底座小程序的触达成本低用户不需要下载 App扫码即用也比较贴近二手交易的实际使用场景。这篇文章按一个可复现的开发方案来展开先梳理业务模型再分别落地后端接口和小程序端实现最后收在部署验证和容易踩的坑上适合正在做同类毕业设计、或想快速搭一个二手交易 Demo 的开发者。2. 业务模型与选型先想清楚二手交易和小程序各自要什么2.1 为什么是“微信小程序 SSM”而不是 Spring Boot Vue严格来说当前新项目用 Spring Boot 更省事但在毕业论文场景下 SSM 依然有其合理性一是网上可参考的代码多出问题时容易找到对照二是它能清楚地展示 Spring 的 IoC 和 AOP、SpringMVC 的请求流转、MyBatis 的 SQL 映射答辩时有东西可讲三是学校机房或自己电脑上的旧 JDK/Tomcat 环境往往能直接跑起来不需要折腾新版本依赖。如果已有的参考代码是 Spring Boot 也没关系Sm拆分的思路完全一致只是注解和配置文件写法不同。小程序端则优先选择原生开发原因在于微信官方文档和社区资料最全涉及登录、支付、地理位置等能力时原生代码可以直接复用如果之前熟悉 Vue用 uni-app 也可以但“UI 层和生命周期差异”会增加不必要的排查成本。2.2 核心业务闭环与状态机设计二手交易平台不能只做一个展示页面。最小可用闭环包含六条链路用户通过微信登录获取 openid后端生成业务 token用户发布闲置物品填写标题、描述、价格、成色、图片、所在城市其他用户按分类或关键词搜索商品查看详情并发起“我想要”买卖双方通过平台内留言或预留的微信号沟通不做即时聊天时买家对心仪商品发起下单卖家标记“已卖出”或“已下架”双方线下交易完成后买家确认收货订单状态变为“已完成”卖家积累信用记录。其中订单状态必须用状态机来控制。常见做法是用一个整型或字符串字段表示状态并在 Service 层定义可流转方向。比如订单状态枚举为待付款/待发货/待收货/已完成/已取消。需要注意“取消”不能从“已完成”回退“发货”只能由卖家操作“收货”只能由买家操作。如果不用状态机只在前端控制按钮显隐很容易出现“用户直接改请求参数跳到任意状态”的漏洞。2.2.1 数据表设计至少需要五张表一张商品表、一张订单表、一张用户表外加收藏和留言就能覆盖 90% 的演示需求。字段设计上注意以下几点价格用分存储避免浮点数精度问题图片用逗号分隔的 URL 字符串最多存 9 张方便小程序端用循环渲染状态字段用 tinyint所有表都带 create_time 和 update_time。商品表的核心字段包括 id、uid、title、description、price、original_price、category_id、status、images、location、view_count、create_time订单表包括 id、order_no、product_id、buyer_id、seller_id、price、status、create_time、pay_time、finish_time。用户表不与微信 openid 之外的信息强绑定首次登录时自动注册即可。3. SSM 后端的接口层实现从登录鉴权到订单流转3.1 用 SSM 搭建最省心的项目结构如果从零创建可以采用标准的 Maven 分模块结构ssm-common 放统一返回结果和工具类ssm-pojo 放实体类ssm-dao 放 MyBatis 的 mapper 接口和 XMLssm-service 放业务逻辑ssm-web 放 SpringMVC 的 Controller。配置上需要 web.xml 加载 Spring 和 SpringMVC 两个上下文一个管业务 Bean一个管 Controller事务配置在 service 层用tx:annotation-driven开启注解事务因为订单下单涉及商品状态和订单表两条写操作必须保证原子性。mybatis-config.xml 里开启驼峰映射和日志输出前者让数据库字段与 Java 属性自动对应后者方便调试 SQL。configuration settings setting namemapUnderscoreToCamelCase valuetrue/ setting namelogImpl valueSTDOUT_LOGGING/ /settings /configuration这是最基础的配置主要解决三个问题数据库列名下划线转 Java 驼峰、SQL 日志输出到控制台、加载 mapper 文件。如果不开启驼峰映射查询结果中的 create_time 字段将无法赋值给 createTime 属性需要手动写 resultMap增加不必要的代码量。3.2 微信登录与 token 鉴权微信小程序的登录不依赖传统账号密码。前端调用wx.login()拿到临时 code后端用这个 code 请求微信接口获取 openid 和 session_key然后用 openid 作为用户唯一标识生成一个自己的业务 token 返回给前端。这里不能直接把微信的 session_key 当作业务 token 使用因为 session_key 有时效且和微信官方服务器有关不应该传到前端。Controller 层代码如下RestController RequestMapping(/api/user) public class UserController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginRequest request) { String openid userService.code2Openid(request.getCode()); if (openid null) { return Result.error(登录失败code 已失效); } User user userService.getOrCreateUser(openid); String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(token: token, user.getId().toString(), 2, TimeUnit.DAYS); return Result.success(new LoginResponse(token, user)); } }逻辑说明code2Openid内部通过 HttpClient 调用微信官方接口把 code 换成 openidgetOrCreateUser先按 openid 查一次库查不到就新建用户token 存入 Redis 并设置两天过期后续请求通过拦截器校验。需要注意的是 code 是一次性的前端拿不到 openid只能拿到后端返回的 token这样才能保证 openid 不泄露。3.2.1 登录 token 的拦截器配置拦截器是必须的否则所有接口都裸奔。在 SpringMVC 配置中注册登录拦截器并排除登录接口然后实现preHandle方法从请求头中取出Authorization字段去 Redis 查 token查不到就返回 401。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException { String token request.getHeader(Authorization); Object userId redisTemplate.opsForValue().get(token: token); if (userId null) { response.setStatus(401); response.getWriter().write({\code\:401,\msg\:\未登录或登录已过期\}); return false; } request.setAttribute(currentUserId, Long.valueOf(userId.toString())); return true; } }要点request.setAttribute把当前用户 ID 存到请求域Controller 里用(Long) request.getAttribute(currentUserId)就能拿到当前登录用户不需要反复解析 token。这里必须考虑“全局异常处理器”兜底因为一旦用户带过期 token 访问接口拦截器返回的是纯 JSON 串而不是统一格式前端解析时可能会挂掉。常见做法是拦截器返回 401 状态码小程序端在封装wx.request时统一跳转回登录页。3.2.2 发布商品接口与图片上传路径发布商品是写入操作需要校验字段非空、价格大于 0、最多传 9 张图。图片上传可以走两种方案直接存服务器本地目录或接入云存储。毕业设计建议直接用服务器本地路径例如/upload/20250406/xxx.jpg数据库里只存相对路径页面拼接完整的域名访问。上传接口用 MultipartFile 接收文件按日期分目录存储文件名用 UUID 加后缀防止重名。注意给上传目录配置静态资源映射否则 SpringMVC 访问不到上传的文件。商品发布接口核心逻辑段如下public Long addProduct(Product product, MultipartFile[] images) { if (product.getPrice() null || product.getPrice() 0) { throw new BizException(价格必须大于0); } String basePath /upload/ LocalDate.now().toString().replace(-, ); ListString urls new ArrayList(); for (MultipartFile image : images) { String fileName UUID.randomUUID().toString().substring(0, 8) getExt(image.getOriginalFilename()); image.transferTo(new File(basePath / fileName)); urls.add(basePath / fileName); } product.setImages(String.join(,, urls)); product.setStatus(1); productMapper.insert(product); return product.getId(); }参数说明getExt用来取文件后缀只允许 jpg、png、jpeg 和 webpsetStatus(1)表示上架在售状态后续下架改为 0。图片格式校验不能省略否则用户会上传 exe 或 html 文件造成存储型 XSS 风险也会拖累打开速度。3.3 订单下单与并发防重下单操作要同时校验三件事商品是否存在、商品是否已下架、买家不能买自己的商品。如果并发请求同时触发可能出现“同一商品被两个人同时下单成功”的脏数据因此在 Service 层要用乐观锁或数据库唯一约束兜底。较简单可靠的方案是在商品表加一个order_lock字段下单时执行UPDATE product SET status 2, order_lock 1 WHERE id ? AND status 1如果受影响行数为 0说明商品已被别人抢过直接抛异常。这是“乐观锁”在单表上的典型应用没有引入 Redis 分布式锁的复杂度SSM 毕业设计足够用。下单接口的时序是校验登录 → 校验商品 → 加锁 → 创建订单 → 返回订单号。相关代码Transactional public Order createOrder(Long productId, Long buyerId) { Product product productMapper.selectById(productId); if (product null || product.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } if (product.getUid().equals(buyerId)) { throw new BizException(不能购买自己发布的商品); } int rows productMapper.lockForOrder(productId); if (rows 0) { throw new BizException(手慢了商品已被下单); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setProductId(productId); order.setBuyerId(buyerId); order.setSellerId(product.getUid()); order.setPrice(product.getPrice()); order.setStatus(0); orderMapper.insert(order); return order; }Transactional保证商品状态变更和订单插入要么同时成功、要么同时失败。productMapper.lockForOrder的 SQL 就是前面说的条件更新语句若商品已被其他订单锁定则返回 0。这里有一个细节订单状态 0 代表“待付款/待交易”二手交易不强制接入微信支付所以订单表里可以去掉支付回调双方线下碰面后由买家点击“确认收货”完成最终状态如果后续要接入校园卡或押金支付再扩展支付字段这一层接口设计不会受到限制。3.3.1 订单状态流转与权限控制状态变更接口需要区分操作者身份。/order/ship只有卖家能调用/order/confirm只有买家能调用前提是当前状态匹配。在 Service 层必须做两件事通过订单查到商品归属而不是信前端传来的 seller_id比较当前请求的用户 ID 是否匹配然后判断当前状态能否流转到目标状态。订单表只有明确的“状态机”才能保证业务闭环否则前端任意调接口就能把订单从“待付款”改成“已完成”。3.4 商品列表的分页查询与条件筛选二手平台的首页普遍是“最新发布”流附带分类、价格区间、城市三个筛选维度。用 MyBatis 动态 SQL 可以一个方法应对多种查询条件不需要为每个筛选条件都写一个接口。分页用 PageHelper因为它是国内使用率最高也最省事的 MyBatis 分页插件。关键查询如下select idselectProductPage resultTypecom.demo.entity.Product SELECT * FROM product where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR description LIKE CONCAT(%, #{keyword}, %)) /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if AND status 1 /where ORDER BY create_time DESC, id DESC /select逻辑说明where标签会自动去掉第一个多余的 AND这是 MyBatis 动态 SQL 最常用的小技巧status 1固定在条件里确保下架商品不出现在搜索结果中排序先按create_time倒序再按id倒序保证同一秒发布的商品也有稳定的先后顺序。分页参数由 PageHelper 注入PageHelper.startPage(pageNum, pageSize)返回结果用PageInfo包装既能得到当前页列表也能一次性拿到总条数和总页数。这里要额外处理图片列表数据库存的是逗号分隔的 URLController 返回给小程序前应该转换成 List 类型避免前端再去split(,)。此类组装逻辑统一放在 VO 层做Service 返回实体、Controller 返回 VO这样数据库字段不会泄露到前端同时便于在字段上面补充描述信息。4. 微信小程序端实现从登录到交易的关键页面4.1 合理划分页面结构与自定义导航栏小程序端建议划分八个页面首页商品流、分类页、搜索页、商品详情页、发布页、订单列表页、订单详情页、我的个人中心。再算上登录页和编辑资料页总共十个左右页面不多但彼此之间跳转关系较密要提前定义好跳转路径防止后期页面嵌套混乱。首页推荐流使用onReachBottom来触底加载下一页用onPullDownRefresh做下拉刷新。顶部导航栏高度是一个不容易处理的问题。默认导航栏左右两边会留出胶囊按钮的空间不同机型比例不同如果直接写padding-top: 64px在 iPhone X 等刘海屏上就会遮住内容。常见做法是获取系统状态栏高度后动态设置占位视图高度const systemInfo wx.getWindowInfo(); const menuButton wx.getMenuButtonBoundingClientRect(); const navBarHeight (menuButton.top - systemInfo.statusBarHeight) * 2 menuButton.height; this.setData({ statusBarHeight: systemInfo.statusBarHeight, navBarHeight: navBarHeight });参数说明wx.getWindowInfo()能拿到状态栏高度和窗口尺寸wx.getMenuButtonBoundingClientRect()能拿到右上角胶囊按钮的位置和尺寸两行计算就能得到自定义导航栏的实际高度。不建议写死数值因为安卓、iOS 和不同机型的刘海屏参数差异很大。4.2 小程序登录与本地登录态小程序端登录流程要与 3.2 节的后端接口配合。核心代码login() { wx.login({ success: (res) { if (res.code) { wx.request({ url: ${this.globalData.baseUrl}/api/user/login, method: POST, data: { code: res.code }, success: (resp) { const { token, user } resp.data.data; wx.setStorageSync(token, token); wx.setStorageSync(userInfo, user); } }); } } }); }代码里wx.login获取临时 code后端用它换取 openid 并生成业务 token前端将 token 和用户信息写入本地存储。这个 token 在后续所有接口请求中通过Authorization请求头传递。注意不要在前端通过 code 直接换取 openid微信不允许这种做法而且也没有小程序端换取 openid 的接口。封装wx.request时遇到状态码 401 要自动清除本地 token 并跳转登录页遇到网络错误需要提示用户检查网络。真机预览时如果发现“请求无法到达后端”最常见的两个原因一是小程序开发工具勾选了“不校验合法域名”而真机没有勾选需要在小程序后台配置 request 合法域名二是后端部署在http://localhost:8080真机无法访问电脑的 localhost需要改成局域网 IP 或云服务器 IP同时确保防火墙和服务器安全组放行对应端口。4.3 首页商品流与上拉分页首页的性能关键点在于分页和图片懒加载。分页参数 pageNum 从 1 开始每次触底加 1如果返回的数据条数小于 pageSize则不再发起请求。使用wx:for渲染列表图片在标签上使用lazy-load属性让屏幕外的图片延迟加载可以显著提升滚动流畅度。loadProducts() { const params { pageNum: this.data.pageNum, pageSize: 10, keyword: this.data.keyword || , categoryId: this.data.categoryId || }; request({ url: /product/page, data: params, success: (res) { const list res.data.data.list; this.setData({ productList: this.data.pageNum 1 ? list : this.data.productList.concat(list), pageNum: this.data.pageNum 1, hasMore: list.length 10 }); } }); }参数说明pageNum 1时是下拉刷新场景直接覆盖列表否则为触底加载使用 concat 追加。hasMore用于控制触底时是否继续发起请求防止无效请求浪费流量。这类分页逻辑在所有列表页通用建议抽成公共 mixin 或公共方法避免每个页面重复写。4.4 发布页图片上传与表单校验发布页的表单包括标题、描述、成色全新/轻微使用/明显使用痕迹、价格、原价、分类、手机号、所在地。成色用radio-group实现分类用picker所在城市可以用picker配合城市数据数组。图片选择使用wx.chooseMedia这是新版 API旧版chooseImage已不推荐最多选择 9 张。上传时先调用后端的图片上传接口拿到 URL再连同表单数据一起提交而不是把地球上图片 base64 塞进表单里否则请求包体积会非常大导致真机上传卡顿。以下是图片选择与上传的核心逻辑chooseImages() { wx.chooseMedia({ count: 9 - this.data.images.length, mediaType: [image], sizeType: [compressed], success: (res) { const tempFiles res.tempFiles; tempFiles.forEach((item) { wx.uploadFile({ url: ${this.globalData.baseUrl}/api/upload, filePath: item.tempFilePath, name: file, success: (uploadRes) { const data JSON.parse(uploadRes.data); this.setData({ images: this.data.images.concat(data.data) }); } }); }); } }); }需要注意wx.uploadFile的响应是字符串类型需要JSON.parse处理上传图片时不能和普通表单请求共用同一个wx.request因为uploadFile的 Content-Type 是 multipart/form-data。用户在选择图片时可以顺带做格式校验直接限制sizeType为 compressed避免上传几十 MB 的原图。4.5 订单操作按钮的显隐逻辑订单列表页的每个订单卡片下方需要显示不同操作按钮依据是订单状态和当前登录用户身份。例如订单状态为“待发货”时卖家和买家看到的内容不同卖家看到“发货”按钮买家看到“等待卖家发货”的纯文本提示。直接在小程序端写一堆wx:if会让模板变得冗长常见做法是后端返回订单数据时同时返回canShip、canConfirm、canCancel三个布尔字段小程序只根据这三个字段渲染按钮。后端一次性算好权限和状态一方面减少了小程序端的判断逻辑另一方面也避免前端知道订单状态机的全部流转规则安全性更好。5. 部署验证的三个关键操作与一个收尾技巧5.1 后端部署后的联调验证顺序后端代码写完后不要急着连小程序先用 Postman 或 Apifox 按顺序验证五组接口登录换取 token、发布商品、分页搜索、下单、确认收货。验证时必须携带刚拿到的 token否则会返回 401。这个顺序实际上就是完整业务主流程能跑通说明核心链路没有问题然后再进入小程序端联调。如果发布商品后图片无法访问先检查 SpringMVC 是否配置了静态资源映射再看上传目录的读写权限如果是 CentOS 服务器/upload目录通常是 root 权限需要把目录属主改成 Tomcat 的运行用户并执行chmod -R 755 /upload。5.2 小程序上线前的合规检查项在小程序后台提交审核前需要逐项确认request 合法域名已配置且为 HTTPS隐私协议中声明收集了用户微信昵称、头像、位置信息有用户协议和售后规则页面涉及交易功能的类目选择“二手闲置交易”需要提交交易纠纷处理机制说明。开发版和体验版可以勾选“不校验合法域名”但正式版不行域名必须有 ICP 备案和 HTTPS 证书。另外要注意平台对交易类小程序的审核较严格发布功能需要在体验版里提前真人测试尤其是“发布失败时是否给出明显提示”“商品被下单后再次访问详情页是否展示‘已抢光’”这类边界状态很可能成为驳回理由。5.3 图片旋转、iOS 静音与页面数据的几个易忽略点用户从手机相册选择图片上传后部分安卓机型会出现图片旋转 90 度的问题。原因是 EXIF 中记录了旋转方向而后端直接存了原图。解决方法是小程序端选择图片时用wx.compressImage或 canvas 重绘一次把方向信息抹掉后端在图片上传接口中也可以引入 Thumbnailator 库统一压缩为宽 800 像素的 JPEG既解决旋转问题又控制大小。iOS 静音模式下页面里嵌入的音频不会自动播放但二手交易平台中这一影响不大唯一要注意的是消息提示音不能用wx.createInnerAudioContext播放应使用wx.showToast或wx.vibrateShort的震动反馈避免用户戴着耳机被突如其来的声音打扰。5.4 数据一致性收尾给关键表加索引直接给出运维阶段容易忽略的一个优化点product表的status和create_time需要建联合索引order表的buyer_id、seller_id、status需要分别建索引。没有索引时随着数据量增长首页查询会退化为全表扫描这是很多 SSM 项目上线后性能下降的第一来源。建索引的 SQLALTER TABLE product ADD INDEX idx_status_time (status, create_time); ALTER TABLE order ADD INDEX idx_buyer_status (buyer_id, status), ADD INDEX idx_seller_status (seller_id, status);这两个索引能覆盖绝大多数场景首页按上架时间倒序、我的发布按状态过滤、订单列表按买家或卖家维度查询。索引不是越多越好像description这种大字段不要建索引模糊查询走 LIKE 本身也命中不了索引不要为price建单列索引因为筛选单价区间的场景通常还会带分类和状态条件联合索引的收益大于单列索引。上线前花十分钟检查EXPLAIN输出确认key字段已经走到idx_status_time再用sysbench或jmeter压 1000 并发订单请求观察是否存在超卖现象。订单表设计时预留version字段后续如果需要把乐观锁做得更完善可以在状态更新时附带WHERE version ?让并发控制更稳。本文还有配套的精品资源点击获取