企业官网建设流程全解析

从当年我自己选“微信小程序二手平台”当毕业设计题目，到后来带过好几届学生做类似项目，我可以很负责任地讲：这个题目是典型的“好写、好讲、好过”的三好型选题。它前有用户登录、商品发布、图片上传、搜索筛选等小程序端功能，后有订单、收藏、留言、后台管理等服务端逻辑，业务链路完整但又不至于复杂到一个人搞不定。更关键的是，这种选题自带“社会价值”的外衣——闲置物品再利用、资源循环、绿色消费，随便往论文绪论里塞一段都是高分素材。而且，如果你能把源代码整理清楚，把演示视频录到流畅，再配一套逻辑在线的PPT，答辩老师几乎找不到发难的切入点。

这篇文章我打算从选题理由、功能设计、技术选型、核心代码、论文结构、PPT与视频筹备，再到真实开发中容易踩的坑，一条龙拆开讲。无论你是正在为毕设发愁的大四学生，还是想快速搭一套课程设计交差的开发者，或者带着学生做项目的老师，都能在里面找到可以直接用的东西。

1. 选题价值与整体设计思路拆解

1.1 为什么“微信小程序二手平台”是毕业设计的稳妥之选

大学里做软件类毕设，最怕的就是两个极端：一个极端是题目太简单，比如纯静态网页，答辩时老师觉得工作量不够；另一个极端是题目太复杂，比如带实时推荐、高并发秒杀，结果做到中期发现推不下去，最后拼拼凑凑交了份自己都看不下去的东西。二手平台恰好站在中间偏左的位置，它的核心难度分布非常合理：小程序端页面美化与交互体验、服务端的接口设计、数据库表关系的规划，这三件事各占一部分，每一部分都有话可说，但每一部分又不至于让人连续通宵一个月。

从另一个角度看，二手交易本身是一个“高频、低技术门槛、需求明确”的场景。你不需要给自己编造复杂的业务流程，因为现实中闲置物品交易非常常见，无论是学校里的二手书群，还是社区里的闲置交换，每个人都能理解“发布商品、浏览、联系卖家、线下交易”这样的逻辑。这意味着你在论文的需求分析章节不会缺素材，也可以在PPT答辩时用一个实际的场景引出问题，而不是干巴巴地背技术名词。

我从带毕设的角度来说，给学生的推荐理由还有一条：这套系统几乎所有模块都能单独拆出来做测试和展示。你可以只演示一个商品发布流程，就能覆盖前端表单、图片上传、后端接口、数据库写入四层内容。如果时间充裕，还能加个关键词搜索功能、分类筛选、留言提问，这些都是加分项，且实现成本可控。

1.2 项目整体方案怎么定才不跑偏

确定题目之后，就要第一时间明确系统边界。根据我的经验，很多学生做着做着就跑偏，原因在于一开始没有把“哪些必须做、哪些可以不做”想清楚。一个典型的二手交易小程序应当具备以下核心闭环：

• 普通用户：微信授权登录后，浏览全部闲置商品，按分类或关键字查找商品，查看商品详情，收藏或留言，也可以自己发布一件闲置物品（选图、填描述、填价格、选分类）。
• 系统核心业务：商品信息需要经过一个简单的状态管理，比如“出售中”和“已售出”，避免买家看完图片跑过去发现东西早就没了。
• 非核心但建议做：个人中心（我发布的商品、我的收藏、留言记录），后台管理员（可选，用于简单管理商品、处理举报）。

至于要不要做真实在线支付，我强烈建议不要碰。一方面，个人小程序开通微信支付有较多限制，另外毕设论文里在线支付会让你陷入第三方回调、退款、对账等大量细节工作，得不偿失。更合理的方案是，交易流程只做到“买家下单/联系卖家”这一步就停，实际钱货交付放在线下或者通过电话沟通解决。这在论文里圆得回来：本系统定位为信息撮合平台，不承担资金担保功能。答辩时这句话能帮你省掉一堆刁钻提问。

方案上还要尽早定前端和后端是否分离。我的习惯是：如果对代码不熟，就选用微信云开发，省掉服务器部署的心智负担；如果面试或升学希望展示传统后端能力，则选择“原生小程序 + Node.js Express + MySQL”的组合。前者开发效率高，后者技术含量看起来更高，且更贴近企业级开发模式。两种方案在论文里都很好写，关键是你自己别犹豫。

