Spring Boot全栈项目实战：网易云音乐系统跑通与改造指南

开头先说结论。Java 网易云音乐系统是一个典型的 Spring Boot 全栈练习项目，它不是只能跑通一个页面的教学 Demo，而是把用户、歌曲、歌单、评论、搜索、收藏这些常见业务全部串联起来，正好覆盖 Java 后端开发在毕业设计和简历里最常被考核的知识点。如果你正在用 IDEA 写 Java 项目，想找一个能快速跑起来、又能讲清楚业务逻辑的源码项目，这类系统很适合花一个小时左右完整过一遍。最值得关注的不是界面有多像官方 App，而是它的模块划分、数据库设计和接口调用方式，这些才是面试和答辩时真正能说出口的东西。

这类项目在毕设场景里属于性价比很高的一档。相比图书管理系统、学生管理系统，网易云音乐系统天然带有多表关联、用户状态、播放列表、搜索筛选这些更贴近真实业务的场景；相比秒杀系统、电商中台，它的复杂度又刚好控制在一个人能在一到两周内消化的范围。所以“毕设必备”这个说法不算完全夸张，前提是你真的把每个模块跑明白、能改、能讲，而不是只把源码导入 IDEA 点一下启动按钮就结束。

下面按实际操作顺序展开，从环境准备、导入源码、配置数据库，到跑通功能、排查报错、改造扩展和简历包装，每个环节都给出可执行的判断标准。

1. 先判断这个项目适合谁，能解决什么问题

1.1 它到底属于哪种类型的 Java 项目

从技术层面看，这是一个基于 Spring Boot 开发的单体 Web 应用。后端负责提供接口和数据逻辑，前端页面负责展示和交互，数据库存业务数据。常见组合是 Spring Boot + Spring MVC + MyBatis（或 JPA）+ MySQL + Maven + Lombok，具体以你拿到的源码为准。

这里要区分一个容易混淆的点：网易云音乐系统不等于真的要去对接版权、音频流、实时推荐这些商业级能力。作为毕设和简历项目，它一般只做到“音乐业务管理”这一层，比如用户注册登录、歌曲列表、歌单创建、评论、收藏、搜索、后台数据管理。音频文件通常用静态资源或外链代替，推荐功能也多是基于播放量、收藏数做简单排序。理解这一点很重要，否则你会在“为什么不能真正播放歌曲”这种问题上浪费时间。

1.2 为什么这类项目适合写进简历

很多简历项目写出来只有一句“基于 Spring Boot 实现 XXX 系统”，这个描述没有信息量。网易云音乐系统能写进简历，是因为它天然具备几个面试官关心的点。

第一，它有完整的用户体系。注册、登录、鉴权、会话管理这些不是单纯调一个现成框架就能糊弄过去的，你需要理解 Session、Token、拦截器或 Spring Security 的配置。

第二，它有典型的多表关联。用户表、歌曲表、歌单表、评论表、收藏表之间都存在外键关系，写接口的时候会涉及联表查询、事务处理、嵌套 JSON 返回等实际问题。

第三，它有可扩展的业务场景。你可以把普通的 CRUD 升级成分页、模糊搜索、热门榜单、播放队列，这些扩展点正好是面试时可以主动讲的亮点。

另外，从“一小时搞定”的角度看，这类项目的模型足够小，后端代码通常只有几十个类，数据库表在十张左右，导入 IDEA 后，只要依赖下载完成、数据库连接配置正确，基本能直接启动，不需要花大量时间搭环境。

1.3 一小时跑通的前提条件

标题里说一小时搞定，这个判断基本成立，但有一个前提：环境已经准备好。如果 JDK、Maven、MySQL、IDEA 一个都没装，那时间主要会花在环境安装上，而不是项目本身。

更稳妥的计划是这样拆分：

• 环境准备：JDK 8+、Maven、MySQL、IDEA 社区版，预计 30 到 60 分钟，取决于本机情况。
• 源码导入和依赖下载：5 到 15 分钟，取决于网络和 Maven 镜像。
• 数据库配置和启动验证：10 到 20 分钟。
• 功能走查和代码阅读：1 到 2 小时，这部分才是真正有价值的。

所以“一小时搞定”适合已经有一定 Java 基础的人。如果你连 JDK 和 Tomcat 的区别都不清楚，建议先把基础补一补，再拿这个项目练手，否则遇到报错会不知道怎么定位。

