企业官网建设流程全解析

如果你正在为计算机毕业设计选题发愁，恰好又看到“基于Python的音乐界面设计与实现”这个方向，我先给个结论：这个题可以做，而且做好的难度不算高，但前提是你要把“界面”当成前端工程来做，而不是当成画图。我上个月刚带一个学弟把这个题目完整跑完，前后端分离、源码、文档、代码讲解全部整理清楚，今天把整个过程中的设计思路和踩坑点写出来，供正在选题或者已经开题的同学参考。

做毕业设计最怕的不是题目难，而是题目看起来很大，你交的东西却撑不起来。音乐界面这个题目，表面上是做一个能放歌的网页，实际上它把Python服务端开发、关系型数据库设计、前端组件化、前后端联调这些计算机专业核心技能全部串起来了。你用一套完整的技术栈把它实现出来，再做一份像样的文档报告，答辩时基本不会被问到无话可说。

这篇文章我会按我实际带项目的顺序来讲：先讲选题时怎么控制范围，再讲技术选型，然后是工程结构、界面设计、后端实现、联调避坑，最后讲源码、文档报告和代码讲解这三样东西怎么准备才算合格。全文涉及大量可以直接抄走的代码和表格，但更重要的是每条结论背后的理由。

1. 选题前先想明白：界面、音乐、实现，三件事分别是什么

1.1 别把“界面设计”理解成画图

很多同学看到“音乐界面设计与实现”这个题目，第一反应是：做一个好看的网页播放器就行。这是最大的误解。题目里的“界面”两个字，在计算机毕设语境下，指的是整个前端交互层，包含页面布局、组件设计、状态管理和前后端协作方式。它不是Photoshop里画一张效果图，而是用代码搭出一个可以真实操作的Web应用。你交给导师的成果，应该是一个打开浏览器就能注册、登录、搜索、播放音乐的完整系统，而不是一张UI稿。

那“基于Python”又是什么意思？表面意思是后端用Python写，但往深一层，是要求你掌握用Python搭建Web服务、操作数据库、处理文件上传下载这些能力。毕设考察的不只是你会不会调用某个库，而是你能不能把一个需求拆成模块，再把模块用工程化的方式组织起来。所以我当时给学弟的建议是，选题归选题，真正开工前先想清楚：这个项目要证明你具备哪些能力，这些能力在文档和答辩里怎么体现。

1.2 一个能自我控制大小的功能边界

“音乐界面设计与实现”这个题，可大可小。往小了做，一个登录页加一个播放器页也能交差；往大了做，歌单、评论、推荐、歌词滚动、在线榜单都能塞进去。最怕的是没有边界，想一出是一出，最后代码写了一万多行，自己却讲不清核心逻辑。

我建议按“一个最小可用闭环加三个扩展点”来规划。最小闭环是：用户注册登录、音乐列表展示、搜索、播放控制、收藏和播放历史。三个扩展点分别是：歌单管理、歌词展示、后台歌曲管理。先花两周时间把最小闭环完整跑通，再去考虑扩展点。这样即使最后时间紧张，核心系统也是完整的，不会出现功能很多但全都没做扎实的情况。

1.3 这个题目的天然优势与隐藏风险

优势很明显。第一，音乐类产品界面表现力强，录演示视频比图书管理系统好看太多，答辩时有天然的展示优势。第二，前后端分离的架构很容易说清楚，数据流、接口文档、部署方式都有标准答案，不会像算法类题目那样被追问到哑口无言。第三，音频资源的处理有很多成熟工具，不需要你从底层实现解码。

隐藏风险也有三个。第一，版权问题，演示用的音乐文件建议用无版权或自己录制的音频，不要拿商业版权库里的音乐直接放进项目里展示。第二，音频播放涉及跨域、Range请求、编码格式等一堆边角问题，如果不提前踩坑，演示当天很可能放不出声音。第三，如果导师要求你部署到真实服务器，学生服务器的带宽可能撑不住音频流，所以设计时就要让音频文件走独立的静态资源路径，至少要在文档里写明这种可扩展性。

2. 技术选型不是越新越好：为什么是 FastAPI + Vue3 + SQLite

2.1 后端没有选 Django，选 FastAPI 的理由

Python后端三件套里，Flask、Django、FastAPI各有拥趸。放在毕设场景下，我最终建议选FastAPI，理由有三个。

