企业官网建设流程全解析

毕业设计选 Java 方向的同学，看到"Spring Boot + 大数据技术 + 中医康养预约系统"这个标题，应该能闻到一股"业务成熟、技术栈新、演示起来漂亮"的味道。我当年就是被这个组合吸引，最后做出来一套集预约挂号、排班管理、医师处方、康养档案、数据大屏于一体的智慧中医药健康服务管理平台。这篇东西不是让你直接抄代码，而是把我踩过的坑、想明白的原理、答辩时被追问的细节全部过一次，对打算选同类题目的你会非常有用。

1. 项目概览与需求拆解

1.1 题目拆解：先弄清楚你是在做系统还是在做博客

拿到这个题目，第一件要做的事是把标题拆开看。它其实包含三层意思：Spring Boot表示后端主体用 Java 生态，"大数据技术"表示系统需要具备采集、清洗、聚合、展示数据的能力，而"中医康养预约系统"是业务载体。换句话说，这不是单纯的增删改查，而是一个"业务闭环 + 数据闭环"的系统。

我在做需求分析时，把业务主线提炼成一条链：患者注册登录 -> 查看医师排班 -> 预约挂号 -> 支付确认 -> 到诊签到 -> 医师开方 -> 生成康养档案 -> 复诊提醒 -> 患者评价。这条链走完，一个"传统医学康养诊疗一体化"的闭环才算成立。大数据分析则挂在这条链的侧面，围绕预约行为、科室热度、医师服务评分、复诊率这些指标来做深度分析。

很多同学一上来就想着"功能越多越好"，结果把论坛、商城、在线聊天全塞进去，最后自己都讲不清系统是干什么的。我的建议是：先守住一条完整业务主线，再往外延伸两三个亮点功能，这样演示的时候逻辑清晰，工作量也可控。

1.2 用户角色与核心痛点分析

一个医疗类系统，角色一定不是单一的"用户和管理员"。我把角色拆成三类：

这三类角色的痛点其实映射的就是系统的三大模块：预约中心、接诊工作台、运营管理后台。我在设计权限时用 Spring Security 做角色区分，避免普通用户直接访问后台接口，也避免医师看到其他医师的排班数据。这个点看似不起眼，但在答辩时会被经常问到。

1.3 功能范围界定与模块划分

基于上面的分析，我把整个系统拆成三个端：

• 用户端小程序/H5：注册登录、医师检索、排班日历、在线预约、订单支付、预约记录、康养档案、健康评价。
• 医师端后台：日程排班、号源维护、接诊列表、患者档案、处方录入、复诊计划。
• 管理端后台：用户管理、医师资质审核、科室管理、排班审核、订单管理、数据统计大屏、系统公告。

模块划分看起来并不复杂，但有一个关键点不能忽略：排班模块是核心，大数据分析模块是差异化亮点。把排班模块做深，比如把号源、时段、医师出诊状态和预约状态关联起来，系统立刻就显得"专业"；再把数据大屏做漂亮，系统立刻就显得"智能"。这两个点是我认为整个项目中最值得投入精力的地方。

2. 技术选型与后端架构设计

2.1 为什么是 Spring Boot 而不是 SSM

现在很多课程还在教 SSM（Spring + Spring MVC + MyBatis），但毕业设计我强烈建议用 Spring Boot。原因很现实：Spring Boot 大幅减少了配置量，你可以把时间花在业务逻辑上，而不是被 XML 配置文件折磨。

用 Spring Boot 搭建项目，最直观的体验就是pom.xml里引入几个起步依赖，项目就能跑起来。我当时的核心依赖大致是这样：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> </dependencies>

这里我特意没有把 Spring Security、Elasticsearch 等依赖一次性列全，而是按需引入。Spring Boot 的自动配置虽然方便，但引入太多用不到的 starter 反而会让启动变慢，也会给答推断"你到底会不会排查问题"的问题埋雷。你需要能说清楚每个依赖是用来干什么的，这是基本功。

2.2 数据层选型：MySQL 稳、Redis 快、Elasticsearch 用于检索

数据层的组合是我最满意的地方，它直接支撑了"大数据技术"这个定位：

