Spring Boot+微信小程序房地产销售系统开发实战解析

"Java springboot基于微信小程序的房地产销售管理系统（源码+文档+运行视频+讲解视频）"这种命名，我一眼就认出来了，这是典型的计算机毕业设计项目。很多读者拿到的素材包里往往只有代码和演示视频，但真正麻烦的从来不是跑通项目，而是看懂项目、讲清项目、在答辩时扛住老师问的那几个问题。这篇文章我就以房地产销售管理这个小程序项目为样本，把从需求拆解到表设计、从后端接口到小程序联调的完整思路梳理一遍，既适合正在做类似毕设的同学参照，也适合想快速上手"Spring Boot + 微信小程序"这套技术栈的开发者。

先说清楚这类项目到底是干什么的。房地产销售管理系统，核心解决的是传统售楼处里信息散乱的问题：楼盘资料靠纸质手册、客户到访记录靠Excel、销售员跟进全靠微信聊天记录、成交情况每天下班前人工汇总。这个系统把楼盘、房源、客户、预约、签约这几条线收到一起，客户在小程序端看房、约看、留资，销售和管理人员在后台做审核、跟进和统计。想跑通一个能演示、能答辩、能讲清业务闭环的系统，你需要吃透的不只是CRUD，而是这几条业务线之间怎么咬合。

1. 项目拆解：这到底是个什么系统

1.1 先从业务场景反推功能需求

拿到需求别急着写代码。即使你下载的是现成源码，第一步也应该是用业务视角把系统切成几块。

想象一个真实场景：某个楼盘开盘，一个客户通过小程序首页看到在售房源，点进去查看户型图、面积、单价，觉得不错就提交了一个"预约看房"申请。后台的销售员看到这条预约，电话联系客户确认时间，线下带看，客户满意则进入认购/签约流程，销售员在后台登记成交信息，客户可以随时在小程序看到自己名下订单的处理进度。

把这个场景拆开，系统的核心功能模块自然就浮出来了：

• 楼盘与房源管理：楼盘基础信息、楼栋、单元、户型、面积、朝向、价格，以及每一套房源的状态（待售/锁定/已售）
• 客户管理：来访登记、意向登记、跟进记录、客户归属（哪个销售的客户）
• 预约看房：客户提交预约、销售确认或改期、现场到访登记
• 交易管理：认购登记、签约进度、款项记录
• 统计报表：按楼盘、按销售员维度的成交量、成交额、客户转化率

有些人会忽略"用户角色"这个分析维度，但这恰恰是答辩时最容易挨问的点。系统至少有三种角色：

1. 客户（小程序端）：看房、预约、查订单
2. 销售员（管理端）：处理预约、录入客户、跟进、登记认购
3. 管理员（管理端）：维护楼盘信息、管理销售员账号、查看统计报表

如果只做客户端和管理员两种角色，业务会显得单薄。加上销售员这层中间角色，流程才完整，也能体现你对权限设计的理解。

1.2 小程序端和管理后台各承担什么职责

明确了角色再看端侧分工，逻辑就顺了。

微信小程序端面向购房客户，界面要简、路径要短。核心页面控制在这么几个：首页（楼盘展示列表）、楼盘详情（户型、价格、配套）、房源列表与详情、预约看房表单、个人中心（我的预约、我的订单）。

管理后台面向销售员和管理员，实际上有两条入口。如果你用的是Spring Boot + Thymeleaf或Vue做独立后台，那权限控制和管理员模块放这里；我见过不少毕设项目采用更省事方案——后台直接做成一整套Web管理系统，小程序只做C端展示和业务提交。两种做法都成立，取决于你素材包里的实际结构。对Spring Boot项目来说，一般还包含一个后台管理界面，负责处理销售端和管理员的业务操作。

不过这一篇我重点讲整体设计逻辑和代码实现思路，管理后台和管理端具体属于同一套Spring Boot的后端。

2. 技术选型：为什么大家扎堆用 Spring Boot + 小程序

2.1 Spring Boot 在这个场景中的生态优势

在最近十年的Java后端项目里，Spring Boot差不多成了事实上的默认起点。原因不复杂：它把繁琐的XML配置收进自动配置，内嵌Tomcat让项目可以java -jar一键启动，再搭配Spring MVC写REST接口、MyBatis-Plus做持久层，一个中小型管理系统的开发周期能压到很夸张的程度。

