如果你正在做毕业设计或者打算把“微信小程序二手交易平台”当成课程设计题目这套东西对你来说应该不陌生一份毕业论文、一套答辩PPT、一份能跑的源代码再加一个演示视频。很多人拿到手的第一反应是“我直接改改就用”但真正到了答辩现场才发现光是搞懂代码逻辑和论文结构就能拦住一大半人。这篇内容我就以“拿到了一套二手小程序毕设项目”为起点把这个项目从里到外拆一遍。不管你是想搞懂代码去答辩还是想自己从零复现又或者只是需要一份能说服老师的论文逻辑下文都会把核心模块、表结构设计、接口思路、论文写作套路以及PPT演示的节奏给你捋清楚。1. 项目整体拆解微信小程序二手平台的“套路”在哪1.1 名称背后的真实需求先看标题里的关键词“微信小程序”限定了载体前端跑在微信生态里不需要下载独立App“二手平台”决定了商业模式核心是C2C个人对个人交易撮合附带商品发布、浏览、联系、交易闭环“开发毕业论文PPT附源代码演示视频”则说明它不只是一个能跑的原型还要有完整的技术文档支撑能让评审老师从“做了什么”问到“为什么这么做”时你都能答上来。这类项目能成为毕设常客原因很直接微信小程序开发门槛比原生App低前后端分离的架构又足够体现“工程能力”而且二手交易场景天然自带用户、商品、订单、收藏、留言这几个基本实体做出来的功能既不会太简单又不会复杂到做不完。从开题到答辩六到八周的时间是能稳稳拿下的。1.2 平台逻辑谁在用谁在卖谁在管一套完整的二手交易小程序用户角色至少得拆成三类买家、卖家、管理员。很多学生拿到代码后第一件事就是注册登录然后发现后台管理页面空空的其实是因为没理解这三层角色的边界。买家端的功能集中在“找东西”和“买东西”首页商品流、分类筛选、搜索、商品详情、收藏、留言咨询、确认交易。卖家端多一个“卖东西”的入口发布商品标题、描述、图片、定价、成色、交易方式、管理自己发布的商品上架/下架/编辑/标记已售出、查看收藏和留言。管理员端则是整个平台的风控中心用户管理、商品审核防止违禁品、评论管理、数据统计。这三个角色对应的是同一个小程序的不同页面权限底层靠的是用户表中userRole字段区分。你在论文里描述系统功能时也按这个逻辑写先从角色出发再展开功能点比单纯罗列“系统有登录、注册、发布、收藏”要有层次得多。1.3 技术选型为什么是这套组合二手平台小程序项目的标准技术栈一般是这样的端主流方案备选方案选择理由小程序前端微信原生小程序uni-app / Taro原生框架调试方便依赖少毕设答辩讲起来清晰后端Spring BootNode.js / DjangoSpring Boot自带starter整合MyBatis/JPA方便REST接口好讲数据库MySQL 5.7 / 8.0SQL Server / PostgreSQL免费、常见、教程多可视化工具Navicat/DBeaver方便出图后台管理独立Web管理端小程序内置管理页面管理端用Web页面更“像真实系统”也方便答辩演示部署本地运行 内网穿透云服务器演示视频需要能跑起来本地远程图片存储更稳定后端选Spring Boot算是最稳妥的因为教科书资源多社区问题解答多最重要的是写论文时“架构图”好画。前端用原生小程序是因为代码量可控而且微信开发者工具的调试体验比跨端框架更直接对不熟悉前端的同学来说踩坑少。如果你手里的代码是uni-app写的也没关系核心逻辑相通答辩时把“跨端支持”作为一个亮点讲反而更有优势。1.4 项目目录与交付物要提前确认拿到源码后不要急着运行先把交付物过一遍。一个合格的毕设包应该包含这几样东西源码目录前端小程序通常是一个miniprogram文件夹、后端Spring Boot工程通常是一个maven项目、数据库SQL脚本务必有否则环境搭不起来。数据库脚本带表结构和初始数据管理员账号、测试商品能在Navicat里一键导入。毕业论文文档一般有开题报告、中期检查、毕业论文终稿注意版本是否配套。答辩PPT15到20页为宜包含技术架构、功能模块图、核心表结构、接口设计、页面截图、创新点。演示视频建议时长5到8分钟横屏录制操作路径清晰有配音或者关键步骤字幕。先花半天确认这些东西全不全再动手配环境。很多人卡在“代码跑不起来”上最后发现是SQL脚本没导入或者端口被占用这种问题在答辩前爆发基本等于送人头。2. 数据库设计的门道表关系立得住论文就稳了一半2.1 核心表结构先看这五张表数据库表设计是整套系统的地基也是答辩老师必问的区域因为项目是你“亲手”做的数据库最看得出水平。二手平台项目的核心表一般包含表名功能关键字段user用户表用户注册登录与身份识别id、openid、nickname、avatar、userRole、phone、createTimegoods商品表商品发布与状态id、userId、title、description、price、originalPrice、images、categoryId、status、viewCount、createTimecategory分类表商品分类id、name、sort、iconfavorite收藏表买家收藏记录id、userId、goodsId、createTimemessage留言/咨询表买卖双方沟通id、userId、goodsId、content、replyTime、status围绕这五张表还能衍生出order订单表、banner轮播图表、feedback反馈表。具体要在论文里放多少张表取决于你手里的代码支持到什么程度。如果是自己重写的建议控制到8到12张既能体现设计的完整度又不会多到给自己答辩挖坑。2.2 字段设计里容易被问到的三个“心机”第一个是用户表里的openid。微信小程序登录的特点是拿wx.login返回的code去后端换openid这个openid是用户在微信生态内的唯一标识设计上应该加unique索引。openid在数据库里通常是varchar(64)类型如果你用的是Spring Boot后端一般通过HttpServletRequest获取请求头里的token再解析出userId。第二个是商品表里的status字段。二手交易和普通电商不一样商品状态不是只有“上架/下架”这么简单。常见的状态机设计是0表示待上架草稿1表示上架中2表示已下架3表示已卖出交易完成。答辩的时候能主动说出“状态机流转”这四个字老师会对你另眼相看因为这说明你考虑到了商品生命周期的闭环。第三个是images字段的处理。很多初学的代码会把图片存成Base64直接塞进字段里这样做的后果是数据库体积膨胀、加载巨慢。正规点的方案是存图片URL字符串多个图片用逗号分隔图片本身传到本地服务器或云存储。如果你是在本机演示最稳妥的是使用小程序上传接口将图片传到后端static目录反向代理出可访问的URL。2.3 表关系一对多与多对一的说辞表关系写清楚画ER图就顺了。user和goods是一对多一个用户能发布多件商品goods和favorite是一对多一个商品能被多个人收藏user和message也是一对多一个用户可以发多条留言。这里特别提醒一个细节删除策略。二手平台里的商品不能“物理删除”因为商品可能被收藏、被留言、被统计。正规做法是逻辑删除也就是加一个deleted字段0正常1删除查询时全局过滤。这个设计写进论文里非常加分答辩时能解释清楚“为什么不用DELETE语句直接删数据”这一条就足够体现你对数据安全的思考。2.4 让ER图变成论文的“视觉锤”论文里ER图的画法也讲一下不要画得太复杂一张图画6到8个实体就够了关系线用标注清楚1:N还是N:M。工具可以用ProcessOn、draw.io或者Navicat自带的反向工程生成。我个人建议用draw.io它导出的图片格式干净放到Word里颜色失真小。画完ER图再画一张系统架构图从上到下小程序端、后端服务、数据库/云存储这两张图放在论文的技术设计章节视觉效果和逻辑性直接拉满。你手里如果有现成的源码按照代码里的实体类反推ER图是最快的路。3. 代码结构拆解与核心功能实现手里有源码心里才有底3.1 小程序前端的页面结构与核心文件拿到源码之后先看文件夹结构。微信小程序的页面一般长这样miniprogram/ ├── pages/ │ ├── index/ # 首页商品瀑布流、分类导航、轮播图 │ ├── category/ # 分类页按类目筛选 │ ├── detail/ # 商品详情页 │ ├── publish/ # 发布商品页 │ ├── user/ # 个人中心我的收藏、我的发布、设置 │ └── message/ # 留言消息页 ├── components/ # 自定义组件商品卡片、搜索框、空状态 ├── utils/request.js # 网络请求封装 ├── utils/util.js # 时间格式化等工具 ├── app.js # 全局逻辑 └── app.json # 页面路由与全局配置你不需要背诵每个文件但要能说出“关键页面处理了什么业务”。比如首页的index.js里一般包含onLoad时调用商品列表接口、分类切换时重新请求、触底时加载下一页分页参数。商品发布这个核心流程前端做的事情是wx.chooseMedia选择图片 - 调用上传接口拿到图片URL - 填写表单 - 调发布接口把整个对象传后端。这里要重点理解一个坑wx.chooseMedia选的是本地临时文件路径绝对不能直接把临时路径塞进表单传给后端因为后端根本访问不了。必须先走上传接口让后端把图片存到服务器再返回一个可访问的URL。3.2 后端核心接口与路由设计后端接口设计得好不好直接决定答辩质量。二手平台的核心接口基本围绕“增删改查”展开但表述上要有业务感。以下是一套标准接口对照表模块接口功能方法用户/api/user/login微信登录换openidPOST用户/api/user/update更新昵称头像PUT商品/api/goods/list分页商品列表支持分类、搜索GET商品/api/goods/detail商品详情GET商品/api/goods/publish发布商品POST商品/api/goods/updateStatus修改商品状态PUT收藏/api/favorite/add收藏商品POST收藏/api/favorite/list我的收藏列表GET留言/api/message/add新增留言POST统计/api/admin/statistics后台数据统计GET每个接口在论文里都应该有一段简短的“接口设计说明”写清楚入参、出参、异常情况。不需要贴全部代码挑两三个核心接口展示关键代码即可比如登录接口因为涉及openid换取和token签发、商品发布接口因为涉及图片上传和状态初始化、分页查询接口因为涉及SQL的limit和条件拼接。3.3 Token鉴权的演进从Session到JWT小程序的登录机制是答辩老师必问的一个点你得能讲清楚。总体的流程是小程序调用wx.login获取临时code。小程序把code传给后端登录接口。后端拿着code到微信接口校验拿到openid。后端到user表里查openid是否注册过没有就自动注册。后端生成一个token学有余力用JWT普通项目用UUID存Redis或数据库也问题不大。后续请求都在请求头里带Authorization: token。后端用一个拦截器Interceptor校验tokentoken合法就放行并把userId塞进请求上下文。这里要说明白的是旧的Session方案在小程序里不是不能用但SessionId在小程序里管理起来比较别扭你需要自己存储和传递。JWT方案无状态、适合小程序场景、前端只存token字符串明显更顺手。使用JWT时要注意密钥不要硬编码在代码里放到配置文件application.yml里答辩时随口说一句“密钥外置”一下就显得专业。3.4 演示视频的录制要点顺序比炫技重要演示视频通常是一键交付物但录制的顺序有讲究不是上来就点商品发布。建议按照这样的顺序走展示系统登录微信授权一键登录演示的时候通常用模拟器或测试号可以先提前跳过登录。首页浏览展示轮播图、分类入口、下方商品卡片流、下拉加载。搜索与筛选搜索“自行车”或某个测试商品关键词演示搜索功能。商品详情与收藏点进商品详情展示图片轮播、价格、成色、点击收藏。发布商品重点选择图片、填信息、提交、回列表看到新商品。个人中心展示我发布的、我收藏的、我留言的。管理员后台用管理员账号登录展示商品审核、用户管理、数据统计。录制工具推荐OBS或者EV录屏横屏分辨率1920x1080帧率30。视频总长控制在6到8分钟如果手头项目功能少宁可放慢操作速度也不要去凑素材不要硬演示不存在的功能答辩时最怕“视频有代码没有”。4. 论文写作结构、篇幅与答辩的“连环问”4.1 论文目录怎么搭才规范毕业论文的目录结构大体就这几章不用追求花哨章节内容建议字数第一章 绪论背景与意义、国内外研究现状、研究内容与目标1500-2500第二章 相关技术微信小程序、Spring Boot、MySQL、前后端交互1000-2000第三章 系统分析可行性分析、需求分析功能/非功能、用例图1500-2500第四章 系统设计整体架构、功能模块、数据库设计、接口设计2500-4000第五章 系统实现各模块实现细节、界面展示、部分核心代码3000-5000第六章 系统测试测试环境、功能测试用例表、测试结果分析1000-2000结束语总结与展望、不足与改进500-1000不要小看“相关技术”这一章很多人以为是凑字数的但其实这里最体现你对项目的理解程度。写的时候不要凭空堆砌概念要把“技术”和“本项目怎么用的”结合起来。例如写微信小程序时要提到“本项目使用微信开发者工具进行调试使用rpx作为响应式单位通过wx.request与后端进行数据交互”写Spring Boot时要说明“使用Spring MVC处理HTTP请求通过MyBatis操作MySQL数据库”。4.2 需求分析里的用例图与用例描述用例图是软件工程老师最看重的图之一。你要画出三个角色各自的用例图用户注册登录、浏览商品、搜索、收藏、留言、卖家发布商品、管理商品、查看留言、管理员商品审核、用户管理、数据统计。如果代码里没有管理员页面用例图里就不要画硬画会被问倒。每个用例再写一份用例描述表包含用例名称、参与者、前置条件、基本流程、异常流程。挑一个核心用例展开就够了比如“发布商品”这个用例写清楚从进入发布页到点击提交的每一步操作以及系统在每一步的处理。这里有个细节很多模板论文的用例图和代码功能对不上老师一细看就露馅。拿到代码后翻一遍页面清单再回头改论文里的用例。合理“造假”可以理解但至少要对齐到90%。4.3 测试章节不是走过场系统测试在论文里大概占一到两章很多同学习惯性随便写几个“功能正常”这个部分其实是最容易拿分的。标准的写法是先列测试环境操作系统、数据库版本、JDK版本、微信开发者工具基础库版本再写功能测试用例表每一条用例包含编号、测试项、操作步骤、预期结果、实际结果。挑8到10条主要用例就够了比如用户注册登录、商品发布、商品搜索、收藏功能、留言功能、商品状态流转、后台审核、退出登录。除了功能测试可以加几条非功能测试的内容比如并发测试可以用JMeter简单压一下接口或者兼容性测试不同手机型号打开页面。哪怕只写“使用多台安卓和iOS设备进行兼容性验证”也比不写好。4.4 答辩现场必问的经典问题清单答辩前把下列问题过一遍基本上就有底了你项目里商品图片存在哪里路径规则是什么如果用户上传了违禁品类目如何处理审核机制token怎么生成过期时间设多久过期之后怎么办商品列表分页怎么做的为什么不用一次性查全量为什么选择MySQL数据量大之后怎么办留言和聊天有什么区别你的系统支持实时聊天吗用户发布商品后谁能看到审核机制是否完整你的数据库里userRole字段的值有哪些分别代表什么收藏功能设计成一张独立表为什么不把收藏数直接加到商品表里如果防范SQL注入和XSS预处理方式、参数绑定、过滤富文本每个问题都值得花半小时去深挖。比如第9题收藏功能单独建表的好处是可以记录“谁收藏了什么”一旦后续要做“我的收藏”页面数据直接按userId查就行不用去商品表里做模糊匹配如果只在商品表里加一个favCount你只能看到收藏总数看不到收藏详情后续功能演进受限。这就是“为什么建关系表而不冗余字段”的经典答案。5. 从拿到题目到上答辩台一份可执行的时间线5.1 四周冲刺计划参考如果你只剩下一个月左右的时间我给你的节奏建议是这样的阶段时间核心任务产出物第一阶段第1周环境准备、导入源码、跑通前后端能正常运行的系统第二阶段第2周深读代码、整理数据库表结构、梳理接口清单表设计文档、接口清单第三阶段第3周论文初稿重点写第3、4章、画图表、开始录视频论文初稿第四阶段第4周论文终稿、PPT制作、演示视频录制、答辩预演全部交付物第一周是最容易卡住的。常见问题包括MySQL版本不兼容导致连接失败、Redis没启动导致登录失败、小程序AppID用的是测试号但后端配置了正式AppSecret、图片上传目录未授权。如果你不是自己从零写的项目第一周不要急着动代码先把README或者环境搭建文档反复看透配好环境、跑通一遍再谈理解。5.2 从零开发还是改造现有项目这个问题很多人都纠结过。如果你代码水平一般时间又紧我建议选“改造现有项目”但不要只改个标题就上交。改造到什么程度算“安全”至少要改动以下内容项目名称、Logo、主色调。商品分类改成自己的例如从“数码/图书/生活”换成“教材/电器/出行/运动”。新增至少一个功能点。比如在商品详情页增加“举报”功能后台增加举报处理列表。自己写一小段接口完整走通答辩时这就是你的“亮点功能”。数据库表增加一到两个字段比如商品的“交易地点”、“商品成色”前端表单和详情页同步更新。只要做到这几点你就不算“纯搬运”答辩时也能讲得出自己的改动细节。直接从零写的话工作量主要集中在登录鉴权和文件上传这两块确实是新手的大坑但走通一遍之后你对整个前后端交互的理解会脱胎换骨。5.3 演示视频的加分细节录演示视频时有几个加分细节可以留意视频开头加一页工程目录截图让老师看到源码完整、结构清晰。发布商品时特意选一张有代表性的商品图用自己的手机拍一张书桌、宿舍里的小物件都可以别用网上下载的随机图。如果项目里有管理员后台登录后先展示一下“数据统计面板”再进商品管理页面走一个“下架违规商品”的流程镜头前会显得你业务逻辑完整。视频里涉及“登录”的步骤提前把登录态准备好避免演示时微信扫码耗时间。另外建议录视频前在微信开发者工具里把模拟器调到iPhone 14 Pro Max的尺寸再把“模拟操作”下的“不校验合法域名”选项勾上仅演示环境可勾页面会干净很多。视频里声音不要太干用OBS配音时提前把台词写个提词提纲不要临场边想边说。6. 常见报错与排坑实录这些坑我替你趟过了6.1 环境类报错排查现象原因解决前端请求一直404后端没启动或端口不一致确认后端运行在8080小程序本地接口填localhost或127.0.0.1登录时报appid不存在小程序AppID填写错误在project.config.json里替换成测试号或自己的AppID图片上传后返回403静态目录权限配置不对Spring Boot要配置静态资源映射或者把上传目录放到resources/static下数据库连接拒绝MySQL连接串、账号密码错误检查application.yml里的url、username、password接口报跨域前后端不同域名且后端未配置跨域后端加CORS配置或用微信开发者工具勾选“不校验合法域名”这里想单独展开“静态资源映射”这个问题因为它在本地跑特别容易踩。Spring Boot默认只处理classpath下的静态资源如果你把上传的图片存到D:/upload/下了前端访问http://localhost:8080/files/1.jpg会直接404。你需要加一个配置类把/files/**映射到D:/upload/目录。这是本地演示最关键的一环图片传不上或者传完看不到八成是这个配置没写。6.2 代码逻辑类报错与业务坑现象原因解决用户登录成功后刷新页面又掉线token没存到storage里或请求拦截器没带token前端wx.setStorageSync(token, token)请求封装里统一加header商品列表分页重复加载加载后没有把page1每次请求成功后要重置loading状态并且做触底判断搜索关键词为空时报错SQL语句拼接空条件动态SQL用MyBatis的if标签判断或者后端判空后给默认查询管理员进后台数据异常用户表里没有管理员种子数据跑SQL脚本初始化一个userRole为admin的账号发布商品后列表看不到状态默认是待审核(0)列表查的是已上架(1)后台先审核通过或前端发布时直接置为16.3 论文与答辩的“隐性坑”论文和答辩环节也有几个容易出问题的坑第一查重率问题。很多二手项目模板已经被传烂了如果你直接用模板的语言和结构知网查重很容易飘红。要用自己的话重写“背景与意义”“相关技术”等章节尤其注意把模板里的大段通用描述改成具体到本项目场景的表述。第二图表编号。论文里只要出现了图就必须有“图3-1 系统架构图”这样的编号和正文引用表格也一样必须有“表5-1 用户表结构”这样的编号。Word里用交叉引用可以自动维护编号省事又规整。第三PPT页数控制。答辩PPT一般每个学生8到10分钟PPT控制在15到20页。核心顺序是项目背景与意义 - 技术栈 - 系统功能结构一张图 - 数据库设计放ER图核心表 - 系统实现截图放4到6张关键页面 - 系统测试放测试用例表 - 总结与不足。不要每页都是文字能放截图就放截图。第四答辩时被问到“你的源码哪里来的”不要硬说“全部自己写的”。比较自然的回答是“本课题参考了目前开源社区的相关项目在理解其架构基础之上针对二手交易的具体业务场景重新设计了数据库表结构并新增了某某功能模块”。这话既诚实又给了自己发挥空间。7. 这套系统还能怎么升级从毕设到真实产品的三条路7.1 功能层升级从“能用”到“好用”当前项目的功能框架大多是交易撮合如果想让系统看起来更有竞争力可以考虑这几个升级点支付闭环需要接入微信支付。不过这里提醒一句小程序里要真正用微信支付需要企业认证的小程序账号个人开发者没有支付权限。演示时可以用模拟支付或虚拟支付状态来替代。论文里写了“微信支付”但代码里其实是模拟的这是很多同学被老师当场问穿的重灾区。消息通知可以做订阅消息。微信小程序有订阅消息能力买家留言后卖家可以收到模板消息提醒。这个功能适合写进“创新点”章节也能体现你对微信生态的了解。推荐系统可以做简单的热度排序。不需要引入复杂的推荐算法按浏览量、收藏量、最新发布时间做权重排序即可score viewCount * 0.3 favoriteCount * 0.5 (now - createTime)的衰减项。面试和答辩说出“我对商品做了简单的热度加权排序”就会显得有算法思维。社区化可以把“留言”扩展成评论加楼中楼增加互动感。真实产品里二手交易最大的问题其实是信任如果加上实名认证、芝麻信用授权或学生认证项目完整性和商业价值会明显不一样。7.2 架构层升级从单体到可扩展从毕设答辩的角度不需要上微服务但可以在论文“不足与展望”里写清楚“本系统目前采用单体架构如果后续用户量和商品数据增加可以考虑将文件存储模块和业务模块分离引入Redis缓存热点数据并对商品表进行分表。”这么写既表现了你的视野又规避了当前项目里的一些妥协老师听着也舒服。如果你真想动手改造推荐一个性价比很高的点给商品列表接口加Redis缓存。第一次查询时从数据库加载并写入缓存之后请求直接读缓存当商品状态变更时再删除或更新缓存。这个改动量不大但答辩时“我使用了缓存来降低数据库压力”这一句话就能把系统的技术层次提高一档。7.3 答辩时的多线包装同一个项目根据答辩老师的背景不同讲的侧重也要换一换。如果老师偏软件工程多讲需求分析、用例模型、模块划分和测试流程如果老师偏技术框架多讲Spring Boot的IOC、拦截器、JWT、MyBatis映射原理如果老师偏前端多讲小程序生命周期、组件通信、rpx适配、缓存策略。提前摸清答辩组老师的背景这个功课很多人忽略但极其有用。一个做算法方向的老师听你讲十分钟“微信如何登录”远不如听到你讲“热度排序如何设计”时兴趣大。同一个项目讲给不同人听重点完全不同提前“备课”绝对不亏。8. 写在最后几个我踩过最深的技术坑最后分享几个实操中容易忽略又特别影响体验的细节坑。第一个是关于后端接口返回格式的。很多项目接口返回的JSON结构不统一有的接口直接返回对象有的却返回{code:200, data:...}这会在前端封装请求时带来很大麻烦。二次开发时建议定一个统一返回体Result包含code、message、data三个字段接口里一律返回Result对象。统一之后小程序端request.js里只需做一次res.data.data的解析逻辑通顺很多。第二个坑是时间格式化。MySQL的datetime传到Java后端默认是Timestamp格式直接序列化成JSON会变成一串数字小程序端拿到后没法直观显示“02-12 14:30”。解决方案是给后端的时间字段加上JsonFormat注解指定时区或者干脆在SQL查询时用DATE_FORMAT格式化。这个坑特别典型答辩演示时页面上全是Unix时间戳非常难看。第三个坑是小程序端的请求超时时间。默认的wx.request超时时间是60秒但后端接口如果碰到慢SQL响应时间可能超过这个值。如果你做的是文件上传接口把超时时间单独调大到120秒否则大图上传一张就要失败一次。这个细节很多人根本不会注意但答辩现场上传图片失败真的会出大事。第四个坑是发布商品页面里“选择图片”的预览顺序。用wx.chooseMedia选图片返回值里临时文件的顺序和你点选的顺序不一定一致。如果你需要用户第一张图作为封面前端要做一次排序处理把首图固定并预览。真实项目里商品首图决定了点击率放在毕设里虽然不做点击率分析但页面展示顺序也别乱掉。说到底二手平台类小程序的毕业设计表面上是个编程项目实际考察的是你对“用户、商品、交易”三个核心概念的理解深度以及把复杂业务转成数据库表和接口的能力。把手里那套代码看懂、改顺、讲通你不仅能稳稳过答辩还能由此触类旁通以后面试时说“做过C2C交易类小程序”对方就不会小看你。