企业官网建设流程全解析

每逢毕业季，计算机专业的同学都会陷入一场"毕设大战"。选题要新、技术栈要全、工作量要够、导师要满意，还得在有限时间里真正把系统跑起来。我见过太多人栽在"论文写完了代码跑不起来"或者"代码能跑但答辩一问三不知"这两种情况上。如果你正为毕设选题发愁，或者已经选了一个感觉撑不起内容量的题目，今天这篇关于基于微信小程序的心血管疾病风险预测小程序的项目拆解，可能会帮你打开思路。

这个选题最吸引人的地方在于，它天然就是一个"小而全"的完整系统：前端是微信小程序，用户填写健康信息就能得到心血管疾病风险评级；后端要有接口、有数据库、有算法逻辑；再加上用户管理、历史记录、健康建议这些常规模块，工作量直接覆盖了毕设要求的大部分维度。而且它具备真实的应用场景和社会价值，"健康中国"背景下心血管疾病防控本来就是热点方向，无论是开题答辩还是最终答辩，都有足够的立意可以讲。

这篇文章我会把这个项目的完整设计思路、技术选型、核心算法逻辑、实操步骤、常见坑点和答辩注意事项全部拆开讲透，适合正在做类似选题（健康类小程序、预测类系统、前后端分离项目）的同学参考。不光是"怎么做"，更会讲清楚"为什么这么做"，让你拿到手后能真正吃透项目，而不是只会按文档机械操作。

1. 项目整体设计与技术选型

1.1 为什么"心血管疾病风险预测"适合作为毕设选题

先说选题逻辑。一个合格的毕设题目，至少要满足三个条件：有明确的应用场景、有足够的技术工作量、有可以展开论述的研究点。心血管疾病风险预测恰好三点全占。

从应用场景看，心血管疾病是全球范围内的头号死因，高血压、高血脂、糖尿病、吸烟、肥胖这些都是公众熟知的危险因素。但大众认知往往停留在"知道这些因素有害"的层面，并不清楚自己到底处于什么风险水平。小程序这种轻量化的工具，天然适合做健康自测——用户打开微信扫一扫就能用，不需要下载App，填完问卷立刻出结果，这种"低门槛、即时反馈"的体验是网页端和原生App都比不了的。从毕设答辩的角度讲，你可以理直气壮地说"本系统旨在降低心血管疾病早期筛查的门槛"，这个立意在评委那里是站得住的。

从工作量看，这个题目覆盖了：小程序前端开发（页面布局、表单交互、数据可视化）、后端接口开发（用户体系、评估记录、健康建议）、数据库设计（用户表、评估记录表、风险因素表）、算法模型设计（风险评估规则）。四个维度各占一块，每一块都是计算机专业学生应该掌握的基本功，组合在一起就是一个完整闭环。导师看了会觉得"该有的都有"，你写论文的时候每一章也有内容可写，不会出现"第一章需求分析、第二章技术介绍、第三章就开始凑字数"的尴尬局面。

从扩展性看，这个题目可深可浅。基础版就是规则评分，把问卷调查结果代入公式算风险等级；进阶版可以引入机器学习模型（比如逻辑回归、随机森林），用公开数据集训练一个分类器；再往上还可以接入智能手环数据、生成PDF体检报告、做医生端后台。我见过不少同学答辩时被问"你的系统有什么亮点"，如果你能在基础功能之外加一两个这样的扩展点，回答的底气会完全不一样。

1.2 技术选型详细对比：原生框架还是uni-app

技术选型是很多同学第一个卡住的地方。微信小程序开发目前主流有两条路：微信官方原生框架和uni-app跨端框架。我做项目时这两套都试过，各自的优劣很清楚。

原生框架（WXML + WXSS + JS/TS + 微信开发者工具）的优点是：没有中间层，性能最好，调试最直接，微信最新的API能力能第一时间用上，社区资料也是最全的。缺点是只能跑在微信里，代码没法复用到其他平台。对于毕设来说，如果导师没有"多端适配"之类的硬性要求，原生框架其实是更稳妥的选择——毕竟你答辩时演示的场景就是微信里运行，原生框架出问题的概率最小，排查起来也最直接。

