企业官网建设流程全解析

简介：Web开发中，选择一个功能完善且生态成熟的框架往往事半功倍。Django作为Python生态的主流全栈框架，内置ORM、用户认证、Admin后台等模块，为快速构建数据驱动型网站提供了坚实基础。理解MTV架构、数据库模型设计以及文件上传与媒体管理，是掌握Django工程实践的关键。无论是SQLite与MySQL的切换，还是音频文件的存储与流式播放，都体现了后端开发中‘数据与资源分离’的核心思想。这类技术组合广泛适用于内容管理、社交互动、在线教育等场景，也是毕业设计中的热门选题。本文围绕在线音乐网站这一典型项目，从数据建模、播放器对接、用户权限到部署演示，完整梳理基于Python+Django的实现路径，帮助开发者避开常见陷阱，高效完成一个功能完整、可演示的Web应用。 做毕设选题目的时候，十个里有八个会想到做网站。如果再往上加一些听起来上得了台面的功能，比如音乐播放、歌单收藏、评论互动，那就几乎锁定了一个方向：基于Python+Django的在线音乐网站。

我自己见过太多同学拿着这个题目来问，一上来就找“源码”，实际自己动手时却卡在模型设计、文件上传、播放器对接这些地方，折腾一两周还没跑通。这篇文章就按我的实际开发经验，把这个项目从设计思路、数据库建模、核心实现到部署演示完整捋一遍，重点说清楚“为什么这样做”，而不仅仅是贴代码。不管是拿去做毕业设计，还是想自己写一个练手项目，这篇都能当你的“外挂”。

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

1.1 为什么用Django做在线音乐网站

选技术栈是很多人纠结的第一步。只做一个期末小作业，用Flask都行；但如果目标是“毕业设计”，那Django基本是这个题目的最优解。原因有几个：

• 自带Admin后台：音乐网站天然需要管理端来维护歌手、专辑、歌曲信息。Django Admin只要注册一下模型，后台管理页面就出来了，不用额外费力气去写一堆管理界面。
• 自带用户认证体系：登录、注册、session、密码哈希、权限控制都是内置的，音乐网站需要的“登录后才能收藏、评论”这类功能，直接基于这套体系扩展就行。自己手写密码哈希和session很容易写出安全问题，放在毕设里就是埋雷。
• ORM省心事：音乐、歌手、歌单之间的外键关系、多对多关系在Django ORM里非常直观，不用手写一堆SQL JOIN，后期改表结构跑一下迁移就行，这对毕设来说极其友好。
• 生态成熟、资料多：Django的中文资料和社区问答非常丰富，遇到大部分报错把错误信息复制到搜索引擎，基本都能找到答案，这对独立开发经验不多的同学来说太重要了。

1.2 MTV架构在音乐网站里怎么落地

Django的MTV（Model-Template-View）架构，放到这个项目里就是一套很清晰的职责分工：

• Model负责定义数据结构，比如音乐、歌手、用户、评论这些表长什么样。
• View负责业务逻辑，比如用户点了一首歌，View就去查库、更新播放量、返回歌曲文件或页面。
• Template负责页面展示，Django的模板语言能直接把歌手姓名、歌曲时长、封面对应的图片URL渲染进HTML。

我见过不少同学把所有代码堆在views.py里面，一个函数干所有事情，最后改一个功能要牵一发动全身。比较好的组织方式是：每个业务模块建一个独立的app，比如music、user、comment，模块之间通过明确的接口交互，就像搭积木一样一个萝卜一个坑。这样不仅自己维护省心，答辩时老师问你“项目怎么设计的”，你也能讲清楚分层逻辑。

1.3 项目目录结构与环境版本

我建议的项目结构大致是这样的：

music_website/ ├── manage.py ├── requirements.txt ├── config/ # 项目配置 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── users/ # 用户模块 │ ├── music/ # 音乐模块 │ ├── comments/ # 评论模块 │ └── home/ # 首页模块 ├── static/ # CSS/JS/图片 ├── media/ # 歌曲文件和封面 ├── templates/ # 共用模板 │ ├── base.html │ └── ... └── db.sqlite3 # 本地开发数据库