具体到房地产销售管理这个场景，Spring Boot主要体现在三个地方：

1. 接口开发效率高：写Controller + Service + Mapper三层结构，配合MyBatis-Plus的BaseMapper，单表CRUD基本不用手写SQL，这能让项目代码量大幅减少，对需要快速交付的毕设项目尤其友好。
2. 生态内组件成熟：权限可以用Spring Security或Sa-Token，文件上传（比如户型图）用本地存储就行，定时任务统计用@Scheduled，几乎每个需求点都能找到现成轮子。
3. 部署演示简单：开发完打成jar包，服务器装个JDK就能跑。演示时可以在本机启动，小程序开发者工具里直接联调，不用额外装Tomcat和复杂环境。

另外提醒一点，Spring Boot的版本选择很影响后面调试。新版本（3.x）强制JDK 17，如果你的环境还是JDK 8，老老实实用Spring Boot 2.7.x，不然编译都过不了就麻烦了。这类项目跑源码时最容易出现的问题就是"JDK版本和框架版本不匹配"，后面第4节会专门说。

2.2 小程序端为什么适合“轻前端”

小程序端我用的是原生微信小程序语法，也有人的素材包用uniapp，你拿到源码后要分清。原生小程序和uniapp在开发习惯上存在差异，但底层都是WXML / WXSS / JS这套思路，切换成本没有想象中高。

选择原生小程序胜在不用引入额外的编译层，微信开发者工具直接创建、编译、预览，调试起来最直接。对项目来讲，前端只负责展示和收集用户操作，剩下的业务规则全部交给后端，这也符合前后端分离的思路——逻辑越往后端收，前端开发和排错就越省力。

小程序端的核心交互离不开这几个要素：

• wx.request与后端REST接口交互
• wx.login拿code换openid（后端session_key交换）
• 用户操作后通过wx.showToast给用户操作反馈
• 分页列表用onReachBottom做上拉加载

2.3 数据库设计是整个项目的命门

很多学生喜欢先写代码再补表结构，这是一条弯路。房地产销售系统数据表之间存在关联和状态流转，一旦表结构不合理，后面代码会越写越乱。

我给出这套系统的核心表清单，以及表与表之间的关联思路：

• 用户表（user）：包括用户ID、用户名、密码、手机号、角色类型、小程序openid、状态。销售员和管理员共用一张表，用角色字段区分，可以省去多表权限关联的复杂度。
• 楼盘表（building）：楼盘ID、名称、位置、区域、均价、描述、封面图、状态。这是最顶层的基础数据。
• 房源表（house）：房源ID、所属楼盘ID、楼栋、单元、房号、户型、面积、单价、总价、朝向、状态（0待售/1锁定/2已售）、图片。房源是房子最小的售卖单位，与楼盘为多对一关系。
• 客户表（customer）：客户ID、姓名、手机号、意向户型、意向预算、客户来源、所属销售ID、跟踪状态。
• 预约看房表（appointment）：预约ID、客户ID、房源ID（或楼盘ID）、预约日期、联系电话、状态（0待确认/1已确认/2已看房/3已取消）。
• 认购/订单表（orders）：订单ID、订单编号、客户ID、销售ID、房源ID、房价、定金、签约状态、创建时间。
• 跟进记录表（follow_record）：记录销售员与客户每次沟通内容和下次跟进时间。

这七张表基本覆盖了完整业务链路。为了演示效果，可以在管理员账号登录后预置几栋楼、几十套房源、几个测试客户，给答辩演示时制造出数据丰富的效果。

很多初学者搞不清房源表和楼盘表为什么要分开。类比一下：楼盘是"小区"的概念，房源是"某栋楼的某一套房子"。一个楼盘有几十上百套房源，每套房源的价格、朝向、状态都不一样。不拆分的话，楼盘信息会在房源记录里重复几百次，数据冗余且后续扩展也麻烦。

3. 核心模块实现精讲：从接口设计到业务规则

3.1 登录鉴权：怎么识别用户身份

小程序端没有传统的账号密码登录那么直接，它的常规方式是微信授权手机号或静默登录，但很多毕设项目为了简化，走的是openid识别。

流程是这样：