uni-app的优点是"一套代码，多端运行"，以后想发App或者H5版本都不用重写。但它有学习成本，而且调试的时候经常需要区分"这是小程序的问题还是uni-app框架的问题"，对新手来说排查难度会增加不少。我见过有同学用uni-app开发，结果一个样式问题在模拟器上正常、真机上错位，查了半天发现是框架编译层的兼容性坑，这种时间成本在毕设阶段是伤不起的。

另外还要提醒一点：做毕设选的工具链，尽量选自己熟悉的，不要为了追求潮流在毕设阶段学新技术。如果你之前没接触过小程序开发，直接上手原生框架，微信官方文档加社区案例足够你踩完所有基础的坑；如果导师明确要求用Spring Boot做后端，那就别纠结要不要换成Node.js——毕设的核心目标是"顺利完成"，不是"技术最潮"。

1.3 后端与数据库选型考量

后端这块，当前毕设圈的主流是Spring Boot，原因很简单：国内高校的Java课程普及率最高，Spring Boot又是当前企业级开发的事实标准，用Java写后端意味着你遇到任何报错都能在CSDN、Stack Overflow上找到答案，而且答辩时老师问"为什么选Spring Boot"，你可以从生态成熟、社区活跃、企业需求匹配等角度回答，基本不会被挑毛病。

如果你的Java基础比较薄弱，也可以考虑Python Flask或FastAPI。Flask的优点是代码量小、逻辑直观，五分钟能写一个接口，对毕设这种规模的系统完全够用。FastAPI的优点是自动生成接口文档，联调的时候特别方便。但要注意，Python后端在部分传统工科院校的答辩现场可能会遇到导师质疑："为什么不用Java？企业里用的多的是Spring Boot。"这不是技术问题，是答辩策略问题。所以选型之前，先搞清楚自己导师和答辩组的口味比较重要。

数据库没有悬念，MySQL。免费、稳定、资料多，Navicat或者命令行都能操作。规模上也不用考虑什么高并发、分库分表，就几张核心表，单机MySQL完全撑得住。ORM框架建议用MyBatis-Plus（如果是Java后端），它的代码生成器能直接从数据库表生成实体类和Mapper，省下的时间用来调前端页面，划得来。

1.4 系统功能结构与模块划分

一个完整的心血管疾病风险预测小程序，可以拆成用户端和管理端两块。用户端就是微信小程序本身，管理端可以做成Web页面，也可以先不做——毕设的核心在用户端，管理端属于加分项。

用户端的核心功能模块我列一下：

• 用户注册与登录：基于微信的wx.login静默登录，获取用户的openid作为唯一标识，不需要用户填用户名密码，体验最顺滑。用户第一次使用时要补充基本资料（性别、年龄、身高体重等）。
• 风险评估问卷：按多步表单设计，一步一步收集风险因素。包括年龄、性别、收缩压、舒张压、总胆固醇、是否吸烟、是否糖尿病、BMI等字段。字段不用一次全展示，分步骤填写体验更好。
• 风险结果显示：根据评估规则计算风险等级（低危/中危/高危），用可视化图表展示各风险因素的贡献度。可以用原生canvas绘制，也可以用echarts-for-weixin。
• 健康建议列表：根据风险因素自动匹配对应的健康建议。这一步其实是个简单的规则映射，但写论文时可以包装成"个性化健康干预方案生成"。
• 历史评估记录：用户可以查看以前填过的问卷和结果，并用折线图展示多次评估的分数变化趋势。
• 个人中心：用户资料修改、评估记录入口、关于系统等。

管理端建议做但可以简化。核心就三个功能：用户管理（查看注册用户列表）、评估数据统计（今天多少人次评估、风险等级分布饼图）、评估记录查看（后台看某条记录的详细风险因素）。别小看管理端，答辩的时候展示后台数据统计页，比展示小程序页面更有"系统感"，能直观证明前后端是打通的。

2. 核心细节解析与实操要点

2.1 风险评估算法设计：从医学模型到工程落地

这个项目最关键的部分就是风险预测算法。从论文角度看，这部分是你"研究内容"的核心；从答辩角度看，评委最可能追问的就是这里。