版本选择上，我推荐Python 3.10及以上，Django使用4.2 LTS版本。这个组合稳定、资料多、新特性全，而且Django 4.2是长期支持版本，到2026年4月前都有安全更新。这里要注意，别用Python 2.x或者Django 1.x，那些古董版本和现代写法差异太大，遇到问题搜到的解决方案可能全部失效。

2. 核心数据模型与数据库设计

2.1 音乐网站需要哪些表

在线音乐网站看起来功能不多，但落到数据库设计上，核心实体并不少。我梳理过一份清单，基本能覆盖绝大部分毕设需求：

• 歌手表（Singer）：姓名、头像、简介、地区、创建时间。
• 专辑表（Album）：专辑名、封面、发行日期、所属歌手。
• 歌曲表（Song）：歌曲名、歌手、专辑、音频文件、歌词、播放量、时长、上传时间。
• 歌单表（Playlist）：标题、封面、所属用户、创建时间。
• 歌单明细表（PlaylistItem）：歌单和歌曲的多对多关系中间表。
• 用户表（User）：直接继承Django自带的AbstractUser即可。
• 收藏表（Favorite）：用户与歌曲的多对多关系，记录用户收藏了哪些歌。
• 评论表（Comment）：评论内容、歌曲、用户、父评论、时间。
• 播放记录表（PlayRecord）：哪个用户在什么时间听了哪首歌，能拿来展示“最近播放”。

实体之间大致是这样一种关系：一个歌手有多张专辑，一张专辑里有多首歌；反过来一首歌一定属于某个歌手和某张专辑。用户和歌曲之间通过收藏表、播放记录表产生联系，用户和歌单是一对多，歌单和歌曲是多对多。

2.2 数据模型的核心代码逻辑

下面是一个简化但能直接用的Song模型写法，关键点我都加了注释：

from django.db import models from django.contrib.auth.models import User class Singer(models.Model): name = models.CharField(max_length=100, verbose_name='歌手名') avatar = models.ImageField(upload_to='singer/', blank=True, null=True) intro = models.TextField(blank=True, verbose_name='简介') created_at = models.DateTimeField(auto_now_add=True) def __str__(self): return self.name class Meta: verbose_name = '歌手' verbose_name_plural = verbose_name ordering = ['-created_at'] class Album(models.Model): title = models.CharField(max_length=100, verbose_name='专辑名') cover = models.ImageField(upload_to='album/', blank=True, null=True) release_date = models.DateField(blank=True, null=True) singer = models.ForeignKey(Singer, on_delete=models.CASCADE, related_name='albums') def __str__(self): return f'{self.singer.name} - {self.title}' class Song(models.Model): name = models.CharField(max_length=100, verbose_name='歌曲名') singer = models.ForeignKey(Singer, on_delete=models.CASCADE, related_name='songs') album = models.ForeignKey(Album, on_delete=models.SET_NULL, blank=True, null=True, related_name='songs') audio_file = models.FileField(upload_to='song/', verbose_name='音频文件') cover = models.ImageField(upload_to='song_cover/', blank=True, null=True, verbose_name='封面') lyric = models.TextField(blank=True, verbose_name='歌词') play_count = models.PositiveIntegerField(default=0, verbose_name='播放次数') duration = models.CharField(max_length=10, blank=True, verbose_name='时长') created_at = models.DateTimeField(auto_now_add=True) def __str__(self): return self.name

几个容易踩坑的点：

• on_delete参数一定要显式指定，新版Django里外键必须传这个参数。歌手删除后歌曲怎么办？最常见的是CASCADE级联删除，比较安全的是SET_NULL搭配null=True，这样歌手被删了歌曲还在，只是关联信息变成空。
• upload_to建议按照业务类型分目录，比如音频放song/，封面放album/，不然media目录下会堆成一片混沌。
• related_name最好明确指定，不然后续写ORM时会出现一堆奇怪的song_set，绕来绕去把自己绕晕。