2. 系统功能架构与核心模块拆解

2.1 用户登录授权模块——所有社交类小程序的命门

这个模块技术难度不大，但它是整个项目的地基。二手平台需要记录“某件商品是谁发布的”，也需要知道“收藏记录和留言属于哪个用户”。因此每个进入系统的用户都需要一个唯一标识。小程序的机制是调用wx.login拿一个临时code，后台用这个 code 换用户的openid。每个微信号对应唯一的 openid，这就是业务系统里用户的身份证号。

具体流程是：前端触发登录时，通过微信接口获得一个临时 code，然后把这个 code 发给自己的服务端；服务端拿着 code 调用微信的接口，换取 openid 和 session_key。拿到 openid 后，在数据库用户表里先查一下这个 openid 有没有注册过，如果注册过就回刷一下用户信息，如果没注册过就自动插入一条新用户记录。前端本地用wx.setStorageSync保存一个后台生成的用户令牌（通常是 JWT 或者随机 uuid），之后所有涉及用户身份的请求都带上这个令牌。

这里有个容易被忽视的细节：新版本微信提审时，如果直接使用wx.getUserProfile弹窗获取头像昵称，必须是在用户主动点击触发，不能小程序一进来自动弹。但二手平台通常允许游客先浏览商品，等他要发布或者收藏时才触发登录按钮，这样就刚好避开了审核风险。开发时很多新手会在onLoad里就调wx.getUserProfile，结果被拒好几次，这一条要特别留意。

2.2 商品发布与信息展示模块——核心中的核心

商品模块承载了二手平台的最主要信息流。设计时注意几个要点：

首先是图片处理。小程序端wx.chooseMedia会让用户从相册选图，或者直接拍照。前端拿到图片后，有两种上传策略：一是把图片上传到自己的服务器，保存文件路径，数据库里存相对路径；二是上传到云文件的存储空间，数据库里存云文件 ID。我建议无论哪种，都不要直接把 base64 图片塞进数据库字段里，因为这样会让数据库表体积暴涨，查询速度也明显下降。另外，商品图片最好限制在 9 张，因为微信的chooseMedia一次最多返回 9 个媒体资源，而我们的业务场景 9 张也足够展示一个闲置物品的各个角度了。

然后是富文本描述的问题。二手商品的描述其实不需要像电商平台那样支持复杂的富文本，一个多行文本框就够了。如果你用了textarea组件，注意它的层级问题，在真机上如果与弹窗或其他原生组件重叠，会出现遮挡问题。我的解决方案是描述页面不要用自定义的view弹窗，要么用微信自带的上拉半屏，要么直接把发布作为一个独立页面。

发布页面的表单要校验以下几个字段：商品名称、描述、价格、分类、货架状态（是否需要上架）。价格建议只保留整数，或者最多两位小数，且前端要限制范围，避免有人填 9999999999 把列表页撑爆。分类字段用数字标识，后端维护一个分类表，比如 1 代表“图书教材”、2 代表“数码电子”、3 代表“生活用品”、4 代表“衣物鞋包”，这样前端picker面板可以直接绑定数字值。

商品列表页需要支持分页加载，常见的做法是页码page和每页条数pageSize。我后端接口统一返回{ list, total, page, pageSize }结构，前端在onReachBottom里判断如果当前列表长度小于 total，则继续拉下一页。分页不仅在列表页有用，在搜索页和“我发布的商品”列表里也都需要，干脆做成一个通用的请求封装，不要每个页面各写一遍。

2.3 留言、收藏与订单状态管理

二手平台要不要做“购物车”？原则上不需要。二手平台核心是单向一对一的交流，用户看到一件东西有兴趣，更应该采取“留言咨询”或“直接获取对方联系方式”的方式。我建议在系统里加入留言板和收藏夹两个轻量功能。

留言功能很简单，本质上就是针对某个商品 ID 插入一条记录，记录里包含发送用户的 openid、正文、发送时间。展示时按时间倒序输出，注意做好“留言者是商品发布者本人还是来访者”的标识，方便对话感。如果有闲工夫，还可以做成“商品咨询回复”，但不要头铁去做实时聊天，那会牵扯 webSocket 长连接、在线状态管理、多端支持，扩展到论文里会变成一个单独的大课题，而且很难在短时间内稳。

