企业官网建设流程全解析

做毕设选了这个题目的人，十有八九都在搜索引擎里翻过这几行字：微信小程序、优购电商、SSM。为什么这个组合那么热？因为它是一个性价比极高的全栈闭环——前端是微信生态里最主流的小程序形态，后端是Java后台里最经典实用的SSM框架，两者一拼，就把从数据库建模、接口设计到移动端体验的一条完整链路全部练到了。这篇文章把我做“微信小程序+SSM优购电商”的实际过程、踩坑记录和可以“抄作业”的方案完整写出来，适合正在做相关毕设的本科生、想快速搭一套可演示电商系统的开发者，以及准备毕业答辩但心里还发虚的同学。

我会把注意力放在三个地方：一是这个题目为什么要选、怎么设计才不会被导师追问到哑口无言；二是后端接口和小程序页面里那些“真会用到”的细节，比如登录态、购物车、分页加载、订单事务；三是开发过程中最容易翻车、但网上很少有人说透的问题。基本都是我用真实代码踩出来的经验，不是教科书搬过来的概念。

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

1.1 为什么客户端选微信小程序而不是App或H5

优购电商的目标用户是C端消费者，做毕设时最怕的是“功能还没写，环境先劝退”。原生App要处理应用商店审核、不同手机适配、证书打包，对一个学生团队来说周期和成本都不可控。H5虽然开发快，但支付能力、消息通知能力都要靠浏览器环境，体验上差不少。

微信小程序相当于“微信里的门店”，用户扫一扫码就能进去逛，免安装、免注册流程。更重要的是它直接把微信生态里的能力开放出来：wx.login() 做静默登录、wx.requestPayment 唤起微信支付、wx.requestSubscribeMessage 做订阅消息通知。这些能力对一个电商系统来说，正好是“闭环”的最后几块拼图。毕设答辩时老师问“为什么选小程序”，把这些点说出来，比一句“因为流行”要站得住脚得多。

另外还有一个很现实的原因：微信开发者工具的调试体验对新手非常友好。模拟器、真机预览、Network面板都是内置的，遇到问题定位起来比纯前端H5项目快很多。我实测下来，从零开始写一个用户端小程序页面，熟练后一天能出三到五个页面，效率比想象中高。

1.2 为什么后端选SSM而不直接上Spring Boot

SSM是Spring、SpringMVC、MyBatis三个框架的组合，国内教学和毕设里它有很长一段时间的统治地位。虽然现在Spring Boot已经成了企业开发的主流，但对这个体量的电商系统来说，SSM的轻量和可控性反而更适合学习和答辩展示。

原因有三点。第一，SSM的请求链路是显式的：请求进来找Controller、Controller调Service、Service调Mapper、Mapper里写SQL操作数据库，每一条线都清晰可见，你在答辩时说“我用了三层架构”是能指给老师看的；Spring Boot把很多东西自动化了，反而说不清楚底层发生了什么。第二，SSM需要手动维护配置文件，比如Spring的applicationContext.xml、SpringMVC的spring-mvc.xml、MyBatis的mybatis-config.xml，这一套配置写下来本身就是工作量，也很容易在论文里画架构图。第三，经典框架的提问点非常集中：IoC是什么、AOP用在哪儿、SpringMVC的处理流程、MyBatis的#{}和${}有什么区别，这些问题网上资料一大堆，准备起来稳。总共来说，这个项目体量用SSM是完全撑得住的，还能帮你把框架底子打扎实。

1.3 系统模块划分与整体架构

整个系统我拆成了三层：小程序客户端、SSM后端服务、MySQL数据库。用户端功能包括首页商品展示、分类浏览、商品搜索、商品详情、购物车管理、订单提交与支付、个人中心、地址管理。管理员端不需要再做一个小程序，用一个轻量Web管理页面就够了，负责商品上架/下架、库存修改、订单状态更新、用户列表查看。

角色权限我采用了最简单的方案：用户表里加一个role字段，0表示普通用户，1表示管理员。管理员直接通过数据库预置或一个小接口创建，不必引入Spring Security这种重型权限框架。做毕设时把“权限控制”讲清楚即可，不需要把企业级权限模型搬进来。