2.3 SQLite和MySQL之间的选择

毕设项目本地演示、上传到GitHub给老师看，SQLite足够了，零配置、单文件、搬运方便。但如果数据量大、并发访问高，或者部署到云服务器上，SQLite容易遇到“database is locked”问题，这种情况就应该换成MySQL。

切换到MySQL时，除了在settings里改数据库配置，还要注意：

• 创建数据库时指定UTF-8字符集，否则中文很容易变成问号：

  CREATE DATABASE music_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

• 安装连接驱动：

  pip install pymysql # 然后在项目__init__.py里添加 import pymysql pymysql.install_as_MySQLdb()

3. 音乐播放与文件管理的核心实现

3.1 音频文件到底存在哪里

这是一个容易被忽视但对毕设项目很核心的问题：歌曲文件是直接存数据库，还是存文件系统、数据库只存路径？

答案很明确：存文件系统，数据库里只存文件的路径（URL）。把音频文件以BLOB字段塞进数据库，会让数据库文件膨胀得飞快，备份、迁移都变得极其痛苦，播放时还要把整个BLOB读出来再传给浏览器，性能和资源消耗都很差。Django的FileField本质上就是把文件放到MEDIA_ROOT目录下，然后在数据库里存一个相对路径字符串。

在settings里这么配：

MEDIA_URL = '/media/' MEDIA_ROOT = BASE_DIR / 'media'

然后根URL文件里加上静态服务：

from django.conf import settings from django.conf.urls.static import static urlpatterns = [...] if settings.DEBUG: urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

这样模板中就能直接用{{ song.audio_file.url }}拿到可访问的音频地址。

3.2 网页播放器对接

在Django模板里播放音乐，其实就是HTML5的<audio>标签加上歌曲文件的URL，没有任何魔法：

<audio controls> <source src="{{ song.audio_file.url }}" type="audio/mpeg"> 您的浏览器不支持音频播放。 </audio>

不过如果只做到这一步，体现不出一个在线音乐网站的气质。我建议加一个全局播放栏，就是那种页面底部固定、切换页面也不中断播放的播放器。做法很简单：把当前播放列表和当前播放索引放在JavaScript全局变量里，点击歌曲时动态更新<audio>的src并调用play()。具体可以这样：

let playList = []; // 当前播放列表 let currentIndex = 0; function playSong(songId, songName, songUrl, coverUrl) { const audio = document.getElementById('globalAudio'); audio.src = songUrl; audio.play(); // 更新播放器UI document.getElementById('nowPlayingName').innerText = songName; // 记录到后端 recordPlay(songId); } function nextSong() { currentIndex = (currentIndex + 1) % playList.length; playSong( playList[currentIndex].id, playList[currentIndex].name, playList[currentIndex].url, playList[currentIndex].cover ); }

这里有一个很现实的问题：服务端怎么知道播放了一首歌？你不希望每次切歌都刷新页面，所以要写一个异步上报接口，比如POST /api/song/play/，前端每次播放新歌时往后台发送一个歌曲ID和时间戳，后端据此更新播放次数和播放记录。

3.3 上传音乐的校验和封面上传

如果你打算做一个后台管理页面，让管理员上传歌曲，那么文件校验这块儿必须处理好。我踩过最深的坑就是：前端只校验扩展名，恰好某个用户上传了一个改名为.mp3的垃圾文件，后台播放时直接卡死。

建议在后端同样校验，至少做两层：

def validate_audio_file(file): # 扩展名校验 ext = os.path.splitext(file.name)[1].lower() if ext not in ['.mp3', '.wav', '.ogg', '.m4a', '.flac']: raise ValidationError('不支持的音频格式') # 大小校验，限制为20MB if file.size > 20 * 1024 * 1024: raise ValidationError('文件大小不能超过20MB') return True

封面上传同理，建议用Pillow库把图片尺寸压缩一下，避免用户传了一个5MB的大图，页面加载速度被拖死。代码大致这样：

