PHP+Vue+微信小程序学习交流平台毕设全流程开发实战

当年我做“基于PHP+Vue的微信小程序学习交流平台”这个毕业设计的时候，最大的感受不是技术有多难，而是“系统怎么从零到一跑通”这件事远比想象中琐碎。选题要求很直接：用户端用微信小程序，后台管理系统用 Web 页面，后端提供真实数据接口，还要有完整的数据库设计和论文支撑。所以我最终把架构定成了 PHP 提供 API、Vue 做管理后台、微信小程序当用户端、MySQL 存数据，四个部分串成闭环。这篇文章就把我从需求拆分、表结构设计、接口开发、Vue 后台实现到小程序调试的完整过程讲一遍，顺带整理毕设答辩时最容易被追问的问题。准备做类似选题、或者在找现成案例参考的朋友，可以直接对照着抄作业。

1. 先把这个毕业设计题目拆明白

1.1 这个项目到底在做什么

“学习交流平台”这六个字，听起来很宽泛，但如果用在毕业设计里，核心就是两个字：闭环。不能只有学习资料的上传和下载，还得有用户交流；不能只有交流，还得有管理员去审核和治理，否则评委一句“你的系统如何保证内容质量”就把你问住了。所以我在系统里规划了四个基础业务块：

• 学习资料：管理员或用户上传文档、图文，按分类展示，支持关键词搜索。
• 交流社区：用户发帖提问，其他用户回帖，对回复点赞。
• 用户中心：微信登录、个人资料、我的发布、我的收藏。
• 后台管理：管理员维护用户状态、审核内容、管理公告和分类。

每一个块在技术上都不是难点，但把它们串起来之后，你需要考虑的数据关系和接口数量就变得非常真实。这也是这个选题最划算的地方——难度不会大到让你做不完，但又能把后端开发、前端开发和移动端开发的基本功全部展示一遍。

1.2 用户角色的边界要提前划清

定功能之前，角色必须先定。我分了三类角色：游客、普通用户、管理员。

游客：首次进入小程序，只能看部分公开数据，比如资料预览、帖子阅读，但无法发帖、无法下载、无法点赞。普通用户：调起微信登录后即可获得完整功能权限。注意这里不是做传统的注册页，微信小程序比较自然的做法是“微信授权登录后自动建档”。管理员：在小程序端不设管理入口，管理工作全部放进 Vue 后台，包括管理用户状态、删除违规帖子、编辑资料分类、发布公告。

把游客、用户、管理员分开之后，接口和页面都比较好“画边界”。漏掉游客这一角色是很多同学常犯的错：一上来就默认所有人必须登录，结果老师打开小程序连内容都看不到，观感差很多。游客能浏览、登录后能互动，这本身也是一个值得在论文里写的需求分析结论。

1.3 为什么选 PHP + Vue + 微信小程序这套组合

我当时选型没有太多高大上考虑，就三条：部署难度低、生态资料多、演示效果好。PHP 这门语言在虚拟主机时代基本属于“能放进去就能跑”，就算用 ThinkPHP 框架，只要在本地配一个小皮面板或者 PHPStudy，启动速度也远低于 Java 系；Vue 则负责做后台管理界面，组件化写起来比传统 jQuery 拼接 DOM 要清晰得多；小程序端用原生开发，是因为微信开发者工具本身就是调试闭环，你不需要为跨端适配付出额外成本。

这套组合还有一个潜在优势：PHP 服务端代码可以直接用 Nginx 或 Apache 部署在本地或局域网服务器上，老师可以用手机真机扫码访问，比让评委只看 PPT 录屏要有说服力得多。毕设答辩时，“能跑起来”永远是第一位的。

1.4 所以别一上来就把功能铺太大