这里有一个非常关键的策略选择：不建议直接用"黑盒机器学习"模型，建议采用基于医学指南的评分卡方案。原因有三：第一，真正的机器学习模型需要训练数据，你没有真实患者数据，用公开数据集训练出来的模型在小程序场景下准确性和说服力都有问题；第二，黑盒模型无法给用户解释"为什么我是中危"，而评分卡方案每个因素的加分都是透明的，用户能看到年龄加了X分、血压加了Y分，体验上更可信；第三，评分卡方案有明确的医学依据（比如《中国心血管病预防指南》或Framingham风险评分框架），答辩的时候你可以引经据典，说"本系统参考了国际上通用的Framingham风险模型，结合中国人群特点做了简化调整"，这个回答的学术分量比"我用随机森林训练了一下"高出很多。

评分卡的核心设计可以按这个思路来：选定若干个独立的风险因素，每个因素划分几个档位，档位对应不同分值，总分映射到风险等级。比如：

• 年龄：35-44岁加0分，45-54岁加2分，55-64岁加3分，65岁以上加4分；
• 收缩压：<120mmHg加0分，120-129加1分，130-139加2分，140-159加3分，≥160加4分；
• 总胆固醇：<5.2mmol/L加0分，5.2-6.1加1分，≥6.2加2分；
• 吸烟：不吸烟加0分，吸烟加2分；
• 糖尿病：无加0分，有加3分；
• BMI：<24加0分，24-27.9加1分，≥28加2分。

总分0-4分为低危，5-9分为中危，10分及以上为高危。这个规则是我在Framingham模型基础上做的高度简化版本，毕设场景完全够用。你完全可以在此基础上调整阈值的划分，但核心原则一定要保证：规则可解释、总分可计算、等级有区分度。如果所有用户测出来都集中在同一个等级，说明你的分档阈值设计有问题，需要重新调。

2.2 评分计算模块的代码落地

评分计算的代码逻辑其实很直观，核心就是一堆条件判断。我建议把这部分单独抽成一个工具模块，不要在页面的onSubmit里写一堆散落的逻辑，这样既方便测试，也方便论文里讲"本系统采用模块化设计"。

// utils/riskCalculator.js function calculateRisk(formData) { let score = 0; const details = []; // 年龄评分 const age = Number(formData.age); if (age >= 65) { score += 4; details.push({ factor: '年龄', value: age + '岁', score: 4 }); } else if (age >= 55) { score += 3; details.push({ factor: '年龄', value: age + '岁', score: 3 }); } else if (age >= 45) { score += 2; details.push({ factor: '年龄', value: age + '岁', score: 2 }); } else { details.push({ factor: '年龄', value: age + '岁', score: 0 }); } // 收缩压评分 const sbp = Number(formData.sbp); let sbpScore = 0; if (sbp >= 160) sbpScore = 4; else if (sbp >= 140) sbpScore = 3; else if (sbp >= 130) sbpScore = 2; else if (sbp >= 120) sbpScore = 1; score += sbpScore; details.push({ factor: '收缩压', value: sbp + 'mmHg', score: sbpScore }); // 总胆固醇评分（单位mmol/L） const tc = Number(formData.tc); let tcScore = 0; if (tc >= 6.2) tcScore = 2; else if (tc >= 5.2) tcScore = 1; score += tcScore; details.push({ factor: '总胆固醇', value: tc + 'mmol/L', score: tcScore }); // 吸烟评分 const smokeScore = formData.isSmoke === 'yes' ? 2 : 0; score += smokeScore; details.push({ factor: '吸烟', value: formData.isSmoke === 'yes' ? '是' : '否', score: smokeScore }); // 糖尿病评分 const diabetesScore = formData.hasDiabetes === 'yes' ? 3 : 0; score += diabetesScore; details.push({ factor: '糖尿病', value: formData.hasDiabetes === 'yes' ? '是' : '否', score: diabetesScore }); // BMI评分 const height = Number(formData.height) / 100; const weight = Number(formData.weight); const bmi = weight / (height * height); let bmiScore = 0; if (bmi >= 28) bmiScore = 2; else if (bmi >= 24) bmiScore = 1; score += bmiScore; details.push({ factor: 'BMI', value: bmi.toFixed(1), score: bmiScore }); let level = 'low'; if (score >= 10) level = 'high'; else if (score >= 5) level = 'medium'; return { score, level, bmi, details }; } module.exports = { calculateRisk };