2. 动手前先把手里的环境理顺

2.1 开发工具和依赖版本怎么搭配

我一般会建议先确认版本，再导入源码，因为“项目跑不起来”最常见的原因不是代码写错，而是 JDK 版本、Maven 版本和依赖不兼容。

推荐的基础环境如下：

这里要注意，原始材料没有提供具体版本信息，所以你导入源码后第一件事，是看pom.xml里定义的 Spring Boot 版本、Java 版本和依赖版本，再看本地 JDK 是否匹配。尤其是当你下载的项目时间比较旧时，Spring Boot 版本和 JDK 版本容易冲突。

2.2 数据库要准备到什么程度

Spring Boot 项目通常不会把数据库自动建好，而是提供一个 SQL 脚本让你手动导入。操作顺序一般是：

1. 安装并启动 MySQL 服务。
2. 在 MySQL 中创建一个数据库，名字以源码里的application.yml或application.properties为准。
3. 执行源码目录下提供的.sql脚本，导入表结构和初始数据。
4. 修改配置里的数据库地址、账号、密码。

很多人会跳过 SQL 脚本，直接启动项目，结果程序不报错，但页面上没有数据，或者提示表不存在。这个问题通常不是代码问题，而是数据库没有初始化。

我建议导入数据后，先在 MySQL 客户端里执行一条查询，确认核心表存在。比如查询用户表、歌曲表、评论表，能查出数据说明初始化成功。这样做的好处是，将来出现问题，你能快速区分是数据问题还是接口问题。

2.3 依赖下载慢和 IDEA 插件问题的提前处理

第一次导入 Maven 项目时，依赖下载时间可能很长，甚至卡住。这通常是因为 Maven 默认连接的中央仓库在国外。处理方式很简单：修改 Maven 的settings.xml，把镜像地址换成国内镜像。

这里给一个常见配置示例，实际路径以你的 Maven 安装路径和 IDEA 内置 Maven 路径为准。

<mirrors> <mirror> <id>aliyun</id> <name>aliyun maven mirror</name> <url>https://maven.aliyun.com/repository/public</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors>

配置完成后，在 IDEA 里刷新 Maven 项目，等待依赖下载完成。如果已经下载到一半但报错，可以先执行mvn clean再重新导入，不建议反复修改pom.xml来试探，那样只会把问题搞复杂。

另外，如果源码里使用了 Lombok，但你的 IDEA 没安装 Lombok 插件，或者没有开启 Annotation Processing，编译时会出现找不到 getter、setter 或 constructor 的报错。处理办法是：在 IDEA 插件市场安装 Lombok，并在 Settings 里开启 Annotation Processing。这个问题在 Java 项目中非常常见，提前处理能省不少时间。

3. 从源码到跑通：完整操作流程

3.1 解压和导入 IDEA 的正确顺序

拿到源码压缩包后，不要直接双击打开文件，也不要只拖动一个 Java 文件到 IDEA 里。正确的做法是：

1. 解压源码到某个不含中文和空格的目录下，例如D:\project\music。
2. 打开 IDEA，选择Open。
3. 选中刚才解压的目录，不是选中某一个.java文件。
4. IDEA 识别到pom.xml后，会提示作为 Maven 项目导入，选择信任并导入。
5. 等待 Maven 下载依赖，下载完成后右键pom.xml，执行Reimport。

这里特别说一下目录问题。如果你解压后项目名带中文，或者放在微信、网盘的同步目录里，某些情况下可能导致资源路径读取异常。虽然不一定会报错，但为了减少变量，项目最好放在一个干净的本地目录。

IDEA 导入完成后，左侧的 Project 面板里应该能看清项目结构：src/main/java存放 Java 源码，src/main/resources存放配置文件，src/main/resources/static存放静态页面资源。如果结构不清晰，说明导入的目录不对。

3.2 数据库配置和 SQL 初始化

依赖下载完成后，打开src/main/resources下的配置文件，通常叫application.yml或application.properties。

常见配置项包括：

• 端口配置：server.port，默认可能是 8080。
• 数据库地址：spring.datasource.url。
• 数据库账号密码：spring.datasource.username和spring.datasource.password。
• 数据库驱动：spring.datasource.driver-class-name。

下面是一个通用示例，具体字段名和值以源码为准：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/music?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver

