企业官网建设流程全解析

1. 项目整体设计与思路拆解

1.1 核心需求：这门课设/毕设题目到底在要求什么

先说个现象：微信小程序 + Django 这种组合在近几年的计算机类毕业设计里出现频率相当高，原因是它的技术栈覆盖很完整，前端涉及小程序原生开发，后端涉及 Python Web 框架，中间还要处理数据库设计、API 接口、状态管理、部署上线等环节，一个项目能把大学四年的大部分知识点串起来。咖啡馆/博物馆/展览馆预约系统，本质是一个“资源预约 + 信息展示 + 后台管理”的典型业务系统，业务逻辑清晰、边界明确，适合作为课程设计或毕业设计的载体。

我最初拿到“基于微信小程序 Django 咖啡博物馆预约小程序的设计与实现”这个题的时候，先做了一件很多同学会忽略的事：把题目里的关键词拆开读一遍。咖啡博物馆是一个具体场景，但它本质上对应的是“门店 / 场馆预约”，预约才是核心；博物馆属性对应的是“展品信息展示”，咖啡属性对应的则是“商品 / 套餐展示”。这就意味着，系统至少要有两条业务线：一条是用户浏览展品或商品然后预约参观/消费，另一条是管理员管理预约订单、维护展品信息、处理用户反馈。如果只做一个简单的“填表单选择时间然后提交”，那这个设计在答辩时基本会被老师追问得体无完肤。

所以我把这个项目定位成：一个面向 C 端用户的小程序预约入口 + 一个面向运营人员的后台管理端。小程序端负责用户注册登录、展品/商品浏览、预约下单、个人中心；后台基于 Django Admin 或自定义管理页面，负责展品管理、预约时段管理、订单审核与统计。这样的架构，既能满足“设计与实现”的要求，又为后续扩展留了余地。

1.2 技术选型：为什么是微信小程序 + Django 而不是其他方案

选型是毕设开题时最常被追问的问题，也是我在远程调试时最常帮学生补的“答辩素材”。先说前端，微信小程序是当下国内学生最容易上手、也最容易展示成果的移动端形态。它不需要开发者在本地搭 Android 或 iOS 环境，只需要注册一个小程序账号，下载微信开发者工具，就能写代码、看效果、真机预览。如果你用 uniapp 写小程序，那还能顺便保留一套代码以后打包成 App 的潜力，不过这里我建议原题怎么要求就怎么来——题目写的是“微信小程序”，直接用原生小程序语法去实现，最稳。

后端选 Django 的理由更实际。Python 本身就是很多高校计算机专业的主修语言，Django 是 Python 生态里最成熟的全栈框架之一，自带的 ORM、Admin 后台、表单校验、认证系统，能让开发效率翻倍。尤其是 Django Admin，它几乎“白送”了一个后台管理界面——你只需要定义好数据模型，注册到 admin.py，就能在网页上对数据库里的记录做增删改查。对于一个课时有限的毕设项目来说，这能省出大量时间，让你把精力放到业务逻辑和界面实现上。

还有一个重要的点是，论文和答辩材料好写。Django 是 MTV 架构，M 指 Model 数据模型，T 指 Template 模板，V 指 View 视图函数，这直接可以对应到软件工程的“三层架构”，写进设计章节非常顺。比选 Node.js + Express 或 Flask 这种轻量方案，Django 的“电池全内置”风格，在毕业设计的篇幅上天然有优势。

数据量小、并发量低，这是学校项目的普遍特点，所以我没有引入 Redis 或 Celery，直接用 MySQL 或 SQLite 存数据就够了。数据库选型上，如果老师要求用 MySQL，可以在 Django 的 settings.py 里配置 PyMySQL；如果为了本地演示方便，SQLite 零配置也很好用。两种方案我都配过，后面会讲怎么切换。

2. 数据库设计与 Django 后端实现

2.1 核心数据模型：用户、展品、时段、订单怎么设计

数据库设计是很多同学拿到题目后的第一个卡点，因为模型设计直接决定后续所有接口怎么写。我习惯先从“订单”这个核心业务出发往回推。一次预约行为涉及哪些要素？谁预约（用户）、预约什么（展品/咖啡套餐/参观场次）、什么时间（预约日期和时段）、状态如何（待确认/已确认/已取消/已完成）。基于这个分析，我设计了四个核心模型：

