企业官网建设流程全解析

每到毕业季，都会有一批同学在为毕设选题发愁。图书阅读打卡小程序，是我这几年看下来比较适合做毕业设计的一个方向，同时也是我最近完整从零到一带出的一个项目。这个题目听起来不算花哨，但把一个Spring Boot后端、一个微信小程序前端、再加上MySQL数据库串成了一个很完整的业务闭环，用来展示自己的代码能力和设计能力，分量足够了。

这个项目最终交付的东西很清晰：一个小程序端，用户注册登录后可以搜索图书、添加书架、开始阅读并打卡，系统自动记录阅读时长，统计连续打卡天数、阅读偏好，还会生成阅读报告；一个后端管理平台，管理员可以维护图书数据、查看用户打卡记录、发布公告、做数据统计。整个项目包含完整源码、数据库脚本、毕业论文文档、以及逐模块的代码讲解，配套一条龙答疑和定制化扩展服务。对于需要快速落地毕设、又想真正搞懂代码逻辑的同学来说，这套组合拳能把“做完”和“做懂”之间的距离拉近不少。

我习惯从业务理解、技术选型、数据库设计、核心接口实现、前端页面联调、部署答辩这几个维度来拆解这类项目。所以这篇文章我会完整走一遍这套流程，把关键的实现思路、代码写法、踩过的坑都写进来，希望能让你少走点弯路。

1. 项目整体设计思路与选题价值拆解

1.1 为什么选择“图书阅读打卡”这个业务场景

毕设选题最怕的就是“大而空”。图书阅读打卡这个场景的妙处在于，它天生自带一个非常完整的业务闭环：用户发现图书 → 加入书架 → 开始阅读 → 完成打卡 → 形成阅读记录和数据统计。这条链路中有实体对象（用户、图书、打卡记录），有状态流转（未开始、阅读中、已读完），还有数据积累（阅读时长、连续天数、排行），任何一个环节拿出来都足够设计成表格和接口。

从导师视角来看，这个题目涵盖了软件工程的大部分核心环节。需求分析要做角色划分和管理员、普通用户两类角色；概要设计要画系统架构图、功能结构图；详细设计要画E-R图、用例图、时序图；编码阶段要求实现后端接口、前端页面、数据库交互；测试阶段要写测试用例；最后还有部署和演示。一个业务逻辑不复杂的系统，正好可以把这些环节全部走一遍，不会因为业务太复杂而把宝贵的精力耗在没有技术含量的规则描述上。

从演示效果来看，阅读打卡的场景非常适合做成小程序。用户每天打开小程序扫一眼自己读了几天、本周目标完成得怎么样，这个交互在小程序上非常自然。相比传统的Web后台系统，小程序的界面演示时更有抓手，面试展示或者答辩演示都更好讲。

1.2 技术栈选型：Spring Boot + 小程序 + MySQL这套组合为什么稳

后端选择Spring Boot是毕设场合下最稳妥的方案。目前市面上的主流教程、网上的代码示例、导师的熟悉程度，都集中在Spring Boot这条线上。相对Servlet和SSH那些老框架，Spring Boot极大地减少了配置量，一个注解就能完成Bean注入，内嵌Tomcat让本地启动变成一步操作。这些特性对毕设阶段的开发效率非常重要，因为大部分同学不是不会写业务代码，而是被环境配置、框架整合这些“非业务成本”拖住了。

小程序端我建议用微信原生开发框架。现在市面上有很多跨端框架，比如uni-app、Taro，它们确实在跨平台上有优势。但毕业设计的评审逻辑不太一样——你的代码量、代码结构、逻辑清晰度都会被直接看到，原生的WXML、WXSS、JS、JSON四件套虽然繁琐一点，但每一行页面结构都是透明的，导师问起来你也讲得清楚。跨端框架虽然开发效率高，但封装了一层之后，很多同学反而说不清底层逻辑。

数据库层面没什么悬念，MySQL是毕设标配。需要注意版本选择和字符集配置，建议直接用MySQL 8.x，安装的时候就把utf8mb4设置好。很多同学后面踩的“中文乱码”坑，基本都是在这个环节埋下的。

1.3 功能模块拆解：前后端到底要做哪些事

做一个完整的图书阅读打卡平台，功能切分要同时考虑“用户端能做什么”和“管理端能做什么”，否则做着做着就会漏掉角色权限这个环节。

用户端核心模块：