第一，FastAPI自带OpenAPI接口文档，启动服务后访问/docs就能看到所有接口的请求参数、返回结构和在线调试界面。这份文档可以直接截图进毕设报告，答辩时也能现场演示给老师看，省掉大量手写接口文档解释的功夫。第二，FastAPI基于Pydantic做参数校验，你定义一个请求体类，前端传错了类型后端会自动返回422错误，这个特性让前后端联调时排查问题非常直观。第三，FastAPI是异步框架，虽然毕设数据量不大，但在写音频文件响应、调用外部工具时能省不少事。

可能有人会问，Django不是自带Admin后台吗？Django确实自带，但Django的默认开发模式是服务端渲染模板，想做前后端分离需要额外配DRF，学习曲线比FastAPI陡。而且Django内置功能太多，很多同学用着用着就去研究它的中间件和信号机制，反而偏离了毕设主线。Flask则太轻，接口文档要自己装flasgger，异步支持也一般。

我给的结论是：如果导师不强制指定框架，FastAPI是当前前后端分离毕设里性价比最高的选择。

2.2 前端选 Vue3 + Element Plus，界面成型快

前端框架的选择，决定了“界面设计”这部分的工作量。我推荐Vue3配合Element Plus组件库，配合Vite构建工具。

实际操作下来，Element Plus提供的表格、表单、弹窗、消息提示、分页组件，几乎覆盖了音乐管理系统后台管理页面的所有常见需求。前台页面如果需要更强自定义，就自己写样式，但登录页、用户信息页、歌曲管理页这些“管理型界面”直接用组件库，开发速度会快很多。

为什么不选React？不是说React不好，而是React生态里的Ant Design虽然成熟，但React的学习曲线对很多毕设同学来说偏陡，JSX语法、Hooks依赖数组、状态管理方案选择都容易让人混乱。Vue3的组合式API配合<script setup>，模板语法更接近普通HTML，组件之间传值也更直观，对“先保证毕业设计能跑通”这个目标来说更合适。

前端工程化这块我建议固定版本：Node 18 LTS以上，npm或pnpm都行，Vite 4以上。创建项目时用npm create vite@latest，选择Vue模板即可，不要手动去配Webpack，浪费时间也没有增量收益。

2.3 数据库、媒体文件和环境版本怎么固定

数据库方面，SQLite和MySQL之间我选了SQLite，而且这可能是最容易被导师质疑的点。我的应对方式是：用SQLAlchemy ORM操作数据库，底层连接SQLite，所有数据表在代码里定义，答辩时主动解释“本地演示用SQLite零配置，如果部署上线，只需要改一个数据库URL就能切到MySQL或PostgreSQL”。这个说法在毕设答辩里是站得住的，因为它体现了你的工程抽象能力。

媒体文件的存储也需要提前想清楚。音乐本身不是普通文本，一首MP3动辄几MB，放进数据库里绝对不靠谱。正确做法是：音乐文件放在后端服务器的一个media目录下，数据库只保存文件的路径、文件名、时长、歌手等信息。这样播放时前端拿到的是一条静态资源URL，后端只需要把文件用HTTP响应的方式吐出去。

环境版本我建议在项目根目录写一个README.md，固定以下信息：

• Python 3.10+（不要用2.7，也不要追求3.13最新版，部分依赖可能没跟上）
• FastAPI 0.100+，Uvicorn 0.20+
• SQLAlchemy 2.x（1.4和2.0写法有差异，锁版本很重要）
• Node 18+，Vue 3.4+，Vite 5+
• 包管理器：npm或pnpm

这些内容一开始就写清楚，后面换电脑或者导师在自己机器上跑项目时，能少掉一大半环境问题。

3. 工程结构怎么摆：目录、路由、组件，导师一眼能看懂

3.1 前后端加文档三段式目录

毕设项目工程结构看似是小事，实际影响导师对你代码的第一印象。我见过太多把入口文件、工具函数、测试脚本全部堆在根目录下的项目，即使功能做完了，答辩时导师也懒得翻。

我建议用三段式目录，把前端、后端、文档分开：

