企业官网建设流程全解析

这个项目标题里其实藏了三个产品名：萌崽、爪友、毛孩子。很多同学看到这种名字，第一反应是直接开一个 SpringBoot 工程，把增删改查糊上去，最后论文里写一句“本系统实现了宠物社交功能”。如果只是应付交差，这样确实能混过去，但这个 Java 毕设程序真正的价值，就在这三个名字的关系里。拆不明白，后面所有表结构、接口、页面全是散的；拆明白了，一个小程序项目也能做到像真实创业项目一样逻辑闭环。

先说结论：萌崽是“内容入口”，解决用户为什么来的问题；爪友是“服务闭环”，解决用户来了之后能干什么的问题；毛孩子是“社区心智”，解决用户为什么留下的问题。三个名字对应三种功能层，正好嵌套成一套宠物社交加服务平台加内容社区的完整方案。下面我按这个思路，把从需求、技术架构、数据库设计、核心功能实现到部署调试的完整经验过一遍，做毕设或者自己做项目练手都可以直接照着搭。

1. 项目定位与需求拆解：三个名字背后的产品逻辑

1.1 “萌崽”：宠物社交小程序的切入点

宠物社交最怕的一件事，是用户来了之后没东西可看、没东西可发。萌崽这个模块解决的就是“内容从哪来”。很多毕设上来就做“用户主页、发动态、评论、点赞”，做完却发现整个应用像一个空壳子，根本不像宠物社区。原因很简单：用户没有绑定宠物，发什么内容都缺灵魂。

我建议把“宠物档案”作为整个小程序的第一优先级功能。用户在注册之后，第一步不是完善个人资料，而是给宠物建档案：宠物昵称、品种、生日、性别、是否绝育、疫苗情况、头像、个性签名。听起来很常规，但这一步是整个社交链路的起点。宠物有了档案，动态才能挂靠到宠物名下，用户才能通过“附近宠友”“同品种圈子”找到同类，内容才有聚合维度。

说白了，萌崽解决的是“我为什么发内容”，因为我要晒我的猫、记录它的成长。有了这个出发点，之后做关注、点赞、评论、转发才有意义。所以第一阶段的功能清单可以很聚焦：宠物档案管理、动态发布、动态信息流、评论点赞关注、宠友搜索。这些做完，一个“宠物朋友圈”的骨架就起来了。

1.2 “爪友”：宠物互动与服务平台的服务闭环

光有内容没有服务，用户看完就走，这是纯内容产品的通病。爪友这个名字放在中间，就是要把“线上互动”升级成“线下服务”，让用户在这个小程序里真的能约到一次遛狗、一次寄养、一次上门洗护、甚至一次宠物医疗陪诊。

我见过不少毕设把“服务预约”做成了简单的“发个表单提交一下”，这其实是不够的。服务闭环至少要有四块：服务项目展示、时间选择与预约、订单状态流转、评价反馈。服务方可以是普通用户（比如隔壁养狗的朋友帮你遛狗），也可以是线下宠物店入驻。考虑到毕设复杂度，我不建议做商家后台审核那一套完整流程，只需要一个角色字段：普通用户、服务者。服务者可以发布服务项目，普通用户可以在服务大厅看到附近的遛狗、寄养、洗护等服务并预约。

这里要特别考虑一个问题：线下服务是有地域属性的。用户不能预约一个一千公里外的遛狗服务，所以爪友模块必须绑定 LBS，按距离展示服务。这正好也呼应了“宠物互动”里的“附近宠友”“同城约伴”功能。线上看动态、线下约服务，两条线通过地理位置串起来，整个项目的产品逻辑立刻通顺了。

1.3 “毛孩子”：内容社区的运营心智

第三个名字“毛孩子”很容易被忽略，不少同学把它当成一个普通话题标签，随便加个“热门话题”页面就完事。实际上毛孩子才是让用户沉淀下来的社区层，强调的不只是“晒宠物”，而是“爱宠生活分享”。也就是说，内容不能只有萌图，还要有养宠经验、品种科普、寻宠求助、宠物好物种草、同城宠物活动召集。

这一层做起来并不复杂，因为不需要再发明新功能，而是把已有内容按“话题”和“社区频道”重新组织。比如动态发布时可以选择话题标签：#猫咪日常、#养宠求助、#宠物好物、#寻宠启事。然后在社区首页按话题聚合，让用户能刷到一个“求助区”、一个“种草区”。就是这一点“标签化”的动作，就能把零零散散的宠物动态变成有社区结构的内容池。

