微信小程序+SSM框架全栈开发：从设计到部署全解析

最近在整理往年项目的文档时翻到一个很有意思的工程，名字叫“weixin152未知小程序的设计与实现+ssm”，第一眼看到这个命名就觉得特别亲切——这不就是典型的课程设计/毕业设计风格嘛。项目前缀是weixin，中间跟着编号，后缀是ssm，一看就知道是微信小程序前端配合SSM框架做后端管理端的组合。这个项目虽然名字里带了“未知”两个字，但拆开来看，它的技术栈、架构模式、开发流程都非常清晰，非常适合拿来当作小程序全栈开发的入门范本。

接下来我就以这个项目为引子，把微信小程序+SSM这套组合从设计思路到落地实现完整拆一遍，包括我实际开发中踩过的坑和总结的排查经验。无论你是正在做课程设计的学生，还是想快速上手小程序全栈开发的初学者，这篇文章应该能帮你省下不少折腾的时间。

1. 内容整体设计与思路拆解

这个项目的核心价值在于它代表了小程序开发中最经典、最稳妥的一种组合方式：前端微信小程序负责用户交互，后端SSM（Spring + SpringMVC + MyBatis）框架负责业务逻辑和数据持久化。在正式动手之前，先把整套架构的来龙去脉弄清楚，后面写代码才有底气。

1.1 为什么是小程序+SSM的组合

先说小程序端。微信小程序这几年的普及程度不用多说，如果做一个校园类、工具类或者电商类的系统，小程序几乎是最佳载体——用户不需要下载安装App，扫码就能用，传播路径短，微信生态内天然有流量优势。对于课程设计和毕业设计来说，小程序还有一个额外的好处：演示效果好，答辩的时候用微信扫一下就能看到运行效果，比单纯展示网页要直观得多。

再说后端。SSM框架在整个Java技术生态里的地位相当稳固，Spring管理对象依赖，SpringMVC处理请求分发，MyBatis负责数据库操作。这套组合的特点是结构清晰、职责分明，而且社区资料极其丰富，遇到任何问题基本都能搜到解决方案。虽然现在Spring Boot已经是很主流的选择，但SSM对于理解Java Web开发底层的请求流转过程更有帮助——你手动配置过web.xml、spring-mvc.xml、mybatis-config.xml之后，再去看Spring Boot的自动配置，会有一种“原来如此”的通透感。

1.2 核心功能模块的定位与划分

具体到业务功能设计上，这个项目虽然名字里没写具体业务类型，但按照常规的设计套路，功能划分是可以直接套用的。小程序端是面向终端用户的，至少需要包含用户登录注册、首页信息展示、核心业务操作（比如预约、下单、查看列表）、个人中心这些基础模块。后台管理端是面向管理员的，通常包含数据统计仪表盘、业务数据的增删改查、用户信息管理、权限控制这几个核心模块。

我在实际拆分需求的时候习惯先画一个简单的功能树，把用户故事写清楚。比如“用户想查看某个商品/服务的详情”，对应前端就是详情页，后端就是detail接口；“管理员想修改价格”，对应前端就是编辑表单，后端就是update接口。把每个角色能做什么、每个动作对应哪个接口列出来，开发的时候就不会东一榔头西一棒子。

1.3 方案选型的几个关键考量点

选型这件事，直接关系到开发效率和最终效果。有几个点我特别想强调一下。第一，数据库选MySQL是稳妥的选择，轻量、免费、资料多，对初学者友好，工作以后绝大多数公司也在用MySQL生态。第二，JWT（JSON Web Token）做登录态的传递比传统的Session方案更贴合小程序的场景，小程序端没有Cookie机制，用Token放在Header里反而更加自然。第三，后台管理端的UI框架可以选择比较成熟的模板来改，比如基于Bootstrap或者Layui的后台模板，省去大量写CSS的时间，把精力集中到业务逻辑上。