music-project/ ├── backend/ │ ├── app/ │ │ ├── main.py # FastAPI入口 │ │ ├── models.py # SQLAlchemy数据模型 │ │ ├── schemas.py # Pydantic请求/响应模型 │ │ ├── routers/ │ │ │ ├── auth.py # 注册登录 │ │ │ ├── songs.py # 音乐列表与搜索 │ │ │ ├── favorites.py # 收藏 │ │ │ └── history.py # 播放历史 │ │ ├── core/ │ │ │ ├── security.py # JWT与密码哈希 │ │ │ └── config.py # 配置项 │ │ └── utils/ │ │ └── audio_meta.py # 读取音频元数据 │ ├── media/ # 音乐文件、封面图、歌词 │ ├── requirements.txt │ └── .env ├── frontend/ │ ├── src/ │ │ ├── views/ # 页面级组件 │ │ ├── components/ # 播放器、列表等公共组件 │ │ ├── router/ │ │ ├── store/ # Pinia状态管理 │ │ └── api/ # axios封装 │ ├── package.json │ └── vite.config.js ├── docs/ # 需求分析、设计文档、报告 └── README.md

这样摆的好处是：导师想跑后端进backend目录，想跑前端进frontend目录，想检查设计文档进docs目录。目录的名字不需要额外解释，任何人打开项目都能快速定位。

3.2 前端界面拆解：把播放器拆成可维护的组件

音乐界面的核心是播放器的交互体验。很多同学在做播放器的时候，把所有逻辑塞进一个App.vue页面里，结果代码上千行，根本无法维护。正确的做法是拆组件。

我实际拆出来的组件有这些：

• PlayerBar.vue：固定在页面底部的播放控制条，包含上一首、播放/暂停、下一首、进度条、音量、当前歌曲信息。
• SongList.vue：音乐列表展示，支持点击行播放、排序、收藏按钮。
• SearchInput.vue：搜索框组件，带防抖处理。
• LyricPanel.vue：歌词面板，根据当前播放时间高亮对应歌词。
• AudioPlayer.vue：封装原生<audio>元素，负责播放、暂停、切歌、进度更新，不与页面其他部分直接耦合。

组件拆分的原则是：一个组件只做一件自己能说清楚的事。AudioPlayer只暴露play()、pause()、seek()这些方法，PlayerBar负责界面交互，SongList只负责展示列表并触发事件。这样代码量不但没增加，反而因为逻辑清晰，调试时间大幅下降。

播放器布局上我采用固定底部栏方案，这和主流音乐App保持一致。页面主要内容区域使用卡片式布局，音乐列表每行显示封面、歌名、歌手、时长，鼠标悬停显示播放按钮。配色建议用暗色背景加一个主强调色，比如黑金风格，视觉上更容易出效果。

3.3 路由和状态管理怎么组织

前端路由配合页面结构做映射：

状态管理我用Pinia，不需要把所有数据都放进Store。只有两个全局状态必须放进去：当前播放歌曲、播放器播放状态。因为底部播放栏在所有页面都存在，切歌时需要知道正在播哪首歌，所以播放状态必须是全局的。其他页面数据，比如搜索结果、收藏列表，放在各自页面组件里就够了，放进全局Store反而增加心智负担。

路由守卫也要处理：访问除/login外的页面时，检查本地有没有token，没有就重定向到登录页。这一步是前后端分离项目“用户状态”的基础实现，答辩时经常被问到。

4. 核心功能实现：表结构、API、音频流，每一层都踩过坑

4.1 数据模型设计：五张表覆盖完整业务闭环

后端数据库我设计了五张核心表，每张表都能对应一个业务功能点。

users表存放用户信息，核心字段是id、username、password_hash、created_at。密码绝对不能明文存储，要用哈希算法。我选用passlib配合bcrypt做密码哈希，Python代码里即使数据库文件泄露，也无法直接拿到原始密码。

songs表存放音乐元数据，字段包括id、title、artist、album、duration、file_path、cover_path、created_at。file_path存的是相对路径，比如media/songs/001.mp3，这样项目整体迁移时不会因为绝对路径报错。

favorites表和play_history表分别是用户收藏和播放历史，统一用user_id关联用户、song_id关联歌曲，额外加一个created_at做时间排序。播放历史表要不要去重这个问题，我在实践中建议保留多条记录，方便展示“最近播放”列表，如果用户重复播放同一首歌，可以更新记录时间而不是新增记录，这个逻辑在文档里写清楚就行。

如果需要做歌单扩展，可以加playlists和playlist_songs表，但基础五张表已经能支撑一个完整的音乐应用。表结构设计的核心原则是：一张表只描述一个实体，关联表只做关联，不要把所有字段塞进一张大宽表。

4.2 用户体系与JWT：密码处理和登录态

