企业官网建设流程全解析

简介：《校园二手交易平台》是一份基于微信小程序与SSM框架的完整实训项目套件，面向计算机类毕业设计、期末大作业及需要项目实战练习的开发者。项目以校园二手物品买卖为核心，覆盖从用户界面到数据处理的安全与易用设计，适合作为课设参照或能力提升素材。压缩包共1433个文件，大小44.16MB，主要包含小程序前端（wxml/wxss/js）、SSM后端（java/xml）、管理端页面（vue）、数据库脚本（sql）以及说明文档等，同时有png、jpg等设计图与svg图标，结构清晰便于分类检索。目前已有65人浏览学习。除可运行源码外，还附有论文报告、PPT、数据库文档和开发说明，完整记录了需求分析、系统设计、数据库设计、接口设计等环节。源码均经本地编译与调试，配合数据表和说明文档，能帮助理解二手交易系统从业务逻辑到技术落地的全过程，是较实用的毕业设计参考资料。

1. 校园二手交易平台项目：小程序+SSM这套组合先看清再动手

毕设季和课设季最常收到的就是这类压缩包：标题写着“校园二手交易平台的小程序+ssm”，解压之后是一堆文件夹，源码、论文、PPT、数据库文档、说明文档全混在一起。很多人第一反应是双击打开说明文档，然后卡在环境配置上，半天跑不起来。这个标题本质上是两件事：一个跑在微信里的小程序前端，一个用SSM（Spring+SpringMVC+MyBatis）写的Java后端，中间通过JSON接口通信。它解决的是“从0到1搭一个可演示的完整系统”的问题，适合正在做Java课程设计、毕业设计的人，也适合想在微信小程序和后端之间打通一条真实数据链的初学者。要说清楚它值不值得做，得先把这套组合拆开看。

2. SSM后端与微信小程序的分工：先看懂架构再动手

很多同学拿到源码第一件事是点“运行”，结果后端起来了小程序白屏，或者小程序起来了接口报404。原因都一样：没先分清两端各自管什么。小程序端只管页面渲染和用户操作，它不直接连数据库，所有数据都通过wx.request调后端接口拿；SSM后端负责业务逻辑、权限校验、读写数据库，然后把结果以JSON格式返回给小程序。这条链路是理解整个项目的钥匙。

校园二手交易平台的典型流程是：用户在小程序里浏览商品列表，点击详情，发起购买或留言；小程序把请求发到后端接口，后端查数据库，再返回商品数据。登录、下单、我的发布、订单状态这些功能，前端做展示和交互，后端做校验和存储。哪个先启动、哪个后启动，取决于谁依赖谁：后端必须先跑起来，小程序才有接口可调。

2.1 微信小程序端和后端的数据通路：wx.request、JSON与接口约定

小程序端所有和后端的交互都走wx.request。它类似浏览器的fetch，但有一些自己的限制，比如域名必须备案、必须配HTTPS（本地开发可以勾选“不校验合法域名”）。一个标准的请求长这样：

// pages/index/index.js const app = getApp() Page({ data: { goodsList: [] }, onLoad() { wx.request({ url: app.globalData.baseUrl + '/goods/list', method: 'GET', header: { 'Authorization': wx.getStorageSync('token') }, success: (res) => { if (res.data.code === 200) { this.setData({ goodsList: res.data.data }) } else { wx.showToast({ title: '加载失败', icon: 'none' }) } } }) } })

这段代码里的关键点有三个。url是后端接口地址，baseUrl通常放在app.js的globalData里，这样换环境时只改一处；header里带Authorization是登录后的身份凭证，后端SSM通过它判断当前用户是谁；success回调里的res.data是后端返回的JSON，一般会有code、message、data三个字段。后端返回的结构越统一，前端处理越省事。