这个函数的输出除了总分和风险等级，还包含了一个details数组，里面是每个因素的得分明细。千万保留这个设计，因为结果页展示"因素贡献分解"全靠它——类似"您的收缩压处于较高水平，贡献4分"，这种可视化明细除了让用户感觉专业，也是你论文截图里的亮点素材。

2.3 健康建议的规则映射设计

风险等级出来之后，系统要能给出对应的健康建议。这里的规则设计也很简单，核心逻辑是：按风险因素来匹配建议，而不是按风险等级给一套通用建议。这样每个用户拿到的建议都是个性化的，体验完全不一样。

举个例子：如果用户收缩压 >= 140，就推送"建议您定期监测血压，每日清晨静坐5分钟后测量，并记录数值变化"；如果BMI >= 28，就推送"建议控制体重，每周进行至少150分钟中等强度有氧运动"；如果吸烟，就推送"吸烟是心血管疾病的重要危险因素，建议尽早戒烟，必要时可咨询戒烟门诊"。把这些建议配置在后端接口里，前端拿到结果时一并返回，用户评估结束后既能看风险等级，又能看针对自己危险因素的具体建议。

这里有个小坑要提醒：建议文案一定要专业、克制，千万不要出现"治疗""用药"等医疗决策类表述。小程序属于工具类应用，一旦涉及医疗建议，审核风险会大幅上升。全程使用"建议""咨询医生"这类措辞，既安全又合理，论文里还可以写一句"本系统仅作为健康风险自测工具，不构成医疗诊断建议"来体现你的合规意识。

2.4 四项数据库表完整设计思路

后端数据库大概是四张核心表：用户表、评估记录表、健康建议表、管理员表。

用户表t_user字段大致为：id（主键）、openid（微信唯一标识，加唯一索引）、nickname、gender、age、height、weight、create_time。这里的openid是小程序用户体系的核心，通过wx.login拿到code，在后端调用微信接口换取openid，整个登录链路就通了。

评估记录表t_assessment_record字段为：id、user_id（关联用户表）、age、gender、sbp（收缩压）、dbp（舒张压）、tc（总胆固醇）、is_smoke、has_diabetes、bmi、score（总评分）、level（风险等级）、result_detail（JSON类型，存评分明细）、create_time。关键技巧是result_detail字段设计成JSON类型，把前面计算的details数组整体存进去，查询和展示都非常方便，不用单独建一张详情表。

健康建议表t_health_advice字段为：id、factor_type（建议类型，如血压/体重/吸烟）、condition_min、condition_max、advice_content、sort_order。用条件区间来匹配建议，后端查询时写个简单的范围判断就行。

管理员表t_admin字段为：id、username、password（BCrypt加密存储）、create_time。管理端登录可以做在Web页面里，也可以做一个隐藏的小程序入口，具体看你的时间安排。

3. 实操过程与核心环节实现

3.1 环境准备：五个必装组件

实操第一步是把环境搭好。使用微信开发者工具是必须的，到微信官网下载稳定版即可。后端看你的技术选型，Java就装JDK 8+和Maven，Python就装Python 3.8+和pip。数据库装MySQL 5.7或8.0，建议顺手装一个Navicat，看数据比命令行直观得多。

这里有个很多新手忽略的点：小程序开发必须配置合法域名才能请求接口。在开发者工具里，右上角"详情 - 本地设置"可以勾选"不校验合法域名"，这样开发阶段用http://localhost:8080调试接口不会报错。但真机预览的时候，如果你没勾选这个选项，请求会被拦截。所以开发阶段没问题，一旦要上真机测试，就需要把后端部署到服务器上，然后在微信公众平台配置request合法域名。如果没有自己的服务器，也可以先用内网穿透工具，把本地后端暴露成一个公网HTTPS地址，临时解决真机联调的问题。

3.2 从零创建小程序项目的顺序和配置