用户注册和登录接口是几乎所有系统都要做的功能，但在音乐项目里我会用更贴近实际的方式实现：注册接口创建一个用户，登录接口校验密码后返回一个JWT令牌，前端把令牌存在localStorage里，后续所有请求都带上Authorization: Bearer <token>头。

为什么不用Session？因为前后端分离架构下，前端和后端可能部署在不同的域名或端口，Session的Cookie跨域处理非常麻烦，而JWT是无状态的，只在请求头传一个字符串，天然适合前后端分离。答辩时老师如果问起区别，可以从“服务端是否需要保存会话状态”这个角度回答。

核心代码其实很短：

from datetime import datetime, timedelta from jose import jwt SECRET_KEY = "your-secret-key" ALGORITHM = "HS256" def create_access_token(user_id: int): payload = {"sub": str(user_id), "exp": datetime.utcnow() + timedelta(days=7)} return jwt.encode(payload, SECRET_KEY, algorithm=ALGORITHM) def decode_token(token: str): return jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])

注意SECRET_KEY不要硬编码在代码里，放到.env文件中，通过pydantic-settings读取。这个细节虽然简单，但能体现工程意识。

4.3 音乐列表、搜索与上传：文件存本地，元数据存数据库

音乐列表接口和搜索接口是前端音乐广场页的数据来源。接口设计上，我建议统一返回分页结构：

class SongOut(BaseModel): id: int title: str artist: str album: str duration: int cover_url: str audio_url: str class PageResult(BaseModel): items: list[SongOut] total: int page: int page_size: int

搜索功能最简单的实现是SQLite的LIKE查询：

query = select(Song).where( Song.title.contains(keyword) | Song.artist.contains(keyword) )

如果搜索量再大，可以在文档里写明未来可以迁移到全文搜索引擎，但毕设演示阶段SQLite的LIKE完全够用，而且逻辑清晰便于答辩。

歌曲上传是另一个关键点。前端上传MP3文件，后端接收后先存到本地media目录，然后通过mutagen库读取时长和ID3标签信息：

from mutagen.mp3 import MP3 audio = MP3(file_path) duration = int(audio.info.length)

这里有一个我踩过的坑：部分MP3文件的ID3标签是旧版编码，中文歌名和歌手名可能乱码。保险做法是读取标签时加异常处理，如果解析失败就用文件名去掉后缀当作歌曲名。演示阶段不要因为这个小事翻车。

4.4 播放器拖进度条背后是Range请求

大多数毕设音频播放做不好的原因不是前端，而是后端没有正确处理HTTP Range头。浏览器播放音频时，拖进度条需要向服务器发送一个Range: bytes=0-1024这样的请求头，服务器返回206 Partial Content和对应的字节区间，浏览器才能实现拖动播放。

FastAPI的FileResponse和StaticFiles都支持Range请求，这是我选择FastAPI的另一个原因。如果你用的是某些老旧Python Web写法，自己手动拼HTTP响应处理Range，容易出错。最简单的正确写法是：

from fastapi.responses import FileResponse from pathlib import Path @app.get("/media/{file_name}") async def get_media(file_name: str): file_path = Path("media") / file_name if not file_path.exists(): raise HTTPException(status_code=404, detail="file not found") return FileResponse(file_path, media_type="audio/mpeg")

前端拿到音频文件地址后，把它直接塞给<audio>标签的src属性即可。前端播放器组件里，拖动进度条本质是修改audio.currentTime，后端只要正确支持Range请求，拖动就不会卡顿。

我特意在文档里写了一段“音频流媒体支持”的内容，把Range请求和206响应的原理画图说明，这个点让答辩显得很有深度，其实实现就那几行代码。

5. 前后端联调最容易翻车的四个场景和处理记录

5.1 CORS跨域：加了响应头还报错，通常是通配符和credentials打架

开发阶段前端跑在5173端口，后端跑在8000端口，浏览器会拦截跨域请求。解决办法是给后端加CORS中间件：

from fastapi.middleware.cors import CORSMiddleware app.add_middleware( CORSMiddleware, allow_origins=["http://localhost:5173"], allow_credentials=True, allow_methods=["*"], allow_headers=["*"], )

这里有个非常常见的坑：allow_origins如果设置成["*"]，同时allow_credentials=True，浏览器会直接报错，因为带Cookie凭证时不能使用通配符来源。所以要么明确写死前端地址，要么把allow_credentials设为False。学生阶段建议明确写死本地开发地址，不要用通配符。