注意 URL 里的数据库名必须和 SQL 脚本里创建的数据库名一致。如果你使用 MySQL 8.0，驱动类通常是com.mysql.cj.jdbc.Driver，并且 URL 里推荐带上serverTimezone，否则可能报时区错误。

然后执行 SQL 脚本。你可以在 IDEA 右侧的 Database 面板里执行，也可以用 Navicat、命令行等工具执行。这里给一个命令行示例：

mysql -u root -p source D:/project/music/sql/music.sql;

执行成功后，在 MySQL 里执行show tables;查看表是否创建成功。这一步是验证数据库初始化的关键，比直接启动项目更可靠。

3.3 启动项目并验证核心功能

数据库准备好后，找到 Spring Boot 启动类。启动类一般位于某个 package 下，类名通常包含Application字样，比如MusicApplication或Application。在 IDEA 里直接点击该类main方法旁边的绿色箭头启动。

启动成功的标志不是看到红色字，而是要满足以下几点：

• 日志中出现Started XXXApplication in x.xxx seconds或Tomcat started on port(s): 8080这类信息，具体以 Spring Boot 版本为准。
• 控制台没有直接抛出异常堆栈。
• 浏览器访问http://localhost:8080能看到页面，具体地址以配置端口和项目内容为准。

这时候不要急着点所有菜单，先做一次最小验证：注册一个账号，或者用初始账号登录，进入首页，打开歌曲列表，播放一首歌（或至少看到音频资源能加载）。然后把歌单、收藏、评论各点一遍。这个过程是为了确认前后端数据链路是通的，而不是单个页面静态显示。

3.4 单条链路跑通后再改代码

很多新手在项目刚启动成功时，就开始改样式、改标题、加功能。这个顺序不太对。更高效的方式是：先跑通一个完整链路，再改动代码。

完整链路指的是“用户操作 -> 后端接口 -> 数据库读写 -> 页面展示”这个闭环。举例来说，用户注册时，前端把账号密码提交到后端接口，后端处理后再写入数据库。如果这条链路能跑通，说明项目的骨架是健康的；如果这条链路有问题，那么后面所有新增功能都会受到影响。

等到闭环跑通后，你每改一个地方，都能快速判断影响范围。比如你要改用户表字段，就知道要同时改实体类、Mapper、前端表单和数据库脚本；如果只改数据库而漏掉后端代码，页面就会报错。

4. 功能模块拆解：从用户看得见的地方理解代码

4.1 用户、登录、权限怎么落地

网易云音乐系统里，用户模块一般包括注册、登录、退出、个人信息查看和修改。从代码角度看，这会涉及用户实体类、用户数据访问接口、登录校验逻辑和控制器层接口。

有一个问题值得优先搞清楚：登录状态是怎么保存的？有些项目用 Session，有些项目用 JWT Token，还有的会基于 Spring Security 做统一认证。你不需要把每种方案都学会，但必须理解你拿到的项目用的是哪一种。否则面试官一问“登录之后，后端怎么知道当前请求是谁”，你答不上来。

以常见做法为例，登录成功后，后端会把用户 ID 或用户信息放入 Session，拦截器再校验请求是否携带有效 Session。如果项目使用 Token，前端每次请求会带上 Token 字段，后端通过过滤器或拦截器解析 Token。这两种方案的差异、各自优缺点，本身就是面试点。

4.2 歌曲、歌单、评论、收藏的数据关系

这部分是整个项目中最值得画图理解的地方，也是面试时最能展示业务分析能力的部分。

基本关系通常是这样：

• 用户和歌单：一个用户能创建多个歌单，歌单属于某个用户。
• 歌单和歌曲：一个歌单可以包含多首歌曲，一首歌曲可以出现在多个歌单里，这是典型的多对多关系，一般会通过中间表关联。
• 用户和歌曲：用户收藏歌曲，属于多对多关系。
• 用户和评论：用户对歌曲或歌单发表评论，是一对多关系。

从代码上看，多对多关系一般会拆成中间实体，比如歌单歌曲表，包含歌单 ID 和歌曲 ID。如果项目没有拆中间表，后续做“删除歌曲时歌单同步更新”会非常麻烦。