如果你还有六周时间，我建议把功能砍到最低可用版本：一个用户端首页、一个学习资料列表、一个发帖回帖页面、一个后台数据管理页面就够了。等基础版本演示通过后再考虑加收藏、加分类、加公告、加浏览量统计。原则是：功能第一完整，第二丰富，千万不要一上来就给自己画一个“视频弹幕级”的饼。我见过太多同学把需求文档写得非常宏大，最后连登录都调不通的例子。先闭环，再好看，是做毕设最务实的思路。

2. 整体架构与技术选型里的门道

2.1 前后端分离到底分离在哪

这套系统里有两个客户端：一个是浏览器里打开的管理后台（Vue），一个是在微信开发者工具里运行的小程序。它们都需要数据，所以后端直接把业务能力暴露成 HTTP 接口即可。我采用的架构是：

小程序客户端 → Nginx/Apache → PHP 接口服务 Vue 管理后台 → Nginx/Apache → PHP 接口服务

数据库统一用 MySQL 5.7。如果要让同学在手机上真机调试，后端地址需要是局域网里能访问的 IP，小程序开发工具里把“不校验合法域名”勾上即可，否则真机总会报域名不合规。这种前后端分离结构最大的好处是职责清楚：改前端不用动后端，接口稳定后两条线就能并行开发，在期末冲刺阶段特别省时间。

2.2 PHP 后端用框架还是原生

先说结论：毕设里我推荐使用 ThinkPHP 6 这样的轻量框架，而不是完全原生。

框架自带数据库查询构造器，能让你少写大量冗余的mysqli_代码，也让老师觉得你工程化意识过关；框架自带路由机制，接口风格统一；控制器与模型分层之后，论文里可以直接画软件架构图。完全原生 PHP 的优势是“单文件解释起来简单”，但劣势也明显：登录接口加文件上传接口写到后期，SQL 注入和代码可维护性问题都要亲力亲为。对毕设来说，时间不该浪费在这上面。

我当时按 ThinkPHP 6 的标准结构组织代码：

app/ controller/ // 接口控制器 model/ // 数据模型 api/ route.php // 路由绑定 config/ // 数据库和跨域配置 public/ // 入口和静态资源

如果你不熟悉 ThinkPHP，用原生 PHP 照样能做，下面代码我会尽量用接近原生和查询构造器的风格来写，方便你迁移到自己的项目里。

2.3 Vue 后台为什么选 Vue 而不是 jQuery

管理后台的页面虽然不过就是用户列表、审核列表、表单提交，但如果继续用传统 jQuery 去操作 DOM，数据一变就要手动重绘表格，代码会越来越乱。Vue 的思路是“数据驱动视图”：列表数据绑定后，this.list = res.data，表格自动更新，写起来非常舒服。我用的是 Vue 2.6 + Element UI。现在虽然有 Vue 3 和 Element Plus，但 Vue 2 的案例在网上最多，遇到问题随手就能搜到，对毕设来说效率最重要。

作为过来人，我提醒一句：安装 Vue 环境前先确认 Node 版本。Vue 2 的项目在 Node 16/18 上大多数依赖都能跑，但有些旧依赖会让你折腾到怀疑人生。建议统一使用 npm 安装依赖，项目里尽量不引入需要编译原生模块的包，否则换一台电脑演示就变成灾难现场。

2.4 数据库设计：核心表和字段

整个毕设里，数据库表是最值得你花时间想清楚的东西。我最终把表拆成下面这些：

• user：id、openid、nickname、avatar、role、ban_status、create_time
• category：id、name、sort_order、status
• resource：id、category_id、title、description、file_url、cover_url、views、create_time
• post：id、user_id、title、content、images、likes_count、comment_count、status、create_time
• comment：id、post_id、user_id、content、create_time
• like_record：id、post_id、user_id、create_time
• announcement：id、title、content、create_time
• admin：id、account、password、last_login_time

这里有两个设计细节要强调。

第一，点赞记录一定要单独建一张like_record表，而不是在post表里存一个 JSON 字段，因为后面要判断“当前用户是否点过赞”必须通过查表，而不是去解析 JSON。第二，openid是微信用户唯一标识，设计上要加唯一索引。登录接口第一次拿到时插入，以后都靠openid识别用户。表之间的外键约束不需要写太多，否则以后删除用户时会被一堆外键卡住，毕设里用逻辑关联就够了。