提示：如果你是第一次做小程序+SSM的项目，建议先别急着追求花哨的技术点，把最基本的注册登录、列表展示、增删改查跑通，再考虑优化和扩展。基础链路通了，后面所有功能都是在这个骨架上长肉。

2. 核心细节解析与实操要点

框架选好之后，真正拉开差距的是细节。这一部分我挑几个直接影响项目成败的细节来讲，这些都是我在开发过程中实际碰到过的、真正花过时间解决的问题。

2.1 小程序端配置的注意事项

小程序的前端代码要在微信开发者工具里运行，首次创建项目的时候需要填AppID。开发阶段可以选测试号，但如果你需要用到登录功能、获取用户手机号、微信支付这些能力，就必须有一个正式注册的小程序账号。注意，小程序的request域名必须是HTTPS，开发阶段可以在开发者工具里勾选“不校验合法域名”，但上线之前一定要把域名配置好——HTTPS证书、ICP备案、域名解析，这三件套缺一不可，而且备案周期可能要一两周，务必提前准备。

还有一个很常见的坑是请求封装。小程序自带的wx.request功能比较基础，如果直接在业务代码里散落地调用，后面改域名、加鉴权会非常痛苦。我的做法是统一封装一个request.js文件，把baseUrl、超时时间、header里面存放token的逻辑都集中管理起来。这样所有网络请求都走同一个入口，出了问题只需要改一个文件。

javascript复制// utils/request.js
const BASE_URL = 'https://yourdomain.com/api';

function request(path, method = 'GET', data = {}) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: BASE_URL + path,
      method: method,
      data: data,
      header: {
        'Content-Type': 'application/json',
        'Authorization': wx.getStorageSync('token') || ''
      },
      success: (res) => {
        if (res.statusCode === 200) {
          resolve(res.data);
        } else if (res.statusCode === 401) {
          wx.redirectTo({ url: '/pages/login/login' });
          reject(new Error('未授权'));
        } else {
          reject(new Error(`请求失败：${res.statusCode}`));
        }
      },
      fail: (err) => {
        reject(err);
      }
    });
  });
}

module.exports = { request };

封装这一步价值极大。接口请求统一走到Promise里面，状态码集中处理，业务代码里只需要关心成功和失败两个分支，可读性和可维护性一下就上来了。

2.2 数据库表结构设计的思路

SSM项目的数据库设计是整个后端的根基，表结构没设计好，后面写Mapper和Service会处处别扭。我常用的设计方式是围绕业务实体拆表，并明确每个表的主外键关系。比如用户表，核心字段就包括openid、nickname、avatar_url、phone、create_time这些。业务表方面，以预约/订单这类系统为例，核心表至少包含业务编号、关联用户ID、业务内容、状态字段、创建时间。

设计表结构的时候有几个容易忽略的坑。第一，尽量不要用MySQL的关键字做字段名，比如order、desc，如果非用不可，记得加反引号包裹，但最好的方式还是换个名字，比如order_no。第二，每张表都建议加上create_time和update_time两个字段，排查数据问题的时候非常有用。第三，状态字段建议用tinyint，0和1表示不同状态，比直接存字符串更节省空间，查询效率也更高。

2.3 后端接口设计的最佳实践

后端接口的设计规范程度，直接决定了前端开发的效率。很多SSM项目接口设计比较随意，URL命名混乱，参数传递方式不统一，前端对接的时候苦不堪言。我在实际项目里总结了几个对自己团队比较受用的规范。

URL命名统一采用语义化的方式，比如“/api/user/login”表示用户登录，“/api/order/list”表示获取订单列表，“/api/order/detail”表示获取订单详情。请求方法要有明确的语义：查询用GET，新增用POST，修改用PUT，删除用DELETE。参数传递也尽量统一，GET请求用query参数，POST/PUT请求用JSON体。

返回数据的格式必须统一。我习惯封装一个Result对象，包含code、message、data三个字段。code为200表示成功，其他为异常码；message是给前端提示的文字信息；data是真正的业务数据。这样前端解析返回值时逻辑非常简单，只要判断code是否为200即可。