• MySQL：存放用户、排班、预约、处方、评价等核心业务数据。MySQL 事务能力强，预约和支付这些操作必须保证数据一致性。
• Redis：用于缓存热点排班数据、存储验证码、实现分布式锁。尤其是"专家号秒没"的场景，Redis 的原子操作和过期策略很关键。
• Elasticsearch：用于医师姓名、科室、擅长领域的全文检索。MySQL 的LIKE '%关键字%'在中文本分词场景下既不支持拼音检索，性能也差，而 Elasticsearch 的中文分词效果明显更好。

我见过一些同学直接把日志、报表数据也塞进 MySQL，结果一张表几百万条后查询明显变慢。正确的思路是分层：业务实时数据放 MySQL，热数据缓存进 Redis，检索数据同步到 Elasticsearch，离线统计结果单独建统计表。

提示：如果觉得 Elasticsearch 部署成本高，可以先只做 MySQL + Redis，把"数据同步到 ES"作为加分项在论文里说明设计思路。毕业设计最怕的不是功能少，而是技术选型和业务需求对不上。

2.3 大数据技术栈的轻量集成方案

很多人听到"大数据技术"就以为要上 Hadoop、Spark，这是最大的误区。对于毕业设计体量，真正的诉求是"从用户行为数据中提取有价值的信息并可视化展示"。

我采用的方案是：前端埋点采集行为日志 -> 后端 AOP 统一记录 -> 日志表存储 -> 定时任务聚合指标 -> ECharts 可视化大屏展示。这条链路完全可以用 Spring Boot + MySQL + Redis 实现，不引入任何重量级框架。如果你还有余力，可以再加一个 RabbitMQ 做消息异步处理，把埋点日志和生产环境解耦，但这个属于锦上添花。

这里我想强调一个判断标准：技术选型没有绝对好坏，只有合适不合适。你的系统数据量只有几十万时，强行上 ClickHouse 只会让你陷入运维泥潭。相反，能把一个简单的聚合统计做到实时、准确、可视化，已经能很好地体现"大数据思维"。

2.4 工程结构设计与 package 规划

工程结构直接决定代码的可维护性和答辩时的印象分。我把项目拆成多模块 Maven 工程：

tcm-health-platform/ ├── tcm-common/ // 通用工具类、常量、状态枚举 ├── tcm-system/ // 后台管理核心模块 │ ├── tcm-system-api/ // 接口定义、DTO │ ├── tcm-system-service// 业务逻辑实现 │ └── tcm-system-web/ // Controller 层 ├── tcm-job/ // 定时任务模块 ├── tcm-admin/ // 后台管理端启动器 └── tcm-user/ // 用户端接口服务

分包原则是：按业务域分包，而不是按技术层分包。比如排班和预约相关的controller/service/mapper放在同一个业务包下，而不是把所有 controller 堆在一起。这样做的好处是，改一个功能时你能在同一个包内完成，不会把代码翻得昏天黑地。

3. 数据库设计与核心实体建模

3.1 核心业务表清单

数据库设计是整篇论文里最容易拿到分的地方，也是面试官最爱追问的地方。我最终落地的表有 13 张，其中最核心的几张如下：

这里我特别想提醒一点：表和表之间的外键不建议强制创建。我在实际开发中发现，MyBatis-Plus 配合逻辑外键（即仅保留关联 id，不建物理外键）在小规模系统里更灵活，也不会影响数据的逻辑一致性。你在设计文档里可以说明"采用逻辑外键，由应用层保证数据关系"，这是业界常见做法，不丢人。

3.2 排班表与号源设计，让"专家号秒没"变得合理

排班表是整个系统的命脉。我见过不下三个项目，排班表就一张schedule_id, doctor_id, date，完全没有号源的概念，预约逻辑全靠一个status字段硬撑。这样设计实际使用中必然出问题：怎么知道还剩几个号？怎么防止超卖？

我的排班表结构是：

CREATE TABLE schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doctor_id BIGINT NOT NULL COMMENT '医师ID', clinic_date DATE NOT NULL COMMENT '出诊日期', period TINYINT NOT NULL COMMENT '1上午 2下午 3晚诊', total_no INT NOT NULL DEFAULT 10 COMMENT '总号源', used_no INT NOT NULL DEFAULT 0 COMMENT '已预约数量', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0停诊', create_time DATETIME NOT NULL ) COMMENT '医师排班表';