from PIL import Image def compress_cover(image_field, max_size=(400, 400)): img = Image.open(image_field) img.thumbnail(max_size) img.save(image_field.path, quality=85, optimize=True)

3.4 关于“流媒体播放”的小加分项

如果想让毕设更亮眼，可以提一下“流式播放”。原理其实不复杂：Django视图里用FileResponse配合HTTP Range头去读取文件的字节片段，浏览器就能实现拖动进度条、续传播放。默认的FileResponse在Django 4.2里已经支持了这个行为，直接用即可：

from django.http import FileResponse def stream_song(request, song_id): song = get_object_or_404(Song, pk=song_id) # 这里可以顺便更新播放次数 song.play_count += 1 song.save(update_fields=['play_count']) response = FileResponse(song.audio_file.open('rb'), content_type='audio/mpeg') return response

答辩时如果老师问“你的网站支持边下边播吗”，你就可以理直气壮地说支持，因为FileResponse本身就是按块读取文件的。

4. 用户系统、权限与业务功能串联

4.1 自定义用户模型还是直接用内置User

Django自带的User模型提供了用户名、密码、邮箱、first_name、last_name等字段，对于音乐网站来说勉强够用，但想给用户加一个“头像”字段、一个“个性签名”字段，就麻烦了——扩展内置User有两种方案：

• 在Django 1.8之后官方推荐的做法是自己定义User模型并继承AbstractUser，这样想加什么字段加什么字段。但注意：必须在第一次迁移数据库之前就设置好，否则中途改User模型会让你想哭。
• 如果项目已经跑起来了，不想折腾User模型，那可以新建一个Profile模型，一对一关联内置User，扩展字段都放在Profile里面。

对于新开工的毕设，我建议直接用第一种：继承AbstractUser。代码非常简单：

from django.contrib.auth.models import AbstractUser class User(AbstractUser): avatar = models.ImageField(upload_to='user_avatar/', blank=True, null=True) nickname = models.CharField(max_length=50, blank=True) bio = models.TextField(blank=True, verbose_name='个人简介')

然后在settings里指定：

AUTH_USER_MODEL = 'users.User'

注册和登录建议直接用Django自带的UserCreationForm改造，不要自己手工拼接密码哈希。Django的make_password、check_password这套内置机制已经处理了盐值和加密算法升级，自己造轮子很容易出现“密码明文存储”这种致命问题。

4.2 收藏、评论、歌单，功能逻辑怎么串

用户登录之后，核心交互无非三块：

• 收藏：用户点击收藏按钮，服务端判断是否已收藏，没收藏则写入Favorite表，已收藏则删除记录，实现收藏/取消收藏的切换。
• 评论：登录用户可以对歌曲发评论，也可以对别人的评论进行回复。为了简单，可以只做一级评论加一个parent字段，前端展示时如果有parent就对楼主做“回复”关联展示。
• 歌单：用户可以创建歌单、删除歌单、往歌单里添加歌曲。歌单和歌曲之间用中间表维护，常用的Django写法是：

class Playlist(models.Model): title = models.CharField(max_length=100) user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='playlists') songs = models.ManyToManyField(Song, through='PlaylistItem', related_name='playlists') cover = models.ImageField(upload_to='playlist_cover/', blank=True, null=True) class PlaylistItem(models.Model): playlist = models.ForeignKey(Playlist, on_delete=models.CASCADE) song = models.ForeignKey(Song, on_delete=models.CASCADE) added_at = models.DateTimeField(auto_now_add=True) class Meta: ordering = ['added_at']

这样相当于给歌单里的歌曲保留了一个“添加时间”字段，后续展示歌单时能按加入顺序排列，体验更好。

4.3 权限控制：哪些页面必须登录才能看

在线音乐网站的常见权限设计是：浏览歌曲、搜索歌曲、播放歌曲不需要登录；但如果要收藏、评论、创建歌单，就必须登录。