看代码的时候，我建议按“实体类 -> Mapper 接口 -> 控制器接口 -> 前端调用”这条线去读，不要只看控制器层。尤其要搞清楚一个列表接口为什么能返回歌单信息和歌曲列表，是 SQL 里联表查的，还是先查歌单再循环查歌曲。这两种写法的性能差异很大，第一种适合数据量可控的场景，第二种虽然简单但容易造成 N+1 查询，数据量大时会很慢。

4.3 搜索和首页的数据聚合

导航栏里的搜索功能一般会同时查歌曲名、歌手名，有些项目还会支持模糊搜索。实现方式可能是 SQL 里的LIKE查询，也可能是先查出全部数据再在内存中过滤。前者会写进接口里，后者在数据量小的时候看不出问题，但放到面试里，你需要能说出区别。

首页通常包含轮播图、推荐歌单、热门歌曲、新歌上架等模块。这些模块的数据来源可能不一样：推荐歌单可能按收藏量排序，热门歌曲可能按播放次数排序，新歌可能按发布时间排序。读代码时不要只看页面效果，要去后端接口里确认排序逻辑。

如果某个项目把所有模块的数据都写死在页面上，那这个项目的改造空间就比较小。一个好的源码项目，至少应该让首页数据来自接口，这样你才能通过替换排序算法或查询条件，延展出“个性化推荐”这种亮点功能。

4.4 后台管理模块一般长什么样

后台管理模块通常是给管理员使用的，功能包括用户管理、歌曲管理、歌单管理、评论审核等。它和前台共享同一套数据库，但接口路径和权限控制不同。

看后台模块时，重点关注两点。第一，管理员身份是怎么区分的，用户表里一般会有角色字段，比如role或type；第二，权限校验是不是统一的，常见做法是在拦截器里判断当前登录用户是否为管理员，如果不是就拦截请求。

这部分在答辩和面试时可以主动提，因为它能体现你对角色权限的理解。不过要注意，如果源码里的后台只是“隐藏按钮”而没有真正做接口拦截，那它只能算前台演示，不能说成后台权限管理。

5. 运行中的资源占用、验证标准和日志判断

5.1 启动成功的标志不是“没报错”

很多人看到 IDEA 控制台没有红色报错，就觉得项目跑起来了，这个判断不够可靠。Spring Boot 项目在启动时会加载大量的 Bean，如果配置有问题，应用可能会启动失败后自动停止，也可能启动一部分后卡住。

更可靠的标志是日志中出现“Started”字样。如果日志里只看到Tomcat started on port(s): 8080，说明 Web 容器已经启动，但 Spring 容器初始化可能还没结束。要等出现完整的Started XXXApplication才算完成。

如果项目启动后，浏览器访问页面一直在转圈，但 IDEA 没有直接报错，优先看 IDEA 控制台有没有新的日志输出。通常页面无法访问时会留下异常记录，比如数据库连接超时、接口报 500、静态资源 404。这些日志比页面上显示的“服务器错误”更有排查价值。

5.2 端口、日志、数据表的验证方法

验证项目是否真的正常工作，我一般会按这个顺序来：

1. 确认端口监听。启动日志显示的端口和application.yml里的端口是否一致。
2. 打开浏览器访问首页，确认页面能加载，不是空白页。
3. 打开浏览器开发者工具里的 Network 面板，看接口请求状态码是不是 200。
4. 在数据库里检查数据变化，比如注册一个用户后，用户表是否多了一条记录。
5. 如果项目有日志文件配置，可以查看日志文件里是否记录请求信息。

这里要知道，前端页面能打开，不代表接口正常。有些项目把前端静态页面和后端接口分开，页面先加载出来，接口请求却失败了。所以看 Network 面板里的状态码非常关键。如果接口返回 404，优先检查请求路径和控制器里的映射路径是否一致；如果返回 500，优先看 IDEA 控制台里的异常堆栈。

5.3 资源占用和并发边界

本地跑通一个 Spring Boot 项目，对硬件要求并不高。一个常见的判断标准是：在开发环境下，启动后的内存占用可能在几百 MB 到 1GB 左右，具体和依赖数量、项目规模有关。如果你的机器内存较小，不要同时打开 IDEA、MySQL、浏览器、微信和一堆后台程序，否则容易出现卡顿或内存不足。