收藏功能就更简单，一张收藏表有用户 ID、商品 ID、收藏时间，唯一键设到用户 ID + 商品 ID 上防止重复收藏。前端在商品详情页展示收藏按钮状态，点击后调接口切换收藏/取消收藏。这里要提醒一点：收藏按钮的“小红心/小星星”状态要等接口返回成功后切换，不要为了视觉流畅直接把状态改了，万一接口失败，用户心里的信任度就崩了。

订单状态管理的设计因人而异。如果你决定只做信息撮合，那商品就只有“在售”“已售”“下架”。发布者在详情页可以点击“标记为已售”，后台修改商品状态。买家侧可以添加一个“我想要”的按钮，每次点击为该商品累计一次“我想要”数量，这既是需求表达，也能给发布者一个热度的参考。这个方法不涉及交易资金，数据模型也非常直观，不说教、不复杂，特别适合毕设。

2.4 管理后台的取舍——到底要不要做一个

我见过不少学生纠结管理后台。实际上，本科软件工程类毕业设计，管理后台是加分项而非必须项。做的话，你至少要完成管理员登录、商品管理（上下架）、用户管理、留言管理等基础功能。不做也需要在设计图上标注“本系统暂不包含管理后台，后续可扩展”。因为这是一个二手信息撮合平台，天然的 C 端属性强于 B 端，管理后台的设计权重可以低一些。

如果决定做，最简单的方案是再写一个网页端后台，用 HTML + 一些前端框架调用同样的后端接口，创建一套 admin 数据表。或者也可以在小程序端通过一个隐藏的“管理员入口”来实现，但那样交互起来比较别扭。我给学生的建议通常是：把后端接口提前留好，管理员接口设计成独立路由前缀/admin/xxx，并做好权限校验，小程序端不做后台管理界面，论文里写明“后台管理功能作为系统扩展方向”，既省时间又能在答辩时给老师留一个思考空间。

3. 技术选型深度解析：前端、后端、数据库怎么搭

3.1 小程序前端：原生还是 uniapp

原生微信小程序使用 WXML、WXSS、JS/TS，官方工具支持好，调试方便，资料多，社区问题几乎都找得到答案。对于只完成一套微信小程序端需求的课程设计/毕业设计，我强烈建议原生小程序，不要为了 show 技术栈去引入 uniapp。原因很简单：uniapp 的价值在于一套代码可以发快手、支付宝、百度等多端，而你的论文场景里只有微信小程序，那实际上多余的兼容层会给你带来更大的踩坑概率。

原生小程序结构上，每个页面分为.wxml、.wxss、.js、.json四个文件，页面页面之间跳转用wx.navigateTo，组件封装可以后续再学，甚至不封装也能把项目写完。我个人习惯用微信开发者工具自带的“小程序框架”模板初始化项目，然后把公共请求封装到utils/request.js里。这个request函数统一处理baseURL、请求头里的 token、成功状态码判断和错误提示，一个项目里所有页面都不要直接调用wx.request，这能给后续开发省很多重复劳动。

要注意的是，小程序端的 BOM 对象是不存在的，也就是说你不能用localStorage、window等浏览器 API，统一改用wx.setStorageSync和wx.getStorageSync。登录态也好、用户信息缓存也好，都用这两个方法。

3.2 后端：Java 还是 Node.js 还是云开发

这里没有绝对答案，因人而异。我将三种常见方案拆开分析：

第一种：微信小程序云开发。它是微信提供的一体化服务，集成了云函数、云数据库和云存储。云函数跑在 Node.js 环境，数据库是一个 JSON 文档型数据库，前端可以直接调用wx.cloud.database()进行增删改查，也可以用云函数批量处理。云开发最大的优势是不需要自己买服务器、不需要备案、不需要处理复杂的网络环境，非常适合没有运维基础的同学。缺点是技术栈偏向专项场景，论文里能写的“架构设计”略少，需要多写业务流程和实现细节来撑篇幅。

第二种：Node.js + Express + MySQL。这是我认为最“稳的一匹”的方案。Express 轻量且生态成熟，MySQL 是面试常提、论文常写的经典数据库，前后端分离的结构也更清晰。部署时可以买一台便宜的云服务器，用 Nginx 做反向代理，把前端静态资源与后端接口放在同一台机器上。如果你用过 Spring Boot 或 Django，原理相通但 Node.js 上手成本更低一些，尤其是当你已经会 JavaScript 写前端逻辑的时候，语言一致性能让你更快地进入状态。