第一个是用户模型。虽然 Django 自带 User 表，但小程序场景下，我们通常直接用微信的 openid 来标识用户，所以更合理的做法是建一个 UserProfile 或者直接用 Django 内置 User 扩展 OneToOne 字段，存用户的昵称、头像、手机号等资料。openid 是个很重要的字段——它是用户在微信生态里的唯一身份标识，后续所有登录态都靠它。

第二个是展品/商品模型。咖啡博物馆里既有历史展品，也有咖啡饮品和文创周边。我在设计时用了一个带类型字段的模型，字段包括名称、封面图、简介、详情、类型（展品/饮品/周边）、库存、是否上架。这样小程序首页的轮播、展品列表、饮品列表，后台都能统一维护，不用为每一种内容单独建表。

第三个是预约时段模型。这是容易被忽视却很重要的表。预约制度的核心是“限流”，如果没有时段表，用户随便选时间，管理员很难控制场馆接待能力。时段的字段很简单：日期、开始时间、结束时间、最大预约人数、已预约人数。设计好之后，前端展示某个日期时，就根据这张表渲染可选时段，同时把已经满员的时段置灰。

第四个是预约订单模型。字段包括订单号、关联用户、关联时段、预约人数、联系人姓名、手机号、备注、状态、创建时间。订单状态我定义了四种：待确认（用户提交后）、已确认（管理员审核后）、已取消（用户或管理员取消）、已完成（预约日期过后自动或手动标记）。有的人会把“支付”也设计进去，但这个项目不是电商，预约通常免费或到店支付，所以不建议引入支付接口，只会增加复杂度。

2.2 接口设计：小程序和 Django 怎么通信

小程序端不能直接访问数据库，必须通过 HTTP 接口和后端交互。我在设计接口时遵循了简单的 RESTful 风格，同时为了让答辩时好讲，特意控制了接口的数量，不是什么都做成接口，而是按页面聚合：

• POST /api/login：接收小程序端 wx.login 获取的 code，通过微信接口换取 openid，完成登录或注册，返回自定义登录态 token。
• GET /api/items?type=exhibit：获取展品列表 / 饮品列表，用于首页和列表页展示。
• GET /api/items/{id}：获取单个展品/商品的详情。
• GET /api/slots?date=2025-06-01：获取指定日期的可预约时段。
• POST /api/order：创建预约订单，参数包括时段 id、预约人数、联系人信息等。
• GET /api/order/list：查询当前用户的预约记录。
• POST /api/order/cancel：取消预约。
• GET /api/home：聚合首页数据，把轮播图、展品推荐、门店信息一次返回，减少请求次数。

在 Django 里实现这些接口，可以用 Django REST Framework（DRF），也可以用原生 JsonResponse。Drf 虽然多装一个依赖，但它自带的序列化器和认证权限控制很好用。我一般建议学生用 DRF，理由是代码更规范、答辩时分词更容易，而且做 API 文档时可以在线的接口文档页面也省了，直接在浏览器里访问接口 URL 就能看到 JSON 数据。

登录这块有一个细节需要讲一下：微信小程序的wx.login拿到的 code 是临时凭证，后端通过 code 换取 openid 需要调用微信的接口，这要求你的服务器有外网访问能力，本地开发时也没问题。如果因为一些原因微信接口调用不稳定，可以采用后端临时方案——让小程序端用 mock 的 openid（比如写上 openid123），后端识别到测试模式直接放行。这种办法在本地演示时非常实用，但论文里要写明线上版本走的是正规流程。

2.3 Django Admin 后台：免费的管理系统长什么样

Django 的 Admin 后台是一个大杀器，很多同学直到交项目都没用过，太可惜了。只要你把数据模型写在 models.py，并在 admin.py 里用admin.site.register(模型名)注册，重新跑一下服务，就能在http://127.0.0.1:8000/admin/看到后台登录页面。用createsuperuser创建的管理员账号登录后，你可以直接在网页上对展品、时段、订单做增删改查。

为了让 Admin 后台更好用，我会做一点定制。比如在 Order 模型里加一个 list_display，让订单列表直接显示订单号、用户名、预约日期、时段、状态；加一个 list_filter，让管理员按状态和日期筛选；加一个 search_fields，支持按手机号和订单号搜索。这些看起来只是几行代码，但在演示时非常加分，老师在后台随便点点就能看到你的系统是“活”的。