架构上前后端通过RESTful风格的JSON接口通信，所有接口返回统一的数据结构{ code: 0, msg: "success", data: {} }。这个统一返回值的设计非常重要，后面会详细说。数据库表设计了六张核心表：用户表、分类表、商品表、购物车表、地址表、订单表（外加订单项表）。

2. 数据库设计与接口规范

2.1 核心表结构与设计思路

数据库是整套系统的地基。我一开始为了赶进度，随手建了一张“万能商品表”，所有信息塞一起，结果写到订单功能时发现历史订单数据根本没法保存，又回头重构。先给出我最终使用的核心表结构，这是踩完坑之后沉淀下来的版本。

用户表user：

商品表product：

订单表order和订单项表order_item是整个系统里最需要用心设计的部分。订单表只存订单维度的信息，比如订单号、总价、收货人信息、支付状态；订单项表存这个订单买了哪些商品，每个商品买了几个、当时单价多少、商品快照是什么。

为什么订单项里要冗余一份商品名称、商品图片和价格，而不是直接通过product_id关联商品表？因为商品是会变的：商家可能修改价格、下架商品、更换主图。如果订单项里不留快照，三个月后查一个历史订单，显示的商品名和价格可能跟用户当时买的不一致，这在电商系统里是严重的体验事故。所有正规电商系统都会在订单里做商品快照，这个细节论文里写出来是加分项。

地址表address也建议单独建，不要在用户表里塞一个单地址字段。用户下单时可以选择一个默认地址，也可以临时换一个收件地址，单独一张address表关联user_id就能支持“多个收货地址”这个常见需求。

2.2 统一接口返回格式与状态码

前后端分离开发，接口规范必须先定好，不然小程序端对接的时候能折腾到你怀疑人生。我定的统一返回类是Result，核心字段就三个：code、msg、data。

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> error(Integer code, String msg) { Result<T> r = new Result<>(); r.code = code; r.msg = msg; return r; } }

状态码我不用HTTP状态码那一套复杂的体系，就自定义了几个够用的：200表示成功，400表示参数错误，401表示登录态失效，500表示服务端异常。小程序端封装一个request方法，拦截所有响应，统一处理401跳转登录页，代码能省一大部分。这个小设计在答辩时也要讲：“我通过统一返回体，把异常处理收敛到了前端请求封装层，业务代码里不用每个接口都写try-catch。”这就展示了架构意识。

2.3 分页参数的约定

商品列表、订单列表这类数据量大又不确定上限的接口，必须做分页。我统一用pageNum（页码，从1开始）和pageSize（每页条数）两个参数。后端返回的数据结构里除了列表本身，还要带total（总条数）或hasMore（是否还有下一页）。我建议返回total，小程序端用它算“有没有更多”更准确。

{ "code": 200, "msg": "success", "data": { "list": [], "total": 57, "pageNum": 1, "pageSize": 10 } }

有了total就能判断pageNum * pageSize >= total时显示“没有更多了”，这个逻辑在后面的“加载更多”部分会用到。

2.4 订单状态流转设计

订单状态是整个业务逻辑的三驾马车，设计成数字状态字段status，我用四个状态：0待付款、1待发货、2待收货、3已完成，另外加一个负值 -1 表示已取消。状态流转是单向的：待付款可以取消或支付成待发货，待发货由管理员发货为待收货，待收货用户确认收货变成已完成。不要设计成任意状态可以互跳，那样会产生一堆脏数据。

3. 后端SSM核心实现与常用注解

3.1 SSM常用注解及作用

网上那么多SSM常用注解的总结，真正写项目时高频使用的其实就这几个，我把它们按出现的位置归类：

重点关注@Transactional和@Autowired。@Autowired的原理是Spring容器按类型自动注入，对于只有一个实现类的Service，直接用字段注入最省事；答辩时可能会被问到“Autowired按什么装配”，答“先按类型byType，找不到再按名称byName”即可。@Transactional用于声明事务边界，默认情况下遇到RuntimeException会自动回滚，这点后面下单流程会具体说。

3.2 三层架构的职责边界

SSM项目和其它Java Web项目一样，分层是骨架。Controller层只做参数接收和结果返回，不写业务逻辑；Service层封装业务规则和事务边界；Mapper层只写SQL操作和结果映射。