参数说明：method不写默认是GET，POST请求要对data做对象传参而不是拼接URL；header里的token如果为空，登录校验接口会直接拒绝。很多项目模板里会把wx.request封装成一个request.js文件，统一处理token过期、错误提示，这是推荐做法，别在每页都写一遍。

2.2 SSM三层结构在二手交易场景里的落地形态：Controller、Service、Mapper

SSM是三个框架的合称：Spring管对象和事务，SpringMVC管接口路由，MyBatis管数据库读写。对应到代码里就是三层：Controller层接收小程序发来的请求，Service层写业务规则，Mapper层操作数据库表。二手交易平台的一个商品列表接口，在代码里大概长这样：

@RestController @RequestMapping("/goods") public class GoodsController { @Autowired private GoodsService goodsService; @GetMapping("/list") public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size) { List<Goods> goods = goodsService.findOnSale(page, size); return Result.ok(goods); } }

Controller只做三件事：接收参数、调Service、包装返回结果。真正的逻辑在Service里，比如查询“只返回上架中的商品、过滤掉已下架”的规则，写在Service而不是Controller里。Mapper层是最后的SQL落地：

public interface GoodsMapper { List<Goods> selectOnSale(@Param("offset") int offset, @Param("size") int size); }

对应的XML文件里写SQL，比如WHERE status = 1 ORDER BY create_time DESC LIMIT #{offset}, #{size}。这样做的好处是SQL和Java代码分离，改查询条件不用重新编译Java。对课程设计来说，三层结构是评分点之一，论文里的架构图也是按这个画。

2.3 数据库文档里最该先看的四张业务表：用户表、商品表、订单表、收藏表

拿到数据库文档，先别急着导入，打开ER图看业务表。校园二手交易平台最核心的四张表是这些：

用户表里的openid是微信登录的唯一凭证，后端的登录接口先调微信接口换openid，再在t_user里查或创建用户。商品表里的status字段很关键，它决定了商品出现在“在售列表”还是“已卖出”里，很多bug都出在这个字段的状态流转上。订单表同时存了buyer_id和seller_id，因为二手交易里买卖双方都是普通用户，不是平台管理员。收藏表是典型的关联表，两个外键拼成一个唯一索引，防止重复收藏。

建议拿到数据库文档后先画一遍ER图，再对照代码里的Mapper接口看，重点确认每个表的主键策略是自增还是雪花ID。SSM课设项目大多用MySQL自增，写SQL时要注意别把自增列的值手动填进去。

3. 把项目和数据库跑通：从解压到接口自测的完整步骤

源码类项目的硬门槛永远是“跑起来”。这一章按我平时带人做课设的顺序来，先把压缩包里的东西分类，再导数据库、启后端、配小程序，每一步做完都有验证方式，不要到最后才一起排错。整个流程走完大概半小时到一小时，取决于MySQL和JDK版本是否顺手。

3.1 先识别压缩包里的文件：源码、SQL脚本和文档各看什么

解压之后一般会看到这几个目录：一个Java工程目录、一个小程序目录、论文和PPT文档、数据库脚本。先建立文件清单，比盲目点开任何文件都重要。

注意：后端的pom.xml是判断项目类型最直接的凭证。看到<packaging>war</packaging>就知道要部署到Tomcat，看到<packaging>jar</packaging>才可能直接启动。校园二手交易平台这种课设项目大多是war包，因为SSM时代Tomcat部署是标配。

3.2 用Navicat导入数据库脚本，并改JDBC连接配置

数据库脚本是项目的“地基”。我一般用Navicat导入，也可以用命令行。两种方式任选，命令行更通用：

mysql -u root -p < db_second_hand.sql

导入完成后，用Navicat看一下表是否齐全。然后打开后端的jdbc.properties或application.properties，改数据库连接：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/second_hand?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=123456