另外，admin.py 里还可以重写 save_model 方法，在管理员确认订单时自动给时段表更新已预约人数，这样后台的数据和前台的展示就是联动的。有同学问要不要自己写一套 Vue 后台，我的建议是：除非题目明确要求，否则不要给自己挖坑。Django Admin 规范整洁，而且你可以在论文里写“基于 Django 自带后台进行二次开发”，这本身就是一个合理的技术方案。

3. 微信小程序端从 0 到 1 的实现

3.1 小程序项目结构：页面划分与文件组织

微信小程序原生开发的项目结构比较简单，核心是一个 app.js、一个 app.json、一个 app.wxss 加若干页面文件夹，每个页面一般包含 .js、.wxml、.wxss、.json 四个文件。我习惯先规划好 tabBar 和页面路由，再把目录建出来。

这个项目我设计了四个底部导航栏目：首页、展品/菜单、预约、我的。首页对应 pages/index，展品页对应 pages/items，预约页对应 pages/reserve，我的页面对应 pages/user。此外还有几个非 tabBar 的二级页面，比如展品详情页 pages/detail、订单列表页 pages/orders、添加预约联系人页面 pages/contact。

app.json 里最关键的是pages数组和tabBar配置。pages 数组的第一项是启动页面，我建议把首页放第一位，不要为了省事把某个中间页面放第一位，否则每次编译打开都是那个页面，调试预约流程时要多划好几步。tabBar 的图标需要准备 PNG 图片，不要直接在本地放一张大图，尺寸最好用 81px 81px 的标准，否则真机预览时图标会被拉伸变形。

页面之间跳转我用wx.navigateTo和wx.switchTab配合使用。有一个坑：wx.navigateTo不能跳到 tabBar 页面，如果你在详情页想返回首页，用wx.navigateTo会报错，必须用wx.switchTab。这个问题我在远程调试时几乎每隔一两个学生就会遇到，先统一说给你们排掉。

3.2 首页与列表页：数据加载和展示怎么做

首页是整个小程序的门面，我建议它包含四块内容：顶部搜索或分类入口、轮播图、展品/饮品列表、底部推荐预约卡片。数据来源是后端聚合接口GET /api/home，小程序端在onLoad生命周期里用wx.request请求这个接口，拿到数据后setData到 data 里，页面通过wx:for循环渲染列表。

在 WXML 里渲染列表时，需要注意wx:key的设置。如果不设置wx:key，小程序在更新列表时会报警告，而且频繁操作时可能出现渲染错乱。最稳妥的做法是给每条数据唯一的 id，比如wx:key="id"。还有一个实际体验相关的小细节：图片的懒加载。小程序原生的 image 组件默认是立即加载，如果列表里有十几张大图，页面切入时会有明显卡顿。可以给 image 组件加lazy-load属性，让它滚动到可视区域附近才加载，实测下来流畅度提升很明显。

首页的轮播图建议用swiper组件，indicator-dots开启指示小圆点，autoplay设置自动播放间隔。我在实际项目里会把轮播图和公告做成可配置的——后端返回什么图就显示什么图，这样运营人员不用改代码就能换首页的推广内容。答辩时你说“首页内容支持后台动态配置”，这句话本身就是加分项。

3.3 预约核心流程：时段选择、表单校验与提交

预约流程是本项目的核心业务，也是我花时间最多的部分。用户从首页点“立即预约”进入预约页，第一步选择日期，第二步选择时段，第三步填写联系人和人数，第四步提交订单。每一步的交互都要有清晰的反馈。

先讲日期和时段的选择。我用一个横向滚动的日期栏展示未来 7 天，默认选中今天。用户切换日期时，小程序端向GET /api/slots?date=...发起请求，拿到当天所有时段，用wx:for渲染成卡片列表。每个时段卡片显示开始时间、剩余名额，剩余名额为 0 的时段自动置灰并且不响应点击事件。这一步的体验细节在于：如果用户选择日期后接口还在加载中，要显示一个 loading 状态，否则用户会以为网络卡死了。我用.loading类配合wx.showLoading来提示。

表单部分，预约人数我用slider和stepper结合的方式实现。用户拖动滑块选择人数，旁边显示具体数字。之所以不用简单的输入框，是因为人数必须是 1 到 5 之间的整数，滑块天然限定了范围，不用再写一堆校验逻辑。联系方式和姓名用input组件，需要注意设置maxlength，手机号设 11 位，姓名建议设置 10 位。