三个名字连起来，就是一篇很好的毕设开题叙事：以宠物档案和动态内容吸引用户留住用户（萌崽），以位置服务和预约能力完成商业闭环（爪友），以话题聚合和社区运营提升粘性（毛孩子）。答辩的时候把这个逻辑讲清楚，比堆功能清单有用得多。

2. 技术选型与架构设计：Java 后端为什么要这样搭

2.1 后端技术栈与选型理由

后端我推荐 Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0 + Redis + WebSocket，这套组合是当前 Java 毕设里最稳的方案。SSH、SSM 那套不是不能写，但 Spring Boot 的自动配置和生态明显更适合短周期开发，答辩时也更好解释：Spring Boot 解决了传统 SSM 配置繁琐的问题，让开发者把精力放在业务实现上。

MyBatis-Plus 最大的价值不是帮你少写几行 XML，而是它自带的 LambdaQueryWrapper 和分页插件能省掉大量重复的 CRUD 代码。你在做宠物动态列表、服务预约查询这种多条件筛选场景时，用 QueryWrapper 直接链式拼条件，写起来比手写 SQL 快得多，也不容易出字符串拼接的坑。

Redis 在这个项目里不是摆设，至少有三个真实用途：存放登录 token 并控制过期时间、缓存点赞计数和动态热度、实现服务预约的分布式锁防止并发重复预约。只要用到了其中两个，答辩的时候被问到缓存一致性、缓存穿透之类的问题，你就有的聊了。

这里也提一句架构层面的事：小程序前端只通过 HTTP/HTTPS 调用后端接口，后端不直接暴露数据库。前端发请求到后端，后端校验 token、处理业务、查 MySQL、读写 Redis，图片文件另外走阿里云 OSS 或腾讯云 COS。整个链路很清晰，画成部署图也容易讲。

2.2 小程序前端与 Java 后端的接口设计

小程序端有两种选择：微信原生开发和 uni-app。如果你只打算发布到微信小程序，那就用原生开发，工具链最稳定，调试也方便；如果想着以后可能是 H5、支付宝小程序都要，再考虑 uni-app。毕设层面，原生开发已经够用，而且中文资料最多，遇到问题搜起来不费劲。

前后端接口要提前定一套统一规范。我习惯定义一个统一的响应体 Result，结构为 code、message、data 三个字段，code 为 0 表示成功，其他值表示业务异常。小程序端封装一个 request 方法，所有请求都走它，自动处理 token 注入、401 跳登录、错误提示。这个统一响应体看起来简单，但项目功能一多，你就知道它有多香——不需要每个接口各写各的返回格式，前端也不需要在每个页面单独处理错误。

token 怎么传？建议放在请求头里，名字可以叫 Authorization。小程序端在本地缓存 wx.setStorageSync('token', token)，每次请求前 getStorageSync 取出来放到 header 里。后端用拦截器统一校验，发现 token 过期就返回 401，前端收到 401 后清缓存并跳转到登录页。这一套逻辑做好，大部分接口的会话问题就都能兜住。

2.3 开发环境与服务器部署

开发阶段最省事的方法是在微信开发者工具里勾选“不校验合法域名”，这样本地局域网访问 Java 后端时不会被拦。但要演示给别人看，或者你自己用手机真机预览，就必须把后端部署到云服务器上，并在小程序后台配置合法域名（HTTPS，证书要有效），否则真机一测全是请求失败。

Java 后端部署我建议用最简单的方式：服务器装 JDK 17 和 MySQL、Redis、Nginx，后端打成 jar 包用 nohup 启动，Nginx 做反向代理把域名 80/443 流量转到 jar 的端口。不需要搞 Docker Compose 编排，那是加分项，不是必选项。小程序开发者工具上传代码之后，体验版二维码一发，别人就能直接看效果，这是演示环节最顺畅的一条路。

我踩过一个很典型的坑：本地使用微信开发者工具一切正常，换到真机就白屏报错。一查，是小程序后台没有配置 request 合法域名。所以别嫌麻烦，提前把服务器域名搞定、证书配好，真机调试这关必须过。

3. 数据库设计：把核心表结构一次想清楚