这里的坑主要在url参数。useSSL=false是必须的，不然MySQL 8.0会频繁警告；serverTimezone=Asia/Shanghai是必须的，MySQL 8.0默认时区和本地不一致会直接报错。密码改成你自己本机的密码，别照抄文档里的默认值。如果XML里MyBatis配置了driver旧值com.mysql.jdbc.Driver，记得换成新值，否则MySQL 8.0会直接抛ClassNotFoundException。

3.3 用IntelliJ导入Maven工程，启动Tomcat并自测接口

IntelliJ里选“Open”，选中后端源码目录，等Maven把依赖下载完。SSM项目一般用Tomcat 8或8.5，配好Artifact后启动。如果是Maven插件方式，命令行也能跑：

mvn tomcat7:run

这个是tomcat7-maven-plugin的常见用法，端口默认8080。启动日志里看到“Starting ProtocolHandler”和“Server startup in xxx ms”就算成功。然后自测接口，先别急着开小程序，用浏览器或curl验证后端活着：

curl -X GET http://localhost:8080/second_hand/goods/list?page=1&size=10

这里的second_hand是Context Path，和你后端项目名一致。返回JSON里有商品数组，说明后端和数据库通了。如果返回404，先看Controller的@RequestMapping里的路径和这里拼的是否一致，这是最常见的路径不匹配坑。返回500就去看IntelliJ控制台的异常堆栈，定位到具体哪一行。

3.4 用微信开发者工具导入小程序端，统一替换接口地址

后端通了，接着导小程序。微信开发者工具里选“导入项目”，AppID可以选测试号。导入后第一件事是找到app.js或config.js里的baseUrl，把它从文档里的示例IP改成你的本机地址：

// app.js globalData: { baseUrl: 'http://localhost:8080/second_hand' }

注意：微信开发者工具默认要求HTTPS，本地调试要在“详情-本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。不勾这一项，所有请求都会报request:fail url not in domain list，这是新手最容易卡住的地方，而且报错信息有迷惑性。

改完地址后，在开发者工具里点“编译”，看到商品列表渲染出来，说明整条链路通了。到这里“跑起来”的目标就完成了，接下来才进入排查和打磨阶段。

4. 论文、PPT和说明文档要怎么用：把文档变成答辩素材

源码包里带的论文、PPT、数据库文档不是装饰品，它们决定了这个项目的“上限”。很多人的问题是：代码跑通了，但论文里写的功能和自己改过的代码对不上。原因很简单——拿到手的论文是原作者在另一个环境下的产物，而你已经改过代码或者换了表结构。正确做法是先梳理文档结构，再对照当前代码逐章修正。

4.1 论文和技术实现对不上？用数据库文档先对齐表结构

论文第4章和第5章通常写“系统设计”和“数据库设计”，里面有ER图和表结构描述。如果源码包里同时有数据库文档，那先打开它，对比论文里的表名、字段名和实际SQL脚本是否一致。常见的不一致有：论文里表名是goods，SQL里是t_goods；论文里字段是price，SQL里是gprice。这种差异答辩时老师一问一个准。

我一般的做法是列一张“论文章节-代码模块对照表”：

对照表的目的不是让你重写论文，而是把差异标出来，统一改成当前代码的实际状态。改论文里的SQL描述比重写代码省事得多。

4.2 从现有代码倒推需求分析与系统设计两章

课设论文最难写的两章是“需求分析”和“系统设计”，因为它们看起来像“写作文”。不擅长写的人可以反过来，从代码里倒推需求。先把Controller里的接口列出来，比如登录接口、商品列表、发布商品、下架商品、下单、订单列表、收藏。每个接口对应一个“用户故事”，把故事串起来就是需求分析。

系统设计章更简单，直接画图。架构图按SSM三层画：展示层是微信小程序，业务层是Controller+Service，数据层是MyBatis+MySQL。时序图挑一条主链路画，比如“用户登录到查看商品列表”的请求顺序。画完图再写文字描述，字数基本就够了。