提交按钮点击后，先在前端做一轮校验：手机号正则匹配、姓名非空、时段已选。校验通过后调用POST /api/order提交数据。这里有一个经验：提交按钮要加一个disabled状态，防止用户重复点击生成多个订单。我采取的做法是：点击后立即把按钮文案改为“提交中...”，同时禁用点击，等后端返回结果后再恢复。这个小细节在演示时非常容易被老师注意到，因为它体现了你对用户体验的思考。

3.4 我的页面与订单管理：状态展示和取消逻辑

“我的”页面主要展示用户信息和预约记录。预约记录我分成几个 tab 或筛选标签：全部、待确认、已确认、已取消、已完成。每次切换标签，小程序向GET /api/order/list?status=...发起请求，重新渲染列表。

预约订单的卡片上，我会展示字段：订单号、展馆/项目名称、预约日期、时段、人数、状态标签、操作按钮。状态标签用不同颜色区分——待确认用橙色，已确认用绿色，已取消用灰色，已完成用蓝色，这样用户一眼就能看明白。操作按钮根据状态变化：待确认和已确认状态显示“取消预约”，已完成状态不显示按钮，已取消状态显示“再次预约”跳转到预约页并预填上次的日期。

取消预约的逻辑看起来简单，实际有一个要注意的点：取消后，对应时段的“已预约人数”要减一，否则这个名额就被永久占掉了。这个操作必须放在后端事务里处理，先检查订单状态，再更新时段人数，最后修改订单状态，三步要么全部成功要么全部失败。Django 的transaction.atomic()在这里派上用场。我在帮学生调试时，不止一次遇到因为漏掉人数回退，导致时段明明没人预约却显示满员的情况，你们写的时候一定记得加上。

4. 环境搭建、部署准备与远程调试

4.1 本地开发环境：Django 项目初始化与关键依赖

拿到源码之后第一件事是让项目在本地跑起来。环境要求很基础：Python 3.8 以上，推荐 3.10 或 3.11；安装 Django 和 Django REST Framework；数据库用 SQLite 开箱即用，想切 MySQL 也可以装 PyMySQL。

初始化步骤我给一个自己经常用的版本。先创建虚拟环境，这一步比较推荐，可以避免不同项目之间依赖打架：

python -m venv venv venv\Scripts\activate # Windows 下的激活命令 # 或者 Mac/Linux: source venv/bin/activate

然后安装依赖：

pip install django djangorestframework pymysql pip freeze > requirements.txt

再创建项目和 app：

django-admin startproject coffee_museum cd coffee_museum python manage.py startapp reservation

在 settings.py 里把rest_framework和reservation加到 INSTALLED_APPS，然后执行数据库迁移：

python manage.py migrate python manage.py createsuperuser python manage.py runserver

浏览器访问http://127.0.0.1:8000/admin/如果能正常显示后台登录页，说明后端环境已经 OK。

4.2 微信小程序端配置：AppID、域名和开发者工具设置

小程序端的配置比后端更容易出问题。注册微信小程序账号后，可以在公众平台的开发设置里拿到 AppID。开发时，把 AppID 填进微信开发者工具的项目设置里，注意不要选“测试号”模式——测试号不支持 wx.request 的合法域名校验，虽然方便但也容易掩盖一些问题。

本地开发时，小程序端请求的接口地址设置为本地 Django 服务的地址，比如http://127.0.0.1:8000。但这里有一个很坑的地方：微信开发者工具默认会校验 request 合法域名，而本地地址不在白名单里，直接请求会报“url not in domain list”。解决方案是在开发者工具的“详情”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，就能正常发起请求了。这个开关只对开发工具有效，真机预览时依然会被拦。所以真机调试时，要么在后端配置 HTTPS 证书并备案域名，要么在真机预览里同样打开“开发环境不校验域名”的开关。我一般建议学生在答辩演示时用真机预览 + 关闭校验的模式，简单可靠。

关于 HTTPS 证书和上线部署，毕设项目通常没有条件买服务器和域名，所以很多同学会用内网穿透工具把本地的 Django 服务暴露到公网，再把 HTTPS 地址填进小程序的合法域名。这条路可以走通，但需要提前测试稳定性，因为免费版穿透服务有时候会断连，答辩现场信号一差就尴尬了。我的建议是：如果只是为了演示，优先用微信开发者工具的模拟器，不依赖外网；如果老师要求真机演示，再考虑穿透或部署到云服务器。

4.3 远程调试时我遇到过哪些问题

提到远程调试，我得说一句：帮学生远程调试其实最怕的不是代码 bug，而是环境不一致。同一个项目在两台电脑上跑起来，可能会出现完全不同的报错，原因常常出在 Python 版本、依赖包版本、数据库迁移顺序上。