我在写这个项目时给自己定的一条规则是：Controller里的方法不能超过十行，Service里的方法尽量不要超过五十行。凡是要跨多个Mapper操作的逻辑，比如“下单要查购物车、验库存、扣库存、生成订单、删购物车”，一定放在Service的一个方法里，并且加上 @Transactional。这样一来排查问题时定位非常清晰：页面报错先看Controller参数对不对，再在Service里打断点看业务逻辑，最后看Mapper的SQL是不是写错了。很多同学的代码喜欢把SQL写在Controller里，刚开始能跑，后期加需求时直接变成一团乱麻。

3.3 微信小程序登录与session管理

小程序登录是后端第一个要对接的接口，也是整个系统的入口。微信小程序的登录流程是这样的：

1. 小程序端调用wx.login()获取一个临时登录凭证code，这个code只能用一次，有效期五分钟。
2. 小程序把code发给后端。
3. 后端拿着code调用微信的jscode2session接口，传入appid、secret、code，换取openid（用户唯一标识）和session_key（会话密钥）。
4. 后端用openid查用户表，不存在则自动注册一个新用户，然后生成一个自定义的token返回给前端。
5. 小程序把token存在storage里，后续所有请求在header里带上token。

后端生成token我用的最简单的方案：UUID+ 存Redis或用数据库token表保存。毕设项目如果不想引入Redis，可以提前说明“生产环境建议用Redis并设置过期时间，本系统用数据库存储token，通过设置过期时间字段实现会话管理”，这个话术在答辩时很实用。

wx.login拿到code后，后端关键代码如下：

@RestController @RequestMapping("/api/auth") public class AuthController { @Autowired private AuthService authService; @PostMapping("/login") public Result login(@RequestBody Map<String, String> params) { String code = params.get("code"); if (StringUtils.isEmpty(code)) { return Result.error(400, "code不能为空"); } return authService.login(code); } }

在AuthService里，调用微信接口的部分用RestTemplate或HttpClient实现。核心逻辑是请求这个URL：

https://api.weixin.qq.com/sns/jscode2session?appid=APPID&secret=SECRET&js_code=CODE&grant_type=authorization_code

微信会返回一段JSON，其中openid字段就是用户在微信体系内的唯一标识。这里有一个非常容易踩的坑：不要直接拿openid当前端登录凭证。如果直接把openid传给前端，任何人抓包看到别人的openid，就可以伪造请求头伪装成那个用户登录，这是严重的安全漏洞。正确做法是后端自己生成一个不透明的token，把openid映射关系保存在服务端。

3.4 商品分页查询：Mapper写法和PageHelper的取舍

商品列表接口是最典型的列表接口，也最适合展示SSM的开发规范。我一开始用的是手写分页SQL，逻辑很简单：

SELECT * FROM product WHERE status = 1 ORDER BY sales DESC LIMIT #{pageNum}, #{pageSize}

LIMIT第一个参数是偏移量，计算公式是(pageNum - 1) * pageSize，这个要放在SQL参数里提前算好。手写分页的优点是逻辑完全可控，对小项目来说性能也够。后来为了演示效果，我在项目中使用了PageHelper插件，它能让你不用关心方言，直接PageHelper.startPage(pageNum, pageSize)然后查询List，返回结果会自动带上分页信息。

这里有个使用细节必须提醒：PageHelper.startPage()只对接下来的一条SQL查询生效。如果连续执行两条查询，第二条会查出全表数据。所以使用PageHelper时，startPage必须紧跟需要分页的那条Mapper查询，中间不要插入任何其它查询或操作。

3.5 下单与库存扣减的事务实现

电商系统最核心的业务逻辑就是下单。先用文字梳理完整流程，再说明为什么必须加事务。

下单接口的入参是：用户ID（从token解析）、收货地址ID、购物车选中条目ID列表。后端处理逻辑：

1. 根据购物车ID列表查出商品信息，校验商品状态为上架且库存充足。
2. 计算总价。
3. 生成订单主表记录，状态为待付款。
4. 批量生成订单项明细。
5. 批量扣减商品库存。
6. 删除对应的购物车记录。