项目初始化这一步建议严格按照顺序来，避免后面返工。先在微信开发者工具里新建项目，AppID可以选择"测试号"，公司主体未认证的号也能正常开发。项目建好之后，先配置全局文件app.json，把tabBar加上——我建议tabBar放三个页面：首页（风险评估入口）、记录（历史评估列表）、我的（个人中心）。tabBar配完后，pages目录里对应的页面路径必须齐全，否则编译直接报错。

页面的整体风格建议走"清爽医疗"路线，主色调用浅蓝或者青绿，别用大红大紫。表单页用小程序原生组件picker做下拉选择、slider做数值滑动输入（比如收缩压直接滑动选择120-180），会让填写体验比手动键盘输入好很多。单个评估表单建议拆成3步，第一步填基本资料（年龄、身高、体重），第二步填生理指标（血压、胆固醇），第三步填生活习惯（吸烟、糖尿病史），每步一个进度提示，数据放在全局变量里暂存，最后一步统一提交。这种交互形态比一屏展示所有字段要优雅不少。

3.3 远程调试的核心逻辑与实际操作

很多同学选项目时会看到"远程调试"这个服务，到手之后却不知道它到底是干嘛的。这里我解释一下。毕设项目中所谓的远程调试，通常指两种情况：一种是你本地开发，卖家或指导老师通过远程桌面/IDE的远程开发功能帮你处理代码问题；另一种是后端部署在服务器上，你在本地通过SSH连上去看日志、改配置。无论哪种，本质都是"帮你把跑不起来的代码跑起来"。实操中，远程调试最常用的场景是请求链路排错：小程序端报错、后端接口没有响应、数据库连不上，三个环节只要一个有问题，整条链路就断了，而远程调试能快速定位问题出在哪一环。

如果你是自己调试，我建议按这个顺序排查：先看微信开发者工具的Network面板，确定请求有没有发出去、状态码是多少；再看后端控制台日志，看接口有没有接收到请求、有没有报异常；最后看数据库，确定数据有没有正确写入或查询返回。七成以上的联调问题都能在这个流程里定位清楚。

3.4 微信原生组件避坑：单选框、顶部导航栏、slider

开发过程中，微信小程序的组件有些地方和普通H5不一样，我挑几个高频踩坑点说一下。

单选框的样式定制是搜索量很高的话题。小程序原生的radio组件改样式比较麻烦，它默认的圆圈样式在不同的真机上显示效果不一致，而且想要做成卡片式选中效果很难。我的建议是直接用view标签模拟单选框——点击某个选项时，用一个状态变量记录当前选中值，动态给选中的view加一个带边框和高亮的class。这样的交互灵活度和视觉效果都更好，代码逻辑也完全可控。

顶部导航栏高度是一个你迟早会遇到的问题。小程序的导航栏在不同机型上高度不一样，刘海屏和非刘海屏的胶囊按钮位置也不一样。如果页面要做自定义导航栏，不要写死高度，建议用wx.getWindowInfo()获取状态栏高度和菜单按钮的边界信息，动态计算导航栏的高度和胶囊位置。这样在每个机型上都能对齐，不会出现按钮被刘海挡住的情况。

slider滑动组件用来输入血压这类数值非常好用，但有个细节要注意：slider的step属性决定滑动的步长，比如收缩压从80到200，step设置成2或者5，滑起来手感顺滑，最终值也比较规整，提交到后端的数据不会出现一堆奇怪小数。在做风险评估问卷时这个细节看似很小，却能大幅提升整体体验。

3.5 后端部分建议的数据接口一览

后端接口按功能可以规划为：

submit接口是核心，前端把表单原始数据传上来，后端按照和前端utils/riskCalculator.js中一样的规则再计算一遍评分（以后端计算为准，前端计算只是为了即时展示体验）。这样设计的好处是：恶意用户即使修改了小程序端代码，也没办法把风险等级改成对自己有利的值，而且后端留存的score字段保证数据统一可信。答辩时如果老师问"为什么不在前端直接算"，这就是标准答案。

4. 常见问题与排查技巧实录

4.1 开发阶段的高频报错与排查

问题1：真机预览白屏，模拟器正常