2.5 接口返回格式必须提前统一

前后端联调最怕的就是“每个接口返回格式都不一样”。我在开发时提前定了一个通用 JSON 结构，所有接口都按这个格式吐数据：

{ "code": 0, "msg": "ok", "data": {} }

code 为 0 表示成功，非 0 表示失败，msg 给前端提示。这个约定看着简单，但能极大减少沟通成本。Vue 和小程序端的 axios、wx.request 拦截器统一读取 code，如果不是 0 就直接弹提示，完全不用每个接口单独判错。后面在答辩时讲“接口规范设计”，这段也能拿出来说。

3. PHP 端开发：写完接口也得背锅

3.1 公共逻辑优先处理

后端开发前，先把三件事做好：统一跨域、统一返回格式、统一参数校验。

跨域主要针对 Vue 后台，小程序不存在跨域问题，但浏览器访问后台接口时有。在 ThinkPHP 中通常在中间件里加响应头：

header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization'); header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');

另外因为浏览器发跨域请求前会先发一个 OPTIONS 预检，如果你的路由中间件没放行 OPTIONS，前端调用会一直失败。这个问题几乎每个做前后端分离的人都踩过，我当时以为后端已经加了响应头就万事大吉，结果 Vue 后台所有请求都挂在 preflight 上，排查了整整一个下午。

3.2 微信登录接口怎么实现

小程序端拿到微信登录的临时 code 后，后端需要用自己的 AppID 和 AppSecret 去微信接口换 session_key 和 openid。核心逻辑可以简化成：

$code = input('post.code'); if (empty($code)) { return json(['code' => -1, 'msg' => 'code不能为空']); } // 开发环境建议用 curl，这里示意 file_get_contents $res = file_get_contents( "https://api.weixin.qq.com/sns/jscode2session?appid={$appid}&secret={$secret}&js_code={$code}&grant_type=authorization_code" ); $result = json_decode($res, true); if (isset($result['errcode'])) { return json(['code' => -1, 'msg' => '微信登录失败']); } // 根据 openid 查找用户，不存在则自动建档 $user = UserModel::where(['openid' => $result['openid']])->find(); if (!$user) { $user = UserModel::create([ 'openid' => $result['openid'], 'nickname' => '微信用户' . mt_rand(1000, 9999) ]); } // 生成自定义 token 返回给前端 $user->token = md5($user->openid . time()); $user->save(); return json(['code' => 0, 'data' => ['token' => $user->token, 'userInfo' => $user]]);

这里有两个坑要提前说。

一是file_get_contents请求微信接口时，如果你的服务器没开allow_url_fopen或者缺少 CA 证书，会直接请求失败。更稳妥的方案是用 curl，并设置CURLOPT_SSL_VERIFYPEER为 false，开发环境下这样能省很多事。二是不要在登录接口里保存session_key到前端。我们自己生成 token 存到user表，前端每次请求带上 token，后端中间件鉴权即可。这个方案简单，而且答辩时能讲清楚。

3.3 学习资料模块的接口

资料模块无外乎列表、详情、上传、删除、分类。开发时把接口写得整齐一点，能给后面的 Vue 管理端省下一大堆工作量。比如分类列表：

public function category() { $list = CategoryModel::where('status', 1) ->order('sort_order asc') ->select(); return json(['code' => 0, 'data' => $list, 'msg' => 'ok']); }

资料分页列表接口要支持关键词搜索，SQL 部分用查询构造器拼接，注意别把用户输入直接拼进原始 SQL：

$where = []; if (!empty($keyword)) { $where[] = ['title', 'like', "%{$keyword}%"]; } $list = ResourceModel::where($where) ->page($page, $limit) ->select();

