做个人日程安排的微信小程序用的是SSMSpring、SpringMVC、MyBatis这套后端框架说白了就是一个典型的小程序做前端、Java做后端的课程设计或毕业设计项目。我最近完整地拆解实现过一遍从需求分析到数据库设计从登录鉴权到日程提醒再到最后部署到服务器完成真机调试中间踩了不少没想到的坑也攒了一套可以直接放着用的实现路径。这篇文章把整个项目从零到交付的过程摊开来讲包括每一层的代码怎么写、接口怎么对、真机调试会卡在哪适合正在做同类课题、或者想通过一个完整项目把前后端串联起来的同学参考。先说一个现实判断这类课题在计算机专业里确实很常见但正因为常见很多人的实现都停在能跑就行的层面。真正让答辩和评测能往上走一档的是对整体架构、数据表设计、登录态、提醒机制这些细节有清楚的认识。所以我下面不只是贴代码更多是讲当时怎么做选择以及每个选择背后的原因。1. 项目概述与整体设计思路1.1 核心需求解析个人日程安排这个选题表面上就是记录、查看、提醒三件事但拆细了之后需求并不少。我把一套比较完整的个人日程需求梳理成下面几类用户管理注册、登录、个人信息维护这是所有业务的前提。日程管理新增日程、编辑内容、删除日程、标记完成状态属于最基础的CRUD。分类管理日程要有工作、学习、生活、运动这类分类帮助用户按场景筛选。日程查询按照日期维度查看当天或某一周的日程是日历类应用的核心体验。提醒功能日程时间快到的时候给用户发提醒这是日程工具区别于普通便签的关键。很多人做这个课题时只实现了增删改查提醒功能直接砍掉理由是订阅消息太麻烦。但说实话提醒恰恰是这个项目最能体现完整性的地方。在毕设答辩或者课程设计评审里有没有提醒机制体现的是你对日程安排这个问题有没有真正理解。所以我建议无论如何都要保留提醒退一步也可以做成服务端定时判断在小程序里生成站内通知不需要调用微信订阅接口。1.2 技术选型背后的原因为什么是微信小程序而不是纯网页、不是App原因很直白小程序无需安装微信内直接打开对个人开发者友好前端开发门槛也比原生App低。而且不管是课程设计还是毕设小程序是目前最常见的载体参考资料多、演示方便评委老师也熟悉不容易出幺蛾子。为什么后端选SSM而不是Spring Boot这个问题几乎每个做毕设的人都会被问到。SSM是Spring、SpringMVC、MyBatis三个框架的组合曾是Java Web开发的主流方案现在虽然Spring Boot更普遍但很多学校的教学大纲、毕设验收标准仍然默认使用SSM仍然是一个正规、完整的Java后端技术栈。而且SSM的配置过程更透明启动时能看到大量的XML配置和Bean装配反而能逼你理解Spring的容器机制、SpringMVC的前端控制器、MyBatis的映射原理。搞懂SSM之后再去看Spring Boot基本就是原来这些自动配置帮我做了这么多事。前端小程序我建议用原生开发而不要一开始就上uni-app。单页面应用、简单页面跳转、组件间传值原生框架完全够用。uni-app虽然可以一套代码多端发布但多了一层编译抽象遇到问题时排查链路更长。这个项目体量很小原生开发反而干净利落。1.3 这个项目适合谁如果你是这几类人这个项目会很对口正在做XX微信小程序的设计与实现这类毕业设计的在校生目标是一套能通过、能演示、能讲清楚的完整系统。刚学完JavaWeb但没做过完整项目的后端初学者需要一个练手项目来把SSM和前端串起来。想快速了解微信小程序登录、订阅消息、请求封装等常见玩法的前端开发者。如果你是去找工作、想用这个项目去打动面试官那就要把关注点从功能实现往架构思考上移比如登录态的保存方式、并发场景下的数据库设计、订单或消息的重试机制。这些我会在后面适当地提到。2. 架构设计与数据库建模2.1 前后端分离的分层架构这个项目采用的是典型的前后端分离结构但不是全分离因为小程序本身只是微信里的一个前端容器后端以RESTful API的方式提供数据服务。整个链路是这样的小程序页面WXMLWXSSJS发起请求到后端接口后端接口按照 Controller、Service、Mapper 三层往下走最后落到 MySQL 数据库再把数据以 JSON 格式返回给小程序前端。Controller层负责接收 HTTP 请求、参数校验、调用 Service、返回统一结果。Service层负责业务逻辑比如新增日程需要校验用户是否存在、日期格式是否正确、是否需要创建分类。Mapper层通过 MyBatis 操作数据库每个方法对应一条 SQL。没有硬堆微服务、Redis、MQ这些技术不是说它们不重要而是这个项目体量下引入这些只会增加交付风险。日程管理就是一个单用户多数据的业务SSMMySQL已经能承担全部数据量和并发量。如果答辩时被问到如果用户量大了怎么办你可以说出分表分库、加缓存这些方向但没必要在代码里真的铺开。2.2 数据库表设计三个核心表数据库是整个项目地基表设计直接决定后端的SQL写得顺不顺。我设计了三张核心表用户表、日程表、分类表再加一张可选的提醒订阅表。用户表user主要字段id主键自增openid微信用户的唯一标识长度64加唯一索引nickname、avatar_url展示信息phone手机号可以为空create_time注册时间日程表schedule主要字段id主键自增user_id关联用户表title日程标题content详细内容category_id关联分类表schedule_date日程日期DATE类型start_time开始时间DATETIME或TIMEend_time结束时间priority优先级用0/1/2表示低中高is_completed是否完成tinyint默认0location地点可空remind_time提醒时间create_time、update_time记录创建和更新时间分类表category设计成用户级分类而不是全局分类因为每个人的分类习惯不同。字段包括id、user_id、name、color。其中日程表里比较关键的两个索引一个是(user_id, schedule_date)联合索引用于按用户和日期查日程另一个是remind_time索引用于定时任务扫描需要提醒的日程不加这个索引的话数据量大了会出现慢查询。设计数据库时有个经常被忽略的点时间字段用DATETIME还是用BIGINT时间戳。我当时用的DATETIME理由是在MySQL里可以直接用日期函数做范围查询先得清晰兼容性好但如果你计划做多时区或者跨服务器部署BIGINT时间戳会更安全避免时区转换带来的人的认知偏差。两种方式没有绝对优劣但要保持统一不要在同一个系统里混用。2.3 接口设计与统一返回协议后端给小程序提供的接口要七到八个就够POST /api/user/login 登录GET /api/user/profile 获取用户信息GET /api/schedule/list 查询日程传入日期或日期范围POST /api/schedule/add 新增日程POST /api/schedule/update 修改日程POST /api/schedule/delete 删除日程GET /api/category/list 获取分类列表POST /api/remind/list 提醒相关也可以直接复合进日程中接口返回统一用一个 Result 对象包裹格式是{ code: 0, message: success, data: {} }code为0表示成功非0表示各种业务错误比如10001表示未登录10002表示参数错误。这样小程序端就可以封装一个统一的请求函数先判断code再决定是进入业务逻辑还是弹出错误提示避免每个页面各自重复处理异常逻辑。关于接口命名不建议直接用动词拼接到处都是比如/addSchedule、/deleteScheduleById这样。用REST风格加上语义化路径更清晰新增就是POST /api/schedule删除就是DELETE /api/schedule/{id}。实际开发时我用的是偏REST的表达答辩讲起来也顺畅。3. 核心功能实现登录、日程、日历、提醒3.1 微信登录与手机号获取微信小程序登录的完整流程是很多第一次做项目的人最容易绕晕的地方。标准的登录链路是这样的第一步小程序端调用wx.login()拿到一个临时凭证 code这个 code 有效期只有五分钟而且只能用一次。第二步小程序把这个 code 通过后端接口传给服务端服务端拿着 code、小程序appid、小程序secret 去请求微信的接口jscode2session换取 openid 和 session_key。第三步后端把 openid 存进数据库如果这是第一次登录就自动注册然后生成一个自定义登录态 token 返回给小程序token 通常是 UUID 或者 JWT。小程序把 token 存到本地 Storage之后的每次请求都把这个 token 放在请求头里后端通过 token 识别用户身份。这里我要强调一点不要在小程序前端直接拿 code 换 openid因为 secret 是服务端保管的核心密钥放进小程序代码里等于公开了。所有涉及 secret 的操作必须放在后端。获取手机号是另一个容易翻车的地方。微信目前在手机号能力上有比较大的变化使用getPhoneNumber之后拿到的不是一个明文手机号而是需要一个动态令牌(code)再由服务端调用微信的getuserphonenumber接口换取真实手机号。而且这个能力要求小程序必须是通过企业认证的主体个人主体无法直接调用。如果你做的是个人主体的毕设项目在开发文档中写明手机号获取依赖企业认证演示时采用输入手机号短信验证码的替代方案这个问题在答辩时是可以正常解释的。还有一个细节登录态 token 不能无限期有效。我项目里给 token 设置了七天过期时间每次请求时校验通过就滑动续期。日程工具是高频应用用户大概率长期登录但演示时如果长时间不操作再打开确需要做好重新登录的跳转处理。3.2 日程增删改查与状态管理日程列表页是主界面展示逻辑按日期分组默认显示今天的日程顶部可以切换日期。新增日程页面会收集标题、内容、日期、开始时间、结束时间、优先级、分类、提醒时间这几项。新增时后端要做几件事参数非空校验、日期格式解析、确认用户存在、可选地生成一条提醒记录。我用的代码结构是 Controller 里只做参数接收和结果返回Service 里判断业务逻辑事务交给 Spring 的Transactional管理。比如新增日程时同时要更新统计字段或者插入提醒记录任何一个失败都应该整体回滚不能出现日程创建成功但提醒没插入的状态。日程列表加载后有一个很常见的前端问题小程序里直接修改数组某个元素不能触发视图刷新。比如你要切换一个日程的完成状态如果直接写this.data.scheduleList[index].is_completed 1; this.setData({ scheduleList: this.data.scheduleList });在某些情况下视图不会更新因为setData对同一引用对象的深层次修改感知不到。正确做法是复制一份数组再修改或者用this.setData({ [scheduleList[ index ].is_completed]: 1 })这种精确路径写法。这个坑看起来小但真机上一旦遇到会让人排查半天。日程列表的筛选除了按日期还要支持按分类、按状态待办/已完成过滤。查询接口我用了 MyBatis 的动态SQL参数非空才拼进条件避免返回多余数据。3.3 日历视图与日期联动日历视图是这个项目的门面也是很多同学的难点。如果你不想自己造轮子可以直接用 Vant Weapp 的 Calendar 组件或者用小程序原生组件库里的日期选择器做降级版本。我当时为了练手选择自己实现一个简单的月历视图。月历的核心算法并不复杂获取当前月份第一天是星期几再算出这个月有几天然后把日期按照周一或周日开头排成网格。具体用 JavaScript 的Date对象就能算function getMonthData(year, month) { const firstDay new Date(year, month - 1, 1); const startWeek firstDay.getDay(); // 0为周日 const daysInMonth new Date(year, month, 0).getDate(); const cells []; // 前方补空白 for (let i 0; i startWeek; i) { cells.push(null); } // 填充日期 for (let d 1; d daysInMonth; d) { cells.push(d); } return cells; }月历上每个日期格子要显示两种状态今天、已选中的日期。同时要把有日程的日期标记出来做法是后端返回这个月所有的日期列表前端用一个集合存起来渲染时判断该日期是否在集合中。日历和下方日程列表的联动核心是点击某个日期更新选中状态重新请求该日期下的日程列表。这里要注意请求的防抖防止用户快速点击多个日期导致旧请求覆盖新请求。我做法是在请求函数里用一个requestSeq递增序号回调里只接受最新一次请求的结果视频里看着很流畅不会闪跳。3.4 订阅消息提醒的实现提醒是这个项目里最有系统感的地方但微信小程序的提醒实现有一个绕不开的限制小程序不能像App后台那样随便推进推送必须依赖订阅消息而普通订阅消息是一次性的用户授权一次开发者只能发送一条消息。多量次的提醒需要用户每次都重新授权。实现步骤如下在小程序公众平台申请订阅消息模板拿到模板ID。用户在添加日程的时候前端调用wx.requestSubscribeMessage请求一次性订阅授权。用户点击同意后前端把这个授权状态和模板ID保存同时后端保存一条提醒订阅记录包含用户openid、模板ID、日程ID。后端写一个定时任务SpringScheduled每分钟扫描一次schedule表找出remind_time在接下来几分钟内、状态待办、而且没有被提醒过的日程推送订阅消息。推送成功后把该日程的has_notified字段置为1避免重复推送。定时任务的启停要控制好否则开发环境会一直空转。我在applicationContext.xml里用task:annotation-driven开启定时任务并加了一个开关配置部署到服务器时打开本地调试时关闭。如果不需要走微信订阅消息的复杂度也可以做简化版小程序端检测到日程快到时间主动从后端拉取临近提醒列表在页面上横幅展示。这种站内提醒虽然打开小程序才看得到但胜在不依赖企业认证和模板审核对个人开发者非常友好。我推荐的做法是主体使用订阅消息同时保留站内提醒作为兜底演示时两条路都说得通。4. SSM后端关键配置与代码示例4.1 项目依赖与基础配置SSM项目的骨架我习惯用Maven管理pom.xml里核心依赖就那么几个spring-context、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java加上Servlet API和Jackson序列化库。web.xml里必须配置SpringMVC的DispatcherServlet和Spring的ContextLoaderListener。有一个很多人容易忽略的点要在web.xml里显式配置字符编码过滤器把request和response的编码统一成UTF-8否则接口返回中文会乱码。这个过滤器要放在所有过滤器的最前面filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter数据库连接配置可以放在jdbc.properties里用context:property-placeholder加载数据源我用的是阿里的Druid主要看中它的监控和连接池Web项目里丢掉它只怪不够熟人。当然用C3P0或者HikariCP也行核心是思路不是某个具体库。4.2 Controller与Service层代码模式Controller层的代码写起来很模板化但越是模板化越要写规范。每个接口都做四件事接收参数、校验参数、调用Service、返回统一Result。以新增日程为例RestController RequestMapping(/api/schedule) public class ScheduleController { Resource private ScheduleService scheduleService; PostMapping(/add) public Result add(RequestBody ScheduleDTO dto, RequestHeader(token) String token) { // 1. 从 token 解析出用户ID Integer userId userService.getUserIdByToken(token); if (userId null) { return Result.error(10001, 未登录或登录已过期); } // 2. 参数校验 if (StringUtils.isBlank(dto.getTitle())) { return Result.error(10002, 日程标题不能为空); } // 3. 调用业务逻辑 scheduleService.addSchedule(userId, dto); return Result.success(); } }Service层要加上Transactional因为实际业务往往不只操作一张表。比如新增日程时还要更新分类计数或者给日程生成提醒任务只要其中一步失败整个操作就要回滚。我写Service时养成了一个习惯只做业务判断和数据组装不把SQL查询的手法暴露给Controller这样如果后面从MyBatis换成JPAController一行都不用改。4.3 MyBatis Mapper与动态SQLMyBatis的Mapper层最爽的地方是动态SQL。日程查询往往要根据多个可选条件拼SQL比如筛选今天的日程还需要按分类过滤用if标签拼起来就特别清爽select idselectByCondition resultMapscheduleResultMap SELECT * FROM schedule WHERE user_id #{userId} if testdate ! null AND schedule_date #{date} /if if testcategoryId ! null AND category_id #{categoryId} /if if testisCompleted ! null AND is_completed #{isCompleted} /if ORDER BY start_time ASC /select注意if条件里不能用date ! null这种写法去判断字符串类型要用StringUtils.isNotBlank引导。还有#{}和${}的区别#{}是预编译参数占位能防SQL注入${}是直接拼接尽量少用。resultMap可以把数据库字段和Java实体属性对应起来也可以开启mapUnderscoreToCamelCase自动把下划线字段映射成驼峰属性。我推荐开启自动驼峰映射省去一大堆resultMap配置只要表和实体的命名规范这个配置一行搞定。4.4 跨域与字符编码配置小程序开发和网页有个不同点小程序的wx.request不存在传统Web里CORS跨域问题但后端接口部署后小程序端请求HTTPS域名时需要在公众平台配置request合法域名。开发调试阶段有个取巧的办法在微信开发者工具右上角详情-本地设置里勾选不校验合法域名就可以直接请求本地局域网IP但真机预览时必须走合法域名。如果你的后端还有Web管理端页面跨域问题还是躲不开。我加了一个全局CORS配置让后端支持跨域请求Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); // 允许携带token等认证信息 config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这个配置加上之后网页端和小程序端都能畅通请求接口。但要注意allowCredentials(true)时allowedOrigins不能写*得用addAllowedOriginPattern(*)这是很多人在网上复现CORS配置时容易踩的坑。5. 真机调试与部署发布的排坑实录5.1 小程序开发者工具的常见问题微信开发者工具是日常开发的主战场但它的模拟器和真机行为不完全一致。我遇到比较典型的几个问题第一个是顶部导航栏高度。模拟器里状态栏高度可能是44px但真机上不同机型适配不同尤其全面屏和刘海屏。我做自定义导航栏时用wx.getSystemInfoSync()里的statusBarHeight和menuButtonBoundingClientRect动态计算导航栏高度不要硬编码。第二个是请求域名校验。本地开发接口地址是http://localhost:8080或者局域网IP开发者工具里可以勾选跳过校验但真机上会直接报request:fail url not in domain list。解决方法是后端在本地起服务用内网穿透或者把开发机IP加进合法域名限测试账号更正式的方式是生产环境走HTTPS域名。第三个是模拟器里请求能够正确发出但真机上一片空白大概率是证书问题。小程序要求所有请求域名必须HTTPS且证书有效用自签名证书会直接失败。我本地测试时用的是http加跳过校验部署到生产环境再换成HTTPS。域名备案和SSL证书申请这部分要提前做因为审核周期通常比想象中长。5.2 时间时区与数据格式化的坑时间问题是这个项目里最容易出现看起来对、实际不对的地方。我遇到过一个特别典型的在本地写一条日程开始时间是14:00保存到MySQL后查询出来变成了18:00一看就是服务器时区设置导致的偏移。MySQL的serverTimezone、Java程序的默认时区、以及前端传过来的时间字符串三方必须统一。我当时统一用东八区并在数据库连接URL里显式加上jdbc:mysql://localhost:3306/schedule_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8日程查询按日期过滤时前端传的是2025-07-01这种字符串后端直接用字符串比较即可不需要转成Date再比否则容易在边界时间上出错。但如果是凌晨附近的提醒任务就要非常小心2025-07-01 00:05和2025-06-30 23:59很容易因为时区问题被错误归类到前一天或后一天。我建议在提醒模块里全部用时间戳比较避免踩时区雷。另外前端格式化日期时不要用new Date(2025-07-01)这种写法有些版本的JavaScript引擎会把它解析成UTC时间然后东八区会偏一天。安全做法是拆分成年月日再实例化new Date(2025, 6, 1)注意月份从0开始。这种细节做演示时不会暴露但在真机时间段选择器联动时就会出现日期差一天的诡异现象。5.3 订阅消息授权链路的问题订阅消息的授权弹窗只能在用户主动触发时弹出不能在页面onLoad里直接调用。这是很多新手第一道坎想在日程列表一进来就申请授权结果弹窗不出现上报也不弹。正确做法是把授权请求绑定在用户点击添加日程或设置提醒这个按钮事件上。第二个坑是用户拒绝授权后二次调用wx.requestSubscribeMessage将不会再次弹出弹窗而是直接返回拒绝状态。我的处理是在用户拒绝后给一个引导提示说明开启提醒不会读取隐私信息可以点击重新开启点击后再调用一次授权。如果还是拒绝就降级为站内提醒不影响日程保存。第三个坑和模板有关申请开通订阅消息后模板不是立刻生效后台审核通过后才能请求。而且模板内容不能随意改动字段名必须严格按照模板定义。我在测试阶段申请了一个不合适的模板后面把所有推送代码写好了却发现模板不可用又得改文案。建议先确定提醒内容再申请匹配的模板。5.4 服务器部署与HTTPS配置小程序生产环境的请求必须走HTTPS所以服务器上要装Nginx加上SSL证书。我部署时的整体结构是域名–Nginx–Tomcat–MySQLNginx监听443端口把/api/开头的请求反向代理到本地的8080端口Tomcat。Nginx配置里需要注意一个坑小程序要求返回的响应必须在规定时间内完成如果接口逻辑较重、数据库慢查询响应超时会导致小程序端报错。我给Nginx配了合理的超时时间同时后端接口的SQL尽量都命中索引避免出现全表扫描。数据库部署方面我建议生产环境的MySQL单独建一个用户不要用root权限只给业务库的最小权限。这虽然不是必须但能避免很多安全风险。毕竟项目源码会贴到文档里连接密码也写在配置文件里如果你泄露的是root密码并且服务器还被其他人访问那问题就大了。服务器上部署SSM项目的打包方式是打WAR包放到Tomcat的webapps目录。注意Java版本要和本地保持一致我曾经在本地用JDK17编译到服务器上只装了JDK8项目直接启动不了。当时排查了不少时间所以现在写文档时都会把环境版本明确列成一张表。6. 从项目到毕设文档演示与答辩经验6.1 文档结构怎么组织做完了项目和源码下一步就是写文档。这个文档不是代码的堆砌而是要能讲清楚你解决了什么问题、怎么解决的、为什么这样解决。我的文档结构大致是第一章 绪论项目背景、研究意义、国内外现状。第二章 需求分析功能性需求、非功能性需求、用例图。第三章 系统设计总体架构、技术选型、数据库设计、接口设计。第四章 系统实现核心功能的实现截图和关键代码说明。第五章 系统测试功能测试用例、接口测试结果。第六章 总结完成内容、不足与展望。写需求分析时一定要画用例图但记得不要用Mermaid这种工具生成推荐用PowerPoint或者ProcessOn画清楚。答辩现场老师第一眼看的是你的用例图是否合理第二眼看数据库表是否完整第三眼看核心功能能不能跑起来最后才看界面好不好看。文档里不要贴大段源码。每段代码贴两三行核心逻辑然后用文字说明这段代码解决了什么问题比贴百行代码更能得分。我在写文档时把每张表都做了字段说明表格字段含义、类型、约束写得清清楚楚这比贴SQL更有说服力。6.2 演示脚本与答辩要点演示环节往往是决定印象分的关键。很多同学现场演示从登录开始一步步操作节奏拖沓讲到一半时间不够。我建议提前准备一套演示脚本按登录→建立日程→修改日程→完成日程→查看提醒→查看统计的路线走每个环节控制在30秒到1分钟。录演示视频的时候有一个小技巧提前把数据和状态准备好不要现场去新增太多无用数据保证演示节奏干净。如果你要展示提醒功能把提醒时间设置为当前时间的后两三分钟现场等待时可以先讲代码逻辑让时间自然过去然后切到提醒展示。这样演示安排就显得很紧凑。答辩中容易被问到的几个问题建议提前准备答案为什么用SSM而不用Spring Boot如果日程数据量很大怎么优化分页查询用户登录态是怎么保持的token过期怎么处理订阅消息为什么是一次性的用户没授权怎么办你这个系统的部署架构是怎样的HTTPS证书怎么配置的这些问题的回答思路我都在前面的章节里提到了核心是理解技术选型的原因和能说出备选方案不要死记硬背用自己做过的事来回答就稳。最后再分享一个我自己的实操习惯项目做完后一定压缩一个干净版的源码包把数据库初始化的SQL、部署文档、启动说明放在最前面并且写一个简洁的README。不要小看这个习惯很多时候过了几个月再打开项目能让自己少走弯路。把这个项目交付出去、或者放到简历上作为作品时一份规范的README就是给代码的第一张名片。开发过程里那种能跑就行的状态和交付时那份看得懂、拉得起来、复现得了的工程状态差距就在这里也往往就是评分和面试评价的分水岭。