• 微信登录注册：基于微信小程序的code换取openid，自动完成账号体系的建立
• 图书发现：图书搜索、图书列表分页浏览、图书详情展示
• 书架管理：将图书加入“在读”或“想读”书架，移除或切换状态
• 阅读打卡：填写阅读时长、阅读页码或笔记，提交打卡记录
• 数据统计：累计阅读天数、累计阅读时长、连续打卡天数、历史打卡日历
• 个人中心：昵称、头像、打卡记录列表、我的书架、意见反馈

管理端核心模块：

• 管理员登录：独立的管理员账号体系，和用户账号隔离
• 图书信息管理：图书录入、编辑、下架、删除
• 用户管理：查看注册用户列表，处理异常账号
• 打卡记录管理：查看所有用户的打卡明细，违法内容和数据异常处理
• 公告管理：发布系统公告，控制在小程序端展示
• 数据概览：统计注册用户数、累计打卡次数、图书总量，用图表方式展示

在这些模块中，打卡记录是业务核心，图书是基础数据，用户是主体，统计是亮点。如果把模块再合并一下，那就是：基础数据维护、核心业务流转、数据统计分析。做设计文档的时候按这个思路去写，逻辑会非常顺畅。

2. 数据库设计与核心业务逻辑规划

2.1 核心数据表结构设计讲解

数据库设计是毕设答辩的高频提问区。图书阅读打卡系统的数据模型围绕“用户-图书-打卡”这三个核心对象展开。

用户表（sys_user）需要包含主键id、微信openid、昵称、头像URL、累计阅读时长、累计打卡天数、连续打卡天数、注册时间、账号状态。openid直接作为唯一业务标识，主键id用于内部关联。

图书表（book_info）包含主键id、书名、作者、出版社、ISBN、封面图URL、分类、简介、总页数、状态（上架/下架）、创建时间。图书数据建议支持批量导入，所以表结构上要预留好唯一索引，我的做法是对ISBN建立唯一索引，用来做去重判断。

书架表（user_shelf）本质上是用户和图书的多对多关联表，记录用户把书放入了哪个分类（想读，在读，已读完）、加入时间、开始阅读时间。这张表在统计用户阅读偏好时非常关键。

打卡表（read_record）是业务核心中的核心。字段包括主键id、用户id、图书id、打卡日期、阅读时长（分钟）、阅读页数、读书笔记、打卡时间、关联的书架记录id。这里有一个很关键的逻辑：打卡日期和打卡时间要拆分，因为连续打卡天数的计算依据是“打卡日期”，而打卡时间只是流水记录。

辅助表包括公告表（notice_info）、反馈表（feedback_info）和管理员表（sys_admin）。

设计表的外键关系时，建议逻辑外键而不是物理外键。也就是说，在实体类中保留userId、bookId这些关联字段，但不建数据库级的外键约束。原因很简单，毕设阶段改表结构非常频繁，物理外键会让删改数据的代价成倍增加，逻辑外键配合查询时的JOIN或回表，效果一样但对开发友好得多。

2.2 连续打卡天数的核心算法实现

连续打卡天数这个功能，看起来简单，但实现起来有几个坑。第一个坑是“自然日”和“活跃日”的关系，第二个坑是时区问题，第三个坑是如何处理今天没打卡但昨天有打卡的情况。

我的实现方式是这样的：在用户表中维护一个lastCheckDate字段记录最近一次打卡日期，再维护一个continuousDays字段记录连续打卡天数。打卡时执行如下判断逻辑：

• 如果今天是第一次打卡：continuousDays = 1
• 如果lastCheckDate是昨天：continuousDays + 1
• 如果lastCheckDate是今天：说明重复打卡，提示用户今天已经打过卡
• 如果lastCheckDate既不是今天也不是昨天：产生中断，continuousDays = 1

这个逻辑虽然用三个字段就搞定了，但要注意“昨天”这个概念。如果直接拿LocalDate.now()减一天，在晚上23点到零点之间可能会出问题。我的做法是在后端统一使用服务器时间，并且接口请求中带上当前日期字符串作为参数，防止用户手机本地时间和服务器时间不一致导致的判断错误。

另外，要考虑“补卡”这个扩展需求。很多同学做这个功能时，导师会问：“如果我昨天忘了打卡，今天能补吗？”如果要做补卡，就不能只靠两个字段了，而是需要一张独立的打卡日历表，记录每一天的打卡状态，连续天数通过查表计算。做毕设时建议把打卡记录表设计得正规一点，多加一个年月字段和当月打卡状态快照，后面做月度日历视图会非常省事。