java复制// 统一的返回结果封装
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(Integer code, String message) {
        Result<T> result = new Result<>();
        result.setCode(code);
        result.setMessage(message);
        return result;
    }
    // getter/setter 省略
}

统一的返回结构是所有前后端分离项目的基础设施。定好这个规范之后，前端处理接口返回值时只需要关心data部分，处理异常的代码量也大幅减少。我遇到过很多项目因为返回格式不统一，前端每个请求都要写额外的判断逻辑，这种不必要的复杂度完全可以在设计阶段规避掉。

2.4 SSM 框架整合的核心配置细节

SSM整合的经典配置文件有四个：web.xml、spring-mvc.xml、spring-mybatis.xml、mybatis-config.xml。很多新手第一步就卡在配置这里，报各种奇怪的错误。

web.xml里需要配置Spring的ContextLoaderListener和DispatcherServlet。ContextLoaderListener负责加载Spring容器，管理Service层和Mapper层；DispatcherServlet负责加载SpringMVC容器，管理Controller层。两个容器各有分工，需要注意避免重复扫描。

spring-mvc.xml里要配置组件扫描、注解驱动、视图解析器。我把controller包的扫描放在这个文件里，并且把静态资源放行配置好，防止CSS/JS/图片等静态请求被DispatcherServlet拦截。

spring-mybatis.xml里配置数据源和SqlSessionFactory。数据源我习惯用Druid连接池，不仅性能好，自带监控页面也很方便排查问题。SqlSessionFactory需要注入数据源，并配置Mapper文件的位置。

xml复制<!-- spring-mybatis.xml 核心配置片段 -->
<context:property-placeholder location="classpath:jdbc.properties"/>

<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource">
    <property name="driverClassName" value="${jdbc.driver}"/>
    <property name="url" value="${jdbc.url}"/>
    <property name="username" value="${jdbc.username}"/>
    <property name="password" value="${jdbc.password}"/>
</bean>

<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="mapperLocations" value="classpath:mapper/*.xml"/>
</bean>

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
    <property name="basePackage" value="com.example.mapper"/>
</bean>

注意，如果你的项目里出现了“Invalid bound statement (not found)”这个报错，九成是mapper.xml文件没有被扫描到。检查一下mapperLocations的路径是否和实际的xml文件路径一致，这是SSM开发中最高频的问题之一。

2.5 前后端联调时的接口调试技巧

前后端联调是开发流程中最容易出问题的阶段。我习惯后端项目启动之后，先用Postman或者Apifox把所有接口过一遍，确定自己这端的逻辑没问题，再跟小程序端对接。这样做的好处是把问题范围缩小到单一侧，不会出现两边都有问题但互相甩锅的情况。

调试时有一个小技巧很有用——在小程序开发者工具的Network面板里，可以看到每个请求的详细信息，包括请求URL、请求头、请求体、响应结果。如果接口报错，先看Response里的code和message，这通常能直接定位到问题。如果Response为空，再看请求是否真的发出去了、请求地址是否正确、baseUrl的协议是不是https。

3. 实操过程与核心环节实现

纸上谈兵讲了这么多，现在进入实际开发环节。我按常规开发流程走一遍，把每个阶段的重点工作、关键代码实现和注意点都过一遍，你可以把它当作实施清单来参考。

3.1 环境准备与项目骨架搭建

开发环境的准备是第一道关卡。JDK版本建议1.8，这个版本是SSM项目的黄金搭档，踩坑最少。IDE我用的IntelliJ IDEA，社区版就够用了。MySQL装5.7或8.0都可以，Navicat或DBeaver用来管理数据库。小程序前端用微信开发者工具，官网下载稳定版即可。

