拓冰网站定制 
简介这份资源是面向高校计算机相关专业毕业设计的完整项目包围绕基于微信小程序的博物馆文创系统展开适合正在准备毕设、需要小程序与Spring Boot全栈实战案例的学生及开发者参考。包内整合了Spring Boot后端源码、配套论文、PPT答辩材料、数据库文档与演示视频覆盖从需求分析、系统设计到功能实现的完整链路。系统前端采用微信小程序后端基于Java与Spring Boot框架数据层使用MySQL核心模块包括文创商品展示与在线购买、文创活动发布、用户间文创交换、展品语音讲解、积分排行榜以及交流论坛能够帮助读者理解文创互动平台的业务逻辑与实现思路。资源包整体约38.59MB以zip格式压缩文件类型涵盖源码、文档、演示视频等便于按模块查阅与二次开发。目前已有76人学习下载可作为毕设选题参考、代码复现与答辩准备的实用素材。1. 从一份「博物馆文创系统」毕设包说起它到底交付了什么如果你正在搜「毕业设计基于微信小程序的博物馆文创系统」大概率是三种人之一选题刚定下来想知道这套东西到底包含哪些模块代码跑不起来想找一份能对照的落地路径或者答辩临近论文、PPT、数据库文档还没凑齐。这个标题背后其实是一套完整的交付物组合微信小程序前端、SpringBoot 后端源码、论文、PPT 答辩材料、数据库文档外加一段演示视频。它解决的不是「怎么做一个商城」这种泛问题而是「博物馆文创这个垂直场景下从选题到答辩怎么闭环」。博物馆文创和普通电商最大的区别在于商品带文化属性用户买的是「文物 IP 的衍生品」所以系统里通常会有文物介绍、文创故事、分类按馆藏或朝代划分这些模块。适合谁适合计算机相关专业、时间紧、需要一套能讲清楚技术选型又能演示的毕设的同学。下面我按「先立住技术选型再动手复现最后避坑」的顺序把这条路走一遍。2. 技术选型先立住小程序 SpringBoot 为什么是毕设的稳妥组合2.1 前端为什么选微信小程序而不是 uniapp 或纯 H5毕设答辩时老师最爱问的一句是「你为什么用这个技术」。微信小程序作为前端理由要能站住一是免安装、扫码即用博物馆场景里游客现场扫码看文创很自然二是微信登录能直接拿到用户身份省掉一套注册登录的账号体系三是开发者工具成熟调试和真机预览都方便。相比之下 uniapp 虽然能一套代码多端打包但对毕设来说多出来的跨端能力用不上反而增加了打包配置的复杂度。纯 H5 则拿不到微信登录的便利还得自己处理会话。这里有个热词值得说清楚微信小程序登录获取手机号。很多同学以为小程序能随便拿手机号其实不是。手机号获取需要用户主动点击授权按钮且后端要用code换session_key再用encryptedData和iv解密这套流程在毕设里如果做不好答辩演示时很容易翻车。我的建议是毕设阶段用openid做用户唯一标识就够了手机号作为可选增强别把它做成核心流程。2.2 后端为什么是 SpringBoot而不是别的SpringBoot 在毕设里的地位几乎是默认选项原因很实际生态全、教程多、出问题能搜到答案。博物馆文创系统的后端无非是商品、订单、用户、文物信息这几张表的增删改查SpringBoot 配合 MyBatis-Plus 能把 CRUD 写得非常快。热词里提到的springboot版本太高是个真实痛点——很多同学直接拉最新版结果和 JDK 版本、依赖不兼容启动就报错。稳妥做法是锁一个长期支持版本比如 2.7.x 配 JDK 8 或 11别追新。数据库选 MySQL 就够了热词里的 sqllite、tdengine 这些在这个场景下没必要。MySQL 的数据库增删改查是答辩必问所以表设计要清晰字段命名要规范别用拼音缩写。2.3 一套能跑通的最小工程结构后端目录我一般这样组织答辩时讲结构也清楚museum-backend/ ├── src/main/java/com/museum/ │ ├── controller/ // 接口层对外暴露 REST │ ├── service/ // 业务逻辑 │ ├── mapper/ // MyBatis 映射 │ ├── entity/ // 数据库实体 │ └── config/ // 跨域、拦截器等配置 ├── src/main/resources/ │ ├── application.yml // 数据源、端口配置 │ └── mapper/ // XML 映射文件 └── pom.xml这个结构的好处是分层明确老师问「你的业务逻辑写在哪」你能直接指到 service 层。小程序端则按页面划分首页、文创列表、详情、购物车、订单、个人中心每个页面一个文件夹配app.json统一注册。3. 动手复现从数据库建表到小程序调通第一个接口3.1 数据库建表四张核心表怎么设计博物馆文创系统的核心表不多但字段要想清楚。下面是我常用的建表脚本直接可执行-- 用户表以 openid 为唯一标识 CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE COMMENT 微信唯一标识, nickname VARCHAR(64) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 文创商品表关联文物带文化属性 CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, cover VARCHAR(255) COMMENT 封面图, relic_id INT COMMENT 关联文物ID, stock INT DEFAULT 0, status TINYINT DEFAULT 1 COMMENT 1上架 0下架 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 文物表文创的文化来源 CREATE TABLE relic ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, dynasty VARCHAR(32) COMMENT 朝代, description TEXT COMMENT 文物介绍 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表 CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, total DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0 COMMENT 0待付款 1已付款 2已发货, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明user表用openid做唯一键避免重复注册product通过relic_id关联文物这样详情页能同时展示商品和它背后的文物故事这是博物馆文创区别于普通电商的关键orders的status用数字枚举前端映射成文字。参数上注意DECIMAL(10,2)存价格别用 float否则金额会出现精度问题答辩时被问到这是加分项。3.2 SpringBoot 接口商品列表和详情怎么写后端接口用 MyBatis-Plus 能省掉大量样板代码。先看商品列表接口RestController RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; // 分页查询上架商品支持按文物筛选 GetMapping(/list) public Result list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size, RequestParam(required false) Integer relicId) { LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, 1); if (relicId ! null) { wrapper.eq(Product::getRelicId, relicId); } PageProduct result productService.page(new Page(page, size), wrapper); return Result.success(result); } }逻辑说明LambdaQueryWrapper用方法引用写条件避免字段名写错status1保证只返回上架商品relicId可选用于「按文物筛选文创」这个博物馆特色功能。参数上page和size给了默认值前端不传也不会报错。Result是统一返回体包含code、msg、data前端好处理。3.3 小程序端调通第一个接口并处理跨域小程序端在app.js里配好请求基地址然后页面里调用// utils/request.js 封装统一请求 const BASE_URL http://localhost:8080; function request(url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: reject }); }); } module.exports { request };逻辑说明把wx.request包一层 Promise页面里就能用async/await代码干净。code 200是后端统一约定的成功码。参数上BASE_URL在开发时指向本地真机调试要换成局域网 IP否则手机访问不到 localhost。后端要配跨域否则开发者工具里会报错Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true); } }注意allowedOriginPatterns而不是allowedOrigins因为后者配*时和allowCredentials(true)冲突这是很多人踩过的坑。4. 避坑与排查毕设从能跑到能答辩之间的五个坎4.1 小程序请求报「不在以下 request 合法域名列表中」现象开发者工具里勾了「不校验合法域名」能跑真机预览就失败。原因微信要求所有请求域名必须备案并配置在后台。解决毕设演示阶段在开发者工具里关闭域名校验真机演示时用「预览」模式并保持校验关闭如果老师要求真机扫码提前把后端部署到有域名的服务器或者用内网穿透工具把本地服务暴露出去。4.2 SpringBoot 启动报数据源或版本不兼容现象Failed to configure a DataSource或依赖冲突。原因application.yml里数据源配置缺失或者 SpringBoot 版本和 JDK 不匹配。解决确认application.yml里有spring.datasource.url/username/password四项版本上锁 2.7.x 配 JDK 8别用 3.x 配 JDK 8那是跑不起来的。4.3 微信登录换 openid 时解密失败现象encryptedData解密报错或session_key失效。原因session_key有时效且每次wx.login都会刷新如果前端先拿 code 又延迟调解密key 就对不上了。解决登录流程做成「前端拿 code → 后端立即换 openid 和 session_key → 需要手机号时再解密」中间不要有长时间等待。4.4 数据库中文乱码现象文物介绍、商品名存进去变成问号。原因建表时字符集不是utf8mb4或连接串没指定编码。解决建表统一CHARSETutf8mb4连接串加?useUnicodetruecharacterEncodingutf8两边都对齐。4.5 答辩演示时订单流程走不通现象下单后订单列表查不到。原因下单接口写了但订单查询没按user_id过滤或者openid没正确传到后端。解决下单时后端从 token 或请求头里取openid反查user_id查询订单时用同一个user_id过滤保证数据闭环。演示前把这条链路单独走三遍。5. 让答辩加分把「文物关联文创」做成可验证的亮点大部分同学的毕设止步于「能跑」但答辩要拿高分得有一个能讲清楚、能演示、能验证的亮点。博物馆文创系统最自然的亮点就是「文物与文创的关联」。普通电商的商品详情只有图片和价格你可以做成点进一件文创先看到它取材自哪件文物、什么朝代、有什么故事再看到商品本身。这个功能技术上不难但叙事上很占优势。具体做法是在商品详情接口里做一次关联查询把文物信息一起返回GetMapping(/detail/{id}) public Result detail(PathVariable Integer id) { Product product productService.getById(id); if (product null) { return Result.error(商品不存在); } // 关联查询文物信息组装成 VO ProductVO vo new ProductVO(); BeanUtils.copyProperties(product, vo); if (product.getRelicId() ! null) { Relic relic relicService.getById(product.getRelicId()); vo.setRelic(relic); } return Result.success(vo); }逻辑说明用ProductVO而不是直接返回Product是为了把文物对象嵌进去前端一次请求就能拿到全部数据减少请求次数。参数上relicId可能为空有些文创不关联具体文物所以要做判空。这个 VO 模式在答辩时也是个可以展开讲的点为什么不用联表查询直接返回 Map因为 VO 字段可控、类型安全、前端对接清晰。验证方法很简单准备三条数据一条关联文物、一条不关联、一条文物不存在分别请求详情接口看返回是否符合预期。这个测试用例写进论文的「系统测试」章节比空泛地说「系统运行正常」有说服力得多。最后说个我自己的习惯每次改完接口先用 Postman 或浏览器直接访问一遍确认返回结构对了再去小程序里点。很多同学一上来就在小程序里调报错了分不清是前端还是后端的问题来回折腾。先把后端接口单独验证通过再联调能省一半时间。数据库文档和 PPT 里的接口说明也趁这个时候截图存好别等答辩前一天再补。希望帮到你。本文还有配套的精品资源点击获取 微信小程序博物馆文创系统毕设：SpringBoot全栈交付与避坑指南
简介这份资源是面向高校计算机相关专业毕业设计的完整项目包围绕基于微信小程序的博物馆文创系统展开适合正在准备毕设、需要小程序与Spring Boot全栈实战案例的学生及开发者参考。包内整合了Spring Boot后端源码、配套论文、PPT答辩材料、数据库文档与演示视频覆盖从需求分析、系统设计到功能实现的完整链路。系统前端采用微信小程序后端基于Java与Spring Boot框架数据层使用MySQL核心模块包括文创商品展示与在线购买、文创活动发布、用户间文创交换、展品语音讲解、积分排行榜以及交流论坛能够帮助读者理解文创互动平台的业务逻辑与实现思路。资源包整体约38.59MB以zip格式压缩文件类型涵盖源码、文档、演示视频等便于按模块查阅与二次开发。目前已有76人学习下载可作为毕设选题参考、代码复现与答辩准备的实用素材。1. 从一份「博物馆文创系统」毕设包说起它到底交付了什么如果你正在搜「毕业设计基于微信小程序的博物馆文创系统」大概率是三种人之一选题刚定下来想知道这套东西到底包含哪些模块代码跑不起来想找一份能对照的落地路径或者答辩临近论文、PPT、数据库文档还没凑齐。这个标题背后其实是一套完整的交付物组合微信小程序前端、SpringBoot 后端源码、论文、PPT 答辩材料、数据库文档外加一段演示视频。它解决的不是「怎么做一个商城」这种泛问题而是「博物馆文创这个垂直场景下从选题到答辩怎么闭环」。博物馆文创和普通电商最大的区别在于商品带文化属性用户买的是「文物 IP 的衍生品」所以系统里通常会有文物介绍、文创故事、分类按馆藏或朝代划分这些模块。适合谁适合计算机相关专业、时间紧、需要一套能讲清楚技术选型又能演示的毕设的同学。下面我按「先立住技术选型再动手复现最后避坑」的顺序把这条路走一遍。2. 技术选型先立住小程序 SpringBoot 为什么是毕设的稳妥组合2.1 前端为什么选微信小程序而不是 uniapp 或纯 H5毕设答辩时老师最爱问的一句是「你为什么用这个技术」。微信小程序作为前端理由要能站住一是免安装、扫码即用博物馆场景里游客现场扫码看文创很自然二是微信登录能直接拿到用户身份省掉一套注册登录的账号体系三是开发者工具成熟调试和真机预览都方便。相比之下 uniapp 虽然能一套代码多端打包但对毕设来说多出来的跨端能力用不上反而增加了打包配置的复杂度。纯 H5 则拿不到微信登录的便利还得自己处理会话。这里有个热词值得说清楚微信小程序登录获取手机号。很多同学以为小程序能随便拿手机号其实不是。手机号获取需要用户主动点击授权按钮且后端要用code换session_key再用encryptedData和iv解密这套流程在毕设里如果做不好答辩演示时很容易翻车。我的建议是毕设阶段用openid做用户唯一标识就够了手机号作为可选增强别把它做成核心流程。2.2 后端为什么是 SpringBoot而不是别的SpringBoot 在毕设里的地位几乎是默认选项原因很实际生态全、教程多、出问题能搜到答案。博物馆文创系统的后端无非是商品、订单、用户、文物信息这几张表的增删改查SpringBoot 配合 MyBatis-Plus 能把 CRUD 写得非常快。热词里提到的springboot版本太高是个真实痛点——很多同学直接拉最新版结果和 JDK 版本、依赖不兼容启动就报错。稳妥做法是锁一个长期支持版本比如 2.7.x 配 JDK 8 或 11别追新。数据库选 MySQL 就够了热词里的 sqllite、tdengine 这些在这个场景下没必要。MySQL 的数据库增删改查是答辩必问所以表设计要清晰字段命名要规范别用拼音缩写。2.3 一套能跑通的最小工程结构后端目录我一般这样组织答辩时讲结构也清楚museum-backend/ ├── src/main/java/com/museum/ │ ├── controller/ // 接口层对外暴露 REST │ ├── service/ // 业务逻辑 │ ├── mapper/ // MyBatis 映射 │ ├── entity/ // 数据库实体 │ └── config/ // 跨域、拦截器等配置 ├── src/main/resources/ │ ├── application.yml // 数据源、端口配置 │ └── mapper/ // XML 映射文件 └── pom.xml这个结构的好处是分层明确老师问「你的业务逻辑写在哪」你能直接指到 service 层。小程序端则按页面划分首页、文创列表、详情、购物车、订单、个人中心每个页面一个文件夹配app.json统一注册。3. 动手复现从数据库建表到小程序调通第一个接口3.1 数据库建表四张核心表怎么设计博物馆文创系统的核心表不多但字段要想清楚。下面是我常用的建表脚本直接可执行-- 用户表以 openid 为唯一标识 CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE COMMENT 微信唯一标识, nickname VARCHAR(64) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 文创商品表关联文物带文化属性 CREATE TABLE product ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, cover VARCHAR(255) COMMENT 封面图, relic_id INT COMMENT 关联文物ID, stock INT DEFAULT 0, status TINYINT DEFAULT 1 COMMENT 1上架 0下架 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 文物表文创的文化来源 CREATE TABLE relic ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, dynasty VARCHAR(32) COMMENT 朝代, description TEXT COMMENT 文物介绍 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表 CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, total DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0 COMMENT 0待付款 1已付款 2已发货, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明user表用openid做唯一键避免重复注册product通过relic_id关联文物这样详情页能同时展示商品和它背后的文物故事这是博物馆文创区别于普通电商的关键orders的status用数字枚举前端映射成文字。参数上注意DECIMAL(10,2)存价格别用 float否则金额会出现精度问题答辩时被问到这是加分项。3.2 SpringBoot 接口商品列表和详情怎么写后端接口用 MyBatis-Plus 能省掉大量样板代码。先看商品列表接口RestController RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; // 分页查询上架商品支持按文物筛选 GetMapping(/list) public Result list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size, RequestParam(required false) Integer relicId) { LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, 1); if (relicId ! null) { wrapper.eq(Product::getRelicId, relicId); } PageProduct result productService.page(new Page(page, size), wrapper); return Result.success(result); } }逻辑说明LambdaQueryWrapper用方法引用写条件避免字段名写错status1保证只返回上架商品relicId可选用于「按文物筛选文创」这个博物馆特色功能。参数上page和size给了默认值前端不传也不会报错。Result是统一返回体包含code、msg、data前端好处理。3.3 小程序端调通第一个接口并处理跨域小程序端在app.js里配好请求基地址然后页面里调用// utils/request.js 封装统一请求 const BASE_URL http://localhost:8080; function request(url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: reject }); }); } module.exports { request };逻辑说明把wx.request包一层 Promise页面里就能用async/await代码干净。code 200是后端统一约定的成功码。参数上BASE_URL在开发时指向本地真机调试要换成局域网 IP否则手机访问不到 localhost。后端要配跨域否则开发者工具里会报错Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowCredentials(true); } }注意allowedOriginPatterns而不是allowedOrigins因为后者配*时和allowCredentials(true)冲突这是很多人踩过的坑。4. 避坑与排查毕设从能跑到能答辩之间的五个坎4.1 小程序请求报「不在以下 request 合法域名列表中」现象开发者工具里勾了「不校验合法域名」能跑真机预览就失败。原因微信要求所有请求域名必须备案并配置在后台。解决毕设演示阶段在开发者工具里关闭域名校验真机演示时用「预览」模式并保持校验关闭如果老师要求真机扫码提前把后端部署到有域名的服务器或者用内网穿透工具把本地服务暴露出去。4.2 SpringBoot 启动报数据源或版本不兼容现象Failed to configure a DataSource或依赖冲突。原因application.yml里数据源配置缺失或者 SpringBoot 版本和 JDK 不匹配。解决确认application.yml里有spring.datasource.url/username/password四项版本上锁 2.7.x 配 JDK 8别用 3.x 配 JDK 8那是跑不起来的。4.3 微信登录换 openid 时解密失败现象encryptedData解密报错或session_key失效。原因session_key有时效且每次wx.login都会刷新如果前端先拿 code 又延迟调解密key 就对不上了。解决登录流程做成「前端拿 code → 后端立即换 openid 和 session_key → 需要手机号时再解密」中间不要有长时间等待。4.4 数据库中文乱码现象文物介绍、商品名存进去变成问号。原因建表时字符集不是utf8mb4或连接串没指定编码。解决建表统一CHARSETutf8mb4连接串加?useUnicodetruecharacterEncodingutf8两边都对齐。4.5 答辩演示时订单流程走不通现象下单后订单列表查不到。原因下单接口写了但订单查询没按user_id过滤或者openid没正确传到后端。解决下单时后端从 token 或请求头里取openid反查user_id查询订单时用同一个user_id过滤保证数据闭环。演示前把这条链路单独走三遍。5. 让答辩加分把「文物关联文创」做成可验证的亮点大部分同学的毕设止步于「能跑」但答辩要拿高分得有一个能讲清楚、能演示、能验证的亮点。博物馆文创系统最自然的亮点就是「文物与文创的关联」。普通电商的商品详情只有图片和价格你可以做成点进一件文创先看到它取材自哪件文物、什么朝代、有什么故事再看到商品本身。这个功能技术上不难但叙事上很占优势。具体做法是在商品详情接口里做一次关联查询把文物信息一起返回GetMapping(/detail/{id}) public Result detail(PathVariable Integer id) { Product product productService.getById(id); if (product null) { return Result.error(商品不存在); } // 关联查询文物信息组装成 VO ProductVO vo new ProductVO(); BeanUtils.copyProperties(product, vo); if (product.getRelicId() ! null) { Relic relic relicService.getById(product.getRelicId()); vo.setRelic(relic); } return Result.success(vo); }逻辑说明用ProductVO而不是直接返回Product是为了把文物对象嵌进去前端一次请求就能拿到全部数据减少请求次数。参数上relicId可能为空有些文创不关联具体文物所以要做判空。这个 VO 模式在答辩时也是个可以展开讲的点为什么不用联表查询直接返回 Map因为 VO 字段可控、类型安全、前端对接清晰。验证方法很简单准备三条数据一条关联文物、一条不关联、一条文物不存在分别请求详情接口看返回是否符合预期。这个测试用例写进论文的「系统测试」章节比空泛地说「系统运行正常」有说服力得多。最后说个我自己的习惯每次改完接口先用 Postman 或浏览器直接访问一遍确认返回结构对了再去小程序里点。很多同学一上来就在小程序里调报错了分不清是前端还是后端的问题来回折腾。先把后端接口单独验证通过再联调能省一半时间。数据库文档和 PPT 里的接口说明也趁这个时候截图存好别等答辩前一天再补。希望帮到你。本文还有配套的精品资源点击获取