2.3 图书数据从哪来？数据初始化方案

毕设最怕的就是打开系统，里面空荡荡一片，演示效果大打折扣。图书数据的初始化，一般有几个方案。

第一个方案是手工录入，适合图书量较少（20本以内）的场景，优点是质量可控，缺点是累。第二个方案是通过爬虫采集公开书城的图书数据，这个我不太建议，一方面是合规风险，另一方面爬下来的数据需要大量清洗。第三个方案是使用公开的图书API，例如一些开放的书目数据接口，返回JSON格式的数据后写个脚本批量导入数据库。

实操中我建议用一个折中方案：主数据用手工录入加Excel批量导入，封面图使用线上图片URL而不是本地存储。这样既控制了数据质量，又不至于把项目体积弄得太大。另外启动数据初始化时，写一个CommandLineRunner，当图书表为空时自动插入一批预设图书，这样项目clone下来跑起来就有数据可用，这个细节在答辩演示时非常加分。

3. 后端Spring Boot核心接口设计与实现

3.1 项目初始化与基础架构搭建

后端项目建议直接用Spring Boot 2.7.x版本，Java 8或11，Maven管理依赖。导入依赖时核心用这几个：spring-boot-starter-web撑起Web层、mybatis-plus-boot-starter做ORM和分页、mysql-connector-java支持数据库连接、lombok减少样板代码、jwt工具库处理登录状态（这里用Java的jjwt或hutool的JWT工具都行）、hutool-all做通用工具集。

项目结构按业务分包，不要按技术层次分包。我推荐这种分包方式：

com.example.readbook ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 数据库实体 ├── dto // 请求参数封装 ├── vo // 响应结果封装 ├── config // 配置类 ├── common // 通用工具，统一返回结果、异常处理等 └── interceptor // 拦截器

controller目录下再按业务模块分包，比如user包、book包、record包、admin包。这样横向和纵向都是一目了然的，答辩时讲项目的代码结构会很轻松。

统一返回结果类我建议一定提前写好，否则后面每个接口的返回值都是零散的Map，一处改了处处要改。我的写法是定义一个通用的R类，里面包含code、msg、data三个字段，提供ok()方法和fail()方法。这样前端拿数据时统一从data字段取，后端的错误信息也能统一从前端弹窗展示。

3.2 用户登录和Token鉴权实现

小程序的登录流程和传统Web登录不太一样。传统Web是用户名密码登录，小程序要依赖微信的登录凭证。核心流程是：小程序调用wx.login()拿到code，发送到后端；后端拿着code去微信的接口服务交换openid和session_key；后端用openid去查询用户表，如果查不到就自动注册新用户；最后生成一个自定义登录态Token返回给小程序。小程序后续的所有请求都带上这个Token，后端通过拦截器解析Token中的用户id。

Token我建议用JWT方式实现。JWT的payload中可以携带userId和openid，生成之后设置一个过期时间。这里要重点注意一个问题：小程序端的Token不能和传统Web端一样简单存到localStorage，而是要用wx.setStorageSync，每次请求在header中手动带上。

拦截器中需要放行登录和注册接口，其他所有接口都要校验Token。校验失败时返回401状态码，小程序端收到401后统一跳转到登录页。这是我见过最容易遗漏的环节，很多同学接口都写好了，但忘了加拦截器，结果前端页面上所有接口都是裸奔状态，答辩时被问到防越权就答不上来了。

3.3 打卡接口的核心代码实现

打卡接口是系统的核心，需要同时保证业务正确性和并发安全性。前端传过来的参数是：bookId、readDate、readMinutes、readPages、note。后端要做的事包括：校验用户是否把这本书加入了书架，写入打卡记录，更新用户累计阅读时长和连续打卡天数，更新书架状态。

核心代码如下：