环境装好之后，先创建一个数据库，比如命名为weixin_app，然后执行建表SQL。表结构不需要一次到位，先把用户表、核心业务表建出来，后面需要再追加。建表完成后，在IDEA里新建一个Maven项目，项目结构按照Java Web的标准来组织。groupId可以用com.example，artifactId用项目名，package结构建议分层清晰：controller、service、mapper、entity、config、common。

3.2 后端SSM框架整合流程

项目骨架创建好之后，开始整合SSM框架。这一步是最繁琐的，但走完一次以后就会觉得套路化程度很高。

第一步，在pom.xml中引入依赖。核心依赖包括：spring-context、spring-webmvc、spring-jdbc、mybatis、mybatis-spring、mysql-connector-java、druid、jackson-databind、javax.servlet-api、jstl。版本号不要乱选，spring用4.x或5.x都可以，mybatis-spring要用能与版本匹配的版本，否则运行时会报错。

第二步，写web.xml。这里有一个容易踩的坑——Spring和SpringMVC的扫描范围必须区分开。Spring容器扫描service和mapper层，SpringMVC容器只扫描controller层。如果两边都扫描了service，事务配置可能失效，调试起来非常头大。

第三步，写spring-mvc.xml。只扫描controller包，开启注解驱动，配置视图解析器。如果你的项目是前后端分离（小程序调接口），不需要返回JSP页面，视图解析器其实可以去掉，Controller里直接返回JSON数据由Jackson负责序列化。

第四步，写spring-mybatis.xml。配置数据源、SqlSessionFactory、MapperScannerConfigurer。事务管理用DataSourceTransactionManager，开启注解驱动事务。

第五步，写jdbc.properties，把数据库连接信息抽离成外部配置，后续发到不同环境的时候直接改这一个文件就行。

全部配置完成后，先写一个测试Controller，比如返回一句“Hello SSM”，启动Tomcat，访问验证框架是否整合成功。这一步通过之后，再开始写业务功能。

3.3 小程序端项目创建与页面开发

登录微信开发者工具，新建小程序项目，AppID用你注册的正式AppID或测试号都行，后端语言选择JavaScript基础库（注意别选了TypeScript模板，基础库不一样会徒增学习成本）。

项目创建成功之后，先梳理目录结构。需要创建或调整的文件夹包括：pages（放所有页面）、utils（放工具类，比如request.js）、components（放自定义组件）、static或images（放静态图片）。app.json里注册所有页面路径，设置window窗口样式；app.js里放置全局逻辑，比如启动时检查登录态。

首页、业务操作页、个人中心这几个核心页面逐个开发。首页通常是信息展示和主入口，用轮播图（swiper）、列表（list）组合出内容框架。业务操作页根据系统类型不同而不同，比如预约类就是表单加提交按钮，商城类就是商品卡片加购物车。个人中心页面通常包含头像昵称展示、我的订单/记录入口、设置相关功能。

每个页面的基础构成是wxml结构、wxss样式、js逻辑和json配置四个文件。开发时有一点需要注意——js里onLoad只会在页面首次加载时触发，而onShow每次进入页面都会触发。如果你的页面数据需要实时刷新，把数据加载逻辑放在onShow里会更可靠。

3.4 微信登录流程与用户体系打通

小程序登录是整个系统的关键环节。微信登录的基本流程是：小程序端调用wx.login接口获取code，把code发送给后端；后端拿这个code加上小程序的appid和secret去微信的接口换取openid和session_key；openid是用户的唯一标识，用它去查数据库，如果不存在就创建新用户，存在则直接返回登录成功；后端生成JWT token返回给前端，前端把这个token存到storage里，后续每次请求都带着它。

javascript复制// 小程序端登录逻辑
login() {
  wx.login({
    success: (res) => {
      const code = res.code;
      wx.request({
        url: BASE_URL + '/user/login',
        method: 'POST',
        data: { code: code },
        success: (response) => {
          if (response.data.code === 200) {
            wx.setStorageSync('token', response.data.data.token);
            wx.setStorageSync('userInfo', response.data.data.userInfo);
            // 跳转到首页
            wx.switchTab({ url: '/pages/index/index' });
          } else {
            wx.showToast({ title: '登录失败', icon: 'none' });
          }
        }
      });
    }
  });
}