这种写法属于查询构造器的基本操作，安全性和可读性都有保障。如果你的项目是原生 mysqli，也请务必使用预处理语句，答辩时“防 SQL 注入”这一点非常好谈，老师很吃这一套。

3.4 社区帖子与评论接口

社区部分的核心接口有：发布帖子、帖子列表、帖子详情、发布评论、点赞与取消点赞。需要联合查询的地方不少，比如帖子列表要同时显示发帖人的昵称和头像；详情要返回帖子内容以及“当前用户是否点过赞”。我直接查询用户表合并数据，会有两次查询，数据量大时有点浪费，但毕设完全够用。

点赞实现的核心是：先查like_record，如果不存在就新增并执行post.likes_count + 1；如果存在就删除并执行post.likes_count - 1。这个逻辑要放在事务里：

Db::startTrans(); try { $has = LikeRecordModel::where(['post_id' => $postId, 'user_id' => $uid])->find(); if ($has) { $has->delete(); PostModel::where('id', $postId)->dec('likes_count')->update(); } else { LikeRecordModel::create(['post_id' => $postId, 'user_id' => $uid]); PostModel::where('id', $postId)->inc('likes_count')->update(); } Db::commit(); } catch (\Exception $e) { Db::rollback(); return json(['code' => -1, 'msg' => '操作失败']); }

事务在这里不是炫技，是为了保证“记录写了但数量没加”这类不一致的 bug 不会出现。答辩时如果你能主动说出“这里用了事务保证数据一致性”，评委好感度会明显提升。

3.5 文件上传与附件管理

学习资料平台肯定要支持上传文档或封面。PHP 端接收上传文件后不能直接把原始文件名存进数据库，万一两个用户上传了同名文件就会互相覆盖。我建议统一改成时间戳风格的新文件名再落盘：

$file = request()->file('file'); $info = $file->move('/www/upload/resource'); if ($info) { $url = '/upload/resource/' . $info->getFilename(); }

另外文件存储目录不要放在 public 之外，否则访问时容易 404；上传接口必须做类型和大小校验，文档只允许 pdf、doc、docx、ppt、zip，单文件控制在 50MB 以内。不然有人传一个超大文件，你的服务器和小程序端都会卡到没脾气。如果功能要做到“每下载一个文件就记录一次”，需要额外加一张resource_download_record表，这属于加分项，时间够的话建议做。

3.6 后端安全：越权与审核

做后台接口的时候，记得把所有管理员相关接口挂一个管理员鉴权中间件，不能只在控制器里写业务逻辑。接口里还要时刻保持一个观念：前端隐藏了按钮不等于后端没有漏洞。比如删除帖子，前端管理页只给管理员显示删除按钮，但如果普通用户知道接口地址直接 POST 调用，后端又没校验管理员身份，那就是越权漏洞。答辩老师很可能会挑这种点提问，越早加权限校验越好。

另一个容易被忽视的点：无论帖子还是评论，设计状态字段就要保证“上线后接口只返回审核通过的数据”。学生最容易犯的错是在本地数据库不小心插入了一条 status=0 的记录，小程序端也不过滤，结果演示时出现了脏数据。解决办法很简单，查询条件里加上status=1，不要依赖数据库默认值。

4. Vue 管理后台开发实录

4.1 从零创建项目和目录梳理

Vue 后台我实际使用的是 Vue 2 + Element UI，用vue create admin-web初始化项目，选择 Vue 2 / Router / Axios。创建好之后安装核心依赖：

npm install element-ui axios vue-router@3

安装完成后在main.js中引入 Element UI。这里有个容易踩的坑：如果你用 Vue 3 且安装了 Element Plus，API 和组件名称跟 Vue 2 版差异很大，网上抄代码时经常牛头不对马嘴。做毕设建议思想统一：要么全 Vue 2 + Element UI，要么全 Vue 3 + Element Plus，千万别混着抄。

项目内部目录我按下面的结构组织：

src/views/ 页面 src/api/ api 请求模块 src/router/ 路由配置 src/utils/request.js axios 封装