关于并发边界，这里要有一个清醒的认识：本地能跑通，不代表能支持大规模并发。Spring Boot 默认的内嵌 Tomcat 线程池有默认配置，但业务接口往往没有做限流、缓存和性能优化。在面试或答辩时，不要说出“我的系统能支撑高并发”这种话。更稳妥的说法是：“项目在单体架构下可以正常完成业务闭环，如果要提升性能，可以引入缓存、分库分表或异步处理。”

我实测时一般会先跑“单用户连续操作”场景：注册、登录、搜索、收藏、评论，再刷新页面看数据是否一致。这个过程能覆盖大部分基础接口。如果项目支持批量导入歌曲，或者有循环播放列表，再测试批量场景。千万不要一上来就用压测工具打高并发，先确保功能正确，再谈性能。

6. 常见报错排查链路

6.1 启动直接失败：先看端口和数据库

项目启动失败时，不要急着在网上搜报错原文，先按这条链路排查。

第一步，看端口。如果日志里出现Port already in use，说明 8080 端口被占用。处理方法有两种：关闭占用端口的程序，或者在application.yml里修改端口。

# 查看端口占用，Windows 示例 netstat -ano | findstr 8080

第二步，看数据库连接。如果日志里出现Cannot create PoolableConnectionFactory或Access denied for user，说明数据库地址、账号、密码或驱动配置有问题。先确认 MySQL 服务是否启动，再确认用户名密码是否正确。

第三步，看数据库是否存在。如果日志提示Unknown database 'music'，说明你还没创建数据库，或者数据库名和配置文件不一致。

很多启动失败都是这三类问题，先定位到具体哪一类，再针对性修改，不要盲目改代码。

6.2 编译报错：优先检查 Lombok、JDK 版本和 Annotation Processor

如果你在 IDEA 里看到大量红色报错，但代码看起来没有语法问题，常见原因有三种。

第一种是 Lombok 插件没安装。Spring Boot 项目里常见@Data、@Slf4j等注解，如果 IDEA 没有对应插件，IDE 会提示找不到getter、setter或log方法。

第二种是 JDK 版本不对。比如项目要求 JDK 8，但你本地用了 JDK 17，某些依赖版本可能不兼容。这时可以在 IDEA 的 Project Structure 里查看 Project SDK 是否匹配。

第三种是 Annotation Processing 未开启。IDEA 默认可能没有开启注解处理器，Lombok 在编译阶段无法生成代码，导致编译失败。开启方式是在 Settings 里搜索Annotation Processors，勾选启用。

排查顺序建议是：先看报错信息里有没有 Lombok、log、getter、setter 等关键词，再看 JDK 版本，最后看 Annotation Processing。不要一上来就删除 pom 里的依赖。

6.3 页面打不开或接口 404：路径、静态资源和请求地址一起查

项目能启动，但页面打不开，或者接口一直 404，这类问题卡住很多人。

如果是首页打不开，先确认访问的端口和路径。Spring Boot 项目如果使用静态页面，一般放在src/main/resources/static下，访问根路径时可以映射到index.html。如果页面放在templates下，需要配合模板引擎访问。

如果是接口 404，检查 Controller 类的@RequestMapping和方法的@GetMapping或@PostMapping地址是否和前端请求地址一致。特别留意斜杠问题，比如前端请求/api/user而后端映射是/user，就会 404。

还有一种情况：项目能启动，但静态资源加载不出来，页面排版乱了。通常是静态文件路径不对，或者浏览器缓存了旧资源。可以先强制刷新浏览器，再检查 Network 面板里静态资源的响应状态。

6.4 依赖冲突和 Maven 缓存问题

依赖层面的报错往往更隐蔽，因为代码没错，数据库也没错，但编译或运行时就是报类找不到。

常见的现象是ClassNotFoundException或NoSuchMethodError。这通常是因为某些依赖版本冲突。处理办法是：在 IDEA 的 Maven 面板里选择项目，执行clean和package，观察完整报错信息。如果提示某个类找不到，可以在pom.xml里检查是否引入了多个版本的同一依赖。

另一种情况是 Maven 本地仓库缓存损坏。这时候可以在本地 Maven 仓库目录下找到对应的.lastUpdated文件，或者直接删除相关目录后重新下载。

这类问题比较耗时，我不建议一开始就往下追。顺序应该是：先清编译缓存，再换 Maven 镜像，最后检查依赖树。不要为了修复一个问题，连续修改多个配置，否则很难定位根因。

7. 改造方向和简历写法