如果前端用Vite的proxy代理，那么开发环境可以完全不配置CORS。但如果把前端打包后挂在FastAPI的静态目录下，前后端同源了，CORS问题也会消失。两种方案选一种即可，不要混用造成认知混乱。

5.2 Vue Router history模式打包后刷新404

前端路由用history模式时，Vue项目打包后直接扔给后端，刷新页面会404。原因是浏览器请求/search这个路径，后端没有这个路由定义，它返回了404而不是前端页面。FastAPI里可以这样兜底：

# 这段挂载一定要放在所有API路由之后 from fastapi.staticfiles import StaticFiles app.mount("/", StaticFiles(directory="../frontend/dist", html=True), name="frontend")

但这么做要注意：API路由必须全部注册完再挂载静态目录，否则静态目录会拦截掉所有/api请求。我把这个顺序写进了项目文档的部署小节，避免临到答辩部署时踩坑。

如果你不想部署前端，答辩演示时也可以分开跑开发服务器，一个npm run dev，一个uvicorn app.main:app --reload，两个窗口解决，但这样对网络和机器内存要求稍高，现场演示容易手忙脚乱。

5.3 Token失效后的前端拦截

前端所有请求我统一封装在api/request.js里，用axios实例发送。这里要做两件事：请求拦截器自动把token加到请求头，响应拦截器统一处理401错误。

import axios from 'axios' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => response, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )

这样做的效果是：后端任何一个接口返回401，前端都自动踢回登录页，用户不会看到一堆红色报错弹窗。这个小细节在答辩演示时很加分，因为老师实际点着点着，token过期是很常见的情况。

5.4 演示环境里的中文乱码和媒体路径问题

联调阶段容易出现的第四个问题是中文乱码。FastAPI返回JSON时，默认会把中文转成Unicode转义，前端拿到后显示正常，但如果你用命令行curl测试接口，看到的是\u97f3\u4e50。这不影响功能，但会在文档截图里很难看。解决方法是：

from fastapi.responses import JSONResponse # 在FastAPI实例化时设置 app = FastAPI(default_response_class=JSONResponse)

更彻底的做法是启动时设置：

uvicorn.run(app, host="0.0.0.0", port=8000) # 并在创建app时指定 app = FastAPI() app.json_encoder = ...

其实最简单是写一个自定义JSONResponse，但毕设阶段不必过度纠结，保证前端显示正常即可。

媒体路径的问题更实际：音频文件路径千万不要在数据库里存绝对路径，比如C:/Users/.../media/song.mp3，换个电脑就废了。要存相对路径，比如media/song.mp3，前端拼地址时用后端的基础URL加上这个路径。我在README里写了一个启动脚本，自动检查media目录是否存在，不存在就提示先拷贝音乐文件，这个小脚本帮我避免过几次演示现场找不到音频的尴尬。

6. “源码、文档、代码讲解”三件套怎么准备才算合格

6.1 源码工程：注释、README、依赖锁文件一个都不能少

毕设验收时，源码质量不是看代码行数，而是看别人能不能快速跑起来。我建议把源码工程当成一个小型开源项目来整理，最低标准是三条。

第一，依赖锁文件明确。后端必须有requirements.txt，最好有requirements-dev.txt；前端提交package.json和package-lock.json。这样克隆项目后用pip install -r requirements.txt和npm install就能装好依赖。不要只写一行“安装依赖”就完事。

第二，README要写清楚。内容包含项目简介、技术栈、目录结构、环境要求、启动步骤、测试账号、演示数据说明。其中“测试账号”很重要，评委老师可能会现场登录，你得提前准备好一个账号和一个包含若干首歌曲的演示数据库。

第三，关键函数注释不要偷懒。不是每行都写注释，而是要在文件顶部写清楚这个文件的功能，在复杂函数前写清楚输入输出和处理流程。比如audio_meta.py读音频元数据时，注释里写明“兼容MP3 ID3标签解析失败场景”，代码里捕获异常返回文件名，这个细节比注释本身更有价值。

6.2 文档报告的结构和界面设计写法

毕设文档报告我按学校模板来写，但内容上有几个地方可以针对“音乐界面”这个题目做加分处理。

需求分析章节里，不要只贴一张需求列表，要画出不同角色的用例。管理员要能上传音乐、删除音乐；普通用户要能注册登录、搜索、播放、收藏、查看历史。这些交互关系写清楚后，再描述系统用例图，文档结构就很扎实。