最常见的一类问题是依赖包版本冲突。比如 Django 3.x 和 Django 4.x 在 URL 配置上有细微差异，url()函数和re_path()的导入路径不同，如果学生装的是 Django 4.2 但代码是照着 Django 2.x 的教程写的，那启动时就会报ModuleNotFoundError: urls。这类问题的排查方法很直接，先pip show django看版本，再看代码里的导入语句。统一用pip install -r requirements.txt安装锁定版本，可以解决大部分环境问题。

第二类问题是数据库迁移顺序。如果源码里已经有多张数据表，而你删除了数据库文件或换了一台电脑重新执行 migrate，可能会出现“表已存在”的报错。解决办法是把旧的 SQLite 文件删除，重新执行makemigrations和migrate。但如果你有不想丢失的后台数据，那就不要轻易删库。改模型后一定要先makemigrations再migrate，顺序反了会提示“No changes detected”。

第三类问题是跨域问题。小程序端请求后端接口时，如果后端没有配置CORS，在某些调试场景下会被浏览器的同源策略拦住，报Access-Control-Allow-Origin错误。虽然小程序原生不是浏览器，不存在传统 CORS 的概念，但一些特定的请求头校验还是可能触发问题。最省心的做法是安装django-cors-headers，在 settings.py 里配置允许所有来源即可。

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

5.1 微信小程序端常见报错与处理

开发小程序时，我整理了一个高频问题列表，每一个都是真实踩过的坑。

第一个是wx.request请求返回 404 或 500。404 通常是 URL 路径写错或后端接口还没实现；500 一般是后端代码异常，需要在后端终端看报错信息。排查时需要先在后端访问接口地址确认是否正常返回 JSON，再回小程序端检查路径。如果后端正常而小程序端仍报错，多半是域名校验问题。

第二个是setData数据量过大的性能问题。预约列表、订单列表这些接口返回的数据量通常不大，但如果首页把全部展品和全部饮品一次拉回来，数据可能达到几百条。每一条在 setData 时都会被序列化，次数一多页面就卡。我的做法是后端做分页，接口支持page和page_size参数，小程序端用onReachBottom触底加载下一页。

第三个是预览图片时wx.previewImage不生效。原因是图片链接如果是后台返回的相对路径，小程序端无法直接预览，必须转成绝对路径。比如后端返回/media/item/3.jpg，小程序端要拼接服务器地址变成http://127.0.0.1:8000/media/item/3.jpg。

第四个是用户点击“授权登录”后没有反应。微信小程序近几年的版本对授权接口做了调整，wx.getUserProfile需要在用户主动点击按钮时触发，不能在 onLoad 里自动调用。这个限制让很多学生踩坑，症状就是登录弹窗不出现。解决办法是通过 button 的bindtap触发登录逻辑，而不是在页面加载时调用。

5.2 Django 后端常见报错与处理

后端这边也有几个经典问题。第一个就是python manage.py runserver启动时报Port 8000 is already in use，这说明 8000 端口被其他进程占用了。Windows 下用netstat -ano | findstr 8000找到占用端口的 PID，再在任务管理器里结束进程即可；Mac/Linux 下可以用lsof -i :8000配合 kill 处理。

第二个是ModuleNotFoundError: No module named 'pymysql'，这个问题通常在配置 MySQL 后出现。解决办法是在__init__.py里加入两行代码：

import pymysql pymysql.install_as_MySQLdb()

如果你用的是 Django 4.x，还需要在 settings.py 里指定default数据库的 ENGINE 为django.db.backends.mysql，同时确认 HOST、PORT、USER、PASSWORD 都配置正确。

第三个是admin后台数据显示为对象名而不是可读的标题。这是因为模型类里没有定义__str__方法。在每个模型类里加一个__str__，返回合适的字段，比如订单返回订单号、时段返回日期和时间，后台显示就会变得直观。

5.3 答辩与现场演示的几点建议

答辩演示是这个项目能否拿高分的关键环节，我有几条从学生反馈里总结出来的实操建议。

第一，务必准备一份“最小演示路径”。打开小程序、登录、选择日期、选择时段、提交预约、后台查看订单、修改状态，这个过程最多三分钟，但要确保每一步都顺畅。不要把时间浪费在展示那些容易出错的边角功能上，比如消息推送、地图定位，这些功能如有问题就不要主动展示。

