简介这是一份围绕Python与Django框架展开的社交音乐分享平台毕业论文文档面向计算机相关专业需要完成课程设计或毕业设计的学生以及希望了解Django Web开发完整流程的初学者。文档从需求分析、技术选型到功能实现与测试优化系统梳理了用户注册登录、音乐上传、个人资料、社交关系、评论点赞等模块的设计思路并涉及MySQL数据库、MTV架构、ORM交互、音乐API与社交插件集成、缓存机制与负载均衡等性能优化要点。压缩包内仅含1个doc文件约16.19MB篇幅完整、目录层级清晰便于按章节检索和参考。目前已有73人学习适合用作选题参考、论文框架借鉴与项目实现思路整理其中功能测试与性能优化部分对答辩准备也有一定帮助。1. 从一份毕业论文到一个能跑的 Django 音乐社区很多人拿到基于 Python 的社交音乐分享平台这类毕设文档时第一反应是把它当作文档读——翻完需求分析、可行性分析、测试结论然后卡在到底怎么把代码跑起来。这份文档的价值恰恰不在结论而在它给出的功能边界用户注册登录、音乐上传与分享、个人资料、关注与私信、评论点赞、后台审核再叠加一个推荐位。这七个模块构成了一个最小可用的音乐社区任何多出来的花活都是锦上添花。它适合两类人一是需要从零复现一套 Django 全栈项目的人二是想把 MTV 分层、ORM 建模、文件存储、缓存策略这些零散知识点串成一条线的人。本文不照抄文档的章节编号而是按真实开发顺序拆——先定模型和目录结构再写视图与表单接着处理音频上传这种容易踩坑的环节最后用查询优化和缓存收尾。文中出现的命令和代码都以 Django 当前稳定版为准数据库沿用文档里定下的 MySQL本地开发时用 SQLite 也完全跑得通。2. 数据模型与项目骨架把歌曲、歌手、社交关系先建对模型设计错了后面视图怎么改都别扭。这个平台的核心实体并不多但关系有点绕一个用户可以上传多首歌曲一首歌曲属于一个歌手可以多个用户可以关注其他用户可以对歌曲评论和点赞。先把这些关系落到models.py后面的表单、序列化、查询都会顺很多。2.1 用 startproject 和 startapp 搭出可扩展的目录常见做法是不要把所有 app 塞在一起。音乐核心逻辑、用户社交逻辑、后台管理逻辑分三个 app彼此依赖单向避免循环导入。# 创建项目与三个职责分离的 app django-admin startproject musichub cd musichub python manage.py startapp music # 歌曲、歌手、专辑 python manage.py startapp accounts # 用户资料、关注关系、私信 python manage.py startapp interaction # 评论、点赞、播放记录然后在settings.py的INSTALLED_APPS中按依赖顺序登记accounts放在最前music依赖它引用用户外键interaction依赖前两者。这种顺序不是硬性要求但能让迁移文件的可读性更好。数据库配置直接按文档定的 MySQL 走# settings.py 片段开发环境可用 SQLite 替换 DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: musichub, USER: root, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, # 音乐标题常含 emoji必须 utf8mb4 } }参数说明utf8mb4是必须的因为歌曲名和评论里经常出现 emoji 和特殊符号用utf8会在写入时直接报错。HOST写127.0.0.1而不是localhost能避免部分环境下 MySQL 走 socket 连接导致的权限问题。2.2 歌曲、歌手与标签的多对多建模歌曲和标签、歌曲和歌手之间都用多对多这是这个场景下最容易被写成一对多的地方。一个歌手可以有多首歌一首翻唱也可能涉及多个演唱者所以用ManyToManyField更贴近现实。# music/models.py from django.db import models from django.conf import settings class Artist(models.Model): name models.CharField(歌手名, max_length120, db_indexTrue) avatar models.ImageField(upload_toartists/%Y/%m/, blankTrue) intro models.TextField(简介, blankTrue) created_at models.DateTimeField(auto_now_addTrue) class Meta: indexes [models.Index(fields[name])] class Tag(models.Model): name models.CharField(标签, max_length40, uniqueTrue) def __str__(self): return self.name class Song(models.Model): title models.CharField(歌曲名, max_length200, db_indexTrue) artist models.ManyToManyField(Artist, related_namesongs) uploader models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.CASCADE, related_nameuploaded_songs, ) audio models.FileField(upload_tosongs/%Y/%m/) cover models.ImageField(upload_tocovers/%Y/%m/, blankTrue) tags models.ManyToManyField(Tag, blankTrue, related_namesongs) play_count models.PositiveIntegerField(default0) created_at models.DateTimeField(auto_now_addTrue) class Meta: ordering [-created_at] indexes [models.Index(fields[-created_at])]关键点有三个。第一upload_to带年月路径避免单目录下文件数量爆炸导致ls卡顿这是文件存储的常见做法。第二-created_at加索引因为列表页默认按时间倒序没有索引时分页越往后越慢。第三play_count用PositiveIntegerField而不是整型从字段层面约束非法值。2.3 关注关系与唯一约束关注关系是典型的多对多自关联但必须防止重复关注和关注自己。# accounts/models.py from django.conf import settings from django.db import models class Profile(models.Model): user models.OneToOneField(settings.AUTH_USER_MODEL, on_deletemodels.CASCADE) nickname models.CharField(max_length60, blankTrue) bio models.TextField(blankTrue) class Follow(models.Model): follower models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.CASCADE, related_namefollowing ) following models.ForeignKey( settings.AUTH_USER_MODEL, on_deletemodels.CASCADE, related_namefollowers ) created_at models.DateTimeField(auto_now_addTrue) class Meta: constraints [ models.UniqueConstraint(fields[follower, following], nameuniq_follow) ]这里的UniqueConstraint是关键它把去重逻辑交给数据库比在视图里先查再插入更可靠——高并发下查了不存在再插入很容易插入重复行。注意on_delete用CASCADE用户注销时关注关系一并清理不会留下悬空外键。用户资料用OneToOneField挂在自带的User上而不是重写用户模型。对毕设或中小项目来说中途替换用户模型代价很高用 Profile 扩展是最稳的选择。提示写完模型立刻执行python manage.py makemigrations和migrate不要攒着几个 app 一起迁移出问题时定位成本会高很多。3. 视图、表单与路由把上传和社交互动串起来模型建好后最容易出问题的是文件上传和评论点赞这两个交互。上传涉及大文件、格式校验、存储路径点赞涉及并发下的计数一致性。这两块处理好了其余列表页和详情页基本都是模板的事了。3.1 用 ModelForm 加自定义校验拦住非法音频直接让用户填 FileField 会放进任何文件所以要用表单层的 clean 方法做类型和大小校验。# music/forms.py from django import forms from .models import Song ALLOWED_EXT {.mp3, .wav, .flac, .m4a} MAX_SIZE 30 * 1024 * 1024 # 30MB class SongUploadForm(forms.ModelForm): class Meta: model Song fields [title, artist, audio, cover, tags] widgets {tags: forms.CheckboxSelectMultiple} def clean_audio(self): audio self.cleaned_data[audio] ext . audio.name.rsplit(., 1)[-1].lower() if ext not in ALLOWED_EXT: raise forms.ValidationError(f不支持的格式{ext}) if audio.size MAX_SIZE: raise forms.ValidationError(音频文件不能超过 30MB) return audio逻辑说明clean_audio在字段级校验通过后执行返回的值会替换原始值。判断扩展名用rsplit只切一次避免文件名里含多个点导致误判。大小限制放在表单层而不是模型层是为了给用户友好提示模型层不做这样重的校验。视图里只需判断form.is_valid()# music/views.py from django.contrib.auth.decorators import login_required from django.shortcuts import render, redirect from .forms import SongUploadForm login_required def song_upload(request): if request.method POST: form SongUploadForm(request.POST, request.FILES) if form.is_valid(): song form.save(commitFalse) song.uploader request.user song.save() form.save_m2m() # 多对多字段必须在实例保存后写入 return redirect(music:song_detail, pksong.pk) else: form SongUploadForm() return render(request, music/upload.html, {form: form})注意commitFalse配合save_m2m()这一对很多人在保存带多对多字段的表单时忘记调用save_m2m()结果标签静默丢失且不报错排查起来很费时间。3.2 点赞用 F 表达式避免计数丢失点赞计数如果写成song.like_count 1; song.save()并发时会丢更新。正确做法是用数据库层面的原子自增。# interaction/views.py from django.db.models import F from django.http import JsonResponse from django.views.decorators.http import require_POST from .models import Like from music.models import Song require_POST def toggle_like(request, song_id): song Song.objects.get(pksong_id) like, created Like.objects.get_or_create(userrequest.user, songsong) if not created: like.delete() Song.objects.filter(pksong_id).update(like_countF(like_count) - 1) return JsonResponse({liked: False}) Song.objects.filter(pksong_id).update(like_countF(like_count) 1) return JsonResponse({liked: True})逻辑说明get_or_create返回(对象, 是否新建)用它同时实现点赞和取消点赞的判断比先查再插更简洁。F(like_count) 1生成的是 SQL 层面的自增表达式不经过 Python 内存读改写因此并发安全。require_POST装饰器把非 POST 请求直接挡回 405避免有人用 GET 触发副作用。3.3 路由分层与命名空间三个 app 各自维护urls.py在主路由里用include加命名空间挂载模板里用{% url music:song_detail song.pk %}引用改路径时不用满项目搜字符串。# musichub/urls.py from django.contrib import admin from django.urls import path, include from django.conf import settings from django.conf.urls.static import static urlpatterns [ path(admin/, admin.site.urls), path(accounts/, include((accounts.urls, accounts), namespaceaccounts)), path(music/, include((music.urls, music), namespacemusic)), path(social/, include((interaction.urls, interaction), namespaceinteraction)), ] if settings.DEBUG: # 开发环境由 Django 直接服务媒体文件生产环境交给 Nginx urlpatterns static(settings.MEDIA_URL, document_rootsettings.MEDIA_ROOT)参数说明static()只在DEBUGTrue时生效生产环境必须由 Web 服务器托管媒体文件否则每个音频请求都要经过 Django 进程性能会断崖式下跌。模块路由前缀典型视图是否需要登录用户资料/accounts/profile、follow_list部分歌曲/music/list、detail、upload上传需要互动/social/comment、toggle_like需要后台/admin/Django Admin需要 staff注意媒体文件的MEDIA_ROOT和静态文件STATIC_ROOT不要放在同一个目录collectstatic 时会把上传的用户文件一起清掉的风险始终存在。4. 音频上传、存储与后台审核的实战处理功能能跑和功能能稳定跑差距就在这一章。音频文件大、播放请求频繁、后台还要做内容审核这三点决定了平台能不能扛住真实使用。4.1 大文件上传的分片思路与配置调整30MB 的音频在正常网络下没问题但如果放开到几百 MB单请求上传很容易超时。常见做法是前端分片、后端合并但在 Django 层面至少要先调好两个参数# settings.py DATA_UPLOAD_MAX_MEMORY_SIZE 50 * 1024 * 1024 # 表单内存上限 FILE_UPLOAD_MAX_MEMORY_SIZE 5 * 1024 * 1024 # 超过此值转临时文件FILE_UPLOAD_MAX_MEMORY_SIZE决定文件是留在内存还是写临时文件。设成 5MB 意味着 5MB 以上走磁盘临时文件能显著降低内存压力。Nginx 侧对应要放开client_max_body_size否则请求还没到 Django 就被拒了。# Nginx 中对应 location 段 client_max_body_size 100m; proxy_read_timeout 300s;如果确实要做分片可以在现有模型上加一个ChunkedUpload表记录分片状态前端用Blob.slice切割后端收到最后一片时合并。这是进阶内容中小项目用单请求加超时配置足够。4.2 播放计数与详情页查询优化详情页要展示歌曲信息、歌手、标签、评论列表很容易触发 N1 查询。用select_related和prefetch_related一次性取全。from django.shortcuts import get_object_or_404 from django.db.models import F from .models import Song def song_detail(request, pk): song get_object_or_404( Song.objects.select_related(uploader) .prefetch_related(artist, tags, comments__user), pkpk, ) # 用 F 表达式原子自增避免并发播放计数丢失 Song.objects.filter(pkpk).update(play_countF(play_count) 1) return render(request, music/detail.html, {song: song})逻辑说明select_related用于外键和一对一走 JOINprefetch_related用于多对多和反向关系走额外查询再拼接。两者混用是列表和详情页的标准优化组合。播放计数在返回前自增不导出到模板也不参与渲染避免把写操作和读操作耦合进同一事务。查询方式适用关系SQL 行为使用场景select_related外键、一对一JOIN歌曲取上传者prefetch_related多对多、反向外键分两条查询标签、评论Prefetch 对象需过滤的预取自定义查询集只取已审核评论4.3 后台审核流程与 Django Admin 定制文档里明确提到管理员要审核上传作品这在 Django Admin 里可以做得像模像样。给 Song 加状态字段然后用 list_editable 批量审核。# music/admin.py from django.contrib import admin from .models import Song, Artist admin.register(Song) class SongAdmin(admin.ModelAdmin): list_display (title, uploader, status, play_count, created_at) list_filter (status, tags, created_at) search_fields (title, artist__name) list_editable (status,) # 列表页直接改状态批量审核 list_select_related (uploader,) # 列表页避免 N1 actions [approve_selected] admin.action(description批量通过审核) def approve_selected(self, request, queryset): updated queryset.update(statusSong.Status.APPROVED) self.message_user(request, f已通过 {updated} 首歌曲)逻辑说明list_select_related让列表页的 uploader 一次性取回否则每行一次查询。actions定义批量操作queryset.update是单条 SQL比循环保存快几个数量级。list_filter里放status管理员可以快速筛出待审核的歌曲。前台列表页只展示已通过的歌曲过滤条件写在视图层def song_list(request): qs Song.objects.filter(statusSong.Status.APPROVED).select_related(uploader) return render(request, music/list.html, {songs: qs})提示审核状态用TextChoices定义枚举别用魔法数字 0/1/2后期看数据库时你会感谢自己。5. 查询优化、缓存与上线前的验证清单功能齐了之后真正决定体验的是响应速度。数据库查询、模板渲染、媒体文件分发这三段各有各的优化手法也各有各的验证方式。5.1 用 django-debug-toolbar 定位慢查询开发环境装上 debug toolbar打开任意列表页就能看到执行了多少条 SQL、每条耗时多少。pip install django-debug-toolbar# settings.py仅开发环境启用 if DEBUG: INSTALLED_APPS.append(debug_toolbar) MIDDLEWARE.insert(0, debug_toolbar.middleware.DebugToolbarMiddleware) INTERNAL_IPS [127.0.0.1]打开页面后在侧栏看 SQL 面板。判断标准很直接列表页 SQL 条数应该是个位数如果随页面上显示条数线性增长就是 N1 没处理干净。定位到具体视图后回去补select_related或prefetch_related。5.2 热门榜单用 Redis 缓存挡住重复查询排行榜、首页推荐这类数据读多写少且允许短时间不一致缓存收益最高。用 Django 内置缓存框架接 Redis# settings.py CACHES { default: { BACKEND: django.core.cache.backends.redis.RedisCache, LOCATION: redis://127.0.0.1:6379/1, TIMEOUT: 300, # 默认 5 分钟 } }from django.core.cache import cache from django.db.models import F def hot_songs(): data cache.get(hot_songs) if data is None: data list( Song.objects.filter(statusSong.Status.APPROVED) .order_by(-play_count)[:20] .values(id, title, play_count) ) cache.set(hot_songs, data, 300) return data逻辑说明values()直接返回字典列表比返回模型实例轻缓存序列化也更省空间。缓存键用hot_songs这种语义化名字不要用songs_1之类难维护的形式。TIMEOUT300 秒是按允许榜单延迟 5 分钟这个业务假设定的改成 60 秒会更实时但命中率下降。关键点是缓存失效。新歌通过审核或播放量大幅变动时要主动删键否则用户会看到过期榜单def approve_song(song): song.status Song.Status.APPROVED song.save(update_fields[status]) cache.delete(hot_songs) # 榜单过期下次访问重新计算update_fields限制只更新状态字段避免整行写回。5.3 上线前的检查命令与常见坑Django 自带一条部署检查命令上线前务必跑一遍python manage.py check --deploy它会提示DEBUG是否为 True、SECRET_KEY是否硬编码、SECURE_*系列安全头是否配置。按提示逐条处理其中DEBUGFalse之后必须正确配置ALLOWED_HOSTS和静态文件服务否则页面会直接 400 或样式全丢。最后一个容易被忽略的点生产环境不要用runserver。文档提到的性能优化第一步就是把服务切到 WSGI 服务器Windows 环境下可以选 waitress 搭配 Nginx 做反向代理Linux 下用 gunicorn 更常见。媒体文件交给 Nginx 直接返回Django 只管动态请求这样音频播放才不会拖垮应用进程。验证优化是否生效最直接的办法是压测对比# 用 ab 对榜单接口做简单对比注意先确认接口返回正常 ab -n 1000 -c 50 http://127.0.0.1:8000/music/hot/关注Requests per second和Time per request两个指标加缓存前后各跑一次差距会非常直观。如果数值没变化检查缓存是否真的命中可以在视图里临时打日志确认。本文还有配套的精品资源点击获取