1. 小程序端执行wx.login，拿到临时code
2. 把code传给后端接口/user/login
3. 后端调用微信接口（jscode2session）换openid和session_key
4. 如果openid在user表里不存在，则自动创建一个新用户，角色设为客户；如果存在，直接登录
5. 后端生成一个token（可以是UUID或JWT）返回给小程序，小程序后续请求都带上这个token

你可能会被问：为什么不直接传openid给后端？因为code是一次性的，且openid算用户敏感标识，正常的做法是服务端持有code去换。这个点在答辩时值得主动说，会显得专业。

后端核心代码示意如下（这是你在源码里经常看到的标准写法）：

java复制@RestController
@RequestMapping("/api/user")
public class UserController {

    @Autowired
    private IUserService userService;

    @PostMapping("/login")
    public R login(@RequestBody LoginDTO dto) {
        // 根据 code 调用微信接口解析 openid
        String openid = wxService.code2Session(dto.getCode());
        User user = userService.findByOpenid(openid);
        if (user == null) {
            user = new User();
            user.setOpenid(openid);
            user.setRole(1); // 默认角色为客户
            userService.save(user);
        }
        String token = JwtUtil.generateToken(user.getId(), user.getRole());
        return R.ok().put("token", token).put("role", user.getRole());
    }
}

角色判断很关键。管理端接口Controller里可以写个拦截器，把请求头里的token解析出用户角色，拦截掉没有权限的访问。如果项目用了Sa-Token，几行注解就能解决；如果手写拦截器，逻辑也很直观：

java复制public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("token");
        if (token == null || !JwtUtil.verify(token)) {
            response.setStatus(401);
            return false;
        }
        // 这里还可以把用户ID放入request，便于后续业务
        Integer userId = JwtUtil.getUserId(token);
        request.setAttribute("userId", userId);
        return true;
    }
}

3.2 房源查询 + 条件筛选接口

房源列表是小程序使用最频繁的接口。设计时要有分页、关键字、筛选条件和状态控制。

接口设计范例：

• GET /api/house/list?page=1&limit=10&keyword=三居室&minPrice=1000000&maxPrice=2000000&status=0

这里keyword搜的是房号、户型、楼盘名称，minPrice和maxPrice是价格区间，status可以筛选在售。在小程序端，我会把筛选条件做成一个底部弹层面板，用户选择后重新拉取列表。

很多人写分页查询用PageHelper或MyBatis-Plus的Page对象，后者更简单：

java复制public R getHouseList(int page, int limit, HouseQueryDTO query) {
    LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>();
    wrapper.like(StringUtils.isNotBlank(query.getKeyword()), House::getRoomType, query.getKeyword())
           .ge(query.getMinPrice() != null, House::getTotalPrice, query.getMinPrice())
           .le(query.getMaxPrice() != null, House::getTotalPrice, query.getMaxPrice())
           .eq(query.getStatus() != null, House::getStatus, query.getStatus())
           .eq(House::getDeleted, 0)
           .orderByDesc(House::getCreateTime);
    Page<House> pageResult = houseMapper.selectPage(new Page<>(page, limit), wrapper);
    return R.ok().put("data", pageResult);
}

注意一个容易被挑刺的细节：查房源列表时要连楼盘表查一下楼盘名称和封面，不然前端列表页只能展示房源编号，用户根本不知道是哪家楼盘，演示效果差一大截。所以实际返回给前端的DTO里，要有楼盘名称、楼盘区域等冗余字段。

3.3 预约看房的完整生命周期

预约看房不能只做"提交"和"列表"。业务闭环要形成状态变化，这也是体现业务逻辑完整度的地方。

一般情况下，预约状态分四段：

• 状态0：待确认（客户刚提交）
• 状态1：已确认（销售员在后台确认，并按约定时间带看）
• 状态2：已完成（客户到访，看房结束）
• 状态3：已取消（客户主动取消或销售取消）

后端至少要提供以下接口：

• POST /api/appointment 提交预约
• GET /api/appointment/myList 客户查自己的预约（小程序端）
• GET /api/appointment/adminList 销售查所有分配给自己的预约（管理端）
• PUT /api/appointment/status 更新预约状态

业务规则里隐藏一个关键点：客户提交预约时要带上手机号。这个手机号不能只靠小程序端传，也不能只做非空校验。比较完善的做法是，第一次进入小程序就引导用户绑定手机号（或让用户填写咨询电话），后续预约自动带出。这样既方便销售回访，也是后面演示业务闭环的数据基础。