第三种：Java + Spring Boot。如果你的毕设大纲要求更“正统”，或者你希望简历上写 Java 技术栈，那用它也没有问题。但 Spring Boot 项目起步时依赖比较多，Maven 下载依赖、配置 application.yml、写实体类、写 service 层，需要一定心智基础。我建议只有当你有至少一学期的 Java Web 开发经验时，才选择这条路。

我个人推荐学生做毕设时选方案二（Node.js + Express + MySQL），因为它在“代码量适中”和“技术深度”之间取得了很好的平衡。下面所有示例代码我都按这个技术栈来写。

3.3 数据库表结构设计与数据字典

数据库设计直接决定后期代码好不好写。二手平台的核心表我建议七张：

1. user用户表，字段至少要有：id、openid、nickname、avatar_url、phone（可选）、create_time。
2. goods商品表，字段：id、user_id（发布者）、title、description、price（整数或 DECIMAL）、category_id、images（用 JSON 数组存多个图片 URL/ID）、status（0 在售、1 已售、2 下架）、view_count、want_count、create_time、update_time。
3. goods_category分类表，字段：id、name、sort_order、icon（可选）。
4. favorite收藏表，字段：id、user_id、goods_id、create_time。
5. message留言表，字段：id、user_id（留言者）、goods_id、content、create_time。
6. order_info订单/交易记录表（可选），字段：id、goods_id、buyer_id、seller_id、contact_info、status、create_time。
7. admin管理员表（如果做的话），字段：id、username、password_md5 或 bcrypt、create_time。

建表时尽量遵循几个原则：外键关系要清楚，但物理外键可以不加，依赖代码层面保持一致性；所有时间字段用datetime或timestamp；价格字段用分（整数）存储，避免浮点误差——比如 49.9 元在数据库里存 4990，前端再除以 100 渲染。这个习惯很小，但论文里写数据字典时就是亮点。

商品表里的images字段，如果是对象存储的 URL 数组，比如["cloud://xxx.png", "cloud://yyy.png"]，在普通关系型数据库里可以直接用TEXT类型存 JSON 字符串。查询列表页时不需要解析图片数组中的所有项，只取第一张作为封面。这个操作在 SQL 层做不了，Java/Node 层把 JSON 解析出来读第一项即可，不算压力。

4. 核心代码实现与关键接口设计

4.1 登录接口与登录态维护——用代码说话

服务端我用 Express 来搭，先定义用户表模型，再写一个登录路由。假设前文所说，前端wx.login拿到 code 后发给/login。伪造一个简化的实现：