@PostMapping("/checkin") public R doCheckin(@RequestBody @Valid CheckinDTO dto, @RequestAttr Long userId) { // 1. 校验书架记录是否存在 UserShelf shelf = shelfMapper.selectOne( new LambdaQueryWrapper<UserShelf>() .eq(UserShelf::getUserId, userId) .eq(UserShelf::getBookId, dto.getBookId())); if (shelf == null) { return R.fail("请先将图书加入书架"); } // 2. 校验今天是否已打卡 String today = LocalDate.now().toString(); Long count = recordMapper.selectCount( new LambdaQueryWrapper<ReadRecord>() .eq(ReadRecord::getUserId, userId) .eq(ReadRecord::getCheckDate, today) .eq(ReadRecord::getBookId, dto.getBookId())); if (count > 0) { return R.fail("这本书今天已经打过卡了"); } // 3. 插入打卡记录 ReadRecord record = new ReadRecord(); record.setUserId(userId); record.setBookId(dto.getBookId()); record.setCheckDate(today); record.setReadMinutes(dto.getReadMinutes()); record.setReadPages(dto.getReadPages()); record.setNote(dto.getNote()); recordMapper.insert(record); // 4. 更新用户的连续打卡天数和累计时长 updateUserCheckData(userId, today); return R.ok(); }

这里每一步都做了边界条件判断，接口的幂等性也保证了——同一个人同一天同一本书重复提交会被拦截。这是很多线上项目真正会发生的问题，写进毕设里也算是对“业务理解到位”的一种体现。

3.4 统计功能的接口实现

统计接口是阅读打卡的“面子工程”，也是答辩时演示效果好不好的关键。我的统计接口包含这样几个维度：今日打卡人数、累计注册用户数、累计打卡次数、图书总数、本周打卡趋势（7天的折线数据）、用户阅读时长分布（柱状图数据）、热门图书排行（Top 10）。

SQL层面，热门图书排行是最有含金量的部分：

List<Map<String, Object>> hotBooks = recordMapper.selectMaps( new QueryWrapper<ReadRecord>() .select("book_id, COUNT(*) as check_count, SUM(READ_MINUTES) as total_minutes") .groupBy("book_id") .orderByDesc("check_count") .last("LIMIT 10"));

拿到bookId列表后，再查一次图书表做回填，补上书名、封面和作者信息。这里不要用循环去查，直接用selectBatchIds一次性查出所有图书信息。这个小优化在答辩时讲出来，导师会认为你考虑到了性能问题。

周趋势图的数据需要的是7天日期和每天的打卡数量，可以用group by check_date来实现，但要注意补全没有打卡数据的日期（填充0），不然前端图表会缺位。我习惯在后端把7天的数据补成一个完整数组再返回，前端直接渲染，这种后端处理好的数据结构对小程序端特别友好。

4. 小程序端核心页面实现与前后端联调

4.1 小程序页面架构与请求封装

小程序的页面结构大致是：首页（展示推荐图书、公告、今日打卡入口）、书架页（在读和想读的Tab切换）、统计页（打卡日历和图表）、我的页面（个人信息和设置入口）。由于小程序原生框架不支持全局状态管理，我建议用简单的全局数据缓存来存放用户信息，或者用一个简单的全局app.js存储登录状态。

请求封装是整个小程序端的核心工程。原生小程序的wx.request功能薄弱，响应拦截、错误提示、Token注入都要手动处理。我的做法是封装一个http.js文件：

const BASE_URL = 'http://localhost:8080'; function request(url, method, data) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method: method, data: data, header: { 'Content-Type': 'application/json', 'Authorization': 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) { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(res.data); return; } resolve(res.data.data); }, fail: (err) => { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); }

这个方法在Promise里包了一层wx.request，统一处理了Token注入、过期跳转和错误提示。每个页面只需要调用http.get('/book/list')就能拿到后端返回的数据，写起业务来很干净。很多同学的小程序端就是单个页面一个wx.request，代码堆得到处重复，答辩时被问到“代码复用性”就很被动。

4.2 打卡页面的交互实现与注意事项

打卡页面是整个小程序的业务核心。用户从小程序首页或者书架页进入某本图书的详情页后，点击“开始打卡”按钮，会弹出一个半屏面板，上面有三个输入项：阅读时长（默认30分钟，可以调节）、本次阅读页码段、读书笔记（textarea）。

提交时先做前端校验：时长不能为0，页码格式不能错。这里的交互上有一个很重要的点：提交成功后要给用户一个强烈的反馈，比如显示一个打勾动画或者“打卡成功，已连续X天”的提示。这种即时正反馈会让用户有继续打卡的动力，放在产品设计里叫“游戏化”。放在毕设答辩里讲，导师会觉得你有产品思维。

一个比较隐蔽的坑：小程序页面在打卡成功之后，如果直接返回上一页，前一页的统计数据不会自动刷新。需要在打卡成功时用wx.navigateBack配合getOpenerEventChannel把最新数据传回去，或者在返回页面的onShow中重新拉取统计接口。