注意别把论文写成“操作手册”。论文里写“系统分为管理员端和用户端”这种话没有意义，要写“用户点击商品详情后，系统根据goodsId查询t_goods表，校验status为1后返回商品信息”这种和代码强相关的描述。

4.3 答辩PPT的核心三张图：架构图、ER图和时序图

PPT页数不用多，但要保证三张图清晰。第一张是系统架构图，画小程序端、后端SSM、数据库三层，标出接口协议是JSON；第二张是数据库ER图，把四张核心表的关联画出来，尤其是订单表和商品表、用户表的关系；第三张是功能模块图或时序图，选一个完整流程，比如“发布商品-管理员审核-商品上架-用户下单”，画出状态和接口调用的顺序。

答辩老师最常问的三个问题分别是：为什么选微信小程序而不是App、SSM相比Servlet好在哪、数据库为什么这样设计。PPT里给每张图配两三句说明，其余内容放在讲稿里背熟。每页PPT的正文别超过五行字，图旁边留白，这是最稳妥的格式。

4.4 说明文档里的环境信息：JDK、MySQL、Tomcat版本别忽略

说明文档往往放在压缩包最外层，容易被忽略，但它是最值钱的文件。里面一般写着开发环境版本、部署步骤和初始账号。先确认三件事：JDK是1.7还是1.8，这决定你能不能直接跑Maven编译；MySQL是5.7还是8.0，这决定JDBC连接串和驱动jar；Tomcat是8还是9，这决定servlet-api版本兼容性。

这三处版本直接决定你的“跑不起来”成本。举例来说，JDK 1.8编译的代码放到JDK 1.7会报UnsupportedClassVersionError，MySQL 8.0用老驱动连不上，Tomcat 9对javax.servlet包名兼容性有差异。拿到项目后先把说明文档里的版本记在本子上，再对照本地已装的环境，不一致的部分能改环境就改环境，不能改再改代码配置。

5. 小程序+SSM跑通之后的排查日志：5个高频翻车现场

前后端联调阶段的问题千奇百怪，但校园二手交易平台这类项目的问题高度集中。这里记录5个最常见的翻车现场，每一条都有现象、原因和解决路径，排查时按这个顺序走能省不少时间。

5.1 商品列表空白但后端接口正常

现象：后端用curl访问能返回JSON，数据库里也有数据，但小程序页面一直白屏或显示加载失败。打开调试器Network面板，请求是pending或者报request:fail。

原因：最常见是微信开发者工具没有勾选“不校验合法域名”，小程序默认拦截所有HTTP非HTTPS请求。第二种可能是baseUrl写错了，比如后端Context Path是second_hand，前端拼成了secondhand。

解决：在“详情-本地设置”勾选跳过域名校验；然后检查app.js里的baseUrl和请求拼接路径。建议在Page的onLoad里先console.log一下完整url，确认拼出来的字符串能在浏览器直接打开。

5.2 登录接口总是返回401或token失效

现象：登录后能拿到token，但过一会儿再操作就报401；或者登录接口本身就一直提示“凭证无效”。来回改代码没用，像是玄学。

原因：这类项目的token一般是一个UUID存数据库或Redis，服务端设置有效期，常见是30分钟或2小时。如果代码里同时存在两个登录入口，一个生成新token，另一个还在校验旧token，就会出现时而有效时而失效。数据库里的token字段长度不够也是常见原因，UUID存进去被截断，校验时永远对不上。

解决：先打开数据库看t_user表里的token字段长度，改成varchar(64)；再检查后端登录接口是不是每次登录都刷新token，刷新后老token在哪里失效。课程设计阶段最简单可靠的方案是token里直接存userId，不加过期时间，答辩前再把过期逻辑补上。

5.3 发布商品时图片上传失败

现象：填完商品信息点“提交”，文字字段能保存，但图片要么显示上传中，要么提交后详情页图片裂了。后端控制台偶尔报MultipartException。

