毕设选题有多折磨人，经历过的人都懂。太简单担心答辩不够讲，太复杂又怕三个月做不完。我最后定的题目是《基于微信小程序的同城钓鱼社交APP设计与实现》，从开题到答辩一路走完，最大的感受就是这个题目的“容量”刚刚好：微信小程序覆盖了前端页面、接口交互、本地存储、地图定位这些基础能力；钓鱼社交又天然带LBS、内容社区、活动、消息通知这些业务模块，任何一个方向都能往深了写，但又不会失控到需要微服务才能支撑的地步。
这篇内容想做的事情很直接：把做这个项目过程中沉淀下来的选题判断、技术选型、模块拆分、坑点排雷、远程调试、服务器部署、论文答辩的整套经验讲清楚。不管你只是需要一篇能顺利通过的毕设，还是真的想把一个同城社交类小程序做成能上线的作品，里面的内容应该都能帮到你。
1. 这个题目的底气：为什么“同城钓鱼社交”能撑起一篇毕设
1.1 钓鱼场景的真实痛点和用户需求
先说业务层。钓鱼这件事，看起来是个人休闲活动，但实际上非常依赖“信息”和“圈子”。一个新手最需要解决的是“去哪钓、怎么去、那里出鱼怎么样”；一个老手更在意“有没有合适的钓友一起拼车、最近哪个钓点鱼情好、有没有人可以交流饵料配方和钓法”。
但市面上的钓鱼类产品，要么是纯内容类App，以视频教学为主，离“同城”和“约钓”很远；要么是论坛时代的产品，移动端体验很差。真正贴合本地钓鱼人群的“同城约钓+钓点地图+鱼获记录”工具，一直缺位。我开题的时候调研过，微信小程序里搜“钓鱼”，大部分是商城、视频号、资讯类小程序，真正做同城社交和钓点管理的很少。这个空白就是选题的价值点。
对毕设来说，这意味着你不需要像大厂产品经理那样编造需求，你只需要把一个真实场景里“找钓点、约钓友、晒鱼获、聊钓技”的闭环做出来，业务逻辑就天然完整。答辩老师问到“你的系统解决了什么问题”，你可以非常自然地回答，而不是硬凹一个不痛不痒的功能。
1.2 技术覆盖面：从LBS到内容社交一次凑齐
一个毕设题目，最怕的不是难，而是“一眼看到头”。如果只是做一个登录加增删改查，工作量是够了，但答辩时很难展开，论文也很难写到三万字。同城钓鱼社交APP不一样，它同时牵扯这几条技术线：
- 移动端展示与交互：小程序页面、组件、路由、状态管理；
- 位置服务：wx.getLocation定位、地图选点、逆地址解析、钓点经纬度存储与附近查询；
- 内容社区：图文发布、信息流分页、评论、点赞、关注关系；
- 活动业务：约钓活动的创建、报名、人数上限控制、状态流转；
- 消息系统：站内信、订阅消息通知；
- 后端接口设计：RESTful API、统一鉴权、参数校验、异常处理；
- 数据存储：MySQL表设计、索引、分页查询；
- 部署运维：服务器、域名、HTTPS、小程序后台配置。
这几块每一条单拿出来都能在论文里写一个章节，而且它们之间有真实的业务关联，不是生硬拼凑。对计算机专业的学生来说，这正好覆盖了《软件工程》《数据库原理》《移动应用开发》等课程的核心知识点，导师一看就知道你的工作量是实打实的。
1.3 功能范围怎么控制：三档需求清单
做毕设最怕“什么都想做”，所以我一开始就把需求拆成了三档：
- 第一档（必须做）：微信登录、个人资料、钓点发布与管理、钓点地图展示、钓点详情、社区动态发布、动态列表、评论、点赞、个人中心、我的发布。
- 第二档（尽量做）：约钓活动、活动报名、活动列表与详情、鱼获记录、消息通知、关注与粉丝。
- 第三档（有时间再做）：管理后台、数据统计、支付模拟、钓友聊天、排行榜。
实际上我最终把第一档和第二档都做了，第三档只做了管理后台的雏形和支付模拟流程。这样既保证了核心逻辑完整，又没有把自己拖进“为了做完而做完”的深渊。这个三档划分的思路，后来也直接变成了开题报告中“系统功能结构图”的原始素材。
2. 技术栈定稿：不炫技、好演示、能过审
2.1 前端我选了原生微信小程序，而不是uni-app
很多同学一上来就问：用uniapp打包成微信小程序行不行？它确实可行，而且社区里很多成品项目就是用它写的。但我最终选了原生微信小程序，理由很现实：
- 毕设演示场景下，原生小程序的代码结构更直观，导师翻代码的时候能看懂WXML、WXSS、JS、JSON各自负责什么，讲解成本低；
- 微信官方文档和社区解决方案最多，遇到问题查起来最快；
- 原生小程序无需构建工具链，HBuilderX或者微信开发者工具打开就能跑，远程调试时不用跟各种兼容性问题纠缠。
uniapp的好处是“一套代码多端发布”，但毕设场景通常只需要小程序端，多端能力对你不是刚需，反而会增加一层不确定性。如果你已经会用uni-app，用也行，但论文里要解释清楚为什么引入这一层框架，别让导师觉得你在绕远路。
表格上给个对比参考：
| 对比项 | 原生微信小程序 | uni-app |
|---|---|---|
| 上手门槛 | 低，官方模板即可运行 | 中，需要理解Vue语法和编译机制 |
| 调试便利性 | 微信开发者工具全流程支持 | 需通过HBuilderX或CLI，偶发编译差异 |
| 代码可读性 | WXML结构清晰 | Vue模板，有一定抽象 |
| 多端复用 | 无 | 强，可导出H5/App |
| 毕设适合度 | 高 | 中 |
2.2 后端用Spring Boot + MyBatis-Plus，单机部署就够
后端我选了Spring Boot 2.7 + MyBatis-Plus 3.5。为什么不用SSH或SSM手写一堆XML？因为毕设的核心是展示你对业务和系统设计的理解，而不是展示你能写多少样板代码。MyBatis-Plus可以少写大量CRUD，把精力留给核心业务逻辑，这对三个月完成一个完整项目非常关键。
Redis我用了，但只用在两个地方：一是登录token的存储，二是热门钓点列表的缓存。没有做复杂的分布式锁、消息队列、ES搜索这些。原因很简单：同城钓鱼APP在毕设规模下根本没有那么多并发，你用Redis做缓存可以讲“性能优化”，但硬上一套MQ或者微服务，只会让系统变得脆弱，答辩演示时一个服务起不来就是事故。
部署方案是单台云服务器：2核4G的配置，装MySQL 8.0 + Nginx + Spring Boot Jar包，完全够用。域名申请一个，备案后绑定到Nginx，把小程序的合法域名配置好，整个系统就跑通了。
2.3 数据库表设计：九张表撑起整个业务
数据库是整个系统最容易体现功底的环节。我最终设计了两组共九张核心表：
| 分组 | 表名 | 关键字段 | 作用 |
|---|---|---|---|
| 用户相关 | user | openid, nickname, avatar, phone, city, status | 保存用户基础信息和微信openid |
| 用户相关 | user_follow | user_id, follow_user_id | 关注关系 |
| 钓点相关 | fishing_spot | user_id, name, description, longitude, latitude, address, city, type, images, status | 钓点信息，type区分野钓/黑坑/路亚等 |
| 钓点相关 | fish_record | user_id, spot_id, fish_type, weight, weather, bait, images, create_time | 鱼获记录，关联钓点 |
| 社区相关 | post | user_id, content, images, location, like_count, comment_count, status | 动态 |
| 社区相关 | comment | post_id, user_id, content, reply_user_id | 评论 |
| 社区相关 | like_record | user_id, target_type, target_id | 点赞，target_type区分动态/钓点 |
| 活动相关 | activity | organizer_id, spot_id, title, description, start_time, end_time, max_num, current_num, status | 约钓活动 |
| 活动相关 | activity_signup | activity_id, user_id, status | 活动报名记录 |
这里有几个设计细节值得说一下：
- 点赞用
like_record分开做，不要在每个帖子里堆一个likes字段，虽然那样写起来更快，但论文里讲到“数据一致性”和“反范式设计”时你就没了素材。 activity_status我用的数值字典：0待开始、1报名中、2已报满、3已结束、4已取消。状态流转放在Service层，不在前端改。- 经纬度字段用的
decimal(10,7)，精度够定位用。附近钓点的查询，因为数据量不大，先全量查出来在Java里按距离排序，没有硬上MySQL空间索引。这个取舍在论文里要写清楚，答辩老师反而会认可你“知道什么时候不需要复杂方案”。
2.4 统一返回体和接口风格
接口设计看似简单，但统一返回体真的能省很多事。我定义了一个Result<T>结构：
{ "code": 200, "message": "success", "data": {} }约定code=200表示成功，401表示未登录，500表示服务端异常。前端封装了一个request函数，所有HTTP请求都会先判断code，如果遇到401就自动跳登录页。这样避免了在每个页面里重复写错误处理逻辑，也让前后端联调时的沟通成本下降很多。
接口风格用的RESTful，核心接口大概二十个左右，比如POST /api/user/login、GET /api/spot/list、POST /api/spot、GET /api/post/list?page=1&size=10、POST /api/activity/{id}/signup。写接口文档时直接生成Swagger，论文里贴几张请求响应截图，就很有说服力。
3. 三大核心模块的实现拆解
3.1 登录与用户信息采集：跟上微信最新的合规要求
登录模块是整个项目的地基。流程是这样的：小程序端通过wx.login拿到临时code，发送给后端；后端拿code去微信接口服务换openid和session_key；拿到openid后查数据库，没查到就注册新用户；最后用用户id生成一个token返回小程序端。
有一点必须提醒现在做毕设的同学：微信已经调整了用户头像和昵称的授权策略。以前wx.getUserProfile可以弹窗拿到头像昵称，现在这个接口返回的已经是匿名数据了。正确做法是在个人资料页面让用户主动填写，头像用button open-type="chooseAvatar"，昵称用input type="nickname"，通过一番引导让用户自己确认。这不是bug，是合规要求，论文里最好也提一句“遵循微信官方用户个人信息保护指引”，显得你关注了平台规范。
token我用的是JWT，生成一段时间有效期。小程序端每次请求在header里带Authorization: Bearer <token>，后端用一个拦截器校验。为了演示方便，JWT有效期我设成了7天，避免演示到一半掉登录态。
3.2 钓点模块：定位、地图选点、详情与导航
钓点模块是整个APP的特色功能。发布钓点的页面由两部分组成：一个map组件和下面的表单。
用户点击“选择位置”后，小程序通过wx.getLocation获取当前定位，同时显示在地图上；如果用户想手动选点，可以直接拖动地图，我监听bindregionchange事件，在地图视野变化结束后用mapContext.getCenterLocation()拿到中心点的经纬度，再调用腾讯地图的逆地址解析接口，把经纬度转成具体地址文字。
这里要注意权限问题。wx.getLocation需要在app.json里声明requiredPrivateInfos，还需要在“小程序管理后台-开发-开发管理-接口设置”里申请开通位置接口，否则真机调试时会直接报错。我当时就是因为漏了后台申请，卡了半天时间以为代码写错了。
钓点详情页有一个很重要的功能：点击“导航到这里”，直接调微信的wx.openLocation接口。这个接口会打开微信内置的地图并自动规划路线，完全不需要自己去集成地图SDK。这个方法我在演示时用过很多次，效果很稳。
3.3 同城社区：信息流、评论、点赞的实现细节
社区模块是社交属性最重的一块，也是页面最多的模块。动态发布页面支持最多九张图片，配一段文字，可选择钓点定位。动态列表用分页加载，每页十条，按照发布时间倒序。
这里有一个容易忽略的点：列表页的“点赞状态”一定要在SQL里一步查出来，不要在Java里循环判断。我用MyBatis-Plus写了一个自定义SQL，通过LEFT JOIN关联当前登录用户的点赞记录，查每一条动态时直接带上liked字段。如果先查帖子列表，再循环查一次点赞表，就是经典的N+1问题，数据量小的时候看不出来，答辩时被问到就尴尬了。
评论实现相对简单，一张comment表通过post_id关联。我额外加了reply_user_id，支持“回复某人的评论”这种交互。前端展示时直接按时间查出来渲染在动态详情页底部。这个功能在整个项目中技术难度不高，但它是社区模块的必要组成部分，论文的功能设计章节里必须包含它。
3.4 约钓活动：从创建到结束的状态机设计
约钓活动是拉开项目档次的模块。一个活动由用户发起，填写标题、钓点、时间、人数上限，其他用户浏览后报名。
活动状态我设计成了明确的状态机：待开始、报名中、已报满、已结束、已取消。创建时默认报名中；报名人数达到上限时自动变已报满；到结束时间后由定时任务或前端触发变已结束；创建者在开始前可以取消活动。
报名的时候必须做两个检查：一是活动状态是否允许报名，二是当前用户是否已经报名。这两个检查我用数据库唯一约束(activity_id, user_id)做了兜底，确保同一用户不能重复报名。业务校验放在Service层，数据库约束作为最后一道防线。这个“双重校验”的思路在答辩时是加分项。
3.5 消息通知：站内信与订阅消息组合
消息通知我做了两层。站内信比较简单：用户发表动态或创建活动时，系统往关注的用户消息表里插入一条记录，消息列表页读取后按“未读数”标红。订阅消息稍微复杂一点，因为微信要求用户先主动订阅，后续才能推送。
我用订阅消息做了一个“活动开始提醒”的场景：用户报名活动后，活动详情页会弹出一个“订阅活动提醒”的按钮，用户点击后调wx.requestSubscribeMessage，后端在活动开始前半小时通过接口发送一条模板消息到用户微信。在毕设演示时效果非常直观——手机真的能收到服务通知，比单纯靠嘴讲“我有消息模块”有说服力得多。
需要提一句：订阅消息的模板ID要提前在微信公众平台的“订阅消息”里申请，个人主体的小程序也能申请部分模板，这点不用担心。
4. 开发期最容易翻车的细节，我替你踩过了
4.1 自定义导航栏高度计算
小程序默认的导航栏样式很丑，想做成和页面融为一体的效果，就要在app.json里设置"navigationStyle": "custom"，然后自己画导航栏。但一旦自定义，各种不同机型的顶部状态栏高度、胶囊按钮位置都不一样，适配不好就会出现按钮重叠或者留白过大。
我当时用官方推荐的方式：通过wx.getWindowInfo()拿statusBarHeight，再通过wx.getMenuButtonBoundingClientRect()拿胶囊按钮的位置信息，导航栏高度等于“状态栏高度 + 胶囊高度 + 上下预留间距”。注意wx.getSystemInfoSync已经被标记废弃，新项目建议直接用wx.getWindowInfo，网上很多老代码还在用旧API，容易踩坑。
这块代码建议封装成一个公共的工具函数，在全局登录后或每个自定义导航栏页面初始化时异步获取。别在onLoad里同步拿，部分机型可能拿不到准确数据。
4.2 图片上传：压缩、批量、进度
图片上传是所有内容类小程序都绕不开的点。我当时卡得最久的是：用户选完九张图片后，如果直接循环wx.uploadFile，会并发发请求，后端磁盘IO和带宽很容易被占满，而且失败后不好重试。
最终的方案是“先压缩、后串行上传”。用wx.chooseMedia拿到临时文件后，先循环调用wx.compressImage把图片压到质量60%，长宽限制在1280以内，压缩完的图体积基本能控制在200KB以下。然后写一个递归的串行上传函数，传完一张再传下一张，每传完一张更新进度条。串行虽然慢一点，但对服务器的压力小，也方便在网络不稳定时定位是哪张图传失败了。
图片存储我开发阶段直接存在服务器磁盘上，Nginx配一个静态资源映射来访问。后面如果要上线，建议换成对象存储，但毕设场景用磁盘存完全没问题，只要在论文里写清楚你的存储方案。
4.3 列表分页、下拉刷新与setData性能
社区列表页用的是onReachBottom触底加载下一页，配合enablePullDownRefresh下拉刷新。这里有个很多人会犯的错：直接在onReachBottom里调到接口然后this.setData把新数据concat进去，但忘了判断loading状态，导致快速滑动时触发了多次请求。
正确做法是维护一个loading标志和一个pageNo，每次加载前先判断是否已经在加载中、是否已经加载完；接口返回后页数加一；如果返回的条数小于页大小，就置为“没有更多”。整个过程还要用try...finally确保异常情况下loading能被正确复位。
另外，setData的时候只传变化的数据，不要整个列表重新赋值。尤其不要为了图省事把整个data对象都传进setData，数据量一大页面立刻掉帧。这些点看起来很基础，但论文里写到“前端性能优化”一节时，这就是实打实的素材。
4.4 表单组件的坑：单选框、选择器和日期选择
发布钓点的表单里，我用了单选框来选钓点类型，分别是“野钓/黑坑/路亚/海钓”。原生radio-group加radio组件本身很简单，但要注意默认的样式比较丑，建议直接用cover-view或者自定义一个可点击的选择卡片，选中的加边框高亮效果，比默认单选框好看太多了。
日期时间选择用的是picker组件的mode="date"和mode="time"，但用户要选的不是当前操作时间，而是“约钓开始时间”，所以需要把日期和时间组合起来。我用了两个picker联动，先用日期选择器选日期，再用时间选择器选时间，最终拼接成yyyy-MM-dd HH:mm提交后端。字段校验上要注意结束时间必须晚于开始时间，这个校验前后端都要做，前端为了体验，后端是为了安全。
4.5 微信支付：毕设到底做不做
很多钓鱼APP都会涉及报名的费用或者钓场门票，所以很多人会问我：微信支付能不能做进毕设？答案是可以，但要有心理准备。
第一，微信支付要求主体必须是企业或个体工商户，个人开发者无法开通，如果自己没有资质，就需要用海豚支付之类的话找有资质的主体代申请，流程复杂。第二，微信支付v3的对接逻辑确实比v2复杂，涉及证书、签名、回调验签，对第一次接触的同学来说很容易撞墙。
我的建议是：毕设最终展示时，做一个“模拟支付”流程。报名约钓活动时，点“报名”弹出支付确认框，支付方式展示微信支付样式，确认后直接调用后端一个POST /api/payment/mock接口，把订单状态标记为已支付，同时生成一条模拟支付记录。这样业务流程是完整的，又不会被卡在资质上。论文里诚实写清楚“因个人开发者无支付资质，支付环节采用模拟实现，生产环境可无缝切换为微信支付v3”，导师完全能理解。
5. 从本地到线上：远程调试与部署的完整链路
5.1 真机调试与预览
小程序开发不像网页，F12一下就行，真机运行和开发者工具模拟器之间经常存在差异。我第一次上线前在模拟器里一切正常，结果手机上一打开，地图组件渲染不出来，定位权限也弹窗报错。所以一定要养成“边开发边真机调试”的习惯。
微信开发者工具里有两种典型方式：一是预览，生成一个二维码让其他人手机上也扫;方式扫码打开体验版，适合给导师演示；二是真机调试，可以像开发者工具一样看控制台日志和网络请求，适合自己排查问题。两种方式都要求手机和电脑在同一网络下，或者用开发者工具的“局域网调试”功能。我第一次真机调试时一直连不上，后来发现是电脑防火墙把端口拦住了，关掉开发者工具对应的入站规则才正常。
如果后端是本地起的Spring Boot，小程序真机里访问不到localhost，必须把后端请求地址改成电脑的局域网IP，同时关闭防火墙，或者在同一个局域网下运行。如果电脑和手机不在同一个网络，可以临时把后端部署到云服务器，把接口地址改成线上域名。这就是“远程调试”最常见的场景——本地开发没法完全复现，直接调线上环境。
5.2 后端代码远程调试
毕设做到后期，会遇到一种很折腾的场景：接口在本地跑得好好的，部署到服务器就报错。这时候远程调试能救命。
Spring Boot支持JPDA远程调试，在服务器上用下面这个参数启动应用：
nohup java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar fishing-app.jar &然后在IDEA里配置一个Remote JVM Debug，主机写服务器IP，端口写5005，连上之后本地IDE就能直接给线上代码打断点。注意生产环境不要开着远程调试端口，调试完一定要关掉，否则有安全风险。这个操作在答辩前的“最后一公里”非常好用，让我少跑了好几趟服务器。
5.3 服务器、域名与HTTPS
小程序的正式环境要求所有请求域名必须是HTTPS，而且是配置在“小程序后台-开发管理-服务器域名”里的白名单。也就是说，光拿到一个云服务器还不够，至少要准备：
- 一台云服务器，我用的2核4G，安装JDK、MySQL、Nginx；
- 一个域名，需要完成ICP备案，备案周期一般一到两周，要提前准备；
- SSL证书，可以用云服务的免费证书，配置到Nginx上，强制HTTPS访问。
Nginx配置里把/api/开头的请求反向代理到本地的Spring Boot端口，静态资源例如图片加上缓存头，基本就完事了。因为这是一篇毕设项目的复盘，我把整个部署操作压缩一下提一句：顺序是“域名解析 -> 申请证书 -> Nginx配置 -> Spring Boot打包上传 -> 启动验证 -> 小程序后台配合法域名 -> 真机验证”。其中任何一步卡住，都建议先看日志，而不是凭感觉改配置。
5.4 上线前的自测清单
上线之前，我给自己列了一个自测清单，防止重要功能在演示时出丑：
| 检查项 | 通过标准 |
|---|---|
| 用户登录 | 新用户自动注册，老用户直接登录，token有效期正常 |
| 发布钓点 | 定位准确，逆地址解析正确，图片可上传成功 |
| 钓点导航 | wx.openLocation能打开内置地图并规划路线 |
| 动态发布 | 图片可压缩上传，内容可正常展示在feed流 |
| 评论点赞 | 点赞后数字+1，再次点击取消，评论可展示 |
| 活动报名 | 人数未满可报名，满员后不可报名，同一用户不可重复报名 |
| 订阅消息 | 用户同意订阅后，模拟推送能收到微信服务通知 |
| 消息列表 | 未读消息正确展示红点，点击后已读 |
| HTTPS请求 | 所有接口域名正常，无混合内容警告 |
| 真机兼容 | iPhone和Android各测一轮，地图和图片功能正常 |
这个清单还有一个额外的作用：整理完之后几乎就是论文里“系统测试”章节的内容，测试用例表格直接复制粘贴就能用。我当时把每一行都补上了“前置条件、操作步骤、预期结果、实际结果”，答辩老师看完明确表示测试这块很完整。
6. 论文与答辩：怎么让老师认可你的工作量
6.1 论文结构怎么安排
如果是用源码和文档做基础，千万别原封不动交上去。要把项目彻底读一遍，然后按下面的顺序组织论文：
- 绪论：背景、意义、国内外研究现状、主要工作；
- 需求分析：可行性分析、功能需求、非功能需求、用例图；
- 总体设计：系统架构图、功能模块图、数据库ER图、接口设计；
- 详细设计：按用户模块、钓点模块、社区模块、活动模块、消息模块分章节写核心流程和关键代码；
- 系统实现：贴页面截图、写实现效果和关键代码片段；
- 系统测试：测试环境、测试用例、测试结果分析；
- 总结与展望：总结工作，展望后续可扩展的方向。
这里有个核心技巧：论文里贴的代码片段不要整段复制，挑核心方法、挑有业务逻辑的代码，每段代码后面至少写两到三句注释性说明。比如展示状态机代码时，要写清楚为什么这样流转，异常情况怎么处理。这样论文查重率可控，也显得你真正理解了代码。
6.2 一个贯串全场的演示脚本
答辩演示的时候，很多同学是“想到哪点到哪”，点着点着忘了功能在哪。我的方法是提前写好演示脚本，按真实用户的使用路径来走：
第1步，打开首页，展示推荐的钓点列表和同城动态； 第2步，进入地图页面，演示附近钓点分布，点开一个钓点详情； 第3步，点击“导航”，展示wx.openLocation地图导航效果； 第4步，返回首页，发布一条带图片的钓鱼动态； 第5步，从另一个账号登录，给这条动态点个赞、评论； 第6步，创建一个约钓活动，切号报名，展示报名人数变化和订阅消息； 第7步，打开个人中心，展示我的钓点、我的动态、我的活动、我的鱼获记录； 第8步，最后切回管理后台，展示用户列表和内容管理功能。
这条链路既能覆盖全部核心功能，又能让导师看到你的系统是一个完整的产品，而不是几个零散的页面。
6.3 答辩高频问题与应对思路
根据我在答辩现场被问到的问题，整理了几条出现频率比较高的，提前准备答案：
- “你的系统解决了什么问题？”不要一上来就答“钓鱼社交”，要具体：解决了本地钓友去哪找钓点、如何约人、鱼获信息无法共享的问题。
- “为什么选择微信小程序而不是App？”小程序免安装、传播方便、适合低频工具型应用，同时又满足移动端场景需求。从成本和分发讲清楚就行。
- “数据库为什么这么设计？”讲清楚表之间的主外键关系，讲清楚点赞表独立设计和活动报名的唯一约束为什么合理，就足够。
- “系统的安全性怎么保障？”可以讲JWT鉴权、HTTPS、后端参数校验、SQL注入防护，还有小程序请求鉴权和敏感数据脱敏。不要只说“我做了”。
- “系统的性能瓶颈在哪里？”不要回避，直接说现阶段数据量小，分页和缓存已满足场景，后续可引入更细粒度的索引和缓存方案。这种“承认局限并给出方案”的回答很加分。
如果答辩老师问到了你不会的问题，记住一个原则：不要瞎编，也不要直接说“不会”，你可以说“这块在我现在的实现里没有深入，但我的理解是……”，然后把你懂的部分讲出来。大多数老师看重的不是你无所不知，而是你面对问题时有没有清晰的思路。
我个人在演示中最受用的一个细节是：所有账号和密码都提前写在便利贴上，演示时快速登录，绝不现找。还有，准备一个备用网络和一台备用手机，真机演示的时候微信开发者工具偶尔会掉网，备份才能确保万无一失。
这个项目从开题到答辩完，前后大概花了两个半月。最开始我也幻想过要不要挑战高并发、推荐算法、微服务，后来做下来的感受是：毕设项目最重要的不是技术有多花哨，而是你把它做完整、讲清楚了。同城钓鱼社交APP这个题目正好踩在“业务有趣、技术够用、逻辑完整”的平衡点上，认真做完，你就是能对导师和评委讲清楚自己做的东西、为什么这么设计、踩过哪些坑、还能怎么优化。把这些想明白，论文和答辩自然就都有了底气。