3.1 用户与宠物：平台的“双主体”建模

宠物社交平台和普通社区最大的区别在于，它的数据模型是双主体的：用户一套，宠物一套，用户和宠物之间是一对多关系。很多同学做宠物社区时只建了用户表，宠物信息直接塞在用户表里几个字段，这个设计到后面做“宠物动态时间线”“按品种搜索”“同一只宠物的成长记录”时，会把自己给限制死。

宠物档案表可以这样设计：

CREATE TABLE pet_profile ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL COMMENT '所属用户ID', pet_name VARCHAR(32) NOT NULL COMMENT '宠物昵称', breed VARCHAR(64) COMMENT '品种', category TINYINT COMMENT '1猫 2狗 3其他', birthday DATE COMMENT '出生日期', gender TINYINT COMMENT '1公 2母 0未知', avatar_url VARCHAR(255) COMMENT '宠物头像', sterilized TINYINT DEFAULT 0 COMMENT '是否绝育', vaccine_status TINYINT DEFAULT 0 COMMENT '疫苗状态', signature VARCHAR(200) COMMENT '个性签名', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

注意几点：user_id 建普通索引，因为你几乎所有宠物维度查询都要先根据用户找到宠物；品种 breed 建议存标准品种名而不是存 id，这样搜索和展示都直观；绝育和疫苗状态用 TINYINT 而不是 VARCHAR，既省空间又方便做筛选条件。这套表写出来，答辩时讲“一个用户可以养多只宠物，每只宠物独立建档”就是现成的亮点。

3.2 动态社区与互动关系：关注、点赞、评论别乱建表

动态表是整个信息流的基石。最简单的模型是：

CREATE TABLE pet_post ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, pet_id BIGINT NULL COMMENT '关联宠物', content TEXT, images TEXT COMMENT '图片URL，多个用逗号分隔', topic_id BIGINT NULL COMMENT '话题ID', location VARCHAR(100) COMMENT '发布位置', longitude DECIMAL(10,6), latitude DECIMAL(10,6), like_count INT DEFAULT 0, comment_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这里 images 我用 TEXT 存逗号分隔的 URL，而不是单独建一张图片表。为什么？因为宠物动态的图片数量和动态数量都不算大，拆表反而让查询变复杂，除非图片特别多再考虑分表。评论表和点赞表要单独建。评论区就是 post_id、user_id、content、reply_user_id，一个标准的一对多。点赞表要注意不能重复点赞，最好加唯一索引：

CREATE TABLE post_like ( id BIGINT AUTO_INCREMENT PRIMARY KEY, post_id BIGINT NOT NULL, user_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_post_user (post_id, user_id) );

有了这个唯一索引，重复点赞、取消点赞再点赞都不会产生脏数据，前端也不用担心用户手滑点了两下。关注关系表和点赞表结构类似，也是 follow_user_id + followed_user_id 加唯一索引，但查询时注意方向，别把“我关注了谁”和“谁关注了我”搞反，这个低级错误在答辩演示时出过不少次。

3.3 服务预约、订单与消息通知

预约服务这块，我建议把“服务项目”和“预约订单”分成两张表。服务项目表保存服务者发布的遛狗、寄养、洗护等服务的名称、价格、服务时间、服务范围、封面图、描述；预约订单表保存用户下的每一单，核心字段是 service_id、user_id、provider_id、service_date、service_time_slot、status、remark、create_time。

订单状态可以考虑 status 用 TINYINT：0 待支付、1 待接单、2 已接单、3 服务中、4 已完成、5 已取消。这个状态机不需要做复杂工作流引擎，只用 switch 判断当前状态允许哪些迁移就行。比如“已取消”的订单不能再改成“已完成”，后端接口里做一层校验就够。

消息通知表也很容易被忽略。用户预约成功、服务者接单、用户评价后服务者收到提醒，这些都需要有一个通知中心。最简单的设计是 notice 表：receiver_id、type、content、related_id、is_read、create_time。动态点赞评论可以写入通知，服务状态变更也可以写入通知，一个通用表搞定所有场景，前端小程序做一个小红点就可以了。

4. 核心功能模块实现：从登录到内容闭环

4.1 微信登录与用户体系接入