3.4 认购下单与房源状态防并发

当客户决定购买某套房源，认购单就承担了类似"购物车结算+订单生成"的功能。

这里必须考虑房源防重复销售的问题——同一套房源不能被两个客户同时锁定。如果项目不考虑并发控制，面试官或答辩老师常会追问"两个销售同时卖同一套房怎么办"。我的建议是使用数据库层面的乐观锁：

sql复制UPDATE house SET status = 1 
WHERE id = #{houseId} AND status = 0

或者用MyBatis-Plus乐观锁插件，在house表加version字段。执行update时判断version是否匹配。返回影响行数为1，说明抢到了；为0则说明房源已被别人锁定，需要提示前端"房源状态已变化，请刷新后重试"。

这个点虽然小，但属于"能看出你有没有真实商业项目经验"的细节。只要是做交易类系统，数据一致性问题永远躲不开。在答辩时主动提到这个设计，大概率会让老师觉得你考虑过实际问题。

3.5 管理后台的数据看板

管理端的首页不要只放一张欢迎图。加上几个统计卡片后，项目的演示效果和业务完成度会更上一层楼：

• 今日新增客户数
• 本月成交单数
• 本月成交总金额
• 在售房源数量

这些数据并不需要复杂SQL。一个统计Mapper，用@Select注解就能搞定：

java复制@Mapper
public interface StatisticMapper {
    @Select("SELECT COUNT(*) FROM customer WHERE DATE(create_time) = CURDATE()")
    Long countTodayCustomer();

    @Select("SELECT COUNT(*) FROM orders WHERE status = 2 AND MONTH(create_time) = MONTH(CURDATE())")
    Long countMonthOrder();

    @Select("SELECT IFNULL(SUM(total_price), 0) FROM orders WHERE status = 2 AND MONTH(create_time) = MONTH(CURDATE())")
    BigDecimal sumMonthAmount();
}

再把ECharts或前端图表库接进来展示近7天预约趋势、楼盘成交量Top5、团队成员业绩对比，系统的“管理”属性就非常立体了。如果小程序项目带的素材里没有后台看板图表，这个也容易改，无外乎后端提供一个趋势列表接口，前端循环渲染图表插件而已。

4. 小程序端的关键实现与前后端联调

4.1 原生小程序的项目结构

原生小程序项目的典型目录结构如下：

code复制├── pages
│   ├── index        # 首页（楼盘列表）
│   ├── building     # 楼盘详情
│   ├── house        # 房源详情
│   ├── appointment # 预约看房
│   ├── mine         # 个人中心
│   └── order        # 房源订单列表
├── utils
│   └── request.js   # 封装 wx.request
├── app.js           # 全局初始化、登录逻辑
├── app.json         # 页面注册
└── project.config.json

开发之前先理清页面注册规则。新增一个页面，需要在app.json的pages数组里声明路径，开发者工具才会识别。不少刚上手原生小程序的人，在这个环节没注册页面，导致跳转时页面404，这个坑值得先避开。

4.2 请求封装：登录态和错误提示统一处理

小程序端我建议单独封装一个request.js，不要在每个页面都写一遍wx.request。封装之后的收益很明显：所有请求自动带token、统一处理401跳登录、统一提示后端返回的报错信息。

封装的核心逻辑大概是：

javascript复制function request(url, method, data) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: baseUrl + url,
      method: method,
      data: data,
      header: {
        'Content-Type': 'application/json',
        'token': wx.getStorageSync('token') || ''
      },
      success(res) {
        if (res.data.code === 401) {
          wx.removeStorageSync('token');
          wx.navigateTo({ url: '/pages/login/login' });
          reject(res.data);
          return;
        }
        if (res.data.code === 200) {
          resolve(res.data);
        } else {
          wx.showToast({ title: res.data.msg, icon: 'none' });
          reject(res.data);
        }
      },
      fail(err) {
        wx.showToast({ title: '网络错误', icon: 'none' });
        reject(err);
      }
    });
  });
}

使用的时候在页面里：

javascript复制const res = await request('/api/house/detail?id=12', 'GET');
this.setData({ house: res.data });

这套封装同样适用于uniapp，把wx.request改成uni.request即可，后端接口完全不用动。

4.3 登录时机：什么时候调 wx.login

