1. 项目定位与需求拆解
1.1 高校防艾宣传平台能解决什么问题
高校的艾滋病预防宣传一直是个很特殊的需求场景。传统的线下宣讲、发放宣传册、贴海报这些方式，覆盖面有限，学生参与度也不高，而且很多同学对这类话题存在心理顾虑，不愿意在公开场合提问或了解。我做这个“基于SpringBoot+Vue的高校HIV艾滋病预防宣传平台”的时候，最开始想的就是怎么把这件事搬到线上，让学生可以匿名、随时随地获取靠谱的防艾知识。
这个平台本质上是一个面向高校场景的健康教育宣传系统，核心目标可以拆成四个维度：知识传播（文章和视频学习）、自我评估（匿名测评问卷）、服务对接（检测预约和咨询通道）、宣传教育管理（后台内容发布和效果统计）。它解决的痛点很明确：一是让防艾知识触达更广，二是通过匿名机制降低学生心理门槛，三是帮学校团委、校医院、学生处这些部门把宣传工作的线上化流程跑通。
适合谁来参考这个项目？我觉得有三类人：第一类是计算机相关专业的毕业生，拿这个当毕业设计，SpringBoot加Vue的组合在答辩时也比较好讲；第二类是高校信息化建设的技术人员，想建设类似健康宣传系统可以参考数据模型和功能拆分；第三类是正在学前后端分离开发的初学者，这个项目的业务复杂度适中，既有CRUD又有视频播放、在线测评、数据统计这些可展示的亮点，学完能建立一个完整的全栈开发思维框架。
1.2 功能模块怎么划分才合理
我在设计功能模块时，没有一上来就堆功能，而是先按“平台的角色谁在用”来倒推。整个系统有四种角色：学生（普通用户）、辅导员（班级管理员）、校医院/团委工作人员（运营管理员）、系统管理员。不同角色关心的东西完全不同，如果功能边界不清晰，后期开发和维护都会很痛苦。
最终我把功能划分成六大模块：用户认证与权限管理、防艾知识内容库（图文+视频）、在线测评与风险评估、检测预约与咨询服务、宣传数据统计看板、后台内容审核与管理。
这里有一个经验想分享：很多同学做这类毕设时容易把功能做得特别散，比如做一个在线聊天室，又做一个论坛，再做一个商城，最后每个功能都是半成品。我建议守住“宣传平台”这个核心定位，所有功能都围绕“让用户获取防艾知识、评估自身风险、对接专业服务”这条主线展开，多余的花哨功能一个都不加。这样的系统做出来功能聚焦，需求文档、数据库设计、代码实现都能对得上，答辩时逻辑也能自洽。
1.3 关键业务流程梳理
除了功能模块，业务流程的设计同样重要。我把几个核心流程画过一遍流程草图（拿纸画的，开发画布也行），这里捡两个最关键的说说。
第一个是内容发布流程。管理员新增文章或视频后，不是直接上架的——先进入草稿状态，然后提交审核，审核通过后才会在前端页面展示出来。这样设计是为了防止信息误发。高校的防艾宣传内容需要准确、科学，如果发布流程没有审核环节，内容出错的风险太大。审核角色和发布角色要分开，不能让同一个人既是发布者又是审核者。
第二个是检测预约流程。学生在平台上看到校医院或疾控中心的检测服务，选择时间段提交预约，管理员在后台确认后生成预约凭证。用户可以在“我的预约”里查看状态和历史记录，还能在指定的隐私时间段取消预约。这个流程最重要的设计是匿名与隐私保护——前台预约使用脱敏显示，管理员后台只看到学号后四位，其他个人隐私信息需要更高权限才能查看。这不是技术上的难事，但在高校场景中这个设计非常加分，也算是平台在“防艾”这个敏感话题下应有的态度。
2. 技术选型思路与理由
2.1 为什么选SpringBoot + Vue这套组合
技术选型这个问题，我在项目一开始就反复权衡过。前后端分离是当前Java Web开发的主流架构，SpringBoot 负责后端接口服务，Vue 负责前端交互界面，两边通过 RESTful API 通信。这套组合的优势在于“分工明确、生态成熟、学习资料多”，对于高校项目来说，这三个优势几乎是致命的吸引力。
先说 SpringBoot。它最大的贡献是解决了 Spring 家族繁琐的 XML 配置问题，用自动装配机制把大量样板配置变成了约定俗成，一个内嵌的 Tomcat 就能把服务跑起来，不用再单独部署 war 包。开发者在配置文件里写几个坐标参数，就能非常轻量地把一个 Web 项目跑起来。你去看现在的招聘市场，SpringBoot 几乎是 Java 后端岗位的标配要求，项目做完之后简历上写“熟悉 SpringBoot 框架开发”，含金量是实打实的。
再说 Vue。Vue 的核心优势是响应式数据绑定和组件化开发。拿这个平台来说，后台管理端有大量的表单、表格、弹窗交互，用 Vue 的组件化拆分之后，每个功能区域的代码都很好维护。前端页面写完，用 npm run build 打包成静态资源，丢到 Nginx 里就能独立部署，开发时还能用 Vite 或 Vue CLI 做热更新，体验非常好。
前后端分离还有一个隐藏的好处——接口文档驱动开发。我提前用 Apifox 把所有接口的定义（路径、入参、出参）约定好，前后端并行开发的时候不需要互相等，这个对项目进度管理帮助很大。
2.2 前端技术栈：Vue3 + Element Plus + Axios + Pinia + ECharts
确定用 Vue 之后，我选了 Vue 3 的 Composition API 写法，配合 Element Plus 组件库做后台界面。这里有一个选型细节可以聊聊：Vue 3 和 Element Plus 在 2023 年之后生态已经非常成熟了，组件库的表格、表单、上传、日期选择这些组件直接开箱即用，能省掉至少三成的前端开发工作量。
状态管理我用了 Pinia 而不是 Vuex 4。虽然 Vuex 是老牌方案，但 Pinia 的 API 设计更简洁，去掉了 mutations 这个略显冗余的层，直接同步改 store 里的状态，TypeScript 支持也更好。对于这个项目来说，我主要用 Pinia 来存用户登录信息和权限标识，跨页面共享的时候直接从 store 读取，不用每次都调接口。
HTTP 请求我用 Axios 封装了一层。封装的核心是拦截器：请求拦截器里自动往 header 里塞 JWT Token，响应拦截器里统一处理 HTTP 状态码和业务状态码，后端返回 401 就自动跳转登录页，后端返回 403 就弹提示“无权限访问”。这样业务代码里不用每处都写 try catch，统一收口减少了大量重复逻辑。数据可视化部分用了 ECharts，宣传效果的柱状图、饼图、折线图都能直接找官方示例改，学习成本很低。
2.3 后端技术栈：SpringBoot 2.7 + MyBatis-Plus + JWT + Redis
后端版本我选了 SpringBoot 2.7.18，而不是最新的 SpringBoot 3.x。这里想重点说说原因。很多同学看到 2024 年、2025 年了，觉得应该上 SpringBoot 3，但实践下来 SpringBoot 3 有几个门槛——强制要求 JDK 17，旧的 javax 包名全部变成了 jakarta，很多第三方组件的兼容版本还不稳定。对于追求稳定交付的项目来说，SpringBoot 2.7 是性价比非常高的选择，它的社区资料最多，遇到问题一搜就有答案。
持久层用了 MyBatis-Plus。它是在 MyBatis 基础上做的增强，大部分单表 CRUD 不用写 XML，BaseMapper 里直接提供 selectById、selectPage 这些现成方法。这个项目里的文章表、视频表、预约表、测评表基本都是单表操作，MyBatis-Plus 能显著减少重复代码量，分页插件用 PageHelper 式的一行配置就搞定。
认证授权我用的是 JWT 方案。用户登录成功后，后端生成一个带有效期的 Token 返回给前端，前端存在 localStorage 里，之后每个请求都带上这个 Token。这个方案的优点是无状态，后端不需要保存会话信息，很适合前后端分离架构。Redis 我用来做两部分事情：一是存储验证码的短时缓存，二是给视频的播放进度做热点缓存。选 Redis 的原因是它读写速度快且支持设置过期时间，验证码五分钟过期这种需求天然契合 Redis 的 TTL 机制。
3. 数据库设计与后端核心实现
3.1 核心数据表设计思路
数据库设计在项目里占了非常重要的位置，表结构没设计好，后面写代码会不断返工。我按业务模块把表分成了几组，这里挑几张核心表解读一下设计思路。
用户表（user）：字段包括 id、学号、密码、姓名、性别、学院、班级、角色（0-学生，1-辅导员，2-运营管理员，3-系统管理员）、电话、邮箱、创建时间、状态。密码字段存的是 BCrypt 加密后的密文，绝对不能存明文。角色字段用 int 类型或用枚举字符串，按位设计也行，但对这种规模的项目 int 就够用。
文章内容表（article）：id、标题、封面图、摘要、正文、分类（科普知识/政策法规/案例分析）、是否置顶、浏览量、状态（0草稿 1待审核 2已发布 3已下架）、创建人、审核人、创建时间、发布时间。加一个浏览量字段是为了后面数据统计能直接用，不用 count 查询表记录，性能上更稳。
视频资源表（video）：id、标题、封面图、视频地址、播放时长、简介、所属分类、状态、上传人、创建时间。视频地址我存的是相对路径，完整访问地址通过配置动态拼接，这样部署环境切换时不需要改数据库。存储方面视频文件放在服务器的 /resources/videos 目录，如果是云服务器也可以接 OSS。
测评问卷表（questionnaire）：id、标题、描述、状态、创建时间。测评题目表（question）：id、问卷 id、题目内容、选项 JSON、正确答案、分值。问卷答案表（questionnaire_result）：id、用户 id、问卷 id、得分、风险等级、提交时间。这里有几个设计细节值得说明：选项用 JSON 格式存，是因为不同题目的选项数量不一样，做成 JSON 字段比做关联表更灵活；风险等级是后端根据得分自动算出来的，前端只需要展示结果和建议。
预约表（appointment）：id、用户 id、服务类型（检测/咨询）、预约日期、时间段、地点、状态（0待确认 1已确认 2已完成 3已取消）、备注、创建时间。这张表要和用户表做关联，但查询列表时只返回脱敏信息。
除了这些核心表，还有 banner 图表、通知公告表、操作日志表、字典表。字典表是我做项目时特别推荐加的一张大而全的表——状态值的枚举、学院列表、服务类型这些都可以放里面，前端下拉框选项直接从这里拿，后期要加选项不用改代码和数据库结构。
3.2 登录认证与权限控制的落地方式
登录认证这块，我一共做了三个接口：发送验证码、账号密码登录、获取当前登录用户信息。密码登录的流程是：前端传账号和密码，后端先校验验证码（验证码存在 Redis 里，key 是 uuid，value 是四位数字），再根据账号查用户，用 BCrypt 校验密码，校验通过后生成 JWT，把用户 id 和角色放进 Token 的载荷里，同时把用户基本信息存入 Redis，最后返回 Token 和用户信息给前端。
这里的关键实现是权限控制。我用 SpringBoot 的拦截器机制，配合自定义注解 @RequireRole，做了一个轻量级的权限控制方案。拦截器里先校验 Token 是否存在和有效，再从 Token 里解析出角色，去匹配目标接口上标注的角色要求。放行规则这样定义：
// 自定义权限注解 @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String[] value() default {}; } // 拦截器核心逻辑 public class AuthInterceptor implements HandlerInterceptor { public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (!StringUtils.hasText(token) || !jwtUtil.validateToken(token)) { throw new BusinessException(401, "登录状态已失效，请重新登录"); } // 解析角色 String role = jwtUtil.getRoleFromToken(token); if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod = (HandlerMethod) handler; RequireRole requireRole = handlerMethod.getMethodAnnotation(RequireRole.class); if (requireRole != null && !Arrays.asList(requireRole.value()).contains(role)) { throw new BusinessException(403, "没有操作权限"); } } return true; } }这套方案的优点是轻量、无状态、容易理解，对一个小型管理系统来说完全够用。比引入 Spring Security 加 SecurityFilterChain 那一大套配置要直白得多。我在答辩时重点讲了权限控制的设计思路，老师对这个点的评价还不错——不用框架堆砌，能说清楚原理解释清楚为什么这样做，比盲目引入复杂框架更能体现基本功。
另外一个容易忽略的点是密码策略。管理员的初始密码建议统一设置为类似 Hiv@2024 这样的临时密码，首次登录强制修改。学生注册时如果要设置密码，最少 8 位且必须包含字母和数字，前端后端双端校验。
3.3 内容管理与审核流程的后端实现
内容管理模块是后台最核心的 CRUD 场景，我用 MyBatis-Plus 的 IService 接口封装了一层通用方法，每个业务 Service 继承后直接获得增删改查能力。文章发布接口的代码结构大致是这样的：
public void publishArticle(ArticleDTO articleDTO) { Article article = new Article(); BeanUtils.copyProperties(articleDTO, article); article.setStatus(0); // 草稿 article.setCreatorId(currentUserId()); articleService.save(article); // 记录日志 logService.record("发布文章", "文章《" + article.getTitle() + "》已保存为草稿"); }提交审核接口会把文章状态从草稿改成待审核，运营管理员登录后台看到一个待办列表，点开详情阅读内容，通过或驳回。驳回时填写驳回原因，系统会通知发布者。这个通知我这里做了简化，直接存一条站内信，用户下次登录时红点提示。
视频上传是内容管理里比较麻烦的部分。我用的方案是：前端 Element Plus 的上传组件把视频分片传到后端，后端用 MultipartFile 接收后存到服务器指定目录。视频格式这块我建议统一转成 MP4，因为 MP4 兼容性最好。考虑在线播放的体验，还把视频转出了 M3U8 切片，这也是标题热词里反复出现的 vue 播放 m3u8 这个需求的实际场景。转码用 FFmpeg 的命令行工具，Java 里通过 ProcessBuilder 调用，摄像头少的时候直接传原视频也行。
M3U8 的播放地址生成逻辑是这样的：后端在视频表里保存 .m3u8 文件的访问路径，前端用 hls.js 解析播放。下面这一段是前端播放的核心代码，我从实际项目中摘出来的：
<template> <video ref="videoRef" controls autoplay class="video-player"></video> </template> <script setup> import Hls from 'hls.js'; import { ref, onMounted, watch } from 'vue'; const props = defineProps({ videoUrl: { type: String, required: true } }); const videoRef = ref(null); function playVideo(url) { if (Hls.isSupported()) { const hls = new Hls(); hls.loadSource(url); hls.attachMedia(videoRef.value); } else if (videoRef.value.canPlayType('application/vnd.apple.mpegurl')) { // Safari 原生支持 HLS videoRef.value.src = url; } } onMounted(() => { if (props.videoUrl) { playVideo(props.videoUrl); } }); watch(() => props.videoUrl, (newUrl) => { if (newUrl) { playVideo(newUrl); } }); </script>整个视频模块做完之后，用户可以在线观看防艾科普视频，后台还能看到每部视频的播放次数和人均观看时长，这个数据直接辅助判断哪类内容的接受度更高。
4. 前端页面开发与功能落地
4.1 工程化初始化与路由设计
前端工程我用的 Vite 来初始化 Vue 3 项目，和 Vue CLI 相比，Vite 的开发服务器启动速度快很多，项目大点也不会卡。初始化命令很直接：
npm create vite@latest hiv-frontend -- --template vue cd hiv-frontend npm install npm install vue-router@4 pinia axios element-plus @element-plus/icons-vue echarts hls.js装完依赖后第一件事是建好目录结构。我的习惯是 src 下面分 api（接口定义）、assets（静态资源）、components（公共组件）、router（路由）、stores（状态管理）、utils（工具函数）、views（页面）。api 目录下每个模块建一个 js 文件，比如 article.js 里统一放文章相关的接口调用，这样后端接口路径集中管理，改起来不会东找西找。
路由设计上，前台门户和后台管理分成两个路由容器。前台路由是公开的，包括首页、知识库、视频课堂、在线测评、预约服务、个人中心；后台管理路由做了动态权限控制，根据用户角色异步加挂路由，学生角色访问后台地址会被重定向到首页。这是前端权限控制的做法，和后端接口权限是双重保障。
Vue Router 还用到一个很重要的特性：路由守卫。我在全局前置守卫里判断用户是否登录，未登录跳转登录页并记录来源路径，登录成功后跳回原页面。这个体验细节很微妙，但用户感知非常明显。
4.2 视频学习模块：M3U8 播放与播放进度记录
视频课堂是平台里用户最常访问的模块，所以我把这个模块的细节做得比较多。页面上显示视频封面、标题、播放量、时长，点击进入播放页。播放页的布局是左侧播放器、右边推荐列表，用的是分栏布局。播放器上面提到的 hls.js 方案能胜任。
播放进度的记录是一个隐藏的亮点功能。用户看到一半关了页面，下次打开时从上次位置继续播放。实现逻辑是：播放器触发 timeupdate 事件时，用节流函数每 15 秒向后端提交一次当前播放时间，同时记录用户 id 和视频 id；点开播放页时先查后端有没有历史进度，有的话设置 currentTime 跳转。
注意这里有个细节，节流是必须的，不然 timeupdate 事件每秒触发三四次，带宽和数据库压力都扛不住。节流的简单写法是维护一个时间戳判断是否过了设定间隔，也可以直接用 lodash 的 throttle 方法。
视频播放页还有一个贴心的设计：首次播放前弹出提示框告知用户“本视频包含专业知识，观看全程大约需要 X 分钟”，用户点击“我已了解，开始观看”后视频才播放，这样也侧面起到心理铺垫的作用。这个设计在策划阶段就确定下来，后续在用研反馈里好评率还挺高的。
4.3 在线测评与结果分析
在线测评模块，我做了两套问卷：一套是防艾知识竞赛类的题目（有正确选项，提交后立即出分），另一套是风险评估量表（没有对错，根据选项累加风险分值，最后映射为低风险、中风险、高风险三个等级）。
做这一块时最需要考虑的是前端交互体验。我用了 Element Plus 的步骤条组件，把 10 道题分成 3 步，每步展示 3~4 题，用户答完一页点“下一题”，最后一页展示结果。有一版我做的是所有题目在一个页面上通过滚动查看，但测试后发现用户滚动操作冗长、容易漏题，改成步骤条之后完成率明显提升。这就是产品思维和技术实现的结合，能体现出对用户体验的思考。
测评结果的展示也花了心思。得分页不是一个简单的数字，而是一个评估报告：雷达图展示五个维度（知识掌握、风险意识、行为态度、自我防护、求助意愿）的得分占比，配合文案给出针对性建议。风险等级为“中风险”或“高风险”的用户，页面提示“建议前往校医院或当地疾控中心进行专业咨询与检测”，并提供预约服务的快捷入口。这类文案我在写的时候特别注意语气，避免制造焦虑，用“我们理解每个人的情况不同”这种温和表达替代恐吓式表述。
后端生成评估报告的逻辑相对简单，根据题目分组的权重计算综合得分，然后用一个 Map 把分数区间映射到风险等级和建议文案，再用 ECharts 把各维度数据传给前端渲染。
4.4 宣传数据看板：ECharts 展示运营效果
后台的数据看板我用 ECharts 做了四个核心图表：用户增长趋势折线图、内容分类阅读量占比饼图、预约服务数量柱状图、各学院参与度热力图。这些图表的数据来源是后端统一的统计接口，返回一个 JSON，包含时间范围内的用户注册数、文章阅读量、视频播放量、测评完成数、预约数等运营指标。
值得讲一下访问量和活跃度的统计方式。我没有用复杂的埋点系统，而是用一张每天汇总的行为统计表，定时任务在每天凌晨把前一天的数据汇总写入，报表查询直接读这张表。这种离线汇总的优点是查询性能好、逻辑简单，对宣传平台这种量级的数据完全够用。如果未来数据量大，可以扩展成 ClickHouse 之类的大数据方案，但现阶段用不着。
权限控制下，不同角色看到的看板内容不同。辅导员只能看到自己学院的数据，校医院可以看到全校的数据；学生端则有一个个人学习档案面板，展示自己观看过多少视频、完成过几次测评、最近一次风险等级。把数据权限做细，整个平台的信息隔离就会显得很正规，这也是答辩时一个不错的加分解。
5. 开发过程中踩过的坑与排查心得
5.1 SpringBoot 版本太高导致的兼容问题
这个坑我相信很多用 SpringBoot 的同学都踩过。一开始我图新，用了 SpringBoot 3.2，结果项目中用到的 knife4j 接口文档组件和 MyBatis-Plus 的部分旧版本插件都不兼容，报了一堆莫名其妙的错误。后来整体降级到 SpringBoot 2.7.18，所有问题迎刃而解。
这里有个排查思路可以分享：遇到第三方组件报错时，不要一开始就怀疑自己的代码错误，先检查版本兼容矩阵。很多组件在官方文档或 GitHub 的 README 里会明确写支持哪些 SpringBoot 大版本。优先选择 SpringBoot 2.7 而不是 3.x，不是说 3.x 不好，而是它的生态迁移还需要时间，对交付型项目来说稳定性更重要。
比较隐蔽的问题还有自动配置没生效。比如配置了 Redis 连接，但启动时没有报错，实际一调用就 NPE。后来发现需要检查是不是缺失了 RedisAutoConfiguration 的自动装配条件，排查方法是在启动类上加 -Ddebug 参数看自动装配报告，过滤出 Redis 相关的项为什么没有生效。
5.2 Vue 打包后路由刷新 404 和布局异常
项目部署到服务器之后，出现了两个经典的前端问题。第一个是刷新页面 404，原因很简单——Vue Router 默认用 history 模式，刷新时浏览器向服务器请求具体的路径，但这个路径在静态服务器上不存在。解决办法是在 Nginx 配置里加一条 try_files 指令：
location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }加了之后刷新就不再 404 了。如果你用的不是 Nginx 而是 Tomcat 部署，那需要在后端加一个 Controller 把未知路径转发到 index.html，或者改用 hash 模式路由。hash 模式不需要服务器配置，但 URL 会多一个 # 号，不太好看，我推荐用 history 模式加服务器配置的方案。
第二个问题是打包后布局异常。开发环境一切正常，一打包上线就发现样式错乱，排查到最后是静态资源路径问题——打包后的 index.html 里引用的 JS 和 CSS 路径是绝对路径 /assets/xxx，但我的网站部署在服务器子目录下。解决办法是在 vite.config.js 里把 base 改成相对路径 './'，重新打包就好。类似的还有 Element Plus 的字体文件加载不出来，同样要把 public 路径配置对。
5.3 跨域、联调与 Token 失效的排查
前后端分离开发时，跨域是绕不开的问题。我在开发环境用 Vite 的 proxy 做代理，把 /api 开头的请求代理到后端的 localhost:8080，这样浏览器不会产生跨域请求，开发和生产的运行都很正常。生产环境则是通过 Nginx 反向代理统一转发：
location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Authorization $http_authorization; }这里要注意 proxy_pass 后面的斜杠问题，我在这里吃过一次亏——/api/ 转发到 8080 后，后面的路径如果有差异就会 404。加不加末尾斜杠在 Nginx 里行为完全不同，配置时一定要先理清楚。
另外一个是 Token 失效的体验问题。后端 Token 有效期我设了 24 小时，但学生用系统时基本是上课间隙，隔了两三天再打开就发现“登录已过期”，体验很差。后来我加了双 Token 机制：Access Token 有效期 2 小时，Refresh Token 有效期 7 天，Access Token 过期时用 Refresh Token 自动续期，用户无感知，只有 Refresh Token 也过期了才需要重新登录。这套机制在后端写一个 AOP 切面就能实现，不太复杂，但体验上升非常明显。
5.4 部署发布与运维细节
整个系统部署我用了最简单省钱的方案：一台 2 核 4G 的云服务器，安装了 JDK 8、Nginx、MySQL 8、Redis 6。后端通过 Maven 打成 jar 包，用 nohup 命令后台启动，前端 build 之后把 dist 目录放到 Nginx 的 html 目录下。下面的启动命令在实践中验证没有问题：
# 后端启动 nohup java -jar hiv-platform-1.0.0.jar --spring.profiles.active=prod > app.log 2>&1 & # Nginx 配置 server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; } }另外建议把 MySQL 和 Redis 都加上密码，服务器的安全组只放行 80 和 22 端口，8080 端口不要对外暴露，这些是基本安全实践。数据库每天凌晨做一次全量备份，备份文件保留 7 天，用 crontab 定时任务就行。这些在毕设论文的“系统部署”章节里写上是加分项，实际工作中也是保命技能。
我在实际项目里还用过 SpringBoot Actuator 暴露健康检查端点，配一个简单的脚本监控服务是不是活着，挂了自动重启。对于教学项目来说这不是必须的，但做出来的话说明你有生产环境意识，面试的时候可以拿出来聊。
6. 学习路线与项目扩展建议
6.1 从零复现这个项目需要掌握哪些前置技能
如果你现在准备照着这个思路做类似的项目，我建议先确认自己的基础打得差不多了。前端需要掌握 HTML/CSS 基础、JavaScript 核心语法（ES6 的箭头函数、解构赋值、Promise 这些是必须的）、Vue 3 的组件写法、Axios 的基本使用；后端需要掌握 Java 面向对象、Spring 的核心概念（IoC 和 AOP 至少要理解）、MyBatis 的 SQL 写法、MySQL 的基础增删改查和表设计能力。
这些东西不需要全部精通再动手，但基础语法要熟练到不用查文档的程度，不然项目做着做着就变成“调试代码”而不是“写功能”了。我的建议是按“前端基础 2 周 + 后端基础 2 周 + 项目实战 4 周”的节奏来安排学习。如果已经有 Java Web 开发基础，直接看 SpringBoot 的文档加上狂神的入门视频，一周就能上手；Vue 新手建议先看官方教程的“快速开始”部分，把组件、路由、状态管理三座大山搞定再说。
6.2 可扩展的方向：从课程设计到真实运营平台
这个项目做完之后，我一直在想后续怎么扩展成真正能长期运营的平台。第一个扩展方向是内容推荐——根据用户浏览历史和测评结果，用简单的标签匹配算法做防艾知识的个性化推荐，虽然用不上协同过滤那么复杂的东西，但能把“千人千面”的雏形做出来。第二个方向是移动端适配，现在的界面只能说在手机上“能用”，但谈不上“好用”，下一步可以考虑做一套 uni-app 的小程序版本，触达率会提升很多。
第三个方向是更严谨的数据安全与隐私合规。平台涉及健康类敏感信息，如果要在真实高校中上线运行，必须认真考虑数据脱敏、操作审计、角色权限的最小化授权。我在代码里虽然做了 Token 校验和角色控制，但要达到等保要求还有不少工作量。当然如果你只是在毕业设计层面，当前的设计已经足够有诚意了。
最后想分享一下我反复改了两版才定型的体会：好项目不是一次写出来的，是迭代出来的。做之前多花时间在需求分析、数据库设计和接口约定上，后面实现会轻松很多；反之如果一上来就闷头写代码，后期返工的成本远大于前期规划的成本。我做这个 SpringBoot+Vue 的高校防艾宣传平台，最大的收获不是代码量，而是“先想清楚，再动手”这个朴素习惯。希望这篇整理能帮到正在做同类项目的你。