const express = require('express'); const axios = require('axios'); const mysql = require('mysql2/promise'); const jwt = require('jsonwebtoken'); const router = express.Router(); const pool = mysql.createPool({ host: 'localhost', user: 'root', password: 'yourpassword', database: 'second_hand' }); router.post('/login', async (req, res) => { const { code } = req.body; const appid = '你的appid'; const secret = '你的appsecret'; const wxApi = `https://api.weixin.qq.com/sns/jscode2session?appid=${appid}&secret=${secret}&js_code=${code}&grant_type=authorization_code`; try { const { data } = await axios.get(wxApi); if (!data.openid) { // 拿不到 openid 说明 code 失效或网络异常 return res.json({ code: 400, msg: '微信登录失败' }); } const openid = data.openid; // 根据 openid 查用户 const [rows] = await pool.query('SELECT * FROM user WHERE openid = ?', [openid]); let user; if (rows.length === 0) { // 新用户注册 const [result] = await pool.query('INSERT INTO user (openid, create_time) VALUES (?, NOW())', [openid]); user = { id: result.insertId, openid }; } else { user = rows[0]; } // 签发一个 7 天有效的 token const token = jwt.sign({ id: user.id, openid }, 'secret_for_student_demo', { expiresIn: '7d' }); res.json({ code: 0, data: { token, user } }); } catch (e) { console.error(e); res.json({ code: 500, msg: '服务器异常' }); } }); module.exports = router;

这段代码里，最重要的注释就是“jscode2session”的调用。这个接口内部到底做了什么？其实它就是微信把自己的服务器和你的服务器之间做了一次身份转换，通过 code 换取一个证明你是谁的 openid。之后就不要再去调它了，所有请求都靠 token 证明身份。这个小细节建议写进论文里的“关键技术分析”章节，显得你不是只会抄代码的人。

4.2 商品发布接口与图片上传策略

图片上传有两种路径。如果用云开发，直接在小程序端调用wx.cloud.uploadFile就能把图片传到云存储，然后把返回的 fileID 存在数据库里。如果用自建服务器，需要先从小程序端wx.uploadFile把图片文件传给自己的服务器接口，服务器用multer或formidable接收文件，存到本地静态目录或者云对象存储。

下面以 Node.js +multer为例：

const multer = require('multer'); const upload = multer({ storage: multer.diskStorage({ destination: function (req, file, cb) { cb(null, 'public/uploads/'); // 确保目录存在 }, filename: function (req, file, cb) { const ext = file.originalname.split('.').pop(); cb(null, Date.now() + '-' + Math.round(Math.random() * 1E9) + '.' + ext); } }), limits: { fileSize: 2 * 1024 * 1024 } // 限制2M }); router.post('/goods', upload.array('images', 9), async (req, res) => { const { title, description, price, categoryId } = req.body; const user = req.authUser; // 假设做了中间件鉴权 if (!title || !price) return res.json({ code: 400, msg: '标题和价格必填' }); const imageUrls = req.files.map(f => '/uploads/' + f.filename); const [result] = await pool.query( 'INSERT INTO goods (user_id, title, description, price, category_id, images, status, create_time) VALUES (?,?,?,?,?,?,?,NOW())', [user.id, title, description || '', Math.round(parseFloat(price) * 100), categoryId, JSON.stringify(imageUrls), 0] ); res.json({ code: 0, msg: '发布成功', data: { goodsId: result.insertId } }); });

上传后，前端展示图片时要注意拼接好服务端的域名前缀，例如https://yourdomain.com+/uploads/xxx.png。如果部署在本地开发环境，域名往往是一个局域网 IP，真机调试时还需要打开“不校验合法域名”的开关。但记住，这个开关只在开发模式可用，到了给答辩老师现场演示时，一旦涉及网络请求，需要提前让老师连接同一个局域网，或者使用有公网 IP 的服务器。

4.3 商品列表与搜索接口：分页 + 条件拼接

列表接口是前端展示数据的引擎。我推荐的接口路径是GET /goods?page=1&pageSize=10&keyword=书&categoryId=1。后端实现时，关键是把这些可选的 query 参数拼成一个动态 SQL。

router.get('/goods', async (req, res) => { const { page = 1, pageSize = 10, keyword = '', categoryId = '' } = req.query; const currentPage = Math.max(parseInt(page), 1); const size = Math.min(parseInt(pageSize) || 10, 20); let where = ' WHERE status = 0 '; // 默认只查在售商品 const params = []; if (keyword) { where += ' AND (title LIKE ? OR description LIKE ?) '; const like = '%' + keyword + '%'; params.push(like, like); } if (categoryId) { where += ' AND category_id = ? '; params.push(categoryId); } const countSql = 'SELECT COUNT(*) AS total FROM goods ' + where; const [countRows] = await pool.query(countSql, params); const total = countRows[0].total; const limit = ' LIMIT ?, ?'; params.push((currentPage - 1) * size, size); const sql = 'SELECT id, title, price, images, status, view_count, create_time FROM goods ' + where + ' ORDER BY create_time DESC ' + limit; const [list] = await pool.query(sql, params); res.json({ code: 0, data: { list: list.map(goods => { const images = JSON.parse(goods.images || '[]'); return { ...goods, cover: images[0] || '' }; }), total, page: currentPage, pageSize: size } }); });

商品列表返回的字段中不要包含 description 全文，因为列表页只需要标题、价格、封面图、时间，描述详情在点进详情页再单独请求。这样能显著减少接口响应体积。列表页缓存也是一个可聊的话题，但毕设阶段不需要引入 Redis，把分页和条件搜索做好已经足够优秀。

4.4 留言与收藏的接口实现思路

收藏接口很简单，我写一个组合接口的示例：

router.post('/favorite/toggle', async (req, res) => { const { goodsId } = req.body; const user = req.authUser; const [existing] = await pool.query('SELECT id FROM favorite WHERE user_id = ? AND goods_id = ?', [user.id, goodsId]); if (existing.length > 0) { await pool.query('DELETE FROM favorite WHERE id = ?', [existing[0].id]); res.json({ code: 0, msg: '取消收藏成功', isFavorite: false }); } else { await pool.query('INSERT INTO favorite (user_id, goods_id, create_time) VALUES (?,?,NOW())', [user.id, goodsId]); res.json({ code: 0, msg: '收藏成功', isFavorite: true }); } });

留言接口就更直接了，插入一条留言并返回新留言的 ID。这里要注意一个安全问题：留言内容不能直接渲染进<rich-text>或wxParse里，因为有可能包含 HTML 标签，会出现样式混乱甚至 XSS 风险。最简单的方式是把留言内容当纯文本处理，提交时过滤掉<和>等字符，或者显示时用text组件而不是rich-text。

5. 毕业论文写作框架与答辩PPT构思

5.1 论文从摘要到结论的每一章该怎么写

论文写作是很多人的痛点，实际上它有非常成熟的套路可以被利用。一个软件类毕业论文的标准大纲主要包括以下六个部分：

1. 绪论：项目背景、意义、国内外现状、本文工作。绪论重而意境化，多聊聊“当前二手交易平台存在的痛点——比如线上交易信任问题、线下信息不对称、沟通效率低”，然后引出你的系统。

2. 需求分析：功能性需求、非功能性需求、可行性分析。功能性需求用用例图描述最合适，非功能性需求写性能、安全、易用性。这里可以对你的模块拆解做一次系统级别描述。

3. 系统设计：总体架构图、功能模块图、数据库设计（E-R图、数据字典）、接口设计。这里内容是“硬知识”集中地，也是答辩老师最关注的部分，一定要写清楚表之间关系。

4. 系统实现：按模块逐个说明实现流程，配合核心代码片段、页面截图、关键方法解释。不需要贴所有代码，每段代码控制在 10~30 行以内，必须配文字说明这代码解决了什么问题。

5. 系统测试：列出测试环境、测试用例、测试结果，适当加入边界用例和并发用户模拟测试记录。三到五个功能点的测试足以，关键是测试结果要与预期一致。

6. 总结与展望：总结项目完成的功能、不足之处以及扩展计划。缺点一定要写“交易安全性有待提升、缺少信用体系、商家审核机制需要强化”这类型的内容，然后展望对应加入芝麻信用、人工审核、在线支付安全模块等方向。

论文写作时有一个小原则：不写空话，每段都尽量对应你已经实现的真实功能。哪怕是一个很简单的“热门商品推荐”，你也要在需求分析中写明它的规则（按收藏数、浏览量排序），在设计中讲述实现流程，在测试中加入验证用例。宁可少写几个功能，也要把已有的功能讲圆。

5.2 答辩PPT怎么编排才能让老师顺着你的思路走

PPT是答辩现场的第一印象。我发现很多人喜欢把源代码截图贴在 PPT 上，这是最糟糕的做法——老师既看不清，也不想看。好的 PPT 应该以功能流程图 + 界面截图 + 核心结论为主导。

我的建议是控制在 10~12 页。第一页放题目和姓名，第二页放一句话项目背景并附上小程序体验码的截图，第三页放系统功能结构图，第四页到第六页分别放“发布、浏览、收藏/留言”的核心页面截图，第七页放数据库 E-R 图，第八页放一段最有难度的代码逻辑（比如登录鉴权、分页搜索），第九页放测试结果表，第十页放总结与展望。

每一页上文字不要超过 5 行，且尽量用“一句短句 + 一个图”的形式。答辩现场你最少有 5 到 10 分钟的时间，讲的时候严格按照“背景-功能-设计-实现-测试”的顺序走，中间不要突然跳到一个页面，否则老师的思路容易断，一旦断开就容易被追问奇怪的问题。

5.3 演示视频录制要点：提前设计“剧本”，别边录边想

“演示视频”是现在很多学校答辩都会要求的附加材料，同时也是容易被忽视的翻车点。我的经验是，录视频之前先写一个可执行的演示脚本。

脚本结构大致是：一、打开小程序登录；二、浏览商品列表；三、搜索或筛选；四、查看商品详情并收藏；五、发布一件新商品（提前准备 3 到 5 张测试图片）；六、在“我发布的”里看到刚才的商品；七、模拟管理员端或者其他拓展功能。每个步骤间隔 3 秒以上，点击不要太快，给观看者反应时间。

录屏工具可以用系统自带的录屏功能，手机端打开开发者工具的“真机调试”来录，或者直接在电脑上录微信开发者工具的模拟器，这样更清晰。注意录屏前把模拟器窗口调大，字体调大，避免演示视频里字体模糊。音轨可以单独录制讲解，但如果你口语表达不自信，配字幕即可，不需要硬撑全程解说。

6. 开发与答辩过程中的高频坑点排查实录

6.1 “为什么我的真机请求总是失败”——本地联调三座大山

真机调试时，最经典的问题是request:fail。问题几乎一定出在域名或局域网地址上。如果你用的是局域网 IP，比如http://192.168.1.102:3000/api，必须保证手机和电脑在同一 WiFi 下，并且电脑防火墙允许 Node 服务对外访问。如果电脑开的是防火墙，请手动在防火墙放行 3000 端口。若还是失败，打开手机浏览器的开发者选项，查看网络错误的具体原因，分别确认“域名错误”“连接超时”“拒绝连接”。

还有一个简单可靠的方法：使用内网穿透工具把本地localhost:3000映射成一个临时公网域名，然后把小程序请求地址指向这个域名。这样无需调试域名校验，在真机上也能快速跑通。不过正式部署时仍然要使用备案域名和免费的 HTTPS 证书。

6.2 微信登录接口报 40029 或 40163 是什么原因

40029 表示 code 无效，最常见的成因是：同一个code被用了两次，或者前端拿到的 code 已经过期。40163 则是 code 已使用过，再带着这个 code 去调接口就会报错。所以在写登录逻辑时，务必确保每个 code 只在一次登录请求里使用，不能因为用户快速点击登录按钮而连续发起多次请求。前端应加一个请求锁，例如在页面data里定义isLogining，防止重复提交。

6.3 数据库时间字段的陷阱——时区与 NOW() 的差距

如果你在本地调试没问题，但当部署到云端服务器后，发现商品发布的时间比实际时间早了 8 小时，那基本就是数据库时区问题。MySQL 的NOW()返回的是数据库系统时间，而不是你电脑上的时间。解决方法是：统一在服务端代码里使用固定的时间标准（比如 UTC 时间字符串），或在建连时设置timezone参数，同步为+08:00。答辩演示时出现这种问题会很尴尬，早发现早解决。

6.4 演示时不能只准备一个“完美流程”

我见过太多人临场演示时出状况：模拟器打不开、数据库没启动、依赖包被清理。所以答辩或者录视频之前，一定要预演至少三遍完整流程。准备一个“复活预案”：比如商品发布后列表不更新，就退刷新；如果首页加载慢，就先讲 PPT 再做演示。另外，第三方服务（例如微信接口）偶尔会抽风，如果登录接口超时，可以提前在本地做一套 mock 登录接口作为逃生通道。

6.5 版权与引用规范：写论文时的一个加分小细节

论文里引用了别人的图片、代码库或者教程，一定要在参考文献或致谢部分规范标注。这不是形式主义，查重时如果检测到和网络资源高度雷同，会比较麻烦。我建议哪怕是从网上找的开源模板，也要认真阅读后自己重写部分代码，并把重写的思路写到论文里。这样可以有效降低查重率，又显得整个设计是有自己思考的。

写在最后的一点经验

做了这么多年开发和指导，我最大的感受是：毕业设计不是“造了一枚火箭”，而是“证明你具备把一个想法变成系统、并把它讲明白的能力”。微信小程序二手平台就是一个极好的训练场，你能在一个小项目里完整走完产品需求、前后端协作、数据库设计、接口调试、打包发布、文档编写、演讲展示的整条链路。这个过程里踩过的每一个坑，都会变成你在求职或读研时称手的经验。

最后分享一个小心得：完成源代码之后，一定记得把项目从进程中退出，删掉本地临时缓存，再重新跑一遍完整流程。因为很多答辩项目之所以翻车，不是逻辑设计有问题，而是开发过程中留下的各种临时状态没有清理干净。一个好的项目交付，不只是让你自己跑得通，而是让一个完全没有接触过你代码的人也能跟着 README 把服务跑起来。做到了这一点，无论答辩过不过，你都已经比许多同龄人更接近真实的软件开发工作方式了。