后端接收code以后，调用微信接口的URL是固定的：https://api.weixin.qq.com/sns/jscode2session。参数包括appid、secret、js_code（就是前端传过来的code）、grant_type（固定值authorization_code）。返回值里openid就是需要存储并关联的用户唯一标识。需要提醒的是，微信接口返回的session_key属于敏感信息，只能在服务端使用，绝对不能返回给前端或者写进日志。

3.5 SSM后端核心业务接口实现

登录接口实现之后，核心业务接口按照Controller、Service、Mapper三层结构编写。以预约类系统为例，核心业务接口包括创建预约、查询预约列表、取消预约、管理员查看所有记录、管理员修改状态、用户管理。

Controller层只做参数接收和结果封装，不写任何业务逻辑。真正的判断和计算都在Service层，这样不仅方便复用，还可以在Service上加事务注解。操作写类的接口建议加@Transactional，以防出现“删除主表成功但删子表失败”这种脏数据问题。

Mapper层通过MyBatis操作数据库。简单查询直接用注解写SQL，复杂查询建议放在XML里。搭配动态SQL的where和if标签，可以很方便地实现列表查询的多条件筛选。多表关联查询时，注意返回的实体类字段和SQL查询结果的映射关系，不一致时用as别名处理，或者开启驼峰命名自动映射——mybatis-config.xml里加一行配置即可。

3.6 调试与真机预览的完整流程

开发过程中调试是常态。小程序开发者工具里模拟器、Network面板、Storage面板都很好用。手机预览前，记得在项目设置里把域名校验关闭（仅限开发阶段），或者在“详情-本地设置”中勾选“不校验合法域名”。真机测试时，用开发者工具里的“预览”功能生成二维码，手机微信扫码后可以打开小程序页面，在真机上操作一遍，重点看页面布局是否正常（尤其是底部导航和iPhone的刘海屏安全区）、请求是否通畅、按钮点击是否响应。

真机预览有一个容易忽略的点：手机的调试模式要打开，否则看不了console日志和控制台信息。在预览页面底部找到“调试”按钮打开vConsole，真机上的运行日志就能一目了然地展现在手机上，排查问题时比盲猜有效得多。

注意：小程序正式上线前，域名必须是HTTPS且在微信公众平台配置好合法域名，否则正式环境下所有请求都会被拦截。开发阶段关闭域名校验没问题，但上线前这步是必做的。

4. 常见问题与排查技巧实录

每次带新人做SSM项目，最花时间的就是帮他们排查各种环境、配置、代码层面的问题。下面把本人经历过的典型问题和排查思路整理成速查表，遇到同类问题可以直接对照处理。

4.1 后端启动与配置类问题

第一类是后端启动失败，Tomcat刚跑起来就报错，或者跑起来了但访问接口报404。这类问题绝大多数出在配置上。

Spring容器加载失败先看控制台第一行异常信息，最常见的几个：

• ClassNotFoundException或NoClassDefFoundError：说明pom依赖缺失或版本冲突，先mvn clean，再重新导入依赖。
• BeanCreationException：某个Bean创建失败，常见于数据源配置错误或者Mapper无法注入，检查jdbc.properties的数据库连接信息。
• 无法扫描到Controller：检查spring-mvc.xml中component-scan的base-package是否指向了正确的包路径，另外确认Controller类上是否加了@Controller或@RestController注解。

访问接口404，先确认访问的URL和Controller里@RequestMapping的值是否完全匹配，包括大小写。再看Tomcat部署的应用上下文路径，如果是localhost:8080/app，那接口地址就是http://localhost:8080/app/api/xxx。容易漏的问题是这个app路径，前后端联调时baseUrl忘加导致404的情况太常见了。