这种情况我见太多了，基本是 "不校验合法域名" 只在开发者工具里勾选了，真机上请求被拦截导致页面数据加载不出来。排查思路：打开真机调试的vConsole看报错——如果提示url not in domain list，那就是域名校验问题，把后端部署到公网并在小程序后台配置合法域名，或者临时在手机上开启调试模式可以绕过。这个小程序里的"开启调试"入口在右上角胶囊菜单里，点开就能看到，不过注意正式上线前千万别依赖这个绕过方式。

问题2：请求后端接口超时

本地开发时前端和后端都在自己电脑上，一般不会有超时问题。真机联调时，如果是用内网穿透工具暴露的后端地址，访问速度会受工具免费版的带宽限制，经常出现10秒超时。处理方法有两个：把wx.request的timeout属性调大（默认是60秒，不用改）；或者直接花钱买个最便宜的云服务器部署后端，比穿透工具稳定得多。毕设阶段一定要提前留出部署时间，别等到答辩前一天才部署，我已经见过太多次这种翻车现场了。

问题3：paused in debugger，断点莫名其妙停下

这个提示很多新手一看到就慌，以为代码出bug了。实际上这通常是调试工具自动命中了debugger语句或者源码映射断点，并不是真正的错误。处理方法：在开发者工具的Sources面板里把"自动断点"选项关掉，或者直接停用断点，重新编译就能正常跑。如果是真机调试出现这个提示，可以把调试基础库版本切换一下，或者重启调试会话。

问题4：数据库连接不上，后端起不来

新手最常见的原因有三个：MySQL服务没启动（Windows下到服务管理器里启动）；端口被占用（检查3306端口是否被其他程序占了）；账密或schema配置不对（检查application.yml里的url、username、password有没有写错）。还有一个隐蔽坑：如果安装了MySQL 8.x，驱动配置要注意时区参数，serverTimezone=Asia/Shanghai不能少，否则驱动初始化直接报错。

4.2 数据链路联调问题的三大类排查

前后端联调是毕设项目中耗时最多、最容易出问题的一个环节。我的经验是先把问题分个类，再对症下药。

第一类是请求发不出去。表现是开发者工具Network面板里根本没有请求记录。这种时候先确认wx.request的url写对了没有，特别要注意协议头——开发环境如果是本地后端，要在开发者工具里勾选"不校验合法域名"；如果用了内网穿透的HTTPS地址但证书过期，微信也会直接拦截请求。

第二类是后端收到了请求但报错。这种最好办，直接看后端控制台日志，异常堆栈会明确告诉你哪个字段为空、哪个SQL写错了、哪个类找不到。始终保持后端控制台日志开着，这是最基本的开发习惯。

第三类是接口正常但数据对不上。比如前端传了 age=25，后端收到的却是 undefined，大概率是前端参数名和后端实体字段名映射不一致。建议前后端字段名统一用驼峰风格，并且让后端在日志里打印收到的参数，一行日志就能看出问题在哪。

4.3 答辩阶段的高频提问与应对策略

答辩是毕设的最后一关，很多项目做得好但挂在提问环节，实在太亏。针对这个项目我梳理了几个高频问题，提前准备好答案，现场就不慌。

问题1：你的风险评估模型有什么依据？

回答思路：参考了国际通用的Framingham风险评分框架和国内心血管病预防指南，结合系统使用场景做了简化设计。这里你甚至可以加一句"由于真实临床数据获取困难，本系统的评分规则是通过查阅权威文献制定的，确保各因素的权重方向与医学共识一致"。这样说既诚实又有学术依据。

问题2：你觉得你的系统有什么不足？

这个问题千万别答"没有不足"。比较好的思路是：一是评估模型目前是规则评分，后续可以引入机器学习算法，用更大规模的临床数据集训练模型，提高预测准确性；二是目前只支持用户手动输入数据，后续可以对接智能手环（如微信运动）自动获取步数、心率数据，实现更连续的健康监测；三是健康建议目前是规则匹配的静态文案，后续可以引入知识图谱做更精准的个性化推荐。这样既承认了不足，又展示了你的研究视野。

问题3：用户隐私数据怎么保护？

微信登录用的是 openid，不涉及手机号和真实姓名，这本身就是一种脱敏设计。身高体重血压等健康数据存储在MySQL中，后端接口做了简单的鉴权。你可以再加一句"后续生产环境部署时，可以使用HTTPS加密传输、数据库敏感字段加密存储、接口增加JWT鉴权等措施来进一步提高安全性"。注意别过度承诺没做的功能，就说"后续可以"。