关键点在于把"号源总量"和"已预约数量"拆成两个字段。用户预约时，先查used_no < total_no，然后执行乐观锁更新：

UPDATE schedule SET used_no = used_no + 1, version = version + 1 WHERE id = #{scheduleId} AND used_no < total_no AND version = #{version};

当更新影响行数为 0 时，说明号源已被抢光或版本冲突，这时候才提示"号源已满"。这个设计在并发场景下比先 select 再 update 的方式安全很多，也是面试时能拿得出手的亮点。

3.3 用户画像与体检报告的存储思路

中医康养系统绕不开报告单、体质辨识结果这类数据。我一开始把报告正文直接存进varchar(2048)，后来发现内容太长、不好扩展。最终的方案是：

• 结构化数据（如体质评分、舌苔描述）存为 JSON 字段，用json类型存储；
• 非结构化文件（如报告 PDF、头像）单独建file_info表，存储文件路径和大小，不把文件本身入库；
• 报告的核心指标抽象成字段，方便后续做大数据分析。

MySQL 从 5.7 开始支持原生 JSON 类型，JSON_CONTAINS这类函数可以做简单的查询过滤。我在做"体质类型分布"统计时，就是直接从 JSON 字段里取constitution_type来分组聚合，效率完全够用。

4. 核心功能实现细节与踩坑记录

4.1 用状态机管理预约单，别再用一个字段硬扛

预约状态的流转是最容易写乱的逻辑。我见过有人用一个status字段表示所有状态，service 里到处写if (status == 1)，改一个状态就要动一堆代码，后面根本不敢重构。

我最后用枚举定义了一套状态机：

public enum AppointmentStatus { PENDING(0, "待支付"), PAID(1, "已支付"), CONFIRMED(2, "已确认"), FINISHED(3, "已完成"), CANCELLED(4, "已取消"), NO_SHOW(5, "爽约"); }

状态流转的关键路径是：PENDING -> PAID -> CONFIRMED -> FINISHED，其中PENDING可以取消到CANCELLED，PAID后也可以取消但需要走退款逻辑。我把状态流转判断封装在一个AppointmentDomainService里，核心方法大致是：