4.2 数据库操作类问题

数据库类问题中，最高频的是“Invalid bound statement (not found)”。排查思路按顺序来：看mapper接口路径和Mapper XML的namespace是否对应；确认Mapper XML文件是否在spring-mybatis.xml配置的mapperLocations路径下；确认mapper接口的方法名和XML中的id是否一致；最后，检查一下target目录下是否有XML文件——Maven项目编译时如果resources配置没包含xml，XML不会被复制到classes目录，这种问题查半天都不容易发现。

另一个常见问题是SQL语法报错或参数映射错误。控制台会打印具体的异常，根据异常提示定位到对应的SQL。MyBatis的参数传递要注意，多个参数时必须用@Param注解指定参数名，否则XML里直接用#{paramName}会拿不到值。

数据库连接超时也是常见问题。Druid连接池如果配置了连接超时时间，长时间未操作后再访问可能报“Connection is not available, request timed out”。排查时看数据库maxWait配置是否合理，同时也可以把timeBetweenEvictionRunsMillis设置到合适值，让连接池能自动回收闲置连接。

4.3 小程序端常见问题实录

小程序端的高频问题集中在登录态、请求报错、页面显示三个方面。

登录态失效是经典问题。小程序的token如果过期，后端会返回401。前端统一在request.js里处理401，清理本地缓存并跳转到登录页。注意一个细节：如果多个请求同时返回401，前端会触发多次跳转，最稳妥的办法是用一个标志位加锁，只允许第一次401触发重新登录流程。

请求报错时看具体错误码：fail:url not in domain list是域名配置问题，fail:timeout是网络超时或baseUrl错误，fail:request:fail是请求被拦截。逐一排查时优先看console打印的complete回调信息，那里会有更详细的提示。

页面显示类问题，最典型的像数据加载不出来。先在Network面板看接口是否正常返回，再看setData后的数据格式是否和wxml中遍历的字段对得上。很多时候不是请求出问题，而是返回的JSON字段和你写的{{item.xxx}}对不上——后端字段是userName，前端写成了username，就显示空白，这种低级错误花点时间仔细核对字段名就行。

4.4 安全与性能问题的隐性坑

这些不紧急但会影响体验质量。SQL注入的问题需要注意，MyBatis的#{}是预编译，能防注入；但如果你手写了${}，就有注入风险，用户输入内容拼接到SQL里时禁止使用${}。敏感信息不要硬编码，小程序端的appsecret绝对不能出现在代码里，所有涉及敏感凭证的调用都必须放在后端。性能方面，列表接口建议加limit分页，数据量大时再加索引。在小程序端，图片要压缩后再上传，轮播图和大图列表最影响首屏加载速度。

4.5 常见问题排查速查表

5. 项目打包部署与整体复盘总结

开发阶段告一段落之后，接下来是部署环节。很多初学者写了完整的系统，但不知道怎么把项目跑在云服务器上。这一节重点说说SSM后端和小程序前端从开发环境到正式环境的过程。

5.1 后端打包与服务器部署

SSM项目用Maven打包，在IDEA右侧Maven面板点package，会在target目录生成一个war包。如果你用的是Spring Boot，打成jar包即可。war包部署到Tomcat，把war放到webapps目录，启动Tomcat自动解压。

部署的云服务器配置，推荐最简方案：2核4G的云主机够用，系统用CentOS 7或Ubuntu 20.04。在服务器上安装JDK和Tomcat，配置MySQL数据库。MySQL的数据要与本地开发环境保持一致，可以把本地数据库导出SQL再导入服务器，也可以手动执行建表脚本。环境变量记得配置，启动Tomcat时如果报内存不足，在catalina.sh里调整JVM参数。

部署时需要检查几个地方：spring-mybatis.xml里的数据库连接地址换成服务器的实际地址和密码；如果用了阿里云等云厂商的RDS，注意白名单设置；安全组或防火墙开放相应端口。上线前把HTTPS证书通过Nginx绑定在域名上，为小程序合法域名配置做好准备。