Django里最简单的实现是使用@login_required装饰器。如果是基于类的视图，使用LoginRequiredMixin。举个例子：

from django.contrib.auth.decorators import login_required from django.http import JsonResponse @login_required def add_favorite(request, song_id): song = get_object_or_404(Song, pk=song_id) obj, created = Favorite.objects.get_or_create(user=request.user, song=song) if not created: obj.delete() return JsonResponse({'status': 'removed'}) return JsonResponse({'status': 'added'})

这里用到的get_or_create是一个非常实用的查询技巧：先查一条记录是否存在，不存在就创建，存在就返回。同时它返回一个元组(obj, created)，第二个元素表示到底是不是新创建的——省了一次先查后写的逻辑。前端配合一个Ajax请求，就能做到点击收藏按钮时不刷新页面，状态实时切换。

4.4 搜索功能的实现思路

音乐网站的搜索一般按歌曲名、歌手名、专辑名来搜。最朴素的实现方式是用ORM里的icontains：

from django.db.models import Q def search(request): keyword = request.GET.get('q', '').strip() songs = Song.objects.filter( Q(name__icontains=keyword) | Q(singer__name__icontains=keyword) | Q(album__title__icontains=keyword) ).distinct() if keyword else [] return render(request, 'search_result.html', {'songs': songs, 'keyword': keyword})

icontains在SQLite里会翻译成LIKE查询，不区分大小写，做毕设完全够用。如果后面想加更高级的全文搜索，可以引入django-haystack，但对毕设而言用LIKE已经能讲明白自己的搜索逻辑了。搜索接口最好做成支持GET参数形式，这样后续做分页、排序都方便扩展。

5. 前端渲染与页面交互的实现

5.1 模板继承和静态文件管理

Django的模板继承机制，是开发多页面网站的效率神器。你只需要写一个base.html，把页头、导航栏、页脚、全局播放器都放在里面，然后在子模板里只用{% extends 'base.html' %}和{% block content %}去填充内容区域。这样如果后期想给导航栏加一个菜单项，只需要改一个文件，所有页面同步更新。

静态文件管理上，Django的做法是把CSS和JS文件放在每个app的static目录下，或者统一放在项目根目录的static下，collectstatic命令负责把它们收集到一个统一目录供部署使用。在settings里配置：

STATIC_URL = '/static/' STATICFILES_DIRS = [BASE_DIR / 'static']

5.2 用原生JS还是引入Vue

很多同学在“要不要用Vue”上犹豫。我的建议是：毕设项目用原生JavaScript就够了，最多引入一个jQuery。原因很简单，Django的模板渲染天然是服务端渲染，用Vue反而多一层复杂度，还得处理跨域、API设计等问题。原生JS配合Ajax请求Django的JSON接口，已经能覆盖音乐网站绝大部分交互需求。

比如页面加载时渲染歌曲列表，用Django模板直接循环输出：

<div class="song-list"> {% for song in songs %} <div class="song-item">python manage.py makemigrations python manage.py migrate

第一行会根据模型变化生成迁移文件，第二行把迁移应用到数据库。这对毕设来说好处太明显了——你不需要手写ALTER TABLE语句，不用担心破坏已有数据，Django会记录哪些迁移已经执行过。

但这里有个很常见的坑：改models.py的时候，如果字段加了一个非空限制（比如null=False），而数据库里已经有老数据了，迁移时会提示你“给已有数据提供默认值”。这时直接在字段定义里加default=''或者blank=True就能轻松过去，没必要真的去提供全局默认值。

6.2 数据备份与导出SQL

毕设提交的时候，老师可能要求你提供数据库文件或者SQL脚本。SQLite的话很简单，把.sqlite3文件直接拷出来就行。MySQL的话，可以用命令行工具导出：

mysqldump -u root -p music_db > music_db.sql

如果不想装MySQL客户端，也可以在Django代码里写一个自定义的管理命令，把当前数据库的数据导出为JSON：