public void cancel(Long appointmentId, Long operatorId) { Appointment appointment = appointmentMapper.selectById(appointmentId); if (!appointment.getStatus().equals(AppointmentStatus.PENDING) && !appointment.getStatus().equals(AppointmentStatus.PAID)) { throw new BizException("当前状态不允许取消"); } // 更新状态 appointment.setStatus(AppointmentStatus.CANCELLED); // 释放号源 scheduleMapper.releaseNo(appointment.getScheduleId()); }

这样设计的好处是，所有状态迁移规则集中在一处，其他地方只能调用领域方法，不会出现跨层乱改状态的问题。答辩时，你只要说清楚"状态机 + 领域服务"这个思想，技术深度立刻就上来了。

4.2 防止重复预约：从数据库唯一约束到 Redis 锁

重复预约是真实场景中一定会遇到的问题。用户手滑点了两次提交，或者前端视频卡顿导致重复请求，都有可能生成两条预约记录。

方案分两层：第一层是数据库兜底，在预约表加唯一索引uk_user_date_schedule (user_id, schedule_id)，保证同一用户对同一排班只能有一条预约记录。第二层是 Redis 防重锁，在提交预约时先尝试获取锁：

String lockKey = "appointment:lock:" + userId + ":" + scheduleId; Boolean success = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", Duration.ofSeconds(10)); if (Boolean.FALSE.equals(success)) { throw new BizException("请勿重复提交"); }

注意锁一定要带过期时间，否则用户中途断开，锁永远不释放，后面所有请求都会被挡住。我在测试时就踩过这个坑：有一次压测，有个请求异常导致锁没释放，结果整个预约接口锁死了一分多钟。所以，任何 Redis 锁都必须设置合理的过期时间，同时做好释放的兜底。

4.3 短信通知与用户触达：做得好会让体验直接加分

系统不能只做一个"在线表格"，它得在合适的时间主动触达用户。我接入了短信服务商的下发接口，核心场景有两个：预约成功通知、就诊前一天复诊提醒。

预约成功通知的模板我只留三个变量：

【某康养平台】您已成功预约{doctorName}医师{clinicDate} {period}的号源，请提前10分钟签到，凭身份证就诊。取消请登录平台操作。

这里有个细节：短信模板里的变量必须和接口参数一一对应，否则发送会失败。我当时调试时老是报"模板变量不匹配"，排查半天才发现是日期格式没转成yyyy-MM-dd，多了一个空格都不行。这个经验虽然小，但挺磨人的，提前在文档里写明格式能省很多时间。

复诊提醒更简单，直接用 Spring Boot 的@Scheduled定时任务，每天凌晨 8 点扫一遍未来 24 小时内有预约记录的用户，批量发送提醒。这个逻辑不到 50 行，但演示的时候非常出效果，评委会觉得你考虑了真实业务的运营细节。

4.4 处方与康养档案：JSON 字段存储的结构化优势

中医师给患者开方后，处方需要结构化存储，后续才能做"用药频次分析"这类大数据功能。我的处方表设计得很轻巧：

public class Prescription { private Long id; private Long appointmentId; private Long userId; private Long doctorId; private String symptomText; // 症状描述 private String medicineJson; // 药材 + 剂量列表 JSON private Integer totalDays; // 用药天数 private String healthAdvice; // 康养建议 }

medicineJson字段里存的结构大概是：

[ {"name": "黄芪", "dose": "15g", "usage": "每日一剂，水煎分两次服用"}, {"name": "白术", "dose": "12g"}, {"name": "防风", "dose": "10g"} ]

这么做的好处是，前端拿到 JSON 可以直接渲染，后端做统计时也能用 JSON 函数解析出高频药材。我在论文的"大数据分析"章节里展示了一张"高频中药材 TOP 10"柱状图，数据来源就是这个字段，既简单又有说服力。

5. 大数据分析：让系统从"能用"变得"有用"

5.1 埋点与日志采集：数据从哪来

做大数据分析的前提是得有数据。我提前做了埋点设计，前端在用户点击"预约""取消""评价"等关键动作时上报事件，后端提供一个统一的接收接口：

POST /api/event/track Content-Type: application/json { "userId": 10086, "action": "click_doctor", "targetType": "doctor", "targetId": 5, "deviceInfo": "iPhone/16.0", "timestamp": "2024-12-01 10:30:00" }

后端用 AOP 或者拦截器把请求打到日志表user_behavior_log。这张表会越攒越多，所以我在设计时给它单独建库，并写了定时清理任务，只保留最近 180 天的数据。你要在论文里写清楚数据采集的链路，这本身就是"大数据技术"的体现。

5.2 数据清洗与指标建模：别把垃圾喂给图表

采集到的日志数据不能直接用，需要清洗。我遇到过几类典型脏数据：用户 id 为空的、时间格式解析失败的、设备信息全 null 的。清洗逻辑我在定时任务里统一处理：字段缺失就丢弃该条，时间格式统一转成标准格式，再写入清洗后的表。

清洗完之后，进一步做指标建模。我定义的指标体系分三层：

• 流量指标：日活用户数、访问次数、热门科室访问量。
• 预约转化指标：预约率、支付转化率、取消率、爽约率。
• 服务质量指标：平均出诊准时率、患者复诊率、医师评分。

这些指标的计算逻辑不复杂，但难点在于定义口径。比如"预约转化率"到底是"预约成功数/页面访问数"，还是"支付成功数/预约成功数"，不同口径数值会差很多，论文里必须写清楚。我自己的口径是：支付成功数 / 点击预约按钮次数，这样最能反映预约流程的漏斗效果。

5.3 基于用户行为的医师推荐算法

这个模块是整个系统一个很讨巧的加分项。它的思路是：如果用户 A 和用户 B 访问过的医师高度相似，那么 A 认可的医师也可能符合 B 的需求。这就是协同过滤的朴素思想。

我在实现时没有用复杂的矩阵分解，而是用了基于物品的余弦相似度：把医师看成"物品"，用户对医师的偏好可以来自评价分、预约次数、访问次数。计算两个医师的相似度，然后给目标用户推荐相似医师。

代码实现的核心步骤不复杂：

// 1. 构建医师-用户评分矩阵 Map<Long, Map<Long, Double>> doctorUserScoreMap = buildScoreMap(); // 2. 计算目标医师与其他医师的余弦相似度 double similarity = cosineSimilarity(doctorVecA, doctorVecB); // 3. 取相似度最高的 TopN 医师，去掉用户已预约的，生成推荐列表

这个算法完整实现大概 200 行，我建议一定要亲自写一遍。答辩时你只有真懂它，才能回答"为什么选择余弦相似度""冷启动怎么解决""数据稀疏怎么办"这些问题。

5.4 大屏可视化：让评委一眼看到你的大数据能力

可视化大屏是整个项目最直观的"门面"。我选了 ECharts 做图表，数据接口用 RESTful API 暴露，前端用定时器每 30 秒拉一次最新数据。大屏我放了四个核心区块：

• 左侧：今日预约量折线图、科室热度柱状图；
• 中间：核心指标卡（今日访问量、预约量、营收、复诊率）；
• 右侧：医师服务评分雷达图、高频中药材 Top 10 横向柱状图。

比如科室热度的图表，配置大概是这样：

option = { title: { text: '科室预约热度 TOP5' }, tooltip: {}, xAxis: { type: 'category', data: ['中医内科', '针灸推拿', '康复理疗', '中医妇科', '骨伤科'] }, yAxis: { type: 'value' }, series: [{ type: 'bar', data: [120, 95, 80, 67, 52], itemStyle: { color: '#2f9e8f' } }] };

大屏不需要炫技，关键是数据链路通：数据库里的数据 -> 聚合接口 -> 定时刷新 -> 图表展示。你只要能回答"这个数字怎么算出来的"，比图表本身做得好看更重要。

6. 部署上线与性能优化实战

6.1 Maven 打包：从"一打包就报错"到"一次过"

Maven 打包是横在很多应届生面前的第一道坎，我当年也在这个上面卡了一整天。最常见的坑有两个：本地运行正常，mvn package后提示找不到主类；jar 包启动后访问接口报 404。

前者的原因通常是没配置 Spring Boot 的打包插件，后者多半是没把前端静态资源打进 jar。解决办法很简单，在pom.xml增加：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.tcm.admin.AdminApplication</mainClass> </configuration> </plugin> </plugins> </build>

另一个细节是打包后 jar 体积很大，这是 Spring Boot 依赖未精简导致的。如果觉得体积太大影响演示环境部署，可以用spring-boot-thin-layout或把依赖分开部署，但考虑到毕业设计要求，打成胖 jar 反而是最省事的方案，到服务器上一条java -jar就能跑，不用管依赖。

6.2 前后端分离部署：Nginx 与接口转发

我的部署架构是"前后端分离 + 单机部署"：前端是一个 Vue 项目，打包成dist目录，由 Nginx 托管；后端是一个 Spring Boot jar，监听 8080 端口。Nginx 的关键配置是区分静态资源和 API 请求：

server { listen 80; server_name localhost; # 前端静态文件 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有一个容易踩的坑：Vue Router 使用 history 模式时，刷新页面会 404。必须配置try_files $uri $uri/ /index.html;，把未知路由回退到首页，由前端路由接管。我第一次部署忘了这一行，刷新一次页面就白屏，排查了很久才发现是 Nginx 配置问题。

6.3 慢 SQL 优化实录：从 2 秒降到 50 毫秒

做统计报表时，我写了一条很"直观"的 SQL，数据量只有几万条时秒回，等数据涨到几十万后直接卡死：

SELECT user_id, COUNT(*) FROM appointment WHERE appointment_date BETWEEN '2024-01-01' AND '2024-11-01' GROUP BY user_id;

这条 SQL 慢在appointment_date没有索引，而且COUNT(*)分组扫描了全表。处理方案分两步：

第一步加联合索引：

ALTER TABLE appointment ADD INDEX idx_user_date (user_id, appointment_date);

第二步，业务上把实时统计改成"每日凌晨由定时任务预先聚合"：

INSERT INTO statistics_daily (user_id, stat_date, appointment_count) SELECT user_id, DATE(appointment_date), COUNT(*) FROM appointment WHERE appointment_date >= DATE_SUB(CURDATE(), INTERVAL 1 DAY) GROUP BY user_id, DATE(appointment_date);

优化之后，大屏显示的历史指标直接从预聚合表读取，响应时间降低到 50 毫秒以内。这个优化思路是"宽表 + 预聚合"，几乎所有大数据报表系统都是这个套路，放在论文里很有说服力。

6.4 Redis 缓存一致性：别让数据展示"失真"

系统里有一个高频操作：用户打开排班日历，查询某位医师未来 7 天的号源。这个接口如果每次都走数据库，体验会很差。我把它缓存到 Redis：

String cacheKey = "schedule:doctor:" + doctorId + ":" + date; List<ScheduleVO> schedules = JSON.parseArray(redisTemplate.opsForValue().get(cacheKey), ScheduleVO.class); if (schedules == null) { schedules = scheduleService.queryAvailable(doctorId, date); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(schedules), Duration.ofMinutes(10)); return schedules; } return schedules;

一致性方案是"Cache Aside"：更新时先更新数据库，再删除缓存。为什么不直接更新缓存？因为并发场景下，更新缓存可能用到旧数据，删除缓存可以让下一次读取重新加载最新数据，逻辑更简单也更容易保证正确性。这里务必避免"先删缓存再更新数据库"的写法，否则中间窗口可能把旧数据读进缓存。

7. 常见问题与避坑指南速查

7.1 高频问题排查：我把血泪教训整理成了表

这些大部分不是"不会做"的问题，而是"没注意细节"的问题。写代码时要刻意养成"看控制台完整报错"的习惯，不要只盯最后一行异常信息，前几行的 Caused by 往往才是真正的根因。

7.2 论文答辩被问概率最高的五个问题

我把答辩中真实被老师追问的问题整理一下，你们参考着提前准备：

1. 为什么用 Spring Boot 而不用传统的 SSH？回答要点：Spring Boot 的自动配置、内置服务器、快速启动让开发效率大幅提升，同时它依然基于 Spring 生态，方便集成 Security、Data、Cache 等组件。
2. 你的系统如何保证高并发下号源不超卖？回答要点：数据库乐观锁 + Redis 锁 + 唯一索引三层防护，重点是讲清楚UPDATE ... WHERE used_no < total_no这一条原子 SQL。
3. 大数据分析模块的数据从哪里来，清洗规则是什么？回答要点：埋点日志表 + 定时清洗任务，讲清楚指标口径，最好现场演示一张图背后的聚合逻辑。
4. 如何做权限控制？回答要点：Spring Security + JWT，按角色区分接口访问，资源访问用注解鉴权。
5. 系统上线后你如何持续优化？回答要点：先从慢 SQL 排查入手，再考虑缓存、索引、预聚合，最后是消息队列削峰。

最后一个问题最容易暴露一个人是不是真的做了项目，只有实际跑过系统、看过慢查询日志的人，才能回答得自然。

7.3 给打算做同类题目的你三条建议

第一，先跑通最小可用系统，再追求华丽功能。我建议第一周先完成"登录 + 排班 + 预约 + 管理端列表"这四个核心流程，哪怕前端很丑，业务闭环先通，后面所有功能都在这条链上迭代。

第二，数据库设计文档一定要边写代码边改。很多同学先画好 ER 图再写代码，结果一写就发现字段对不上。我的做法是先建表、跑通接口，再回来补文档，最终文档和代码高度一致。

第三，想清楚你要讲一个什么"故事"。你的系统不是一堆零散功能，而是一个"为中医康养机构提供预约服务 + 数据运营能力"的整体方案。系统演示时的解说词应该围绕这条主线，让评委听完后感觉你的项目不仅技术完整，而且真的解决了行业里的实际问题。

我自己在演示过程中最大的感悟是：一个项目能不能拿高分，不在于用了多冷门的技术，而在于你能否把自己做的每一步都说清楚，包括为什么选它、解决什么问题、遇到什么坑、最后怎么优化。把这个思路带到你的项目里，你就能把毕业设计从"应付差事"变成一件真正拿得出手的作品。