这里有个非常典型的逻辑问题：客户首次打开小程序，你选在哪个时机登录？

常见的错误做法是用户必须点"登录"按钮才会调登录接口，这会导致用户在未登录状态下浏览房源时，看到的是空白数据。其实大部分房源浏览、楼盘列表接口是公开的，不必登录就能看。更合理的方案：

1. 打开小程序后默认允许用户浏览楼盘和房源信息
2. 用户触发需要身份的操作时（比如预约看房、查看我的订单），才判断本地有没有token
3. 没有token就引导用户进入手机号授权登录流程
4. 登录成功后回调到原来的页面，继续之前未完成的操作

这样处理的好处是：房产信息作为推广内容可以敞开给潜在客户看，但是预约、下单这些实际上产生归属关系的动作要锁在登录之后。这也是很多商业地产小程序的通用交互逻辑。

如果项目在开发阶段设置了体验版，并且后端校验了"手机号必须真实"，那可以用测试号或随便一个手机号模拟开发，微信小程序的手机号快速验证组件需要认证过的企业小程序才能用，个人开发者在开发阶段是没法直接拿到用户真实手机号的，这是很多学生第一次联调必跪的地方。

4.4 房源列表的分页加载

小程序列表页最常见的交互是上拉分页加载。实现时分页字段和"是否还有更多"的判断都要小心。

比较稳妥的做法是，data里维护：

javascript复制data: {
  houseList: [],      // 当前已加载的房源
  page: 1,
  limit: 10,
  hasMore: true,
  loading: false
}

每次onPullDownRefresh重置page为1、清空列表；每次触底onReachBottom判断hasMore后，page加1请求下一页。如果接口返回的当前页数据条数小于limit，说明没有更多了，把hasMore置为false，并隐藏上拉加载提示。

这个循环在几乎所有小程序项目中都会用到，属于高频模板。

5. 运行部署、安装调试与避坑经验

5.1 拿到源码后第一步做什么

很多同学拿到压缩包，直接开IDE跑，跑不起来就慌。我这里说下合适的展开顺序：

1. 用IDEA打开源码根目录，等待Maven下载依赖。这一步非常容易卡住，建议把maven仓库镜像改成阿里云公共仓库，群里有不少人被依赖下载慢坑过好几个小时。
2. 查看application.yml，把数据库名、用户名、密码改成自己本地的MySQL配置。
3. 在Navicat里执行项目提供的SQL脚本。如果有人给你的是.sql文件，按文件名先后顺序导入；代码里配置jpa或mybatis-plus的ddl-auto，如果是update就不用手动建表，但这类项目通常仍配了sql脚本供导入初始数据。
4. 启动类上加@MapperScan的包路径要和你项目的Mapper接口所在包保持一致，否则启动就会报找不到mapper。
5. 修改小程序端的接口地址。开发者工具里详情-本地设置，勾选"不校验合法域名"，因为本地调试用的是HTTP://localhost或局域网IP，不勾选会直接请求失败。
6. 小程序端和本机后端联调时，笔者遇到过最多的问题是"请求后台接口一直转圈最后超时"。通常情况下是后端没启动，或小程序baseUrl写成了localhost——真机预览时localhost指的是手机自己，要填电脑的局域网IP。

你一定会需要一块本地跑通的环境清单。下面按最常用的部署方式梳理一遍：

5.2 高频报错及应对

Caused by: java.sql.SQLSyntaxErrorException: Unknown database

这几乎是最常见的启动报错。IDE里看报错日志多半写着Unknown database 'xxx'，说明数据库还没创建，或者名称与配置文件不一致。措施是到Navicat里新建对应名称的数据库，再执行SQL脚本。注意编码要选utf8mb4，否则中文字段会出现乱码问题。

Invalid bound statement (not found)

看到这个错，优先排查mapper接口与XML文件的关系。如果你的项目使用MyBatis的XML方式，会检查resources/mapper目录下是否有对应的XML文件，并且XML里的namespace是否与Mapper接口全限定名一致。另外Spring Boot打包时默认只打包resources资源下的文件，如果你把XML放进了java源码目录里，要额外在pom.xml里配置resource，否则启动后XML不会进classpath。我见过不少人在这里反复折腾。

小程序端报"不在以下 request 合法域名列表中"