我统一习惯是onShow刷新数据，虽然多写几个请求，但对毕设项目来说响应速度没有压力，代码逻辑反而简单很多。

4.3 统计页面的图表展示方案

统计页面用到的图表组件，不建议自己用canvas手写，虽然能把代码量撑起来，但性价比太低。我建议直接使用开源的图表库。在小程序里比较成熟的是ucharts（或者叫qiun-data-charts），它基于canvas渲染，用起来像ECharts，性能在小程序上还不错。

引入之后，柱状图、折线图、饼图都能配置出来。我的统计页展示了三个图：最近7天阅读时长柱状图、书籍分类阅读占比饼图、月度打卡日历热力图。前两个直接用ucharts的demo改配置就行，热力图比较冷门，我建议用简单的方式做一个日历格子面板，统计打卡天数时画上不同颜色的点，一样能出效果。

图表的数据格式要在后端就处理好。比如7天阅读时长，后端返回的数组是[{date: '2024-05-13', minutes: 30}, {date: '2024-05-14', minutes: 45}, ...]，前端拿到后转换成[30, 45, ...]填入柱状图。这些数据格式的约定，要在联调之前就定义好，不要边调边改，否则会被前后端联调拖死。

5. 常见问题总结与排查方法

5.1 高频报错问题速查表

我梳理了一套图书阅读打卡小程序开发和运行过程中最常见的问题，制成速查表，供你对照排查。

这一套问题在开发联调阶段几乎每次都会遇到。下面挑几个最常见的展开详细说。

5.2 小程序合法域名校验和本地调试方案

我第一次带同学做小程序时，最常见的问题就是：后端接口明明在浏览器里都能访问，结果小程序里一请求就报域名不合法。微信小程序的开发者工具里有一项校验，要求所有请求的域名必须是在小程序后台配置过的HTTPS合法域名，但是把localhost或者局域网IP算进来的。而对于本地开发，解决的方案是开发阶段直接跳过校验。

打开微信开发者工具，点击右上角的“详情”，找到“本地设置”，勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”。勾选之后，localhost和局域网IP都能正常请求。

有一个更麻烦的场景：如果小程序跑在真机上调试，不校验域名这个选项是不生效的，因为真机上的微信客户端不会绕过这个限制。此时需要将电脑和手机连在同一个局域网，后端启动后监听0.0.0.0，手机端在小程序工具里的“预览”二维码就能扫码调试，但此时也需要在后端配置中把请求URL改成电脑的局域网IP。这个过程比较繁琐，我一般建议同学们先开发完，最后等部署时再用正式域名调试真机。

还有一个细节：如果你启用了Spring Boot的跨域配置，大概率会导致小程序请求失败。因为小程序的请求不同于浏览器，它不存在跨域问题，不需要CORS配置。但如果在后端加了允许跨域并允许Authorization头，并不影响小程序正常访问。关键是不要在小程序端使用withCredentials: true，小程序原生并不支持这个属性，写了反而会报错。

5.3 部署上线时的常见坑

后端打包部署算是毕设里最容易出问题的环节之一。本地跑得好好的，部署到服务器上就各种报错。最常见的是数据库连不上，此时要检查服务器的防火墙、云服务商的安全组是否放行了3306端口。还有一类问题是打包后JAR包启动时找不到主类，这种通常是maven打包插件配置不对，检查pom.xml里是否用了spring-boot-maven-plugin，并确保repackage阶段没被跳过。

部署的姿势也有讲究。低配服务器直接java -jar也没问题，但如果服务器只有512M内存，Spring Boot启动时极慢甚至直接OOM，建议优化启动参数：

nohup java -Xms128m -Xmx256m -jar readbook.jar > run.log 2>&1 &

同时把MySQL的配置精简一下，去掉不必要的缓存查询。不过坦白讲，如果条件允许，我还是建议直接租一台2核4G的服务器来部署，毕设演示期间的体验会好很多。对于只做本地演示的同学，点开IDEA跑一个Spring Boot，再开微信开发者工具看小程序，效果已经很不错了。

6. 从源码到文档：毕设材料打包与答辩准备

6.1 毕业论文的结构与写作建议

代码写完了，很多精力放在文档上，尤其是毕业论文。论文的结构要尽量正统，不能写成博客体。常见的章节划分是：绪论（背景与意义、国内外现状、研究内容与方法）、相关技术介绍、系统分析（可行性分析、需求分析）、系统设计（总体架构、功能模块设计、数据库设计、接口设计）、系统实现（页面截图加代码片段加逻辑描述）、系统测试（测试计划、测试用例、测试结果）、总结与展望。