# apps/music/management/commands/export_data.py from django.core.management.base import BaseCommand from django.core import serializers import os class Command(BaseCommand): help = '导出数据库到JSON文件' def handle(self, *args, **options): fixtures_dir = os.path.join('fixtures') os.makedirs(fixtures_dir, exist_ok=True) for model_name in ['auth.User', 'music.Singer', 'music.Album', 'music.Song']: output = os.path.join(fixtures_dir, f'{model_name.split(".")[1]}.json') with open(output, 'w', encoding='utf-8') as f: data = serializers.serialize('json', serializers.deserialize(...)) # 简写：生产JSON数据 self.stdout.write(f'Exported {model_name}')

这个导出文件在换电脑、重新部署时可以用loaddata导回去，方便得不行。

6.3 从本地演示到服务器部署

毕业设计一般要求现场演示，演示有两种方式：一种是在自己笔记本上跑起来，访问127.0.0.1:8000；另一种是部署到一台云服务器上，用IP或者域名访问。

如果选择本地演示，有几个细节要注意：

• ALLOWED_HOSTS要配置成['*']或者包含你的局域网IP，不然手机访问电脑IP时会报DisallowedHost错误。
• 演示前确保python manage.py makemigrations和migrate都执行过，否则数据库缺表直接白屏。
• 把DEBUG设为True演示最方便，因为能看到完整的错误页面。

如果部署到服务器，那我推荐用nginx + gunicorn的组合，大致流程：

# 安装依赖 pip install gunicorn # 收集静态文件 python manage.py collectstatic # 用gunicorn启动 gunicorn config.wsgi:application -b 0.0.0.0:8000

nginx负责处理静态文件和反向代理，把请求转发给gunicorn。因为Django的runserver只适合开发调试，性能扛不住生产环境。

6.4 演示时的几个小技巧

答辩那天最怕的就是现场翻车，我在这一点上非常有发言权。给大家几个实战经验：

• 提前准备好一份带真实数据的数据库，里面要有一些热度较高的歌曲、几位知名歌手、几个创建好的歌单。到时候演示时点开页面就内容丰富，观感极佳。不要现场注册用户再慢慢添加歌曲，那样演示节奏会拖得很长。
• 提前在电脑上跑通一遍完整的“用户注册—登录—搜索—播放—收藏—评论”流程，把每一步的预期结果记下来。演示的时候照着这个流程走，绝对比临场乱点要稳。
• 浏览器建议用Chrome，并且开一个隐身窗口演示登录、注册流程，避免缓存cookie导致登录状态错乱。
• 准备一条“演示脚本”，就是一份sop文档，包含了每一步要点击什么、展示什么功能、讲什么亮点。这样万一脑子一片空白，照着念也能撑完整个演示。

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

7.1 数据库迁移报错汇总

做Django项目，几乎没有人能一帆风顺完成所有迁移。我整理了几个高频报错：

其中一个我感到过多次的痛苦经历是“删除了一张表，重新改模型后migrate不生效”。这种情况最干净的办法是：把migrations目录下的文件除了__init__.py全删了，然后把db.sqlite3文件删除，重新makemigrations和migrate。开发阶段数据不重要的情况下，这么做可以省下大量排查时间。

7.2 静态文件和媒体文件404

这是所有Django新手都会遇到的坑：设置好STATIC_URL和MEDIA_URL后，图片和CSS还是加载不出来。

排查思路依次是：

• 开发模式下，确认是否在根urls里加了static()配置。
• 确认文件确实在MEDIA_ROOT对应的目录下。
• 用浏览器开发者工具看Console里的404路径，判断是少了前缀还是路径拼接错误。
• 如果部署到服务器，记得执行collectstatic，并且nginx要正确指向STATIC_ROOT目录。

我见过一个特别容易踩的路径拼接问题：在模板里直接用/media/{{ song.audio_file }}，而忘了audio_file本身已经包含了路径。正确做法是用{{ song.audio_file.url }}，Django会基于MEDIA_URL自动拼接完整URL。

7.3 中文乱码问题