这样一来，每个页面只关心渲染和交互，请求逻辑统一走 api 目录模块，代码非常清爽。

4.2 axios 封装与统一拦截

管理端的请求需要带上登录后拿到的 token，所以封装 axios 时要加请求拦截器。这是所有后台页面都要用到的公共能力：

import axios from 'axios'; const service = axios.create({ baseURL: process.env.VUE_APP_BASE_URL + '/api', timeout: 15000 }); service.interceptors.request.use(config => { const token = localStorage.getItem('adminToken'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; }); service.interceptors.response.use( res => { const data = res.data; if (data.code !== 0) { return Promise.reject(new Error(data.msg || '请求失败')); } return data.data; }, error => { // 统一处理 401 跳转登录页等逻辑 return Promise.reject(error); } ); export default service;

这样做之后，页面里调用接口就很干净了。比如用户列表页：

this.userList = await getUserList({ page: 1, limit: 10 });

这是 Vue 开发时很有成就感的体验：数据流向清楚，页面几乎不需要处理重复的异常状态。

4.3 用户管理页与表格操作

用户管理页面用 Element UI 的el-table渲染，加上一个“封禁/解封”按钮。注意：封禁操作不需要真的删除用户，只需要把user表的ban_status设为 1，小程序端请求个人中心时如果检测到封禁状态就提示并退出登录。这样设计比物理删除用户更合理，也方便以后恢复。

表格开发时我建议按这套顺序找问题：先确认接口返回字段名，前端prop一定要对齐后端；再确认时间格式是否统一；最后确认按钮事件是否传对了 id。很多人把整行对象传进去，后端只能拿到[object Object]的字符串。这种小问题排查起来最花时间，不如一开始就规范。

4.4 资源审核页面

审核页是学习资源平台展示管理能力的核心页面。列表里筛选状态为“待审核”的资源，每行给两个按钮：“通过”和“驳回”。通过的时候直接更新resource.status = 1，驳回时可以填一个原因，存入resource.reject_reason。在小程序端，用户在“我的上传”列表里就能看到驳回原因，整个业务闭环就完整了。

审核页面还有一个细节：文件预览。建议在预览列放一个超链接，指向后端返回的文件 URL，管理员可以点击打开 PDF 预览。别小看这个交互，答辩演示时给评委直接展示文档内容，比在表格里看到一个文件名更有说服力。

4.5 后台构建与部署差异

本地开发时，Vue 项目的 API 地址一般是http://localhost:80/api。实际部署演示时，后端和前端可以在同一台电脑上，执行：

npm run build

然后打包dist目录，放到 Nginx 的 html 目录下，并配置反向代理：把/api前缀的请求转发到 PHP 接口服务，同时加上反向代理需要的跨域头。如果你不想配置 Nginx，也可以在 Vue 里直接写后端完整地址，但那样就要求后端接口开启跨域允许。这两种方式我都试过，相对省心的是 Nginx 反向代理，既不用改前端代码，也让接口地址更统一。

5. 微信小程序端开发实录

5.1 原生小程序的页面结构

原生微信小程序的页面结构就是四件套：wxml、wxss、js、json。我把小程序的页面规划成这样：

pages/ index/ 首页：公告、资料分类、热门帖子 resource/ 资料列表与详情 community/ 社区帖子列表 detail/ 帖子详情和评论 publish/ 发布帖子 mine/ 个人中心：我的发布、我的收藏、退出登录 login/ 登录页

每个页面保持非常纯粹的“请求接口 -> 渲染数据”，不需要引入复杂状态管理库。小程序原生够用，强行引入 Vue 反而会绕。开发工具里勾选“不校验合法域名”，本地调试时接口随便填 IP 都行。

5.2 登录流程与用户信息授权

老版本小程序可以通过wx.getUserProfile获取头像昵称，但新版对用户信息授权已经收紧。要注意：直接用wx.login拿到 code 传给后端建号即可，头像昵称可以在个人中心里让用户自己填写或后续完善。不要卡在授权这一步，否则无法登录，会显得项目不可用。

我当时的登录代码大概是：

wx.login({ success: (res) => { api.login({ code: res.code }).then(res => { wx.setStorageSync('token', res.data.token); wx.setStorageSync('userInfo', res.data.userInfo); wx.switchTab({ url: '/pages/index/index' }); }); } });

这里再说一次避坑点：微信之后对wx.getUserInfo返回真实头像昵称做了限制，所以不要把getUserInfo当作登录主流程。登录主流程只依赖wx.login加后端code2session，这样最稳。

5.3 封装小程序 request

小程序里没有 axios，你需要一个统一的请求模块。我在utils/api.js中封装：

const request = (url, method = 'GET', data = {}) => { return new Promise((resolve, reject) => { wx.request({ url: baseUrl + url, method, data, header: { 'Content-Type': 'application/json', token: wx.getStorageSync('token') }, success: (res) => { if (res.data.code === 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(new Error(res.data.msg)); } }, fail: reject }); }); };

页面调用方式统一成 async/await 之后，代码阅读性很强：

const posts = await request('/post/list', 'GET', { page });

统一封装的好处是：如果后端调整了返回格式或要加统一埋点，只改这一个文件就行，所有页面自动同步。

5.4 首页与学习资料列表

首页做三块内容：顶部公告、横向滚动分类、下方资源瀑布流。公告的数据结构是announcement表，前端直接循环渲染。分类可以做成横向 tab 加下方列表的形式，点击分类时把category_id传给后端，后端按分类过滤即可。

资料列表项显示封面、标题、分类、浏览量，点击进入详情页。详情页要给“下载/查看”按钮，如果后端返回的file_url是静态文件地址，在小程序里需要通过wx.downloadFile下载后用wx.openDocument打开，这是 PDF/Word 预览的常用流程。如果后端接口需要鉴权，记得在downloadFile的 header 里带上 token，否则可能下载 401。

wx.openDocument的调用时机最好放在用户点击按钮之后，不要在小程序onLoad阶段自动调，否则这个接口在部分机型上会有兼容性问题。

5.5 发帖与互动交互

发布帖子使用表单页面：标题输入框、正文 textarea、可选择相册图片。图片上传调用wx.uploadFile，一次一张地循环上传，拿到返回的 URL 再拼接成字符串存到post.images字段。上传完图片后，页面要立即展示缩略图，给用户即时反馈。这里同样需要注意：token 最好同时放到 formData 里，因为wx.uploadFile的 header 设置在部分 Android 端会有兼容问题。

帖子详情页的点赞按钮做“本地置灰 + 远程计数”双策略：记录当前用户是否点过赞，如果点过则显示已赞状态，后端通过like_record去重。这样一方面防止重复点击，另一方面保证显示数值与服务端一致。

5.6 小程序端最容易踩的三个细节

第一，顶部导航栏和内容区高度。很多新人把position: fixed的顶部菜单做出来后，发现页面底部内容被盖住。原生小程序里用wx.getSystemInfoSync()拿到的statusBarHeight和navigationBarHeight动态计算占位高度，别硬写 44px，不同手机的数值不一样。

第二，请求失败时的 loading 状态。页面加载时要有wx.showLoading，请求完成再wx.hideLoading，不然演示网速慢时界面像死锁一样，老师会觉得系统卡。

第三，开发版域名校验。真机调试前，必须在 mp 后台把 request 合法域名配上 HTTPS 接口地址，否则真机总报url not in domain list。如果只是局域网演示，可以在开发工具和体验版里勾选不校验合法域名，但正式发布必须配 HTTPS 域名。

6. 毕业设计交付：文档、演示、答辩

6.1 论文和文档怎么写才不流水账

毕设文档一般包括：开题报告、中期检查、设计说明书、答辩 PPT。我的经验是，设计说明书中不要只写“我用了什么”，而是要写“我为什么这样设计、相比方案 B 有何优势、遇到过什么问题”。比如技术选型对比表里可以写 PHP 和 Java 的对比、原生小程序和 uni-app 的对比；数据库设计要画 ER 图和表结构说明；核心模块要有数据流说明。

接口文档是加分项。我做了一个接口清单表格，包含接口 url、方法、参数、返回字段、说明。评委看到这份表之后，整个系统的业务逻辑一目了然，比写一大段文字更直观。文档的意义不只是交差，它也是你自己理清系统的过程，答辩准备全靠它。

6.2 演示环境一定要提前准备

演示环境永远要比开发环境更“干净直接”。我的建议是：演示前，在数据库里预置好 5 到 6 个带真实感的帖子、3 到 4 个学习资料、几条评论。真实感的意思是标题不要写 test、asdf，而要写类似“高等数学期末复习笔记”“考研英语真题词汇整理”这样有代入感的内容。同时检查一遍：公告里是否有一张正式公告；管理员后台的用户列表中，是否有几个昵称完整的用户。

演示顺序我建议这样走：

1. 小程序用户端：首页进入 → 查看资料列表 → 打开详情 → 发一条帖子 → 回到列表看到刚发的内容。
2. Vue 后台：登录 → 看到用户发的新帖 → 审核通过 → 回到小程序刷新页面，帖子可见。
3. 数据库兜底：某个功能现场卡住时，可以顺带打开数据库管理工具说明表结构，反而能展示你懂底层。

6.3 答辩高频问题与安全答法

评委问来问去就那么几类，提前准备答案会很稳：

• “为什么用 PHP 不用 Java？”答：项目规模聚焦中小型应用，PHP 部署便捷、开发效率高，且和 Vue 前后端分离架构匹配。
• “用户隐私和安全怎么保证？”答：使用微信官方 code2session 换取 openid，不保存明文密码；接口有 token 鉴权；SQL 统一用查询构造器预处理防止注入。
• “并发怎么办？”答：先说明毕设场景下并发量较小，再补充数据库连接池、Redis 缓存作为后续优化方向，点到为止，不要凭空吹牛。
• “如果用户上传了违规内容怎么处理？”答：管理后台审核制度，新内容默认 status=0 待审；小程序端只展示 status=1 的内容。

这些问题考察的不是你会不会造火箭，而是你有没有真正想清楚系统中每一行代码的意义。

6.4 关于“定制、讲解”这类交付的一点提醒

作为一个走过完整流程的人，我不反对找渠道做定制，但我强烈不建议你直接拿现成源码就交了。无论代码从哪里来，你必须至少能讲清楚四件事：用户登录的完整流程、数据表之间的关系、管理端审核数据的流转、某个接口的一次完整请求链路。只要能顺着这四个问题把项目讲明白，老师基本不会为难你。反过来，如果源码拿在手里却一页接口文档都说不出来，就算功能全对，答辩也会被问穿。所以拿到任何一份参考源码，第一件事不是改界面，而是把登录流程从头到尾走一遍。

7. 高频问题排查速查表

我把开发时遇到的高频问题按模块整理成一个速查表，方便你照着排查：

这张表是我整个开发周期里最真实的问题集合。大部分问题不是难在技术本身，而是出在环境配置和参数对不上这两个地方。你只要把这些场景逐个跑一遍，系统能稳定演示的概率就非常高。

说实话，这个项目做完之后，我最深的体会是：技术本身并不烧脑，真正烧脑的是把整个链路跑通的过程。从微信登录的 code 到 Vue 后台的 token，从 PHP 端的 SQL 到小程序端的wx.request，每一环都像一块积木，但只要有一块没对上，整个系统就转不动。这也是我为什么反复强调要先定接口格式再写页面。如果你正走在做毕设的路上，别急着堆功能，先把这个基础闭环打通，后面一切都会顺很多。整个过程拼出来的系统可能不完美，但只要答辩时你能讲清每个环节，这个项目的价值就已经达成了。