写文档的时候一定要注意，截图的质量能直接影响答辩印象。每一个功能页面，务必将窗口背景调成统一风格再截图，不要桌面上开着乱七八糟的东西。截图上方加一个标注说明“图6-1 用户登录页面”之类的编号，这个细节非常加分。

代码部分的展示不要贴大段完整代码，而是贴核心方法、关键业务逻辑，加上旁边注释说明。导师通常没有耐心看几百行代码，你的核心设计思路要在页面截图和简短的代码片段中体现出来。

6.2 答辩时必问的高频问题

答辩过程中，导师的问题往往集中在技术选型原因、数据库设计原因、核心功能实现方式几个方面。提前准备一些“为什么”的答案，比临时发挥要稳妥得多。

例如：“为什么选Spring Boot而不用SSH？”回答思路是：Spring Boot简化了配置，提高了开发效率，且生态成熟、资料丰富。在毕设场景里，选型理由是技术选型分析这一节的核心。

再例如：“连续打卡天数是怎么计算的？”这个问题只要在答辩前自己理一遍逻辑，照着代码讲就能过关。如果真被问到“跨零点怎么处理”，回答清晰一点：打卡时先从数据库查最近打卡日期，在代码里做日期差判断，而不是依赖数据库的定时任务。这里要注意，在自己代码没有特殊处理跨天问题的情况下，要诚实说明当前方案的限制，如果提前补上“日期差判断”这个处理，就没什么问题了。

关于数据库设计的问题往往是最细的，答辩前务必把所有表结构、字段含义、索引设计都再过一遍。特别是图书表和打卡表的字段设计，导师很喜欢问为什么不加外键、为什么用逻辑外键，这就要回到之前说的可扩展性、删除方便性的思路上来。

6.3 源码交付与代码讲解的实用建议

对于需要提交源码和相关文档的同学，建议将所有材料组织成固定的目录结构：一个README.md（说明项目简介、技术栈、启动步骤）、一个sql目录（放建库建表脚本和初始化数据）、一个code目录（后端和小程序代码）、一个docs目录（毕业论文、任务书、答辩PPT）。这样看起来非常规范，也方便别人快速起项目。

代码讲解方面，建议录制成视频，每隔5-10分钟讲一个模块。这个材料在答辩时并不一定要放给老师听，但通过录视频的方式，你会被迫把每个模块的逻辑串起来梳理一遍，这个过程本身就是一次很有效的复习。我在给同学做代码讲解时也发现，能把这个模块讲清楚的同学，答辩时被问倒的概率会大幅降低。

7. 个人实践中的心得体会

我在带同学们做这个阅读打卡项目时，最大的体会是：这个项目的完成度不在于代码量多少，而在于“闭环”是否到位。所谓闭环，就是你注册登录、选书、打卡、看统计、再看排行榜，整个流程自己能顺畅走下来，没有一步是断掉的。很多同学代码写了一堆，结果自己登录进去后连一本书都加不上，就是闭环没打通。

另外一个强烈建议是：iOS和安卓真机调试是不同的，安卓的预览二维码在微信开发者工具里很容易扫开，苹果手机用预览需要先配置AppID，如果没有AppID，可以直接用测试号跑预览。这一点要提前验证，不要等到答辩当天才去联调。

图书数据初始化这批内容，看着不起眼但价值极高。有一次我带同学现场演示，小程序一打开，书架是空的、图书列表只有两条、统计图表都是零数据，整个答辩效果一下子就冷掉了。后来我改了策略，在数据库初始化脚本里放上大约30本图书，分类覆盖文学、科技、历史、经济、心理这几个领域，再预设一个测试账号带有连续15天的打卡记录。这样每次打开系统，首页有推荐图书，统计页有完整图表，书架上有在读书籍，整个演示效果是饱满的，导师看了也会觉得你做得很用心。

最后再分享一个小技巧：在打卡接口返回的数据里，除了返回打卡成功状态，最好一并返回用户当前的连续打卡天数和累计阅读时长。前端收到这两个数据后直接在页面上展示出来，用户看到“已连续打卡多少天”的正反馈会非常强烈。我在实际使用中发现，这种即时可见的激励会对产品的留存率产生很大影响。放在答辩里讲，也能体现出你对用户体验和数据分析有深入的思考。