第二，把数据库里预置一些看起来真实的数据。比如后台提前录入两个星期的时段、二十个展品、几条不同状态的订单，演示时页面一打开就很丰富，比空表数据有说服力得多。数据不要只录今天的，要把未来几天的也录进去，现场万一网络不好，用户看到的列表也还是满的。

第三，准备 3 到 5 个“亮点追问”答案。老师大概率会问：为什么用 Django？为什么不直接用云开发？预约冲突怎么解决？这些问题的答案其实都在你前面的设计里。核心答法是：Django 是 MTV 架构、自带 Admin 后台、ORM 方便维护；云开发虽然简单但无法体现后端设计能力，同时也受平台限制；预约冲突通过数据库事务和时段名额判断来保证，即使多人同时提交，最终也只有一个能成功。

6. 项目扩展思路与代码交付

6.1 从毕设到可落地的三个扩展方向

项目交完之后，如果还有精力，我建议可以往三个方向做扩展，既能丰富简历项目描述，也能在复试或面试时展示自己的主动性。

第一个扩展方向是消息通知。当前系统的预约确认状态只能用户自己刷新查看，体验不够完善。可以引入微信公众号模板消息或小程序订阅消息，在下单成功后提醒用户“您的预约已提交”，在管理员审核后再次通知“预约已确认”。微信小程序的订阅消息需要用户主动授权，每次授权只能触发一次消息推送，需要在用户提交订单时引导勾选。这块逻辑涉及微信 access_token 的获取和模板消息的发送，做完之后你的后端能力会提升一个档次。

第二个扩展方向是数据统计功能。在后台增加一个数据面板，展示每日预约量、热门时段、用户增长趋势等关键指标。Django 的 ORM 可以通过annotate和Count实现按日期分组的统计，返回的 JSON 配上小程序端的 ECharts 或图表组件，就能做出可视化的数据报表。这个扩展在论文里可以单独作为一章“系统测试与数据分析”，分量很足。

第三个扩展方向是国际化或多门店支持。把“博物馆”抽成一个门店维度，一张门店表，展品和时段都挂在门店下，这样系统从一个单店预约系统升级成多门店预约平台。这个改动会涉及数据模型的关联关系调整，工作量适中，能体现你对业务抽象的理解。完成之后可以写进“系统展望”部分，说明你的设计留了扩展空间。

6.2 代码交付时我建议打包哪些资料

毕设交付不是只交源码就完事，尤其是整套源码+文档的形式，交付物要齐全。我建议按以下清单整理：

• 项目源码目录：前后端完整代码，包含注释，README 写清楚环境要求、启动步骤、默认账号密码。
• 数据库文件：SQLite 文件或 SQL 导出脚本，保证对方拿到就能直接跑出数据。
• 环境依赖文件：requirements.txt，锁定关键依赖版本。
• 设计文档：包括需求分析、数据库设计说明书、接口文档。如果没时间写完整论文，至少要有一份功能清单和接口说明。
• 截图素材：小程序页面截图、后台管理截图、数据库设计图，这些是写论文和答辩 PPT 的原材料。
• 演示视频：3 到 5 分钟的操作演示视频。很多老师没时间等你现场演示，直接看视频打分的情况很常见。

整理这些资料时，注意不要在代码里写死真实数据库的密码或密钥。涉及微信 AppSecret 的配置，建议写成环境变量读取的方式，并在 README 里说明配置方法。这既是安全习惯，也是答辩时展示工程素养的机会。

6.3 源码怎么“读”比“写”更重要

最后说一个多数学生忽略的点：对于从网上下载或购买的源码，读代码的能力比写代码的能力更稀缺。你拿到一套完整的 Django + 小程序源码，第一步不是运行它，而是先理清它的目录结构。打开后端的 urls.py，看有哪些路由，再对应找到每个视图函数；打开小程序端的 app.json，看有哪些页面，再逐个打开看 JS 文件中请求了哪些接口。把“接口和页面”对应起来，系统在你脑子里就活了。

调试时多用 print 或日志。在 Django 视图里临时加print(request.data)，在小程序端console.log请求返回值，虽然方式笨，但定位问题非常快。比对着报错信息瞎猜靠谱得多。

小程序和 Django 的结合项目，本质上就是一个“前端页面 + 后端接口 + 数据库”的三层结构，听上去简单，做完之后你会对 Web 全栈开发形成一个完整的认知。这也是这个毕设题目最有价值的地方——它逼着你把大学里散落的知识点真正串起来。