每年到了选课设题目的季节总有一批学弟学妹跑过来问我同一个问题做什么题目能顺利过关还能在答辩的时候讲出点东西如果你现在正翻老师给的题目库大概率看到的是图书管理系统、超市收银系统、学生宿舍管理系统这类老面孔。不是不能做是答辩时真的很难讲出花来。相比之下java springboot 微信小程序方向的秦兵马俑博物馆预约系统反而是个被很多人低估的选题。它表面上是把预约两个字做成页面实际上把用户登录、场次排期、库存扣减、订单状态流转、数据统计这些生产环境里的核心问题全包了进去。而且小程序这个载体本身就很贴博物馆预约的真实使用场景。这篇文章我从开发者的角度把整个项目的需求拆解、技术选型、数据库设计、后端接口逻辑、小程序端对接以及配套的源码、文档、运行视频、讲解视频该怎么配合答辩完整过一遍。适合三类人看一是准备拿这类预约系统做课设或毕设的同学二是想练手SpringBoot加小程序全栈的初学者三是纯粹想了解预约类系统核心逻辑的开发者。我不打算只教你把它跑起来我尽量把每一步为什么这么做也讲清楚。1. 这个项目不是又一个CRUD预约业务的真实痛点拆解1.1 为什么拿兵马俑博物馆做业务场景先说说选题这件事。同样是做预约你做一个会议室预约系统和做一个博物馆预约系统在答辩老师眼里的分量是完全不同的。会议室预约的痛点无非是时间段冲突而博物馆预约有更完整的业务链条游客要先看公告知道开馆时间然后选日期、选场次、选票种提交信息后系统要锁定余票到馆之后还要核销没去的人要么取消、要么过期。这一圈走下来CRUD只是表象里面的库存扣减、状态机、异常处理才是真正的技术含量。兵马俑这个主题还有两个隐性优势。第一它是真实存在的热门景点预约制不是我们虚构出来的需求答辩老师一听就知道你在做一个能用、有人用的东西而不是为了交作业硬凑的玩具系统。第二主题辨识度高同样是排排坐演示系统你说我做的兵马俑预约系统和我做的图书管理系统给人的第一印象完全是两个层级。1.2 把一次预约行为拆成一条完整的业务闭环做这种项目第一步不是建表而是在纸上把业务闭环画出来。我习惯把它拆成一条用户动线和一个管理员动线。用户动线是这样的一条链路打开小程序 → 查看公告和开放时间 → 选择参观日期 → 选择场次上午/下午 → 选择票种成人票/学生票/儿童票 → 填写游客信息姓名、证件号、手机号 → 提交预约 → 系统锁定余票 → 生成预约凭证 → 到馆核销。管理员动线则是维护开放场次 → 设定每日最大承载量 → 查看各场次预约情况 → 处理特殊情况比如某个场次临时关闭 → 查看数据统计每日预约人数、各票种占比、时段分布。这两个动线交汇的地方就是整个系统的心脏场次余票。游客每下一单场次已预约数加一每取消一单减一当天参观结束未核销的订单要么标记过期要么回补库存。所有的页面跳转、接口调用、状态判断都是在围绕这一小段逻辑转。这里有一个关键点要提前想清楚预约不等于支付。国内很多博物馆的预约是免费的预约成功即锁定名额不需要接微信支付。如果你的项目也打算不做支付那订单状态机就得单独设计好。我在设计中把订单状态拆成以下四种表格列出来后面写代码和文档都能直接用状态编码含义触发方式后续可流转状态0待使用已预约用户提交预约成功已核销、已取消、已过期1已核销已完成到馆后管理员/闸机核销无2已取消用户主动取消库存回补无3已过期定时任务扫描过期未参观无非要做支付的话再加个待支付状态订单创建后先锁定库存但不算预约成功支付成功再转成待使用。但课设阶段不建议加支付因为微信商户号申请流程对个人开发者并不友好很容易卡在资质环节纯属给自己找麻烦。2. 技术栈为什么是SpringBoot 微信小程序 MySQL2.1 这套组合在课程设计里的真实优势每年都有同学在选技术栈的时候纠结半天其实对课设来说选型的核心标准就三条资料多不多、跑起来顺不顺、答辩时讲不讲得清。SpringBoot在Java方向的统治地位不用多说社区教程多到看不完遇到问题搜一下基本都有答案MySQL是面试和课程里的常客人人都认识它微信小程序的好处在于一套代码同时覆盖安卓和苹果用户用户点开就能用不需要下载App这非常契合博物馆扫码即约的真实使用习惯。可能有人会问为什么不做成App我在文档里是这样写的App需要两套客户端代码或者引入跨端框架对个人开发者来说开发和测试成本都会明显上升而小程序的审核和发布流程相对轻量用户侧也不需要安装。更重要的是从用户心理来看进一个博物馆还要专门下载App使用门槛太高了小程序才是预约入口的最优解。这个理由在答辩时拿出来讲老师是很认可的。2.2 版本选择的一次到位推荐版本这个问题我见过太多人栽跟头了。有的同学一上来就用了最新的SpringBoot 3.x然后发现JDK版本不对、兼容性报错还没开始写业务就先跟环境和依赖搏斗了两天。课设的底线是什么是稳定跑完整个流程。没必要追新。下面是经过大量项目验证的推荐组合按这个来能少走很多弯路组件推荐版本/方案理由JDK8 或 11与SpringBoot 2.x兼容最好云服务器部署方便SpringBoot2.7.x资料最全支持JDK8避免3.x的升级坑ORMMyBatis-Plus比原生MyBatis少写大量样板代码自带分页插件数据库MySQL 5.7 或 8.0通用、免费、面试常考小程序端原生小程序开发学习成本低调试方便不要一上来就上uniapp构建工具Maven资料多国内镜像配置成熟我特别想强调一下MyBatis-Plus。课设项目里单表操作非常多比如用户表、订单表的增删改查用MyBatis-Plus直接继承BaseMapper就能拿到绝大部分方法省下的时间你可以专心写预约核心逻辑而不是浪费在拼SQL和配XML上面。这在答辩时也是一个加分点——说明你有工具选型的判断力。2.3 环境准备阶段最容易忽略的三个细节这三个坑我在帮别人调环境时反复遇到提前说出来省得你踩。第一Maven一定要配阿里云镜像仓库。不配的话国内网络拉依赖有时候慢到让人怀疑人生尤其第一次构建要下载一大堆包。在settings.xml的mirrors节点加一个阿里云镜像就行具体配置网上到处都有这里不展开。第二小程序开发者工具本地调试时一定要勾选不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书。不勾选的话后端跑在http://localhost:8080或者局域网IP上小程序直接报url not in domain list。这个选项在开发者工具的详情-本地设置里属于调试阶段的官方后门上线时记得关掉。第三MySQL统一使用utf8mb4字符集。utf8在MySQL里实际上不是完整的UTF-8存不了emoji和一些生僻字。游客信息如果包含特殊字符插入的时候会直接报错排查起来很费劲。建库时一句CREATE DATABASE xxx DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;就能解决。3. 数据库设计六张核心表怎么定字段数据库设计是答辩老师重点翻看的部分也是项目能不能写顺的关键。别急着写代码先把表结构设计出来后面后端、前端全部跟着表走。我给你拆成三组来看。3.1 用户表与管理员表登录体系的根基用户表不用太复杂核心字段如下字段名类型说明idbigint主键自增openidvarchar(64)微信用户唯一标识加唯一索引nicknamevarchar(50)微信昵称avatarvarchar(255)微信头像URLphonevarchar(20)手动填写或微信手机号授权create_timedatetime注册时间statustinyint状态1正常 0禁用这里的关键是openid字段。它是微信侧给用户的唯一编号同一个用户在同一个小程序下永远是同一个openid所以直接用它做业务上的用户主键和登录凭证。密码不存在。用户是通过微信授权登录的不设计密码字段这既是真实场景也省掉了一大堆密码加密、找回密码的麻烦事。管理员表是另一张表因为管理员走的是账号密码登录不走微信授权字段名类型说明idbigint主键usernamevarchar(50)登录用户名唯一索引passwordvarchar(255)BCrypt加密后的密码rolevarchar(20)角色标识如 ADMINpassword字段必须加密存储用BCrypt或者MD5加盐都行。哪怕答辩老师不问你你也应该在文档里主动写出来这体现的是基本的安全意识。3.2 场次表与票种表预约系统的关键设计预约系统的核心不是订单表而是场次表。博物馆一天的接待能力是按场次切的上午多少张、下午多少张这是真实存在的约束。场次表设计如下字段名类型说明idbigint主键visit_datedate参观日期time_slottinyint场次0上午 1下午capacityint最大承载量总票数bookedint已预约数statustinyint状态1开放 0关闭注意到我在这里做了冗余字段booked。余票数理论上可以用capacity - 已预约订单数实时算出来为什么非要存一个字段两个原因一是查询快列表页一次性展示未来7天所有场次的余票实时GROUP BY订单表的开销更大SQL也复杂二是扣减方便后面讲防超卖时会看到UPDATE...SET booked booked 1这种原子操作比先查再算再更新要安全得多。票种表很简单就是博物馆里那几种票成人票、学生票、儿童票部分场馆还分淡旺季票价但课设阶段没必要做那么细。字段名类型说明idbigint主键namevarchar(30)票种名称pricedecimal(10,2)价格免费票传0descriptionvarchar(255)适用人群说明3.3 预约订单表整个系统的状态中枢订单表承载的信息最多它是用户、场次、票种三张表的关系汇聚点字段名类型说明idbigint主键order_novarchar(32)业务订单号唯一索引user_idbigint用户ID逻辑外键session_idbigint场次ID逻辑外键ticket_type_idbigint票种ID逻辑外键visitor_namevarchar(30)参观人姓名visitor_id_cardvarchar(18)参观人证件号visitor_phonevarchar(20)参观人手机号ticket_countint购票数量statustinyint状态0待使用 1已核销 2已取消 3已过期create_timedatetime下单时间verify_timedatetime核销时间可空关于索引用户查看我的预约时基本都按user_id查所以user_id加普通索引列表页和定时任务会按session_id status查可以建一个复合索引(session_id, status)。还有一件事值得多说一句为什么不做单独的表存放每个游客的身份信息现实中的预约系统确实允许一单最多预约5个人然后每人填身份证。但课设项目如果这么做订单表和游客表就变成一对多复杂度直接上升一个档次。我处理的折中方案是一个订单只对应一个主参观人一个人预约一张票但允许在订单里加ticket_count字段一次预约多张同类票。这样的设计在课设粒度上完全讲得通也不会把自己绕晕——答辩的时候你可以把这个设计让步主动讲出来说明你考虑过更复杂的模型这是加分项而不是减分项。4. 后端接口编写从登录鉴权到库存扣减的完整思路后端是整个项目里最容易写乱的部分。混乱的根源通常不是业务复杂而是接口职责不清、事务边界混乱。这一章我按请求顺序把核心接口逐个拆开讲。4.1 微信登录的三步流程与自定义登录态微信登录是每一个请求的前置条件。整个流程说起来只有三步小程序wx.login()拿code后端拿code换openid后端再生成自定义登录态返回给小程序。但里面有两个知识点会在答辩时被重点追问。第一个知识点code换openid为什么必须由后端来做因为调微信的code2Session接口需要AppSecret这个密钥一旦放进小程序代码里就等于公开了——任何人反编译你的小程序包都能拿到它然后盗刷你的接口配额甚至冒充用户。所以正确姿势是小程序只把code传给后端后端拿着code appid appsecret去请求微信服务器。第二个知识点拿到openid后不能每次请求都重新走一遍code2Session。微信的code是一次性的而且wx.login的调用频率也是有限制的。更合理的做法是后端拿到openid之后查用户表没有则自动注册一条用户记录然后生成一个自己的tokenUUID即可返回给小程序。小程序把token存起来之后每次请求在请求头里带上Authorization: Bearer token后端写一个拦截器统一校验。这样既实现了用户身份保持也不用每次都去骚扰微信服务器。核心代码示意如下这就是一个controller service的完整链路RestController RequestMapping(/api/auth) public class AuthController { Autowired private AuthService authService; PostMapping(/login) public Result login(RequestBody LoginRequest request) { // 1. 小程序传过来的code String code request.getCode(); // 2. 后端调用微信接口换取openid和session_key WxSession wxSession authService.code2Session(code); // 3. 查用户表不存在则注册 User user authService.findOrCreateUser(wxSession.getOpenid()); // 4. 生成自定义token String token authService.generateToken(user.getId()); return Result.success(token); } }登录成功之后拦截器里统一从请求头取token、查Redis或者内存里的token映射关系。课设阶段用Redis存token是加分项不想引Redis也可以用一个简单的内存Map但要注意重启丢失和并发访问的线程安全。我建议按Redis来做这东西写了就是简历上的一句话成本也不高。4.2 场次余票查询接口列表页每秒都被调用上百次用户进入小程序首页第一件事就是查场次。不要小看这个接口它是最频繁被调用的接口也是前端列表页的数据来源。接口设计成一次返回多天的数据而不是一次查一天GetMapping(/api/session/list) public Result list(RequestParam String startDate, RequestParam String endDate) { // 返回startDate到endDate之间每天的场次信息 // 每个场次包含场次id、日期、时段、余票数、状态 ListSessionVO sessions sessionService.listSessions(startDate, endDate); return Result.success(sessions); }SessionVO里有一个remain字段就是capacity - booked的实时计算值。余票数小于某个阈值比如10张时前端会用红色或者紧张标签标记出来——这个细节建议写进文档和演示视频里一眼就能让老师看到你的系统考虑到了用户体验。有一点要特别注意查询接口不要返回capacity和booked的原始字段只返回计算好的remain。这不是藏着掖着而是前端不需要关心库存的内部结构只关心还能约几张。接口暴露的字段越少后续调整内部实现时越自由。4.3 提交预约防超卖、防重复、防恶意占座的完整方案这应该算整个项目答辩时最核心的亮点。场景是这样的假设上午场次只剩最后2张票同时有两个用户提交预约每个都要2张如果代码是先查库存够不够够了再扣减两个请求都可能查到余票还剩2张然后都通过校验——结果超卖了。怎么解决我在项目里用的是一个原子更新配合事务的方案在Service层实现Transactional(rollbackFor Exception.class) public Order createOrder(CreateOrderRequest request) { // 1. 校验场次是否存在且开放 VisitSession session sessionMapper.selectById(request.getSessionId()); if (session null || session.getStatus() ! 1) { throw new BizException(场次不存在或已关闭); } // 2. 原子扣减余票这条UPDATE自带条件解决并发超卖 int rows sessionMapper.deductBooked(request.getSessionId(), request.getTicketCount()); // deductBooked对应的SQL是 // UPDATE visit_session SET booked booked #{count} // WHERE id #{id} AND booked #{count} capacity if (rows 0) { throw new BizException(余票不足); } // 3. 生成订单号并插入订单 Order order buildOrder(request); orderMapper.insert(order); return order; }关键在于第2步的那条UPDATE语句。booked #{count} capacity是数据库在更新时才做的校验它把查询-判断-扣减三个动作合并成了一个原子操作。即使并发请求同时进来数据库的行锁也会让它们排队执行后到的那个请求因为条件不满足更新行数为0直接抛余票不足。这套方案在答辩时非常好讲不用Redis不用分布式锁一个原子的UPDATE语句配合数据库事务就把超卖问题解决了。这是关系和原理都讲得清、能够当场验证的答案对课设来说足够体面。如果老师追问更高并发怎么办你再往Redis预扣库存、分布式锁那个方向说但那是扩展讨论有这个意识就行。除了超卖还要防重复预约。同一个用户同一个场次只能下一单这一条用什么兜底答案是数据库唯一索引。可以在订单表加一个(user_id, session_id)的唯一约束但只能对待使用状态的订单生效所以实际做法是建一个唯一索引字段是业务上的冗余openid visit_date time_slot表里单独存这两个冗余字段用来做约束。这一部分我会在文档里讲清楚因为它是防刷里最实际的壁垒比后端拿if判断靠谱得多——并发情况下两个if判断可能同时通过但唯一索引一定会拦住其中一个。4.4 取消预约与自动过期库存回补的两条路径预约不是下单就结束了。用户可能行程变更也可能单纯忘了去。这两条线都要有逻辑处理。用户主动取消很简单一条UPDATE把订单状态改成已取消另一条UPDATE把场次的booked减回去两个操作放在同一个事务里保证一致性。这里有一个细节取消操作有一个时效窗口比如参观当天凌晨零点之后不允许取消代码里用visit_date和当前时间比较即可。自动过期则是定时任务的活。Spring的Scheduled注解可以直接实现Component public class OrderExpireTask { Scheduled(cron 0 0 2 * * ?) // 每天凌晨2点执行 public void expireOrders() { // 1. 查询参观日期已过、状态仍为待使用的订单 ListOrder expiredOrders orderMapper.selectExpiredOrders(); for (Order order : expiredOrders) { // 2. 订单状态改为已过期 orderMapper.updateStatus(order.getId(), 3); // 3. 回补库存 sessionMapper.releaseBooked(order.getSessionId(), order.getTicketCount()); } } }演示的时候有个小技巧把cron表达式临时调成Scheduled(fixedDelay 60000)每分钟执行一次然后创建一个过期订单等一分钟给老师看效果。比起嘴讲这里有个定时任务这种现场演示的说服力强得多。演示完记得改回正常cron。5. 小程序端页面怎么组织接口怎么对接后端把接口出好了小程序端的工作本质上就是写页面 调接口。但这里面有一些交互和工程细节直接影响演示的流畅度。5.1 页面规划与目录结构小程序原生项目目录结构如下miniprogram/ ├── app.js # 全局逻辑启动时检查登录态 ├── app.json # 页面注册、tabBar配置 ├── app.wxss # 全局样式 ├── utils/ │ └── request.js # 封装wx.request统一带token、处理401 └── pages/ ├── home/ # 首页博物馆公告、快捷预约入口 ├── session/ # 预约页日期、场次、票种、数量、游客信息 ├── order/ # 订单列表按状态分组展示取消按钮 └── mine/ # 个人中心登录信息、我的预约、帮助中心四个页面足够覆盖整个业务闭环。不需要更多。很多同学做小程序喜欢一口气堆十几个页面结果每个页面都是残的反而减分。小而完整比大而残缺强得多。5.2 登录态在小程序端的具体流转方式小程序端的登录逻辑核心在app.js的onLaunch里启动时读本地Storage里的token没有就调用wx.login()拿code然后请求后端/api/auth/login接口换token存进wx.setStorageSync。所有请求通过utils/request.js统一发出核心代码如下const request (url, method, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(token); wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: Bearer token }, success: (res) { // 后端返回的业务码比如401表示登录失效 if (res.data.code 401) { wx.removeStorageSync(token); // 跳转登录或重新调用wx.login return; } resolve(res.data); }, fail: reject }); }); };注意BASE_URL不要写死在小程序代码的每个请求里而是统一放在一个配置文件里。换后端地址时只改一处这个整洁度答辩时老师是看得见的。为什么要统一封装一层因为如果没有这一层你会在每个页面里重复写wx.request的样板代码而且登录失效这种全局异常处理会在每个页面各写一套改起来会疯掉。封装之后页面里只需要调request(/api/session/list, GET, params)就行。5.3 预约下单的交互细节日期、场次、余票、防重复预约页是用户操作最密集的页面交互细节直接影响演示效果。我的做法是分三个区域日期选择、场次选择、信息填写。日期区域一次展示未来7天每天显示两场上午/下午的余票情况余票为0的场次直接置灰不可选。这一点必须做在前端不然用户选了一个没票的场次到提交才报错体验就很差了。场次选择可以用卡片式布局每个卡片显示时段、余票数。余票少于10张时显示仅剩N张的提示颜色转橙色。提交按钮实际上有一个非常重要的细节点击后立即置灰文字变成提交中...同时用一个本地布尔变量拦住重复提交。submitOrder() { if (this.data.submitting) return; this.setData({ submitting: true }); request(/api/order/create, POST, orderData) .then(res { wx.showToast({ title: 预约成功, icon: success }); wx.redirectTo({ url: /pages/order/order }); }) .finally(() { this.setData({ submitting: false }); }); }这个防重复提交的动作一连串作用下来后端有唯一索引兜底前端在交互层拦截双层保险。答辩的时候把这套前端体验层 后端数据层的双层防护讲出来比只说我做了防重复提交要有说服力得多。另外还有一个容易踩的坑微信手机号授权不能静默获取。2023年之后微信收紧了手机号接口的调用方式必须用户主动点击一个获取手机号的按钮组件才能触发授权回调。如果你的系统非要拿用户手机号就必须做一个显眼的授权按钮而不是在onLoad里偷偷调。课设阶段更省事的方案是让用户手动填写手机号前端做一个简单的正则校验即可省去一堆授权流程的麻烦。这个取舍我在文档里也写了理由是降低使用门槛、简化调试链路。6. 交付物才是这个项目的隐藏价值文档和视频怎么配合答辩说实话源码能跑只是及格线。一个课设项目能不能拿高分很大程度取决于你怎么把项目讲出来。源码、文档、运行视频、讲解视频这四个交付物本质上就是一套完整的表达能力训练材料。6.1 项目文档该怎么写才不会被答辩老师挑刺项目文档的标配是需求分析、概要设计、详细设计、数据库设计、系统测试、项目总结这个框架不用改。关键是怎么把每个章节写出内容。需求分析一定要配用例图和业务流程说明数据库设计章节必须给出完整的建表SQL和ER图详细设计章节放核心接口的列表和说明系统测试章节放测试用例表格格式大概是测试编号、用例描述、输入数据、预期结果、实际结果、是否通过。这一章很多同学只写系统测试通过一句话带过其实这是最容易被翻看的部分表格写得越细越显得项目扎实。文档里还有两个禁忌。第一不要出现系统比较简单这个模块不难这种自我贬低的话一句话可能就让老师对你的工作量产生怀疑。第二所有图表要自己画截图要截自己系统的真实页面不要拿网图充数。答辩老师一眼就能看出来你的项目熟悉程度和文档质量绝对是正相关的。6.2 运行视频和讲解视频的制作要点运行视频的核心是完整和有说服力不是炫酷。正确拍摄路径是启动MySQL → 启动SpringBoot后端 → 启动Redis → 打开小程序开发者工具 → 登录 → 预约成功 → 查看数据库订单表记录 → 取消预约 → 再查数据库库存回补。整个过程用两个窗口并行录一个窗口是前端页面另一个窗口是数据库客户端比如Navicat执行SELECT * FROM visit_session实时观察booked字段变化。这段视频的价值在于它能直接证明你的预约逻辑不是假的是真的在改数据库。讲解视频则更考验表达能力。时间控制在20分钟左右顺序按需求背景 → 数据库设计 → 后端核心接口 → 小程序页面 → 演示效果来讲。每讲到一个模块把对应的代码和表结构调出来展示不要只对着PPT念。我拍讲解视频时的原则是把答辩时准备说的每一句话都在视频里说一遍这样到现场答辩时相当于已经提前演练过好几遍了。6.3 答辩时最容易被追问的五个问题把这五个问题提前准备好答辩现场就不慌了。第一个问题为什么用微信小程序而不用App回答要点开发成本低、用户体验好、扫码即用、贴合博物馆预约场景。第二个问题并发情况下怎么防止超卖回答要点把那段原子的UPDATE...WHERE booked count capacity代码调出来现场讲数据库会排队执行。第三个问题如果恶意用户批量注册下单刷票怎么办回答要点小程序天然以openid为唯一身份一个微信号对应一个账户注册门槛极高再加上同一用户同一场次的唯一索引兜底如果还想加强可以引入手机号核验和预约频次限制。第四个问题这个系统能承受多大并发注意不要吹牛。诚实回答课设方案是数据库行锁保证一致性吞吐量有限生产环境可以演进为Redis预扣库存、异步削峰、消息队列等说明你有扩展认知就行。第五个问题为什么字段里要有冗余的booked回答要点查询性能 原子扣减事务和唯一索引保证冗余数据不会不一致。这一个问题回答好了直接就把项目提升一个层次。最后说点我做这类项目的体会把整套源码、文档、视频、讲解视频都过了一遍回到最开始的问题为什么选这个项目我的看法是预约类系统在课设这个粒度上是进可攻退可守的题目。往简单做就是一个普通CRUD能跑就及格往深了做库存扣减、事务边界、防并发、状态机、定时任务每一个点都能单独拿出来讲十分钟。冰山下面的部分才是答辩拉开差距的地方。最后分享一个我自己的实操习惯这个项目最佳开发顺序是先建表再写后端接口最后写小程序页面。建表阶段把所有字段、索引、唯一约束定死后面的代码只是翻译后端接口先用Postman全部调通再写小程序对接这样出问题时能明确划定是后端的问题还是前端的问题不会两边互相甩锅。如果你准备自己做一遍这个项目照着这个顺序来返工率会低很多。