5. 源码文档到手后如何快速吃透与二次开发扩展

5.1 源码目录结构正确的阅读顺序

拿到一套完整的项目源码之后，千万不要先把每个文件都点开看一遍，那样效率极低。正确的打开方式是：先看数据库脚本，再看接口文档，最后才看源码。数据库表结构能让你快速理解系统的数据模型，接口文档能让你知道前端和后端是怎么对接的，有了这两个基础，再看源码就会顺很多。

小程序端的代码重点看这几个地方：app.json（全局配置和页面注册）、utils/request.js或utils/api.js（网络请求封装）、pages/index（核心评估流程）、pages/result（结果展示）。后端重点看：controller（接口入口）、service（业务逻辑）、mapper（数据库操作），核心评分逻辑要么在service里，要么在一个独立的工具类里。

5.2 从毕设到可用产品的扩展方向

如果你有多余时间，我强烈建议做完基础功能后，挑一两个扩展点做深。这不仅是为了答辩好看，也是让作品真正像样。

第一个扩展方向是数据可视化升级。目前的结果页如果只是显示几个文字和数字会比较单薄。可以引入echarts-for-weixin组件库，把雷达图（六项风险因素对比）、趋势折线图（多次评估分数变化）、风险分布饼图（所有用户低中高危占比）做出来。图表是答辩现场的视觉重点，也是论文截图里的加分项。

第二个扩展方向是预测模型升级。规则评分虽然解释性强，但如果能在系统中加入一个使用逻辑回归训练的机器学习模型作为对照，论文的含金量会直接上一个档次。你可以从UCI或者Kaggle下载公开的心血管疾病数据集，在Python里训练好模型，将模型参数固化到后端Java代码中，这样既不用在线调模型，又能在答辩时说"本系统支持规则评分与机器学习模型双模式评估"。

第三个扩展方向是报告生成。评估完成后，可以生成一份包含各风险因素分析、个体化建议的图文报告，用wx.canvas把报告渲染成图片，用户可保存到相册分享给家人。这个功能技术上不难，但非常出效果，尤其答辩演示时现场生成一张图文报告，比干巴巴的页面截图有说服力得多。

5.3 数据库脚本与配置文件需要改哪些内容

二次开发时，你最需要改的文件大概有这几个：一是application.yml或.env，确认数据库账号密码、服务器端口、小程序AppID和AppSecret配置正确；二是数据库的执行脚本，如果需要调整评估字段（比如增加"家族病史"这个因素），要同时修改数据库表、后端实体类、后端评分逻辑、前端表单页面四个地方，缺一个就报错；三是小程序端的appid配置，在project.config.json里，换成你自己的测试号AppID，否则真机预览会报"appid不匹配"的错误。

5.4 论文撰写的章节规划建议

最后聊聊论文结构。如果项目做完了但论文没有好的组织方式，我建议参考这个目录框架：第一章介绍心血管疾病背景和系统开发意义；第二章技术选型介绍（微信小程序、Spring Boot、MySQL）；第三章系统需求分析与概要设计（数据流图、功能模块图）；第四章详细设计与实现（数据库设计、核心功能流程图、关键代码片段）；第五章系统测试（功能测试用例表、真机测试截图）；最后是总结与展望。

每一章的内容你都可以直接从项目开发过程中提取素材。尤其是第四章，把评分规则的公式、评分明细的JSON示例、数据接口的请求响应示例放进去，页数瞬间充实起来。还有一个经验是：论文里的截图不要直接截开发者工具的界面，最好截真机运行效果图，观感好很多，提前用手机把每个功能页面的截图都准备好。

我自己的体会是，这类健康类小程序选题，最大的价值在于"真实"——真实的应用场景、真实的技术链路、真实的数据流转。做的时候每一步都能看到反馈，不像某些纯管理的CRUD系统做完自己都不想打开第二次。你只需要把上面这些模块按部就班地搭起来，把核心的评分逻辑吃透，再加上一两个拿得出手的扩展点，不管是从完成度还是答辩表现上，都已经超过大多数人了。