5.2 小程序上线前检查清单

小程序正式发布之前，有几个容易遗漏的检查项：

• 合法域名是否已配置到微信公众平台，网络请求是否都改成HTTPS。
• 隐私政策是否填写。现在微信公众平台和小程序后台都强制要求配置用户隐私保护指引，否则审核会不通过。
• 小程序中是否有“测试数据”之类的不应出现在正式环境的内容。
• 是否关闭了开发者工具里的“不校验合法域名”选项。
• 各页面在iPhone和Android真机上跑一遍，重点看底部安全区和页面顶部适配。

小程序的审核一般需要1-3个工作日。首次提交审核可能因为类目不符或内容不合规被打回，被打回后按照提示修改后重新提交就行，不用太紧张。

5.3 项目复盘：这套技术栈能学到什么

整个项目跑通一遍之后，回头梳理一下学到的技术栈。对后端来说，SSM整合的完整流程、RESTful接口设计、统一响应处理、SQL编写和事务控制，这些是Java Web开发的基本功。对前端来说，小程序页面结构的编排、事件与交互逻辑、数据绑定的更新机制，以及请求封装等能力，在小程序领域是通用技能。

更难得的是，完整实践一次前后端分离的开发流程，从数据库设计到接口联调再到部署上线，每个环节都在真实的项目语境中实际操作过。面试时被问到项目经验，你能把从0到1的完整链路讲清楚，会成为一个很扎实的亮点。

5.4 对后续改进方向的一点建议

如果项目做完还有余力，可以继续打磨几个方向。后端可以引入Redis做缓存，把用户登录token存进Redis，既能支持过期时间，也能提升登录状态的校验效率。数据库分页可以封装成分页插件PageHelper，让列表查询的代码简洁很多。小程序端的体验优化更是无止境——加下拉刷新、上拉加载更多、骨架屏、分享给好友、订阅消息提醒，这些都是提升用户体验的功能点。

从课程设计角度讲，多做一点别人没做的功能点，演示效果会明显不一样。比如给预约/订单功能加上状态流转（待付款到待使用到已完成），加上简单的数据统计报表，这些扩展点是答辩时拉开差距的地方。

5.5 再分享一点开发习惯方面的经验

最后想聊几句开发习惯。写项目的时候，Git仓库从一开始就要建好，每次完成一个功能模块就提交一次。我发现很多同学都是项目全做完了才想起用Git，这就失去了版本控制的意义——中间如果改出问题，想回退都没地方退。另一个习惯是写接口文档，不用写得很复杂，用什么工具都行，至少要把哪个接口是什么功能、需要传什么参数、返回什么结构记下来。做小程序的时候，后端接口改了，前端几天后对接时对不上参数，有文档比面对面沟通高效得多。

还有一个点是记录踩坑笔记。可以是一个简单的Markdown文件，也可以是个人博客，遇到问题解决了就顺手记一笔。排查过的问题、解决问题的思路，过两个月再看仍然很有价值。我自己的经验是，踩坑笔记里记录的问题，有相当高的比例会在后续项目中再次碰到。积累得多了，慢慢就会形成自己的排错体系。

从项目命名“weixin152未知小程序”可以看出，这也许是一个还在探索阶段的工程，但技术选型已经非常清晰。小程序加SSM的组合，在校园类、工具类和管理类系统中有着广泛的应用场景，掌握这套体系的完整开发流程，收获的不仅是一个能跑起来的项目，更是一套在不断实践中形成的解决问题的方法论。我个人的体会是，跟着文档教程能写通功能，但真正把项目做到让自己满意的程度，一定要靠自己多调试多折腾。写代码的过程，本质上就是一个不断发现问题、定位问题、解决问题的过程，这个能力是在一次次死磕中练出来的。希望这篇文章能帮你在这条路上少走几个弯路，把精力真正花在设计和实现那些有意思的功能上。