简介这是一套面向计算机专业本科生的Django毕业设计实战项目聚焦旅游攻略分享与社区互动场景为旅游爱好者及Web开发初学者提供可运行、可拓展的完整论坛系统参考方案。资源包含341个文件主体为90个Python后端逻辑文件、79个JavaScript交互脚本、45张JPG攻略配图、37个CSS样式文件及16个HTML前端模板辅以SVG图标、字体文件与SQL数据库脚本整体压缩包12.84MB结构清晰、模块分明涵盖用户中心、发帖管理、论坛分类、邮箱/手机双验证等核心功能。已有220人学习下载配套代码完整支持PyCharm Django 3.0 Python 3.7 MySQL 5.6环境一键部署含Bootstrap与Font Awesome等主流前端库便于理解前后端协同开发流程、权限控制设计及多类型媒体内容管理实践。1. 这不是又一个“Django博客模板”它是一套能跑通真实用户闭环的旅游攻略论坛系统含完整MySQL建模、权限分层与PyCharm可调试工程结构你见过太多标着“Django毕业设计”的压缩包——点开是空的manage.py、三行models.py、首页硬编码五条假数据连登录都跳转404。但这次不一样。这个源码包不是Demo而是一个真实可运行、有用户注册→发帖→点赞→后台审核→管理员封禁全链路的旅游攻略社区最小可行系统MVP。它用Django 3.2兼容PyCharm 2022.3MySQL 5.7建模所有模型字段带业务语义注释比如travel_post.views_count: int, not null, default0, comment累计浏览量用于首页热帖排序URL路由按RESTful风格组织连/api/v1/posts/?categorybeachsorthot这种带参数的接口都已实现。适合两类人一是大四学生赶毕设答辩它能让你在导师面前流畅演示“用户发一篇三亚潜水攻略→其他游客评论收藏→管理员后台看到待审核帖→一键通过或驳回”的完整流程二是刚学完Django基础想练手的开发者它把auth模块权限控制、django-crispy-forms表单渲染、django-pagination分页、mysqlclient连接池配置这些“书上写了但自己搭总报错”的环节全塞进一个能直接python manage.py runserver跑起来的工程里。别再找“Python旅游系统源码”却下到一堆静态HTML了——这次数据库表结构、迁移文件、PyCharm运行配置、甚至MySQL本地连接密码都写在settings.py注释里。2. 从零启动PyCharm Django MySQL环境搭建与项目初始化实操2.1 环境版本对齐为什么必须锁定Django 3.2和MySQL 5.7这不是版本强迫症。Django 4.x默认启用ASGI异步模式而本项目所有视图、中间件、信号如用户注册后自动发送欢迎邮件均基于WSGI同步上下文编写若强行升级request.user.is_authenticated在部分装饰器中会返回None而非True/False导致权限校验失效。MySQL方面项目SQL文件中大量使用ON UPDATE CURRENT_TIMESTAMP语法该特性在MySQL 5.6中为实验性在5.7才稳定支持。更关键的是字符集项目CREATE TABLE语句明确指定CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci这是存储emoji和生僻汉字如“䶮”、“龘”的刚需而MySQL 5.6默认utf8实际是utf8mb3存emoji会截断。所以你的本地环境必须是Python 3.8–3.10推荐3.9PyCharm社区版对3.9支持最稳Django 3.2.23官方最后LTS版本安全补丁持续到2024年4月MySQL 5.7.39 或 8.0.338.0需关闭sql_modeSTRICT_TRANS_TABLES否则INSERT INTO user_profile (user_id) VALUES (1)会因bio字段NULL报错提示不要用pip install django——它会装最新版。请严格执行pip install Django3.2.23 mysqlclient2.1.1pip install Pillow9.5.0处理用户头像上传必需2.2 PyCharm专业版配置让Django调试器真正“看懂”你的代码PyCharm社区版也能跑但调试时无法在views.py断点处查看request.session完整内容、无法展开QuerySet对象看SQL执行计划。专业版配置是提效关键新建项目时选择“Django”模板路径选解压后的源码根目录含manage.py的那层PyCharm会自动识别settings.py。配置Python解释器进入File → Settings → Project → Python Interpreter点击右上角搜索mysqlclient并安装。若提示mysql_config not found说明未装MySQL开发头文件Ubuntu/Debiansudo apt-get install libmysqlclient-dev python3-devmacOSHomebrewbrew install mysql-client brew link mysql-client设置Django Server配置Run → Edit Configurations → → Django Server填入Host:127.0.0.1Port:8000Environment variables:PYTHONUNBUFFERED1;DJANGO_SETTINGS_MODULEtravel_forum.settingsPath to manage.py:your_project_path/manage.pyWorking directory:your_project_path启用Django模板调试Settings → Languages Frameworks → Django勾选Enable Django SupportDjango project root指向项目根目录Settings指向travel_forum/settings.pyManage script指向manage.py。此时在.html模板中按CtrlClick能跳转到对应views.py函数。2.3 初始化MySQL数据库从SQL文件导入到Django迁移的完整链路项目附带db_init.sql位于docs/目录它不是简单CREATE DATABASE而是包含带外键约束、索引、初始管理员账号的完整脚本。执行顺序不能错# 步骤1登录MySQL创建数据库注意字符集 mysql -u root -p -e CREATE DATABASE travel_forum DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 步骤2导入SQL文件必须指定字符集否则中文变乱码 mysql -u root -p --default-character-setutf8mb4 travel_forum docs/db_init.sql # 步骤3验证数据是否就位应看到12张表含auth_*系列 mysql -u root -p -e USE travel_forum; SHOW TABLES;此时数据库已有auth_user、travel_post、travel_comment等表但Django还不知道它们存在。必须让Django“反向生成”迁移文件再假装已执行# 进入项目根目录执行Django命令 cd /path/to/your/project # 1. 生成初始迁移--empty表示不生成模型变更只生成数据库映射 python manage.py inspectdb travel_forum/models.py # 2. 手动编辑travel_forum/models.py删除Django自动生成的冗余字段如id models.AutoField(...)保留与db_init.sql一致的字段名和类型 # 3. 生成空迁移文件关键告诉Django“这些表已存在别再CREATE” python manage.py makemigrations --empty travel_forum # 4. 修改生成的0001_initial.py将migrations.CreateModel(...)全部替换为migrations.RunSQL(SELECT 1;)并在dependencies中加入(contenttypes, 0002_remove_content_type_name) # 5. 最终执行迁移--fake-initial表示“假装这些表已由SQL创建跳过CREATE TABLE” python manage.py migrate --fake-initial参数说明--fake-initial是核心。它让Django记录“migration 0001已执行”但不真正执行SQL避免与db_init.sql冲突。若跳过此步python manage.py migrate会报错Table travel_forum.travel_post doesnt exist因为Django试图CREATE一个已存在的表。3. 核心功能拆解用户体系、攻略发帖、权限控制与后台管理的代码级实现3.1 用户模型扩展为什么不用AbstractUser而用OneToOneField关联项目没继承AbstractUser重写整个用户模型而是采用UserProfile模型通过OneToOneField关联auth.User。这是刻意为之的工程权衡降低耦合auth.User负责认证username/password/emailUserProfile专注旅游场景属性avatar,travel_experience,favorite_destinations。当未来要接入微信登录时只需改auth.User的username生成逻辑UserProfile完全不动。避免迁移地狱若继承AbstractUser每次加字段都要makemigrations而UserProfile是独立App迁移可单独管理。代码可读性查看用户资料时user.profile.bio比user.bio更清晰表明这是扩展字段。关键代码在travel_forum/models.pyfrom django.contrib.auth.models import User from django.db import models class UserProfile(models.Model): user models.OneToOneField(User, on_deletemodels.CASCADE, related_nameprofile) avatar models.ImageField(upload_toavatars/, blankTrue, nullTrue, defaultavatars/default.png) travel_experience models.PositiveSmallIntegerField(default0, help_text旅行年数用于用户等级计算) favorite_destinations models.CharField(max_length200, blankTrue, help_text用英文逗号分隔如Paris,Tokyo,Bali) def get_favorite_list(self): 将字符串转为列表避免前端重复split return [dest.strip() for dest in self.favorite_destinations.split(,) if dest.strip()] class Meta: db_table user_profile # 显式指定表名与db_init.sql一致逻辑说明related_nameprofile让User实例能通过user.profile访问扩展信息。db_table确保Django ORM操作的表名与SQL文件中定义的完全一致避免user_profile_userprofile这类自动生成表名。3.2 攻略发帖模块富文本编辑器集成与图片防盗链处理发帖页/posts/create/用django-ckeditor实现富文本但源码做了关键定制图片上传路径隔离所有用户上传的攻略图片存于media/posts/year/month/而非混在media/uploads/。这便于Nginx按路径配置防盗链。自动添加水印在travel_forum/views.py的PostCreateView.form_valid()中调用add_watermark()函数对上传图片加半透明“旅迹”文字水印使用PIL库。敏感词过滤提交前调用filter_sensitive_words()函数匹配docs/sensitive_words.txt中的词库含“代购”、“低价团”等旅游黑产词命中则返回400错误。核心逻辑在views.pyfrom django.views.generic import CreateView from .models import TravelPost from .forms import PostForm class PostCreateView(CreateView): model TravelPost form_class PostForm template_name posts/create.html def form_valid(self, form): # 1. 先保存草稿未发布状态 post form.save(commitFalse) post.author self.request.user post.status draft # 草稿状态需后台审核 post.save() # 2. 处理富文本中的图片加水印、重命名 if post.content: from .utils import process_ckeditor_images process_ckeditor_images(post.content, post.id) # 关键传post.id确保图片路径唯一 # 3. 敏感词检查 if self.filter_sensitive_words(post.content): form.add_error(None, 内容包含敏感词汇请修改后重新提交) return self.form_invalid(form) # 4. 发布非草稿 post.status published post.save() return super().form_valid(form) def filter_sensitive_words(self, content): with open(docs/sensitive_words.txt, r, encodingutf-8) as f: words [line.strip() for line in f if line.strip()] return any(word in content for word in words)参数说明process_ckeditor_images()函数会解析content中的img src/media/...标签下载原图→加水印→保存为新路径→替换HTML中的src。post.id确保每篇攻略的图片存于独立子目录避免不同用户上传同名图片覆盖。3.3 权限控制系统RBAC模型在Django Admin中的落地项目没用第三方django-rbac而是基于Django原生Group和Permission实现轻量RBAC角色分组Admin超级管理员、Moderator版主可删帖/封禁用户、Contributor普通用户仅可发帖评论权限粒度travel_post | can_publish_post发布攻略、travel_comment | can_delete_comment删除评论、auth | can_ban_user封禁用户后台绑定在travel_forum/admin.py中为TravelPostAdmin类添加get_queryset()方法使版主只能看到自己所在城市的帖子通过request.user.profile.city过滤关键代码# travel_forum/admin.py from django.contrib import admin from .models import TravelPost admin.register(TravelPost) class TravelPostAdmin(admin.ModelAdmin): list_display (title, author, status, created_at, views_count) list_filter (status, category, created_at) search_fields (title, content) def get_queryset(self, request): qs super().get_queryset(request) # 版主只能看到自己城市相关的帖子 if request.user.groups.filter(nameModerator).exists(): city getattr(request.user.profile, city, ) if city: qs qs.filter(location__icontainscity) return qs def has_change_permission(self, request, objNone): # 版主可编辑待审核帖但不能编辑已发布的 if obj and obj.status published: return request.user.is_superuser or request.user.groups.filter(nameAdmin).exists() return True逻辑说明get_queryset()在Admin列表页生效has_change_permission()控制编辑按钮是否显示。两者结合让RBAC规则在后台界面自然体现无需额外JS拦截。4. 避坑指南PyCharm调试、MySQL连接、Django权限失效的5个血泪现场4.1 现象PyCharm调试时request.user始终为AnonymousUser但浏览器访问正常原因PyCharm的Django Server配置中Environment variables未设置DJANGO_SETTINGS_MODULE或值错误如写成settings.py而非travel_forum.settings。Django找不到正确的settings于是加载默认配置其中AUTHENTICATION_BACKENDS未包含django.contrib.auth.backends.ModelBackend。解决检查Run Configuration → Environment variables确认DJANGO_SETTINGS_MODULEtravel_forum.settings。若仍无效在manage.py顶部添加print(os.environ.get(DJANGO_SETTINGS_MODULE))验证。4.2 现象MySQL报错ERROR 1045 (28000): Access denied for user rootlocalhost原因db_init.sql中创建的数据库用户是travel_user密码为travelpass123但settings.py中DATABASES配置仍为USER: root。解决打开travel_forum/settings.py找到DATABASES字典修改为DATABASES: { default: { ENGINE: django.db.backends.mysql, NAME: travel_forum, USER: travel_user, # 不是root PASSWORD: travelpass123, HOST: 127.0.0.1, PORT: 3306, OPTIONS: { charset: utf8mb4, } } }4.3 现象发帖后图片不显示Nginx返回404但manage.py runserver能显示原因settings.py中MEDIA_URL和MEDIA_ROOT配置正确但Nginx未配置location /media/代理。runserver自带静态文件服务Nginx需要显式声明。解决在Nginx配置中添加location /media/ { alias /path/to/your/project/media/; # 注意末尾斜杠 expires 30d; }并确保/path/to/your/project/media/目录权限为www-data可读。4.4 现象管理员后台看不到TravelPost模型admin.py已注册原因travel_forum/apps.py中TravelForumConfig类未在INSTALLED_APPS中声明。Django 3.2要求App必须显式配置。解决检查settings.py的INSTALLED_APPS确保包含INSTALLED_APPS [ # ... 其他app travel_forum.apps.TravelForumConfig, # 必须带.apps. ]4.5 现象用户注册后收不到欢迎邮件EMAIL_BACKEND设为console也无输出原因settings.py中EMAIL_BACKEND django.core.mail.backends.console.EmailBackend被注释实际使用的是smtp后端但EMAIL_HOST_USER和EMAIL_HOST_PASSWORD为空。解决开发阶段取消console后端注释并确保DEBUG Trueif DEBUG: EMAIL_BACKEND django.core.mail.backends.console.EmailBackend else: EMAIL_BACKEND django.core.mail.backends.smtp.EmailBackend EMAIL_HOST smtp.gmail.com # ... 其他SMTP配置5. 进阶技巧用Django Shell快速验证业务逻辑与数据一致性5.1 用Shell模拟用户行为链从注册到发帖的原子性验证别等前端点来点去才发现逻辑漏洞。Django Shell是你的“业务逻辑显微镜”。以下命令在python manage.py shell中逐行执行模拟一个新用户完成全流程# 1. 创建测试用户绕过表单验证直插数据库 from django.contrib.auth.models import User user User.objects.create_user( usernametest_traveler, emailtesttravel.com, passwordTestPass123! ) # 2. 创建用户档案必须否则profile.avatar会报错 from travel_forum.models import UserProfile profile UserProfile.objects.create( useruser, travel_experience2, favorite_destinationsKyoto,Barcelona ) # 3. 发布一篇攻略复现views.py中的核心逻辑 from travel_forum.models import TravelPost post TravelPost.objects.create( title京都枫叶季全攻略, contentp11月是最佳时间.../pimg src/media/posts/2023/10/map.jpg, authoruser, categoryjapan, locationKyoto, Japan, statuspublished ) # 4. 验证数据一致性检查views_count是否为0status是否published print(fViews: {post.views_count}, Status: {post.status}) # 应输出 Views: 0, Status: published # 5. 检查权限版主能否看到这篇帖假设版主user2已存在 from django.contrib.auth.models import Group mod_group Group.objects.get(nameModerator) user2 User.objects.get(usernamemoderator1) user2.groups.add(mod_group) # 现在用user2查询应能获取post qs TravelPost.objects.filter(authoruser) # 版主查询所有帖 print(fModerator sees {qs.count()} posts) # 应0技巧说明create_user()自动哈希密码create()跳过表单clean逻辑直接入库。这比写测试用例快且能立刻看到数据库真实状态。每次改完models.py或views.py先跑一遍Shell验证比等前端报错再Debug快10倍。5.2 数据修复脚本批量修正历史帖子的location字段格式上线后发现老帖子location字段是“日本京都”而非“Kyoto, Japan”影响地图API调用。写一个Shell脚本批量修复# 文件fix_location.py放在项目根目录 from travel_forum.models import TravelPost def fix_locations(): # 匹配中文地名替换为英文标准格式 replacements { 日本京都: Kyoto, Japan, 中国三亚: Sanya, China, 泰国清迈: Chiang Mai, Thailand, } updated 0 for zh, en in replacements.items(): count TravelPost.objects.filter(location__containszh).update(locationen) updated count print(fReplaced {zh} with {en}: {count} posts) # 单独处理空location设为Unknown unknown_count TravelPost.objects.filter(location__isnullTrue).update(locationUnknown) updated unknown_count print(fSet empty location to Unknown: {unknown_count} posts) return updated if __name__ __main__: print(Starting location fix...) total fix_locations() print(fTotal fixed: {total})执行方式python manage.py shell fix_location.py。脚本输出清晰修复前先TravelPost.objects.filter(location__contains日本京都).count()确认数量避免误操作。5.3 性能排查用Django Debug Toolbar定位慢查询当首页加载超过2秒别猜。在settings.py中启用Debug Toolbar# settings.py INSTALLED_APPS [debug_toolbar] MIDDLEWARE [debug_toolbar.middleware.DebugToolbarMiddleware] INTERNAL_IPS [127.0.0.1] # 在urls.py中添加 from django.urls import include, path urlpatterns [path(__debug__/, include(debug_toolbar.urls))]访问http://127.0.0.1:8000/__debug__/点击“SQL”标签页你会看到每个SELECT语句的执行时间如SELECT * FROM travel_post WHERE statuspublished ORDER BY created_at DESC LIMIT 10耗时120ms是否触发N1查询如循环中for post in posts: print(post.author.username)会执行10次SELECT * FROM auth_user优化方案在views.py的PostListView中用select_related(author)预取用户信息def get_queryset(self): return TravelPost.objects.select_related(author).filter(statuspublished).order_by(-created_at)这能将10次查询合并为1次首页加载从1200ms降至200ms。从那以后我每次改完models.py或加新功能都强制走一遍Django Shell验证核心链路——注册→登录→发帖→审核→查看。哪怕只是改了一个字段的max_length也要确认user.profile.travel_experience还能存下两位数。因为毕业答辩现场导师问“如果用户旅行年数填100系统会怎样”你脱口而出“会截断但我在models.py第42行加了validators[MinValueValidator(0), MaxValueValidator(50)]”比背一百遍原理都管用。希望帮到你。本文还有配套的精品资源点击获取