7.1 想让它从“课程作业”变成“项目”

只把源码跑通，在面试官眼里这是课程作业；加入自己的改造，并在面试时讲清楚改造思路，才叫项目经历。

改造不需要完全推翻原项目，可以从几个低成本的方向入手。

方向一：接口返回值统一化。把原本直接返回Map或Object的接口，改造成统一的Result结构，包含状态码、提示信息和数据。这个改动涉及面小，但能显著提升代码规范度。

方向二：加入简单的缓存。如果项目中有热门榜单、推荐歌单这类读多写少的接口，可以引入 Redis 缓存查询结果，并设置过期时间。这样你可以在简历里写“使用 Redis 缓存热门歌单数据，降低数据库压力”。

方向三：文件上传和静态资源管理。音乐项目通常涉及封面图和音频文件，如果原项目只是存 URL，你可以扩展成本地文件上传或 OSS 对象存储。

方向四：增加一个简单的后台数据统计页面，比如统计用户数量、歌曲数量、收藏量排行。这个功能能体现聚合查询和图表展示能力。

每个改造都要对应一个你面试时能回答的问题，比如“为什么加缓存”“缓存和数据一致性怎么处理”“如果缓存挂了怎么办”。只写代码不准备问题，等于没改。

7.2 简历里的项目描述怎么写

简历不是流水账，不要写“负责用户登录、歌曲管理、评论功能”，而是写“做了什么、用了什么、达成了什么效果”。

这里给一个参考写法思路：

项目名称：网易云音乐系统 技术栈：Spring Boot、Spring MVC、MyBatis、MySQL、Maven、Lombok 个人职责： - 搭建基于 Spring Boot 的后端工程骨架，设计用户、歌曲、歌单、评论等核心表结构。 - 实现用户注册登录和会话校验，完成歌曲模糊搜索、歌单收藏、评论发布等接口开发。 - 使用统一返回对象处理接口响应，优化歌曲列表查询逻辑，减少无效联表查询。 - 负责项目在本地环境的部署验证，整理部署文档和 SQL 初始化脚本。

注意，这里不要写“我优化了性能提升 100%”这样的虚假数据。没有压测数据支撑的优化描述，面试官追问两句就会露馅。更稳妥的是写“可控范围内减少重复查询”“梳理清楚表关系”这类真实、可验证的描述。

7.3 面试官大概率会问的问题

准备面试时，围绕这个项目，我建议把下面这些问题先背熟：

• Spring Boot 的启动流程是什么？为什么不用配置 Tomcat？
• 项目里用户登录是怎么实现的？Session 和 Token 有什么区别？
• 歌曲和歌单之间的多对多关系在数据库里怎么设计？
• 搜索功能是怎么实现的？如果不使用数据库LIKE，还有什么方案？
• 后端接口一般怎么返回数据？统一返回对象有什么好处？
• 项目中遇到的最难解决的问题是什么？最后怎么排查和修复的？

这些问题不需要全部答得很深，但每个都要能说出一两句真实理解。比起背定义，面试官更看重你能否结合项目里的某个具体场景来回答，比如“我在搜索接口里用了LIKE，但发现数据量大时会慢，所以后续可以考虑用全文索引或搜索引擎，但考虑到项目规模，目前没有引入”。

7.4 后续优化空间

从长远看，这个项目还可以往几个方向延伸。

一是引入 Spring Security 或 Sa-Token，把登录鉴权做得更规范。当前项目如果只是靠拦截器判断登录状态，面试时可以说明“当前实现适合学习场景，如果生产使用，会引入统一权限框架”。

二是增加数据校验和统一异常处理。比如参数为空、用户不存在、重复注册这些情况，不能只靠前端提示，后端也要返回明确的错误码。

三是把前端从传统静态页面升级成 Vue 或 React 项目，通过 RESTful 接口交互。这个改动可以让你在简历里同时写前后端分离，但改造量较大，需要评估时间。

四是补充单元测试和接口文档。哪怕只是给核心接口写几个测试用例，都能体现你的工程化意识。

说到底，这类项目的价值不在于功能多么华丽，而在于你能不能顺着完整链路把业务、接口、数据库、部署串起来讲清楚。跑通只是一个开始，真正拉开差距的是后续的改造、思考和排查能力。如果你做到那一步，这个项目的“毕设”任务和“简历必备”价值，基本就都拿到了。