微信小程序登录的流程有固定套路：前端 wx.login 拿 code，后端拿 code 调微信接口换取 openid 和 session_key，然后以 openid 判断用户是否存在，存在则刷新登录态，不存在则创建用户并返回 token。核心代码大概长这样：

@PostMapping("/login") public Result<LoginVO> login(@RequestBody LoginDTO dto) { // 1. code 换 openid String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + dto.getCode() + "&grant_type=authorization_code"; String result = restTemplate.getForObject(url, String.class); JSONObject json = JSONObject.parseObject(result); String openid = json.getString("openid"); // 2. 查询或创建用户 User user = userMapper.selectOne(new LambdaQueryWrapper<User>() .eq(User::getOpenid, openid)); if (user == null) { user = new User(); user.setOpenid(openid); user.setNickname("萌宠用户" + RandomUtil.randomNumbers(6)); user.setAvatar("default.png"); userMapper.insert(user); } // 3. 生成 token 存入 Redis，有效期 7 天 String token = UUID.randomUUID().toString().replace("-", ""); redisTemplate.opsForValue().set("login:token:" + token, String.valueOf(user.getId()), 7, TimeUnit.DAYS); return Result.success(new LoginVO(token, user)); }

注意几个容易踩的坑。第一，code 只能使用一次，连续点登录按钮可能造成第二次调用失败，前端要加防重复提交。第二，openid 是用户唯一标识，绝对不能作为 token 直接用，token 和 openid 要分离，否则泄露一个接口参数就能冒充任意用户。第三，真实项目里获取用户手机号要用微信的按钮授权组件，不能自己写 input 让用户填，个人小程序是不开放这个接口的。

4.2 动态发布、图片上传与信息流

图片上传的常规做法是后端生成一个 OSS 临时上传凭证，小程序端直接直传到阿里云 OSS，再回传一个图片 URL 给后端存起来。为什么不能让小程序把图片传给后端、后端再转发到 OSS？因为图片体积通常几百 KB 到几 MB，走你服务器转发会白白占带宽、增加接口耗时，直传又快又省。后端只需要提供一个接口，返回 OSS 的临时凭证和上传路径。

动态发布之后进入信息流。信息流最常见的方案有三种：拉模式、推模式和混合模式。毕设场景下，拉模式完全够用，不要碰推模式。拉模式实现思路很简单：信息流接口根据当前登录用户查它关注列表，然后按时间倒序拉这些人的动态，再辅以分页。如果用户关注的人太少，就补充一些全站热门动态兜底，避免首页空荡荡。

分页推荐用 cursor（游标）方式，也就是把当前列表最后一条动态的创建时间或 ID 传回来，查询条件变成 create_time < lastCreateTime，而不是用 offset 翻页。这有个实打实的好处：新增的动态不会导致下一页里的数据重复或漏掉，用户体验比 offset 好得多。用 MyBatis-Plus 的 Page 也支持，但注意 order by create_time desc。

4.3 同城宠物互动：定位、距离计算与附近推荐

同城功能是小程序里的一个亮点，但也是一个容易翻车的地方。小程序端通过 wx.getLocation 获取经纬度，需要在小程序后台声明位置接口用途，用户也要授权。拿到经纬度之后，可以在前端把定位回传，也可以让后端每次请求都带经纬度参数。

附近宠物列表的实现，毕设阶段不搞 GeoHash 那一套，用 MySQL 加 Haversine 公式直接算就行。SQL 可以这么写：

SELECT id, pet_name, breed, avatar_url, (6371 * acos(cos(radians(#{lat})) * cos(radians(latitude)) * cos(radians(longitude) - radians(#{lng})) + sin(radians(#{lat})) * sin(radians(latitude)))) AS distance FROM pet_profile WHERE latitude IS NOT NULL HAVING distance < #{radius} ORDER BY distance LIMIT 20

这个 SQL 里 6371 是地球半径，单位是公里。只要给 latitude 和 longitude 建复合索引，在几千条数据量下性能完全没问题，没必要为了这个单独引入 Elasticsearch 或者 MongoDB。如果用户拒绝授权定位，就返回一个默认坐标（比如选取一个城市中心），然后提示用户开启定位可以获得更准的同城推荐，别让整个页面直接挂掉。

4.4 预约服务与订单闭环

预约服务模块最容易发生的并发问题是：两个人同时选中了同一个服务者的同一个时间段，结果都显示预约成功。毕设阶段解决这个问题有两种手段，按优先级排列：一是数据库唯一索引约束，比如在预约订单表加一条唯一索引 (service_id, service_date, time_slot)，谁先插入谁成功，后插入的人会报 DuplicateKeyException，后端捕获这个异常后提示“该时间段已被预约”；二是 Redis 分布式锁，预约前先尝试获取锁，获取失败直接返回冲突提示。

我建议把唯一索引作为第一道防线，因为这不需要额外依赖，MySQL 本身就保证。Redis 分布式锁可以作为一个加分点自己加上，并准备一段答辩话术：“在外卖、家政这类场景中，同一个服务者同一时间段只能服务一个订单，所以用唯一索引防重复插入，同时用 Redis 锁前置拦截，减少无意义的数据库写冲突。”这句话一出来，技术深度立刻不一样了。

预约完成之后还要做一个收尾动作：订单完成后用户可以评价，评价内容写入评价表，服务者的评分从评价表里聚合出来展示在服务列表里。评分这个细节虽然只是一个小功能，但它让你的服务闭环显得完整，而不是预约完就断了。

4.5 私信与 WebSocket 即时通信

宠物社交里“宠友互发私信”几乎是标配功能。实现方案无外乎两种：接入第三方即时通讯 SDK，或者自研一个简易 WebSocket 消息系统。对毕设来说，第三方 SDK 虽然稳，但对方 SDK 的文档、依赖、控制台配置会占用大量时间，而且答辩时大多只能讲“我调了别人的接口”，很难讲出深度。自研一个简易 WebSocket 一对一聊天，反而是更好的选择，因为逻辑足够、场景可控、能讲的东西多得多。

自研方案的要点有几块：WebSocket 握手时通过 token 识别用户身份，服务端把 session 维护在 ConcurrentHashMap 里，key 是用户 ID，value 是 WebSocketSession。A 给 B 发消息时，后端先入库（message 表保存 from_user_id、to_user_id、content、is_read、create_time），再检查 B 是否在线，在线则直接推送，不在线则等他下次上线拉取离线消息。心跳机制可以用前端定时发送 ping 消息，后端响应 pong，超过一定时间没收到心跳就关闭连接。自研到这一步，已经能覆盖真实聊天中 80% 的基础能力。

5. 第三方服务与合规细节：这些坑早踩早好

5.1 OSS 存储与图片处理

图片存储我推荐直接用云厂商的对象存储，不要自己写文件写到服务器本地。本地存储看着简单，但后面会遇到几个现实问题：服务器磁盘满了怎么办、图片备份怎么做、小程序访问本地图片路径不稳定。OSS/COS 本身带有 CDN 加速能力，而且可以配置图片处理（缩略图、水印、裁剪）。

接入对象存储时要考虑防盗链，如果不设置，别人拿到你的图片链接可以直接盗用，浪费你的流量费用。可以在对象存储控制台设置 Referer 白名单，只允许你的小程序域名和服务器域名访问。同时图片上传前要在小程序端做压缩，微信的 wx.compressImage 可以直接用，不然用户手机相册里一张 10MB 的照片传上来，既慢又费流量，加载列表时还会卡。

5.2 内容审核：社区类小程序上线逃不掉

只要你的项目里有用户发布动态、评论、私信，就必须考虑内容安全问题。这并不是上纲上线，而是社区类小程序在上线审核时绕不过去的实际要求。最稳的做法是接入云厂商的图片/文本内容安全检测服务，发布动态时先调接口检测图片里有没有违规内容、文本有没有辱骂和违法违规信息，检测通过才允许入库。

同时本地要做一层简单的敏感词过滤，后端拿到 content 后先跑一遍词库匹配，命中就拦截并把请求标记为异常。还有一个更实用的功能是举报机制：动态和评论都支持用户举报，举报后写入举报表，管理员端（哪怕只是简单的后台页面）可以查看并处理，比如禁言或删除动态。你不用把管理后台做得多复杂，但“审核、举报、处理”这条链路得有，答辩时安全性和合规性也是加分项。

5.3 支付与隐私安全提醒

真实接入微信支付需要企业主体、商户号、类目资质，个人开发者基本走不通。毕设项目不要硬接真实支付，建议做“模拟支付”：用户下单后点支付，弹窗显示“演示环境，模拟支付成功”，然后订单状态流转到待接单。在论文里解释清楚“真实环境需要接入微信支付统一下单接口，本项目采用模拟支付便于演示”，这个处理既真实又不会卡在资质上。

隐私方面必须注意两个点。第一，用户的手机号属于敏感信息，存储时建议脱敏，比如只存 138****1234 这种格式，不要明文整串存。第二，需要在小程序里配置隐私保护指引，弹窗告知用户收集了位置信息、头像昵称、手机号等数据。这些不是可以跳过的流程，审核时都会看。数据安全的口径在答辩时也经常被追问，提前想好怎么答，别只说“我数据库里有手机号字段”。

6. 调试实录与经验清单：交项目前最值得检查的五件事

6.1 高频问题速查表

这里要单独提醒一下心跳包。WebSocket 长时间空闲会被服务器断开，前端不处理的话，用户聊着聊着就发现消息发不出去了。我在项目里做了每 30 秒前端发送一次 ping、后端立即响应 pong 的心跳机制，断线之后会自动重连并重新拉取离线消息。这个细节虽然小，但演示私信功能时特别重要，不然现场突然断连会非常尴尬。

6.2 部署演示常见翻车点

毕设演示翻车率最高的一幕，不是功能没写完，而是“本地一切正常，换一台电脑就废了”。数据库连接、Redis 地址、OSS 配置如果写死在代码里，并且指向 localhost，部署到服务器就必然报错。我建议所有外部配置都放进 application.yml 里，部署时通过修改配置文件或环境变量切换。开发环境用本机，生产环境用服务器 IP 或域名，不要图省事写死。

另一个高频翻车点是服务器安全组。很多同学买了云服务器，只放行了 22 端口，结果网页和接口全访问不了。Java 后端一般监听 8080，Nginx 监听 80 和 443，这些端口都要在安全组里放行。如果用了 MySQL 远程连接，3306 也要放行，但更安全的方式是本地连服务器 ssh 隧道，别把数据库端口裸奔到公网。

演示数据一定要提前准备。一个没有任何数据的社区类小程序，打开首页空荡荡，评委的观感会大打折扣。至少准备 3 到 5 只宠物档案、10 条以上动态、3 条附近服务、2 个不同状态的订单，并且提前用演示账号把所有页面跑一遍。这套“演示数据工程”花不了太久，但对答辩效果的提升是肉眼可见的。

6.3 答辩时怎么讲这个 Java 毕设才不心虚

评委看毕设，最常问的五句话，我提前整理出来：

• 为什么做这个选题？答：宠物经济规模增长，养宠人群有社交和服务需求，但市面上缺少一个把内容、互动、预约服务整合到一起的平台。
• 系统包含哪些角色？答：普通用户、服务者、管理员三层角色，不同角色看到的功能入口不同。
• 核心表有哪些？你们字段怎么设计的？答：讲用户、宠物、动态、关注、点赞、订单、通知这几张核心表，再举宠物档案表为例说明一对多关系。
• 遇到过哪些技术难点？怎么解决的？答：同城距离计算的方案选型、并发预约防冲突、WebSocket 在线推送与离线消息，这三个话题任一展开都很加分。
• 项目有哪些不足？后续怎么优化？答：不要只说“没有不足”，而是说“当前采用 MySQL 范围计算距离，数据量增大后可引入 GeoHash 或 Elasticsearch；消息推送是单机 WebSocket，后续可引入 MQ 和分布式长连接网关”。

最后一句话我想特别强调：答辩的时候千万不要背代码，没人关心你写了多少行。评委更想听到的是你的“决策过程”——为什么选这个数据库、为什么用 Redis、为什么分页用游标、并发问题怎么保证。把每个技术选型背后的为什么讲明白，你的 Java 毕设自然就到了优秀档。

这个项目做完之后我最大的体会是，收获不是学会了多少个框架，而是把一条业务链路从产品定位、表结构、后端接口到小程序部署完整走了一遍。如果让我重做一遍，我会把更多时间花在“先画业务流程，再写代码”上，需求一旦通了，后端写起来几乎是流水线。另外提醒一句：代码一定要自己敲，哪怕参考开源项目，也要把每个模块吃透，不然答辩现场一追问就露馅。一个能流畅跑通完整链路的小程序，永远比十个只写了一半的零散功能更有说服力，这也是这个项目真正沉淀下来的最重要经验。