这六个步骤必须在一个事务里完成。中途任何一步失败，比如库存不足、地址无效、购物车记录被删除，之前所有操作都要回滚，否则会出现“订单生成了但库存没扣”或者“库存扣了但订单没生成”的数据不一致问题。

在SSM里，事务只需要在Service方法上加上@Transactional注解：

@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private OrderItemMapper orderItemMapper; @Autowired private ProductMapper productMapper; @Autowired private CartMapper cartMapper; @Override @Transactional(rollbackFor = Exception.class) public String createOrder(Long userId, Long addressId, List<Long> cartIds) { // 1. 查购物车和商品，校验库存 // 2. 计算总价，生成订单号 // 3. 插入订单记录 // 4. 插入订单项 // 5. 更新库存 stock = stock - quantity // 6. 删除购物车记录 // 返回订单号 } }

库存扣减这里有一个并发情况下很经典的问题：两个用户同时抢购同一个商品，假设库存只有1件，两个请求同时读到库存=1，都判断“库存充足”，然后各自扣减。如果用上面的SQL写法，可能出现库存扣成负数。

解决问题的两种常见方案，答辩时问到这个题目可以直接给出来：

方案一：使用乐观锁，扣减库存时带上条件。SQL写成：

UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

这行SQL返回影响行数，如果影响行数为0，说明库存不够（或商品被并发操作改了），再回滚事务报“库存不足”。这个方案简单高效，也是我现在推荐的最优做法。

方案二：使用悲观锁，查询商品时加FOR UPDATE。在MySQL的InnoDB引擎下，SELECT ... FOR UPDATE会对这一行加锁，其它请求必须等当前事务提交后才能查这行。这个方案写起来更简单，但并发量大时会产生锁等待，性能差一些。

毕设项目选方案一就够了，还能在论文里解释清楚“乐观锁”和“CAS思想”，展示你对并发控制有概念。

3.6 微信支付的简化与衔接

真实微信支付需要企业资质申请商户号，还要配置商户证书、回调地址、API v3密钥，学生毕设很难走完整流程。我的处理是：后端先完整实现“生成预支付单并保存订单待支付状态”的接口，小程序端点击支付时，通过wx.requestPayment发起真实支付。如果商户号没有申请下来，就在前端做一个“模拟支付”按钮：点击后直接调用后端接口把订单状态改成已支付。

在论文里一定要把真实支付流程写清楚：小程序端wx.requestPayment唤起收银台，支付成功后微信服务器异步回调后端接口/api/pay/notify，后端验证签名、修改订单状态、更新支付时间。这个回调设计很值得在答辩时讲，因为微信支付的关键不是前端跳转，而是后端的异步通知回调。

4. 微信小程序前端实现的关键细节

4.1 rpx适配与顶部导航栏高度

写小程序页面绕不开rpx这个单位。rpx的全称是responsive pixel，设计理念是“以750rpx对应屏幕宽度”，也就是说不管手机屏幕是320px还是375px宽，只要用rpx写，都会按比例换算。写页面时宽度直接用750rpx统一标准即可。

真正麻烦的是顶部导航栏高度。默认导航栏在小程序里占了屏幕顶部一块区域，iPhone X之后的机型有刘海和底部安全区，同样一段CSS样式在iPhone 8和iPhone 15上的表现完全不同。如果项目页面需要沉浸式大图或者自定义导航栏，必须处理两个参数：状态栏高度（微信官方叫statusBarHeight）和胶囊按钮位置。

获取方式有两种：

// 方式一：获取系统信息 const systemInfo = wx.getSystemInfoSync(); const statusBarHeight = systemInfo.statusBarHeight; // 方式二：获取胶囊按钮位置 const menuButton = wx.getMenuButtonBoundingClientRect(); const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height;

第二种方式里navBarHeight算出来的是自定义导航栏总高度，公式的原理是“导航栏上下空隙相等，所以胶囊到状态栏的距离乘2，加上胶囊本身高度”。我在不同机型上实测过，这个公式算出的高度适配度很高。

还有几个实际坑：Android和iOS的胶囊尺寸不同，Android上胶囊大概高32px，iOS上高32px或34px；状态栏高度在刘海屏和非刘海屏之间差异很大。因此标准做法是拿到数据后用inline style动态设置导航栏高度，不要写死在CSS里。

4.2 商品列表的“加载更多”与上拉刷新

商品列表是电商页面里最典型的长列表场景。前端用scroll-view或者页面自带的滚动都行，我推荐用页面自带的滚动，因为小程序提供的onReachBottom生命周期钩子可以直接监听到滚动到底部，不用手动计算滚动距离。

加载更多的基本思路是维护pageNum、pageSize、list、hasMore等数据，每次触底请求下一页，把新数据append到列表后面。关键代码：

data: { pageNum: 1, pageSize: 10, goodsList: [], hasMore: true, isFetching: false }, onReachBottom() { if (this.data.isFetching || !this.data.hasMore) return; this.loadGoods(); }, loadGoods() { this.setData({ isFetching: true }); wx.request({ url: `${baseUrl}/api/goods/list`, data: { pageNum: this.data.pageNum, pageSize: this.data.pageSize }, success: (res) => { const { data } = res.data; this.setData({ goodsList: this.data.goodsList.concat(data.list), hasMore: this.data.pageNum * this.data.pageSize < data.total, pageNum: this.data.pageNum + 1 }); }, complete: () => { this.setData({ isFetching: false }); } }); }

这里一定要用isFetching标志位防止重复请求。如果不加这个判断，用户快速滚动时onReachBottom会在短时间内触发多次，每次都会发一个请求，页面就会出多条重复数据。

上拉刷新有两种实现方式：页面配置里开启"enablePullDownRefresh": true，然后监听onPullDownRefresh回调；或者用scroll-view的refresher-enabled属性和bindrefresherrefresh事件。我用的是后者，因为在自定义导航栏的页面里，页面级下拉刷新有时会被导航栏的交互影响，scroll-view下拉更可控。

4.3 wx.login完整示例与请求封装

登录这块把完整代码贴出来，毕设里基本可以直接套用。先在app.js的onLaunch里调用登录逻辑：

App({ onLaunch() { const token = wx.getStorageSync('token'); if (token) { this.globalData.token = token; return; } this.login(); }, login() { wx.login({ success: (res) => { const code = res.code; wx.request({ url: `${baseUrl}/api/auth/login`, method: 'POST', data: { code }, success: (response) => { const { data } = response.data; wx.setStorageSync('token', data.token); this.globalData.token = data.token; }, fail: () => { // 登录失败，延时重试 setTimeout(() => this.login(), 3000); } }); } }); } });

封装一个统一的请求方法request.js，所有页面都用它发出请求：

const request = (options) => { return new Promise((resolve, reject) => { wx.request({ url: `${baseUrl}${options.url}`, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', 'token': wx.getStorageSync('token') || '' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { // 登录态失效，重新登录 getApp().login(); reject(res.data); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); } }, fail: reject }); }); };

注意一个容易犯的错误：wx.request的success回调里不能用普通函数方式访问外层this，因为回调函数有自己的this指向。上面代码用了箭头函数（arrow function），箭头函数没有自己的this，所以可以安全使用外层this。如果写成function(res) {...}，里面用this.setData就会报错。这个问题在微信小程序里非常常见，用const that = this或者箭头函数都能解决，推荐直接用箭头函数。

4.4 购物车：服务端存储与本地状态同步

购物车我建议存服务端，不要只存在小程序本地。因为用户换一台手机登录同一个微信号，购物车如果存在本地就全丢了；且购买逻辑基于服务端购物车校验更可靠。用户登录后，购物车接口跟着token走，数据天然和用户绑定。

页面上购物车的数据结构是一个数组：

cartItems: [ { id: 1, productId: 10, name: "商品A", price: 99.00, image: "...", quantity: 2, checked: true }, { id: 2, productId: 12, name: "商品B", price: 59.00, image: "...", quantity: 1, checked: false } ]

页面操作有加号减号、勾选/取消勾选、批量删除。每一项操作都先做本地setData更新界面（保证交互流畅），再异步调接口同步服务端数据。如果接口失败，再回滚本地状态并提示。用一句话概括就是“本地先改，服务端兜底”。

计算合计金额时有一个血泪教训：JavaScript浮点数精度问题。0.1 + 0.2在JS里等于0.30000000000000004，商品价格一多就会出诡异的总价。解决方案是金额一律用“分”做整数计算，比如99元存储为9900，前端展示时再除以100转成元。这个细节写进论文里，技术含量瞬间提升一个档次。

4.5 订阅消息授权弹框的实现与坑

订单支付或者发货后要通知用户，小程序里用订阅消息。用户必须主动同意接收，且一次同意只能发一条。代码示例：

wx.requestSubscribeMessage({ tmplIds: ['模板ID'], success: (res) => { if (res['模板ID'] === 'accept') { // 用户同意了，可以发送一条订阅消息 } else { // 拒绝授权，不要反复弹窗骚扰用户 } } });

常见坑有两个：一是用户拒绝后，不能每次进页面都弹授权框，体验极差，需要做状态记录，比如只在支付成功页弹一次；二是长期订阅需要申请专门的长期模板，个人小程序基本申请不到，所以项目里用一次性订阅是最现实的方案。另外要注意，订阅消息的下发必须由后端调用微信接口触发，前端只是收集用户的授权记录，真正的发送逻辑在服务端完成。

5. 调试、打包与上线部署

5.1 接口调试：开发者工具Network面板与本地抓包

小程序开发最常见的调试需求，是看请求发出了多少、响应是什么状态。微信开发者工具自带Network面板，可以查看每个请求的Headers、RequestBody、ResponseBody，对于绝大部分定位工作已经足够。如果要在真机上调试，可以用开发者工具的真机调试功能，配合“调试”模式中的Network信息。

如果遇到一些比较隐蔽的接口问题（比如HTTPS证书错误、请求被拦截、响应数据被异常截断），可以用本地抓包工具做更底层的分析。原理是让手机和电脑处于同一个局域网，电脑上运行抓包服务，手机端对该服务开启信任后，小程序的完整请求都能在电脑上展示出来。这样能看到微信开发者工具模拟器里“看不见”的内容，比如真实网络环境下请求头的完整信息、TLS握手状态等。用的时候注意，抓包工具看到的都是明文流量数据，自己调试本地开发环境没问题，不要乱抓陌生网络。

更常见的做法是让后端把接口文档维护好，前端和后端各搭各的，联调时再用开发者工具的Network对齐字段。这套流程才是真正高效的，比在模拟器里反复点按钮看效果省一半时间。

5.2 小程序包体积超限问题与分包加载

这是几乎每个人都会撞到的报错：source size 2612kb exceed max limit 2mb。微信小程序主包大小限制2MB，超过就无法上传。如果用的是uni-app框架，发布到微信小程序时经常碰到这个爆包问题。

从根本逻辑来说，单个包体超限意味着要把体积“拆开”。拆包有几种手段，按优先级来：

第一，压缩图片。小程序包里放一张大图就可能占几百KB，商品图等非关键资源全部放到服务器或对象存储，用URL引用，不要放进包代码。

第二，删除无用代码和依赖。检查miniprogram_npm目录是否有引入但没用到的库，把console.log和注释多的代码清理干净。

第三，使用分包加载。在小程序app.json里配置subPackages：

{ "subPackages": [ { "root": "pagesOrderPackage", "pages": [ "pages/order-list/order-list", "pages/order-detail/order-detail" ] } ] }

分包加载的规则是：小程序启动时只加载主包，用户进入分包页面时才加载对应分包。所以把主包里的公共页面（首页、登录、商品详情）放主包，把订单、个人中心这种二级页面放进分包，包体积能降一个量级。主包总大小建议控制在1.5MB以内，留一点余量给后续修改。

实测中还有一个细节：分包里的页面要做到“真分包”，不能只是分发目录但代码里还是通过主包的路由跳转。配置了subPackages后，跳转路径如果从根写，分包需要带上root前缀路径，否则可能跳不到分包页面。

5.3 真机预览、体验版与多人试用

开发完成后要让别人试用，不能直接把代码发过去让人家装开发者工具。正确的流程是：在微信开发者工具右上角点击“上传”，填写版本号和备注，代码会进入微信公众平台。然后在“版本管理”里找到开发版本，点击“设为体验版本”，再把体验者的微信添加为体验成员。体验成员扫码打开小程序，就是体验版。

如果需要收集试用反馈，不要只是口头让大家去试。体验版有“体验数据”隔离的特性：体验成员看到的页面数据，取决于后台API用的是生产环境还是测试环境。如果要收集真实反馈，建议把体验版配置的请求域名指到测试服务器，并开放一个“测试模式”按钮，方便体验者一键生成测试数据。

体验版本还有一个易混淆点：体验版和正式版是两套独立的审核和管理流程。改动代码后必须重新上传并设为体验版，原来那条体验版的二维码链接本身不会更新内容。多人同时体验时，每个人扫同一个码，看到的都是同一份体验版本代码，反馈是统一的，这对收集集中测试意见很友好。

5.4 服务器部署与HTTPS证书

小程序正式版本要求所有请求域名必须是HTTPS，且需要在微信公众平台后台配置request合法域名。域名要求是备案过的，并且证书有效。部署方案：

1. 准备一台云服务器，装好JDK 8、MySQL 8、Tomcat或直接跑打包好的Spring Boot jar（SSM项目一般用Tomcat部署war包）。
2. 初始化数据库，把SQL文件导入。
3. 打包后端项目，上传到服务器，启动。
4. 在域名服务商处申请SSL证书。国内主流云服务商都有免费证书，下载并配置到Nginx或直接配置到Tomcat的server.xml。
5. 在小程序后台的“开发设置”里配置服务器域名。

这里有一个项目结构上的建议：如果后端是SSM的项目结构，尽量打包成war部署到Tomcat；如果是Spring Boot结构，直接java -jar跑更简单。毕设项目如果没有对外真实运营需求，本地演示时可以让开发者工具勾选“不校验合法域名”，用本地或局域网的IP地址联调，这样省去了申请域名和证书的很多麻烦。正式答辩前，把本地环境跑通、把演示数据准备好，比盲目折腾服务器稳妥得多。

6. 常见问题排查与避坑指南

把我在整个开发过程中遇到的、以及在同学们的项目里反复出现的典型问题集中整理成一张速查表，方便定位。

除了表格里这些问题，还有几个不一定报错但会被导师盯上的细节。

第一个是SQL注入。MyBatis里写SQL时，传参用#{}而不是${}。#{}会被预编译成占位符?，由JDBC驱动做参数绑定，天然防注入；${}是字符串拼接，直接拼到SQL里，有注入风险。以“按商品名模糊搜索”为例：

<select id="searchByName" resultType="com.example.entity.Product"> SELECT * FROM product WHERE name LIKE CONCAT('%', #{keyword}, '%') </select>

这个写法安全且能正常模糊匹配。如果写成LIKE '%${keyword}%'，测试时好使，一旦被人传个'; DROP TABLE product; --之类参数，数据库就危险了。这是个一票否决的安全问题。

第二个是日志。SSM项目要养成交代日志的习惯，特别是在Service层的方法入口、数据库操作的异常处。用LoggerFactory.getLogger打印日志，比自己写System.out.println强一百倍。答辩时被问“线上报错怎么排查”，回答“看日志定位异常堆栈”是一个标准答案。

第三个是密码和密钥管理。小程序的appid和secret不要硬编码在前端代码里，secret只能存在后端。有的同学为了省事，把secret写在wx.request的URL参数里，这等于把钥匙插在门上，被人抓包就泄露了。正确做法是把secret放在后端配置文件里，由后端统一调用微信接口。

7. 从开发到答辩的完整建议

7.1 论文写作要点与整体节奏

毕设论文的常见结构是：绪论（背景与意义）、需求分析、系统设计、系统实现、系统测试、总结展望。结合这个项目，每一章的核心输出我总结一下：

第一章绪论里，“国内研究现状”可以写微信小程序的生态发展、电商小程序的应用趋势，但不要空喊“随着移动互联网的发展”，要落到具体数据和技术细节上。第二章需求分析，先画用例图：游客/用户/管理员三个角色各能干什么，每个用例对应到功能模块。第三章系统设计，画架构图、E-R图、主要用例时序图。第四章系统实现，按“登录模块、商品模块、购物车模块、订单模块”拆章节，每个模块给出核心代码片段和界面截图，重点解释关键技术。第五章测试，写功能测试用例表，最后加一点性能测试或安全测试的描述。

论文节奏上，我强烈建议先写“系统设计”再写“需求分析”，因为很多人在写需求分析时根本不知道系统会做成什么样，空想出一堆需求，代码实现时全变了。先搭好表结构、定好接口，需求分析一章等于“照着已有功能写使用说明”，真实且高效。

7.2 答辩常见提问与应对

答辩老师问得最多的几个问题，我提前把标准回答备好了：

问：SSM框架的请求流程是怎样的？ 答：请求进入SpringMVC的前端控制器DispatcherServlet，通过HandlerMapping找到对应的Controller方法，方法内部调用Service，Service调用Mapper接口，Mapper在MyBatis中通过XML或注解找到SQL并执行，返回结果逐层向上传，最终由HandlerAdapter封装成JSON响应给前端。

问：数据库表之间的关联关系？ 答：用户和订单是一对多；订单和订单项是一对多；商品和分类是多对一；用户和购物车是一对多，购物车和商品是多对一。

问：为什么订单表要冗余商品信息？ 答：商品可能改价、下架、删除，历史订单需要保留用户购买时的商品信息和价格快照，这是电商平台的通用做法。

问：事务怎么实现的？ 答：通过Spring的声明式事务@Transactional，Spring AOP在方法前后织入事务开启、提交和回滚逻辑。默认遇到RuntimeException自动回滚，通过rollbackFor配置也可以指定回滚的异常类型。

问：如果用户下单后不支付，订单怎么办？ 答：设计了订单状态机，待付款订单超过一定时间未支付可以自动取消或由用户手动取消。论文里可以写一个定时任务扫单接口，或者在小程序端做倒计时提醒，但核心是说明这个状态流转是有规划的。

能把这几个问题从容答出来，答辩就已经成功了一大半。最怕的是对着PPT念代码，老师一追问就卡壳。保持“我先说流程，再演示结果”的节奏，就不会出现太尴尬的场面。

7.3 如何让项目比同类选题更有亮点

“微信小程序+电商系统”是毕设里的常青树，很多同学做的都差不多，但只要在几个点上下点功夫，就能让项目明显拉开差距。

第一个亮点是搜索功能。不做数据库全表扫描，而是用一个keyword参数配合SQL的模糊查询，同时在前端做一个搜索历史记录，这个功能看起来简单但交互完整，很容易在演示时出效果。

第二个亮点是前端体验细节。比如商品列表的骨架屏、加载中的loading动画、空状态的插画、页面切换的动画，这些都是低成本高感知的部分。评委老师打开小程序第一眼，看到的是界面，不是后端接口。把首页做得干净、加载速度快，印象分会高很多。

第三个亮点是接口安全。登录接口做频率限制，防止恶意刷验证码；所有接口统一校验token，为后续扩展鉴权框架预留接口。这两个点看似轻描淡写，但体现的是工程意识，非常加分。

第四个亮点是数据统计。管理员页面加一个简单的可视化统计，比如按天的订单量柱状图、商品销量排名。后端写一个SELECT DATE(create_time), COUNT(*) FROM order GROUP BY DATE(create_time)，前端用ec-canvas画个柱状图，五分钟就能做完，但整个项目的完整度立刻上了一个台阶。

说到底，毕设项目不是跟别人比谁功能多，而是比谁更能把“为什么这么设计”讲得清楚。做小程序电商这个选题，只要把登录、商品、购物车、订单、支付这几条核心链路彻底打通，把SSM每一层的作用说明白，在技术上就已经是一个完整且合理的学生项目了。

真要说个人体会，做这类全栈项目时最忌讳一上来就写代码。先把数据库字段设计好，把接口列表列清楚，把订单状态流转画明白，哪怕多花两三天，后期开发的顺畅程度完全不一样。数据设计对了，后面所有接口都好写；数据设计乱了，越写越乱，最后不是加需求，是填坑。另一个建议是提前把微信开发者工具里的“上传时自动压缩图片”和缓存设置研究明白，目录能省很多体积，也能少遇到一点莫名其妙的缓存问题。

我到现在还记得第一次把小程序版本传到手机真机上、扫码打开、下单、支付、后台订单状态同步改变时的那种成就感。这条路走下来，所有踩过的坑最终都变成了答辩时的底气。你也一样，按部就班把每一步做扎实，这个小系统一定能撑起一篇合格的毕业论文。