系统设计章节里，前后端分离架构必须画出来。前端通过HTTP请求调用后端接口，后端负责业务逻辑和数据库操作，媒体文件通过静态资源路径访问。数据流向可以用箭头描述，不需要复杂工具，在Word里直接画流程图就行。

界面设计是这类题目最容易出彩的章节。我的写法是：先写设计目标，比如“采用暗色主题，降低长时间使用的视觉疲劳，突出专辑封面”；再写布局设计，把每个页面的模块划分列出来；最后贴前端页面的截图，配合设计说明。不要只贴截图不写理由，设计目标是体现你对界面设计的思考，这个思考比截图本身更让导师认可。

测试章节也要完整：功能测试用一张表列出每个功能模块、测试步骤、预期结果、实际结果；接口测试用Postman导出的示例截图，附带后端/docs自动生成的接口文档截图。这些材料准备起来不费时间，但能撑起整个测试章节的厚度。

6.3 代码讲解：按数据流转讲，不逐行念代码

“代码讲解”看起来是和老师面对面讲代码，实际上很多学校现在要求提交讲解视频，或者答辩时需要现场讲代码。不管哪种形式，最忌讳的是从main.py第一行开始念到文件最后一行。

我建议按数据流转来组织讲解逻辑：

1. 前端用户输入用户名密码，点击登录；
2. 请求发送到后端/api/auth/login；
3. 后端校验用户密码，生成JWT返回前端；
4. 前端存储token并跳转首页；
5. 首页请求/api/songs获取音乐列表；
6. 后端查询数据库表，返回分页结果；
7. 前端渲染音乐列表，用户点击播放；
8. 前端从/media/xxx.mp3拉取音频流播放。

按这个顺序讲，你等于把整个系统的前端、后端、数据库、静态文件四个部分串成了一条完整的线。老师听到的是你对项目的整体理解，而不是被具体某一行代码牵着走。整个讲解过程控制在10到15分钟，先演示功能，再讲架构，最后接答辩提问。

6.4 答辩高频问题清单与回答思路

我把带这个项目过程中被问到的、以及预判会被问的问题整理成一个清单，每个都准备了回答方向。

为什么使用前后端分离？回答：前端负责界面展示和交互，后端负责业务逻辑和数据管理，两者通过HTTP接口通信。好处是团队协作时可以并行开发，前端项目可以单独部署到CDN，后端接口可以被多个客户端复用。

JWT和Session有什么区别？回答：Session需要服务端保存会话状态，JWT把用户信息签名后发放给前端，服务端不需要保存会话状态。前后端分离、尤其是以后要扩展到移动端时，JWT更合适。

音乐文件存在哪里？回答：音频文件存服务器的media目录，数据库保存路径和元信息。这样做避免了把大文件存进数据库导致的性能问题，也方便统一托管静态资源。

Range请求是什么？回答：浏览器播放音频时，可以携带Range头请求文件的一部分，服务器返回206状态码和对应字节段，这样播放器可以快进、快退、拖动进度条，不用一次性加载整个音频文件。

你的系统有哪几张表？回答：用户表、歌曲表、收藏表、播放历史表，如果需要歌单功能再增加歌单表和歌单歌曲关联表。然后简要说明每张表的主要字段和表间关系。

扩展性问题怎么考虑？回答：当前用SQLite做演示，如果用户量增加可以切换MySQL；音频文件可以使用对象存储服务；搜索功能可以升级为全文检索。这些扩展方向在系统设计章节有专门描述，表明项目不是只能跑通演示，而是具备演进空间。

最后说点实际的体会

做这类带界面的毕设项目，最大的坑不是不会写代码，而是不会控制范围和不会讲重点。代码写再多，如果文档里看不到设计思路，答辩时说不清一个请求从前端到后端的完整链路，老师很难给出高分。

我实际带项目时发现，很多同学卡住的地方不是 RestAPI 怎么写，而是前端播放组件的状态管理、后端音频文件怎么按请求吐数据、以及联调阶段各种乱七八糟的错误。这些问题单独拿出来都不难，但放在一个完整项目里就会让人抓狂。所以我的建议一直是：先把最小闭环跑通，再美化界面，再扩展功能。顺序反了，大概率会在答辩前一周通宵改bug。

这个题目本身可扩展的方向很多，往音乐社交、个性化推荐、移动端适配几个方向都能延伸。如果你已经选了题，按上面的思路把源码、文档、讲解准备好，拿个不错的成绩是有把握的。