这只是开发阶段的提示，不是代码错误。两个处理办法：一是到微信开发者工具右上角"详情-本地设置-勾选不校验合法域名以及TLS版本"，二是把后端接口发布到已有合法域名上。本地开发基本用第一种。

连接超时 connect timed out

如果小程序开发工具连接的是本机后端，在开发者工具里填http://127.0.0.1:8080或http://localhost:8080是可以访问的。但安卓真机预览时，由于真机和小程序不在同一台电脑，填localhost就会指向手机自己。要填电脑在局域网的IP，比如http://192.168.1.101:8080。顺便说一句，后端服务启动时不要绑定到127.0.0.1，Spring Boot默认绑定0.0.0.0，局域网可通。如果本机防火墙开着，也要给8080端口放行。

后端启动就闪退，或者一直报端口被占用

项目默认端口是8080，如果本机已有其他程序占用了8080，就需要改配置。在application.yml里加server.port来指定别的高可用端口，比如8081。小程序端的baseUrl也要同步改。

5.3 素材包里的文档和视频应该怎么用

这里的源码附带文档、运行视频、讲解视频，已经是毕设项目的标准交付形态。我的建议是别只盯着演示视频看，还是要自己把项目跑起来。原因也很直接：答辩时老师极有可能让你现场操作几个流程，比如新增一个楼盘、提交预约、修改房源状态。如果你只会照视频复述，一动手就露馅。

讲项目的时候有个可以提前备好的节奏：先讲需求背景和角色划分，再放数据库ER图（或直接贴核心表结构），然后带老师走一遍"客户提交预约->销售确认->录入认购->管理端看统计"主链路，最后强调一两个技术亮点（比如上面提到的乐观锁防并发、token鉴权、多角色拦截）。整个项目讲解控制10-15分钟比较适合答辩节奏。

6. 进阶方向：这个项目还能往哪些方向扩展

到这里，系统已经具备完整的房产销售闭环。不过市场上毕设项目同质化严重，你如果想让项目在答辩中比较出彩，可以从下面几个方向选一个做小步扩展：

1. 增加地图找房功能：在小程序端接入腾讯位置服务或高德地图SDK，按地图缩放级别拉取周边楼盘和房源，这是房产项目的常态化功能，加进去之后业务维度会更有吸引力。
2. 引入消息通知：客户预约成功后，通过订阅消息模板通知销售员；销售员确认/改期预约后，再给客户发送一条小程序订阅消息。这个功能能体现你对微信生态的理解。
3. 增加跟进计划：给每个客户设置一个"下一次跟进时间"，到点了在管理端待办里自动提醒。这个功能本身不复杂，但能体现出你懂房产销售的实际业务节奏。
4. 加入数据权限：销售员只能看自己的客户和预约，管理员的客户和预约列表是全团队的。这个小改动虽然会增加查询复杂度，却能暴露你对授权模型的理解。
5. 替换为Redis缓存看板数据：把首次统计的报表数据缓存起来，五分钟过期后再重新统计。大数据量情况下接口响应能从几秒降到几十毫秒。

每加一个扩展点，都会引入新的表或者新的配置，也会带来新的bug，但项目的深度自然就会更高一些。选1-2项做出来，写进论文的创新点，答辩时老师更容易眼前一亮。

7. 最后再分享一点个人实操体会

这类"Spring Boot + 微信小程序"的全栈毕设项目，这几年我实测下来，真正让你觉得困难的地方大多不在某一个框架本身，而在于跨端联调时的各种状态同步问题。后端接口通了不代表前端列表一定能渲染，前端提交成功也不代表后端异常处理得完善。

跑通一个房地产销售管理系统不要急着改代码，先完整地按业务流程走一遍：注册一个客户账号 -> 浏览楼盘 -> 预约看房 -> 管理端改成已确认 -> 再录一个客户 -> 录一个认购单 -> 回到统计页看数字是否变化。整条链路跑通之后，项目里的每一段代码都不是孤立的，你答辩时的思路也会清楚很多。

如果素材包里带了文档和视频，请在跑通流程后再去对照文档，看当初的实现思路和你自己上手的理解是不是一致。技术上的问题几乎都能搜到答案，但如果连系统能否启动都还不确定，拿到任何"运行视频"都无法在真正需要你动手的那一刻帮上忙。多花几小时跑代码，是你做这个项目最值得的一笔投入。