SQLite通常不会出现中文乱码，MySQL如果创建表时没有指定UTF-8字符集，就会出现中文变成???或者å¯å®¶这种乱码。我建议在连接MySQL时，在settings里显式指定：

'OPTIONS': { 'charset': 'utf8mb4', },

另外Django模板页面的HTML里也要声明编码：

<meta charset="UTF-8">

7.4 播放没声音/加载缓慢

如果本地演示时歌曲卡顿、加载慢，先看是不是音频文件体积太大。一首未压缩的WAV文件可能达到几十MB，网页加载自然慢。建议在测试数据中选择几首MP3格式、大小在2-5MB的歌曲文件。

还有一个经常被忽略的问题：浏览器直连127.0.0.1:8000时速度还行，但如果用局域网IP访问，手机通过WiFi取文件会受路由器带宽影响，大文件就会缓冲。所以演示前先把歌曲文件压缩，或者只准备4-5首歌作为演示数据就够了。

8. 源码组织和自动化给项目加分

8.1 写一份让别人能看懂的项目README

毕业设计提交源码时，源码包里的README.md质量直接决定评审老师的第一印象。我见过太多源码塔了，解压以后不知道怎么跑起来。一份好的README至少应该包含：

• 项目简介：这个项目是什么，实现了哪些功能。
• 技术栈：Python版本、Django版本、用到的第三方库。
• 快速启动步骤：克隆代码 → 创建虚拟环境 → 安装依赖 → 执行迁移 → 创建超级管理员 → 运行开发服务器 → 访问地址。
• 默认账号：如果提供了测试账号，写清楚用户名和密码。
• 项目结构：用树状图列出主要文件和目录。
• 功能列表：分模块列出已实现的功能点。

启动步骤我一般写成这样：

# 1. 进入项目目录 cd music_website # 2. 创建虚拟环境 python -m venv venv # 3. 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 4. 安装依赖 pip install -r requirements.txt # 5. 数据库迁移 python manage.py makemigrations python manage.py migrate # 6. 创建管理员账号 python manage.py createsuperuser # 7. 启动服务器 python manage.py runserver

这几步走完，任何同学都能在不借助外部帮助的情况下把项目跑起来。

8.2 requirements.txt怎么生成

记住一条命令：

pip freeze > requirements.txt

但freeze会把你环境里所有包都列出来，有些是无关的。更专业的做法是用pipreqs工具生成，它只扫描项目实际用到的包：

pip install pipreqs pipreqs ./ --force

这样生成的requirements.txt更干净，避免在别人电脑上安装一堆没用的依赖。这个细节很微小，但能看出项目是否规范。

8.3 用Git管理源码，给自己留条后路

哪怕只是毕设，我也强烈建议用Git做版本管理。在项目最早期就执行git init，每次改好一个功能就提交一次，这样每次改动都有记录，改坏了可以回滚。源码包里带着.git目录，还会让材料显得更专业。如果你愿意，还可以把项目推到GitHub上开一个私有仓库，随时多一份异地备份，比只放在U盘里安全得多。不过要注意，如果使用别人提供的素材、模板或开源代码，一定要看清开源协议，避免出现版权问题影响毕业审查。

最后分享一点我实际开发中的感受

把这个音乐网站从头到尾完整做一遍，你对Django的理解会突飞猛进。我一开始也是照着别人的项目抄，跑到一半发现数据模型根本不适合自己的功能需求，又推倒重来。回过头看，最值得投入时间的其实不是堆功能，而是把基础模型设计好，想清楚每张表之间的关系，后面的功能开发会顺畅得多。

我还有一个亲身教训：网上很多免费“源码”里面塞了冗余的代码，甚至藏了后门，直接下载下来跑很危险。如果只用来学习参考，把设计思路读懂了就够了，最后还是要自己动手写一遍，把技术点变成自己的储备。等你真正写完这个项目，再被问到“你项目里遇到过什么坑”时，你绝对能自信地讲出好几个让老师点头的经历。

本文还有配套的精品资源，点击获取