简介：这是一份面向小程序毕业设计/课程设计的完整睡眠检测项目源码包，适用于计算机相关专业学生、初学小程序开发者及需要快速搭建课设方案的人群。项目功能覆盖睡眠音乐播放与自动关闭、心情和睡眠质量选择、按日期统计睡眠次数及时长的数据记录、知识问答与个人资料维护，并提供Java/PHP后端、MySQL数据库、uniapp/原生小程序前端等环境的配置说明。压缩包共110个文件，大小约14.63MB，其中js逻辑、json配置、wxss/wxml页面文件支撑核心功能，png图片与mp4视频用于界面素材和演示参考，另含doc/docx说明文档及开题报告，可直接配合论文撰写。目前已有170人学习，从选题论证、系统设计到代码运行与论文写作均有对应材料，适合作为毕业设计或课程设计的完整体验参考。
1. 睡眠检测小程序源码：毕设选题里最不容易翻车的那类
睡眠检测小程序是典型的毕业设计选题：技术栈主流，数据链路完整，演示效果好。源码包里通常配齐了小程序前端、后端接口、MySQL 建表脚本，外加说明文档和 LW（论文）配套，拿到的第一反应是“东西挺全”，但真正能派上用场的核心只有三件事：把数据链路讲清楚，把评分逻辑改明白，把演示数据准备到位。这类源码包我拆过几个，结构大同小异，踩过的坑也比较集中。下面按“先立数据模型，再打通接口，最后做界面和评分”的顺序展开，适合选了这个题、又不想从零写代码的开发者照着改。
2. 把数据模型立住：整体架构与 MySQL 建表脚本
开工先别急着写页面。睡眠检测这个题目，数据链路比界面重要得多，答辩时评委问得最多的也是“记录怎么存、怎么查、怎么算”，而不是“你的按钮好不好看”。所以先把架构和表结构定下来，后面所有代码都围绕这张表展开，不返工。
2.1 三层架构各管一摊：前端、后端、数据库的边界
常见做法是拆三层：小程序端只负责录入和展示，后端负责校验、评分和取数，MySQL 负责持久化。小程序端通过 wx.request 调用后端 API，后端再用 SQL 读写数据库，查询结果一路返回给前端渲染。这条链路看起来简单，但每一层都有一个容易敷衍过去的点：前端容易把请求逻辑散在页面里，后端容易忽略时间序列化，数据库容易把表设计成“能存但没法统计”。
| 层次 | 职责 | 开发时重点关注 |
|---|---|---|
| 小程序端 | 录入睡眠数据、展示统计图表 | 请求封装、canvas 绘制、下拉刷新 |
| 后端 API | 接收上报、计算评分、返回列表与统计 | 跨天时长、参数校验、datetime 序列化 |
| MySQL | 用户表、睡眠记录表、索引 | 字段类型、联合索引、字符集 |
这里有个选型判断：为什么不用微信云开发或者 BaaS？云开发确实省事，但题目明确要求“完整前后端 + MySQL”时，答辩重点就是你在本地或者服务器上把 MySQL 真正跑起来，并把建表语句和 ER 图画进说明文档。用云开发等于主动放弃了一个得分点，不划算。
2.2 睡眠记录建表 SQL：字段这样设计才扛得住统计
睡眠记录表是核心，先把建表脚本给出。MySQL 5.7 和 8.0 都能跑，字符集统一用 utf8mb4，否则小程序端昵称里的表情符号会存不进去。
CREATE DATABASE IF NOT EXISTS sleep_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE sleep_db; CREATE TABLE user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, openid VARCHAR(64) NOT NULL UNIQUE COMMENT '小程序 openid', nickname VARCHAR(64) DEFAULT '' COMMENT '用户昵称', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB; CREATE TABLE sleep_record ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id INT UNSIGNED NOT NULL COMMENT '关联 user.id', sleep_date DATE NOT NULL COMMENT '归属日期，按入睡日算', bed_time DATETIME NOT NULL COMMENT '入睡时间', wake_time DATETIME NOT NULL COMMENT '醒来时间', deep_minutes INT UNSIGNED DEFAULT 0 COMMENT '深睡分钟数', light_minutes INT UNSIGNED DEFAULT 0 COMMENT '浅睡分钟数', rem_minutes INT UNSIGNED DEFAULT 0 COMMENT '快速眼动分钟数', awake_minutes INT UNSIGNED DEFAULT 0 COMMENT '夜间清醒分钟数', score TINYINT UNSIGNED DEFAULT 0 COMMENT '睡眠评分 0-100', source TINYINT DEFAULT 0 COMMENT '0 手动录入 1 模拟生成 2 硬件', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_date (user_id, sleep_date) ) ENGINE=InnoDB;几个字段设计上的决定值得说明。sleep_date 单独拆出来，而不是从 bed_time 取日期，是因为睡眠跨天太常见：23:30 入睡、次日 07:00 醒来，按入睡日归属更符合用户习惯，也方便按天聚合。score 冗余存储而不是每次现算，是因为列表页和统计页都要读它，存下来省一次计算，说明文档里也好解释“评分在写入时一次性算好”。source 字段是容易被忽略但答辩会问到的点：评委看到你的睡眠阶段数据，第一反应是“哪来的”，有 source 就能明确回答演示数据来自模拟生成，真实场景来自硬件上报。
联合索引 (user_id, sleep_date) 对应唯一一个高频查询：“查某个用户最近 N 天的记录”。在这个查询里 user_id 等值、sleep_date 范围，索引顺序必须把等值字段放前面。顺序反过来也能命中索引，但效率会差一些，这个细节写进论文的数据库设计章节是加分项。
提示：这里把深睡、浅睡、REM、清醒拆成四个整数字段，虽然录入时麻烦一点，但统计深睡占比、平均时长时可以直接 SUM 和 GROUP BY。如果存成 JSON 字符串，统计前要先解析，SQL 写起来绕一大圈，不划算。
2.3 为什么是 MySQL：选型理由与导入前的小检查
选 MySQL 不是因为它最先进，而是因为这个题目里它的解释成本最低。用户和睡眠记录是清晰的一对多关系，用外键和 JOIN 就能讲清楚；MySQL 的索引机制、事务特性都有成熟教材支撑，说明文档里可以写得很顺手。相比之下，用 JSON 文件或者 SQLite 虽然本地演示更简单，但答辩时很难展示“后端连接数据库”这条完整链路，属于自我减分。
导入脚本前有两个容易踩的检查点。第一，MySQL 8 默认的缓存认证插件和 5.7 不同，老版本的 pymysql 直连会报认证错误，常见解决方式是给连接用户指定 mysql_native_password 或升级 pymysql；后端代码里写连接配置时把 charset 显式写成 utf8mb4，避免乱码。第二，导入前先确认没有同名库，否则旧数据会混进来，导致演示时时间字段乱掉。我的习惯是先看一眼 MySQL 版本再决定连接参数，别急着执行 source 命令。
3. 后端 API 怎么写得让答辩问不倒：接口划分与两个易错细节
后端是整套系统的“中控”。睡眠检测的后端逻辑不复杂，复杂的是几个细节：跨天时间计算、评分到底在哪层算、查询结果返回给小程序时时间字段会不会炸。这一章把接口划分讲清楚，再给一个能跑的 Flask 最小实现，最后说两个最影响稳定性的细节。
3.1 接口划分与 Flask 最小启动：四个接口管住全部数据流
常见做法是拆四个接口，覆盖登录、上报、列表、统计四类操作。
| 接口 | 方法 | 入参 | 返回 |
|---|---|---|---|
| /api/user/login | POST | code | openid、user_id |
| /api/sleep/upload | POST | user_id、sleep_date、bed_time、wake_time、各阶段分钟数 | 写入结果与评分 |
| /api/sleep/list | GET | user_id、days | 最近 N 天睡眠记录 |
| /api/sleep/stats | GET | user_id、days | 平均时长、平均分、深睡占比 |
为什么用 Flask？因为它在毕设语境下最好讲：路由写法直观，ORM 可以不引入，直接用 pymysql 写 SQL 反而更能体现“你真的会数据库”。如果手头的源码包是 Spring Boot，对应关系也能一一映射，只是代码量更大。
from flask import Flask, request, jsonify import pymysql from datetime import datetime, timedelta app = Flask(__name__) DB_CONFIG = { 'host': '127.0.0.1', 'port': 3306, 'user': 'root', 'password': 'your_password_here', 'database': 'sleep_db', 'charset': 'utf8mb4', 'cursorclass': pymysql.cursors.DictCursor, } def get_db(): return pymysql.connect(**DB_CONFIG) @app.route('/api/sleep/list', methods=['GET']) def sleep_list(): user_id = request.args.get('user_id', type=int) days = request.args.get('days', default=7, type=int) if not user_id: return jsonify({'code': 400, 'msg': 'user_id is required'}), 400 since = datetime.now().date() - timedelta(days=days - 1) conn = get_db() try: with conn.cursor() as cur: cur.execute( "SELECT * FROM sleep_record WHERE user_id=%s AND sleep_date>=%s " "ORDER BY sleep_date DESC, bed_time DESC", (user_id, since) ) rows = cur.fetchall() return jsonify({'code': 0, 'data': rows}) finally: conn.close() if __name__ == '__main__': app.run(host='0.0.0.0', port=5000, debug=True)这里三个参数值得注意。host 设为 0.0.0.0 而不是 127.0.0.1，是为了让同一 WiFi 下的手机能访问到电脑；如果只在本机演示，127.0.0.1 也够用。days 的默认值取 7，对应小程序首页“最近一周”的展示场景。debug=True 只建议在开发阶段开，答辩演示时建议关掉，否则前端一旦触发异常，浏览器会弹出调试器页面，演示现场不好看。cursorclass 用 DictCursor，查询结果直接是字典列表，省去手动拼 JSON 的步骤。
3.2 上报接口与跨天时长计算：23:30 睡到 07:00 不能算成负数
上报接口是评分逻辑的入口。前端把用户填的入睡时间、醒来时间、各阶段分钟数 POST 上来，后端先校验必填字段，再算总时长，再调评分函数，最后写入数据库。这里最容易翻车的是跨天：23:30 入睡、次日 07:00 醒来，如果直接 wake_time - bed_time，结果是负的。写一个专门的时长函数处理这个场景。
from datetime import datetime def calc_duration(bed_time_str, wake_time_str): fmt = '%Y-%m-%d %H:%M:%S' bed = datetime.strptime(bed_time_str, fmt) wake = datetime.strptime(wake_time_str, fmt) if wake <= bed: wake = datetime(wake.year, wake.month, wake.day + 1, wake.hour, wake.minute, wake.second) return (wake - bed).total_seconds() / 60这里用的是“给 wake 日期加一天”而不是“加 24 小时”，两者在夏令时地区会有差别，国内没这个问题，但写对总没错。边界情况是 wake 比 bed 晚一天以上，比如用户录错把醒来时间填成了后天，这个由小程序端提交时做范围校验，后端只处理单日跨天。格式必须严格匹配 %Y-%m-%d %H:%M:%S，前端传 2025/06/01 这种格式 strptime 直接抛异常，这正是下一小节要说的校验问题。
上报接口的主体如下。注意先准备一个最小版评分函数，让接口能跑通，完整评分规则在最后一章再展开。
def compute_score(total_minutes, deep_minutes, awake_minutes, bed_hour): score = 60 if 420 <= total_minutes <= 540: score += 15 return max(0, min(100, score)) @app.route('/api/sleep/upload', methods=['POST']) def sleep_upload(): data = request.get_json(silent=True) or {} user_id = data.get('user_id') sleep_date = data.get('sleep_date') bed_time = data.get('bed_time') wake_time = data.get('wake_time') deep_minutes = int(data.get('deep_minutes', 0)) light_minutes = int(data.get('light_minutes', 0)) rem_minutes = int(data.get('rem_minutes', 0)) awake_minutes = int(data.get('awake_minutes', 0)) if not all([user_id, sleep_date, bed_time, wake_time]): return jsonify({'code': 400, 'msg': 'missing fields'}), 400 total_minutes = calc_duration(bed_time, wake_time) score = compute_score(total_minutes, deep_minutes, awake_minutes, int(bed_time[11:13])) conn = get_db() try: with conn.cursor() as cur: cur.execute( """ INSERT INTO sleep_record (user_id, sleep_date, bed_time, wake_time, deep_minutes, light_minutes, rem_minutes, awake_minutes, score, source) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s) """, (user_id, sleep_date, bed_time, wake_time, deep_minutes, light_minutes, rem_minutes, awake_minutes, score, 0) ) conn.commit() return jsonify({'code': 0, 'msg': 'ok', 'score': score}) finally: conn.close()int(bed_time[11:13]) 是把入睡时间字符串里的“小时”取出来传给评分函数，作为“是否早睡”的判据；这里直接对字符串做切片，格式一旦变就会踩坑，所以格式统一这件事必须在前后端约定好。source 写死 0，表示手动录入。总时长和各阶段分钟数之和如果明显对不上，比如总时长 480 分钟、四段加起来才 200 分钟，这种脏数据前端要拦住，后端可以在校验里加一个“四段之和不超过总时长 + 5 分钟”的判断，防止演示时出现明显不合理数据。
3.3 接口稳定性的两个细节：时间序列化与参数校验
第一个细节是 Flask 的 jsonify 序列化不了 datetime 对象。pymysql 的 DictCursor 把 DATETIME 字段原样返回，直接传给 jsonify 会报 TypeError: Object of type datetime is not JSON serializable，接口 500，前端拿到“网络异常”。旧版 Flask 里常见的解决方式是自定义 JSONEncoder，把 datetime 和 date 统一转成字符串。
from flask.json import JSONEncoder from datetime import datetime, date class CustomEncoder(JSONEncoder): def default(self, obj): if isinstance(obj, (datetime, date)): return obj.strftime('%Y-%m-%d %H:%M:%S') return super().default(obj) app.json_encoder = CustomEncoder注册这个编码器之后，所有接口返回的 datetime 字段会自动变成字符串，小程序端拿到后可以直接展示或格式化。新版 Flask 的 JSON 序列化机制换了一套，属性名不一样，但思路相同。不用自定义编码器的话，也可以在 SQL 里 DATE_FORMAT 格式化时间字段，缺点是每个查询都要写一遍，容易漏。
第二个细节是参数校验要做到“缺什么、错什么，直接告诉前端”。上报接口里必填字段缺失要返回 400；阶段分钟数要按 int 解析，解析失败就 400；评分结果要做 0-100 截断，避免出现 115 分这种一眼假的数字。校验逻辑放在后端而不是前端，是因为前端校验可以被绕过，而后端是数据入口的最后一道闸门。答辩时被问到“如果小程序崩溃了，数据会丢吗”，答“写入操作有事务，读取操作无状态，接口可以重试”就比“不知道”强很多。
4. 小程序前端把睡眠数据画成界面：请求封装与 canvas 阶段条
前端这部分的目标很明确：打开首页看到最近一周的评分和时长，点录入页填数据，提交后回来能刷新出新记录。界面不用多花哨，但请求不能散、图表不能糊、演示时不能白屏。
4.1 页面与请求封装：wx.request 不该散落在每个页面
常见做法是新建 utils/request.js，把 BASE_URL、请求头、错误处理统一封装成一个 Promise 方法，页面里只管调用。别在 onLoad 里直接写 wx.request，否则后期想统一加 token、换域名、改错误提示，得改十几个页面。
const BASE_URL = 'http://127.0.0.1:5000'; function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method, data, header: { 'Content-Type': 'application/json' }, success(res) { if (res.data.code === 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }); reject(res.data); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); } module.exports = { request, BASE_URL };这里把协议约定也一并落下了：后端返回体统一是 { code, msg, data }，code 为 0 表示成功。这样前端判断逻辑只有一处，后端返回错误时页面自动弹 toast，不用每个页面重复写。BASE_URL 导出是为了后面真机联调时统一改 IP 用，演示阶段 127.0.0.1 只在开发者工具里有效，这个问题下一章会细讲。
页面结构一般三页：首页展示最近一周的概览，录入页提交一条新记录，统计页看趋势。首页 onLoad 时拉列表数据，录入页提交成功后回首页并触发刷新。如果没做登录，user_id 先写死为 1，等接微信登录后再替换。
4.2 canvas 画睡眠阶段条：不引第三方库也能出图
睡眠阶段条是首页最直观的展示：一条横条分四段，分别表示深睡、浅睡、REM、清醒。很多源码包会引入 echarts 的小程序版，但阶段条这种简单图形用 canvas 就够了，不用多背一个库，加载也更快。关键是选对 canvas 接口：现在用 type="2d" 的写法，别用已经废弃的 wx.createCanvasContext。
<canvas type="2d" id="stageCanvas" style="width: 100%; height: 120rpx;"></canvas>function drawStageBar(deep, light, rem, awake) { const query = wx.createSelectorQuery(); query.select('#stageCanvas').fields({ node: true, size: true }).exec((res) => { if (!res[0] || !res[0].node) return; const canvas = res[0].node; const ctx = canvas.getContext('2d'); const dpr = wx.getSystemInfoSync().pixelRatio; canvas.width = res[0].width * dpr; canvas.height = res[0].height * dpr; ctx.scale(dpr, dpr); const width = res[0].width; const height = res[0].height; const total = deep + light + rem + awake; if (total <= 0) return; const colors = ['#3B82F6', '#93C5FD', '#22C55E', '#F59E0B']; const segments = [deep, light, rem, awake]; let x = 0; segments.forEach((val, i) => { const w = (val / total) * width; ctx.fillStyle = colors[i]; ctx.fillRect(x, 0, w, height); x += w; ctx.fillStyle = '#334155'; ctx.font = '10px sans-serif'; ctx.textAlign = 'center'; ctx.fillText(String(Math.round(val / total * 100)) + '%', x - w / 2, height / 2 + 4); }); }); }最容易被忽略的一行是 dpr 缩放：canvas.width 必须乘设备像素比，否则真机上文字虚、色块边缘糊。ctx.scale(dpr, dpr) 之后，后续绘制坐标仍然按 css 像素写，不用自己换算。文字画在色块中间，x 用 x - w / 2 回退到当前段起点加一半，比画在段头部更居中。如果某段比例太小，比如清醒只有 2%，文字会叠到相邻段上，这种情况可以加一个最小宽度判断，小于 8px 就不画文字。
4.3 加载、下拉刷新与空态：演示时保证页面不白屏
数据请求是异步的，页面启动瞬间拿不到数据就一定得加载态。现在小程序的页面生命周期里，onLoad 拉数据、onPullDownRefresh 手动刷新是标准组合。
Page({ data: { records: [], loading: true }, onLoad() { this.fetchData(); }, onPullDownRefresh() { this.fetchData().then(() => wx.stopPullDownRefresh()); }, fetchData() { this.setData({ loading: true }); return request('/api/sleep/list?user_id=1&days=7') .then((data) => this.setData({ records: data, loading: false })) .catch(() => this.setData({ loading: false })); } });loading 状态配合 wx.showLoading 或者直接在页面里渲染骨架屏；演示时最怕的是“白屏两秒后突然出图”，看起来像卡死。更稳的做法是首页先渲染缓存里的上次数据，再在后台刷新。空态也要处理：数据库里一条记录都没有时，页面不能只显示一个空白 canvas，得有一句“暂无睡眠记录，去录入一条吧”。这类细节不影响功能，但影响答辩观感。录入页提交成功后，返回首页要在 onShow 里重新拉数据，而不是依赖首页 onLoad——因为首页可能还挂在页面栈里，onLoad 不会再次触发。
5. 睡眠检测小程序避坑指南：五个高频翻车点
以下五个坑是我顺着这个标题最常见的翻车场景，有环境问题、有代码问题、也有演示策略问题。每一条都按“现象、原因、解决”拆开，前四条属于“照着做就不出事”，最后一条属于“不出事但答不上来”。
5.1 真机预览就报“网络异常”：域名白名单与局域网地址
现象：开发者工具里接口通，数据正常，一换到真机预览，页面弹出“网络异常”，什么都加载不出来。
原因：两个叠加。第一，127.0.0.1 在真机上指向手机自己，不是电脑；第二，小程序对 request 有合法域名校验，开发阶段虽然可以勾选跳过，真机上如果不勾选调试模式同样会被拦截。
解决：把 BASE_URL 从 127.0.0.1 改成电脑的局域网 IP。电脑上执行 ipconfig（Windows）或 ifconfig（macOS/Linux）查到 IPv4 地址，手机和电脑连同一个 WiFi，再把开发者工具详情面板里“不校验合法域名”勾上。如果部署到云服务器，就要在小程序管理后台配置 request 合法域名，要求域名备案且 HTTPS。我一般会先本机跑通，答辩前一周再挪到服务器，避免现场 WiFi 不稳。
5.2 后端 500：datetime 序列化直接报错
现象：接口在浏览器里访问正常，小程序端调用列表接口，返回 500，后端日志报 TypeError: Object of type datetime is not JSON serializable。
原因：pymysql 查出来的 DATETIME 字段是 datetime 对象，Flask 的 jsonify 默认处理不了，直接抛异常。很多第一次做前后端分离的开发者会在前端看到“网络异常”，误以为是跨域或者网络问题，排查半天。
解决：按第3章 3.3 的方案注册自定义 JSONEncoder，把 datetime 统一转成字符串。注册之后所有接口一劳永逸，比在 SQL 里 DATE_FORMAT 逐个字段处理更省事。改完记得重启 Flask，别改了代码不重启就测试，这种“没生效”的幻觉很常见。
5.3 睡眠时长显示负数：跨天逻辑没做
现象：录入 23:30 入睡、次日 07:00 醒来，列表页显示“-16.5 小时”。
原因：总时长用 wake_time - bed_time 直接算，没有处理跨天。wake_time 比 bed_time 数值小，结果就是负数。
解决：在时长计算函数里加判断，wake <= bed 时把 wake 的日期加一天再减。这一步放在后端统一处理更稳，前端不要自己算时长，也不要在 SQL 里用 TIMESTAMPDIFF 裸算。注意边界：wake 恰好等于 bed 时按跨一天处理，也就是“睡满了 24 小时”，虽然这种录入数据本身可疑，但至少不会算成 0。前端提交时对入睡和醒来的时间间隔做个范围校验，超过 24 小时直接提示。
5.4 canvas 在真机上模糊或被截断：像素比忘乘了
现象：开发者工具里阶段条清晰、颜色正常，真机上色块边缘发虚，右侧明显多出一截或者少了一截。
原因：canvas 的绘制尺寸和展示尺寸不一致。type="2d" 的 canvas 需要自己按设备像素比设置 node 的宽高，忘乘 dpr，图形就会被拉伸，看起来糊；宽度取错则整条画出去。
解决：用 wx.createSelectorQuery 拿到节点实际宽高后，canvas.width = 宽 * dpr，canvas.height = 高 * dpr，然后 ctx.scale(dpr, dpr)。后面 fillRect 的坐标按 css 尺寸写，逻辑和开发者工具一致。还有一个连带坑：canvas 的 id 必须是唯一的，页面里有多个 canvas 时选择器会串，给每个画布单独命名即可。
5.5 评委追问“数据哪来的”：演示数据要能自圆其说
现象：演示很顺利，界面很好看，评委一句“这些深睡浅睡数据是怎么采集的”，回答不上来，场面安静了两秒。
原因：源码包里跑的是模拟数据，没有交代来源。睡眠阶段不是靠小程序本身能测出来的，如果不说清数据是模拟生成的，评委会默认你声称自己做了硬件采集，这是诚信问题。
解决：在说明文档里单独开一节“数据来源说明”，明确写“演示数据由模拟生成器按规则产出，真实场景通过手环等硬件 SDK 上报；上报接口预留 source 字段区分数据来源”。答辩时主动说“为了演示方便，当前数据是模拟的，接入 SDK 时替换上报端即可”。把这个说在前头，评委就不会追着问。source 字段在表里已经预留，接口也支持按 source 过滤，这一套说辞是可验证的，不是糊弄。
6. 把评分规则改成你自己的：一个能讲清楚依据的调参技巧
第3章里那个最小评分函数只算了“时长是否在 7-9 小时区间”，作为跑通接口没问题，但答辩时评委大概率会问“评分依据是什么”。这时候回答“参考通用睡眠时长建议，结合深睡比例、夜间清醒时长、入睡时刻加权”就够了。把评分逻辑做成一个独立函数，参数全部集中在函数头，方便调。
def compute_score(total_minutes, deep_minutes, awake_minutes, bed_hour): score = 60 if 420 <= total_minutes <= 540: score += 15 elif total_minutes < 300: score -= 15 deep_ratio = deep_minutes / total_minutes if total_minutes else 0 if deep_ratio >= 0.2: score += 10 elif deep_ratio < 0.1: score -= 10 if awake_minutes <= 30: score += 10 elif awake_minutes > 60: score -= 10 if bed_hour >= 23 or 0 <= bed_hour < 2: score += 5 return max(0, min(100, score))调参有个技巧：先用生成器造 20 条模拟记录，把每条的总时长、深睡比例、清醒分钟、入睡时刻、最终分数打出来，人工逐条看图判断“这个分合理吗”。如果某条明明睡得很短却因为清醒少拿了高分，就调整对应档位的分值。这里的阈值不是医学标准，是演示逻辑，写进说明文档时如实写“参考值”而不是“临床标准”。
验证方法也很简单：造三类极端数据——睡 5 小时但深睡占比很高、睡 9 小时但夜间醒 90 分钟、凌晨 4 点入睡睡 8 小时，分别看分数是否符合直觉。评分这事带点玄学成分，但只要参数能解释，答辩就能站稳。我早期做这类项目的时候，总想把评分模型做得复杂一点，后来发现评委问得最多的是数据链路的完整性，评分逻辑只要自洽、能讲清依据就够了。把评分函数收敛成一个独立的纯函数，改参数只看函数头，这个习惯希望帮到你。
本文还有配套的精品资源，点击获取