原因：SSM项目的文件上传依赖CommonsMultipartResolver，配置文件里漏配或bean的id写错都会导致上传接口直接报错。另一种情况是图片保存到了Tomcat部署目录下的临时文件夹，重启Tomcat后图片全没了。

解决：检查spring-mvc.xml里的multipartResolver配置，maxUploadSize一般设2MB或5MB，编码统一UTF-8；把图片存储路径改成Tomcat之外的绝对路径，比如D:/upload/，再给Tomcat配置虚拟目录映射。这样重启服务图片还在，答辩演示时不至于翻车。

5.4 数据库脚本导入报错：utf8mb4和MySQL 8.0的兼容问题

现象：用Navicat导入SQL脚本时报错，错误信息是Unknown collation: utf8mb4_0900_ai_ci或者Duplicate column name。多发生在脚本不是原作者的，而是从5.7迁移到8.0时倒出来的。

原因：MySQL 8.0默认字符集是utf8mb4，默认排序规则是utf8mb4_0900_ai_ci，MySQL 5.7不认这个排序规则；倒过来，5.7的脚本导入8.0也可能因为utf8_general_ci没兼容而报错。脚本里还可能有重复的CREATE TABLE语句，没做IF NOT EXISTS保护。

解决：用文本编辑器打开SQL脚本，把utf8mb4_0900_ai_ci替换成utf8mb4_general_ci，再把所有CREATE TABLE改成CREATE TABLE IF NOT EXISTS。导入前先确认目标数据库的字符集是utf8mb4，避免表建好了中文显示成问号。

5.5 改完后端代码，小程序里还显示旧数据

现象：Controller里改了返回逻辑，重启了Tomcat，小程序重新编译，但页面上还是旧数据。清缓存、关掉重开都没用，特别像“没部署成功”。

原因：微信开发者工具默认会缓存接口响应，wx.request的success回调如果没做处理，会直接拿缓存数据渲染；另外Tomcat的war热部署有时没生效，改的是target里重新编译的class，但Tomcat加载的还是旧的。

解决：先确认接口到底改了没，浏览器直接访问后端接口看返回；再确认小程序的wx.request有没有设置cache: false；最后看开发者工具Network面板的请求是不是走了from cache。如果是这样，把模拟器的“清除缓存”点一遍，再重新编译。后端侧最简单粗暴但有效的方法是重启Tomcat而不是热部署，等百分百生效再继续改。

6. 把课程设计变成可演示的项目：验证与上线前的准备

跑通只是开始，答辩和简历上能站住脚才算做完。最后一步做两件事：一次完整的真机验证，以及一个可以对外演示的部署方案。真机验证的目的不是图新鲜，而是模拟器和真机在屏幕尺寸、网络环境上的差异会让布局和加载问题现出原形。在开发者工具里点“预览”，会生成一个二维码，用手机扫码就能在真机里打开。重点测三件事：登录流程是否顺滑、发布商品时相册选图是否正常、订单状态变化后页面是否刷新。

我踩过最大的坑是图片上传后详情页不刷新，后来发现是发布成功的回调里只关了loading，没重新调详情接口。改成在success回调里主动刷新就正常了。如果你想把项目放到云服务器上，注意小程序正式版要求后端域名必须备案且支持HTTPS，本地IP地址只在开发版里能用。把Tomcat配好HTTPS证书，再把小程序里baseUrl从http换成https，才算走完上线前的最后一步。这个环节别临时抱佛脚，证书申请和备案流程都耗时。

这套SSM+小程序的组合虽然不算新，但对你理解前后端分离和接口设计很有帮助。我当年把商品列表的请求从每次都查数据库改成加了一层缓存，论文里多写了一节“性能优化”，答辩时老师恰好问的就是这个。技术可以旧，但你要有能力在里面找到一个可以讲清楚的点，把它做扎实。希望这些经验帮你在同样的路上少走几步，把项目从“能跑”做成“能讲”。

本文还有配套的精品资源，点击获取