企业官网建设流程全解析

做微信小程序聊天交友方向的项目，我前后折腾过不少时间。最核心的体会是：交友类产品的难点从来不在“发消息”这个动作本身，而在注册登录、身份信任、匹配推荐、会话生命周期这一整套链条上。这次要说的这个基于UniApp开发的“个性化大学生线上聊天交友系统”，就是把这条链路从头到尾打通的一份完整实践，覆盖了微信小程序端、后端接口、实时消息通道、数据库建模和匹配算法落地。

这套系统面向校园范围内的学生用户，解决的是“圈子太窄、找不到同好、陌生人聊天信任成本高”这三个非常具体的校园社交痛点。技术栈上选了UniApp做前端跨端框架，后端用Node.js提供接口服务，数据库用MySQL，实时消息走WebSocket，同时接入了WeChat原生的登录与支付能力。如果你正在做毕业设计选题，或者想找一个能真正跑起来、功能完整的小程序项目练手，这份拆解应该能帮你在动手写第一行代码之前，把整个地图看明白。

下面不按官方文档的顺序讲，而是按我自己从需求分析、建表、写接口到真机调试踩坑的流程来复盘。这样你遇到同类问题时，能顺着这套思路去定位，而不是对着报错信息瞎猜。

1. 底层思路与项目定位

1.1 为什么聚焦大学生，而不是做泛人群社交

刚拿到这个需求的时候，可能很多人第一反应是：聊天交友系统有什么稀罕的，微信附近的人、陌陌、Soul不都是现成的吗？但如果你真的往下拆，会发现泛社交产品和校园社交产品面对的问题完全不是一回事。

大学生群体的社交场景有几个非常鲜明的特征。第一是圈子封闭，一个学生日常接触的基本就是同班、同寝室、同社团的人，跨专业跨年级的社交机会极少。第二是作息高度同步，上课时间、期末考试周、寒暑假，用户活跃度曲线和上班族完全不一样，这意味着消息推送时机和推荐策略要做针对性适配。第三是身份背书相对可信，校园用户有学号、院系、年级这些可校验的信息，这让陌生人社交里最头疼的“对面到底是谁”问题有了一个天然的信任锚点。

所以这个项目虽然表面上是个“聊天交友”产品，本质上做的是一件事：把线下的校园人际网络搬到线上，再用标签和匹配逻辑把原本没有交集的人关联起来。泛社交产品常用的LBS附近的人和右滑卡片，在这个场景下反而都不是最优解，因为校园地理范围太小了，附近的人推来推去可能全是低头不见抬头见的同学，尬感会非常强。

1.2 “个性化”不是一个功能，而是一条完整链路

标题里的“个性化”三个字，很多人会误解成“做个标签页，让用户选几个兴趣关键词”。实际上，个性化是一整套从数据采集到匹配展示的闭环链路，缺了任何一环，最后的效果都会很生硬。

我把这条链路拆成四段：

1. 采集阶段：注册时通过分步表单收集年级、院系、兴趣标签、性格倾向、作息习惯等信息，注意表单不能一次铺太长，否则注册转化率会很难看。
2. 建模阶段：把用户选择的标签转成结构化数据，并为不同标签配置不同的权重。例如“摄影”和“羽毛球”是强兴趣标签，而“熬夜党”和“早睡族”则是生活习惯标签，它们在匹配时的重要性是不同的。
3. 匹配阶段：基于标签权重计算用户之间的相似度，再叠加院系、年级、活跃时间等过滤条件，生成推荐列表。
4. 展示阶段：每个人的首页推荐顺序、话题卡片内容都不一样，让用户感受到“这个系统是懂我的”。

这四段链路我在第3章和第4章会详细拆开讲。这里先给出一个核心观点：如果你只想做个简单的聊天Demo，那不需要个性化逻辑；但如果你想做一个真正能被用户持续使用的交友系统，个性化就必须从数据库设计的第一天开始考虑，而不是等聊天功能做完了再回来补。因为标签数据一旦没有在注册阶段落下，后续靠用户自己去补填，大多数人是懒得填的，数据质量会大打折扣。

2. 技术选型：为什么偏偏是UniApp

2.1 先横向对比一圈再做决定

在确定UniApp之前，我认真对比过市面上的几种方案。选型的核心矛盾是：微信小程序原生开发性能最好，但不能一套代码跑到其他端；跨端框架能解决多端问题，但又怕引入额外的性能和兼容性负担。

横向对比完，UniApp的优势就比较明显了。首先是开发语言对前端友好，Vue的单文件组件写法加上uni自带的一系列API，迁移成本很低。其次是一套代码多端编译，这对校园类产品很重要，因为很多学生用户会习惯性地用手机浏览器打开H5版本，你不用额外维护一套Web端代码。再就是uni-app的生态组件很成熟，像登陆、支付、地图、推送等模块都有现成封装，省了不少自己造轮子的时间。

当然，UniApp也有它的短板。最明显的是复杂动画和长列表性能不如原生，如果你要做的是一个类似陌陌那样有复杂进场动画和大量Feed卡片的产品，UniApp的优化成本会比较高。但校园交友场景并不依赖这种重度动效，聊天会话页面和推荐列表都是典型的业务型页面，UniApp完全抗得住。

2.2 整体架构全览

整个系统按经典的前后端分离结构组织，各端职责非常简单清晰：

• 前端：UniApp写的微信小程序端，负责页面渲染、用户交互、WebSocket长连接、本地缓存。
• 后端：Node.js提供RESTful接口，负责注册登录、用户信息管理、动态内容、匹配推荐、聊天消息的路由和存储。
• 实时通道：单独的WebSocket服务处理聊天消息推送，通过Redis做在线状态管理，离线消息落到MySQL，等用户上线后再拉取。
• 数据库：MySQL存储用户、标签、会话、消息、动态等核心业务数据。
• 云存储：头像、动态图片、语音消息文件统一上传到云存储，数据库里只保存URL地址。

这套架构里有个容易被新手忽略的点：聊天消息的发送不能完全依赖WebSocket。WebSocket只管实时推送，但消息一旦发出去，必须立刻持久化到数据库里。如果用户断线了，对方发的消息要先落在MySQL，等用户重新连接时再通过接口拉取离线消息。否则就会出现“当时收到，刷新历史记录却消失”这种非常严重丢消息的体验问题。

2.3 工程目录与模块划分

项目工程用标准的UniApp目录组织，我按模块做了拆分：

campus-chat/ # 前端工程 ├── pages/ # 页面文件 │ ├── index/ # 首页/推荐流 │ ├── chat/ # 会话列表和聊天窗 │ ├── profile/ # 个人主页 │ ├── publish/ # 动态发布 │ └── login/ # 登录 ├── components/ # 公共组件 ├── store/ # Vuex状态管理 ├── utils/ # 请求封装/工具函数 ├── static/ # 静态资源 ├── App.vue ├── main.js ├── manifest.json # 小程序配置 └── pages.json # 页面路由配置

后端工程我个人习惯按业务模块来分，不太喜欢拆得太散：

server/ ├── app.js # 入口文件 ├── routes/ # 路由定义 ├── controllers/ # 业务逻辑 ├── models/ # 数据库模型 ├── middlewares/ # 鉴权中间件 ├── socket/ # WebSocket处理 └── config/ # 配置文件

前端页面的目录命名有个小技巧：聊天模块相关的页面我都放在 chat 和 message 两个目录下分开管理，因为会话列表是一个高频页面，把它的独立性和聊天窗页面区别开，后续做页面分包和预加载时会更方便。

3. 核心功能设计与数据库建模

3.1 用户注册与学籍校验模块

用户表是整个系统的基础，我的设计思路是把注册拆成两步：先用手机号验证码登录拿到临时身份，再完成学籍信息绑定，这样可以避免用户在注册流程第一步就被一长串表单劝退。

学生用户表的核心字段：

CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `nickname` varchar(32) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `gender` tinyint(1) DEFAULT '0' COMMENT '0未知 1男 2女', `school_id` varchar(32) DEFAULT NULL COMMENT '学号', `college` varchar(64) DEFAULT NULL COMMENT '院系', `grade` varchar(10) DEFAULT NULL COMMENT '年级', `bio` varchar(255) DEFAULT NULL COMMENT '个性签名', `status` tinyint(1) DEFAULT '1' COMMENT '账号状态 1正常', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关于学籍识别，这里特别提醒一句：如果你的系统是个人毕设或个人项目，千万不要去对接学校教务的实名接口，既拿不到权限，也有严重的隐私合规风险。我采用的是“学号格式校验 + 校内邮箱辅助验证”的方案。比如某校学号通常是“年份+院系代码+序号”这种结构，后端校验格式合法即可。这个方案能完成基本的身份过滤，又不触碰敏感数据边界。

3.2 标签体系与个性化信息采集

标签体系是本系统的个性化基础。我没有把标签做成一个死板的文本输入框，而是预先定义了一套校园场景下的标签库，用户通过点选完成标注。这样做的好处是数据格式统一，后续做匹配计算的时候不用做文本解析。

标签库我按四个维度划分：

• 兴趣爱好：摄影、羽毛球、桌游、吉他、LOL、剧本杀、跑步、读书
• 性格特质：E人/I人、慢热、话痨、倾听者、直爽
• 生活习惯：夜猫子、早睡早起、重口味、清淡饮食、爱运动
• 校园场景：考研党、实习中、社团达人、竞赛选手

数据库里用户和标签是多对多关系，用三张表来存储：

CREATE TABLE `tag` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(20) NOT NULL, `category` varchar(20) NOT NULL COMMENT '维度', `weight` int(11) DEFAULT '1' COMMENT '权重', PRIMARY KEY (`id`) ) ENGINE=InnoDB; CREATE TABLE `user_tag` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `tag_id` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `idx_user` (`user_id`) ) ENGINE=InnoDB;

采集页面的设计有个细节要注意：一次页面里不要展示超过8个标签。我最初把所有标签放在一个页面上，结果用户一屏滑不完，整个注册流程的流失率明显偏高。改成“分类分步选择，每步4-6个标签”之后，完成率提升了不少，而且用户更愿意认真去选，因为他们不需要一次处理太多信息。

3.3 聊天会话与消息模型

聊天模块的数据模型是这类系统里最需要提前想清楚的，它直接决定了会话列表页和聊天窗页的性能表现。我把会话和消息拆成两张独立的表：

CREATE TABLE `conversation` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL COMMENT '会话归属人', `peer_id` int(11) NOT NULL COMMENT '对方用户ID', `last_message` varchar(255) DEFAULT NULL, `last_time` datetime DEFAULT NULL, `unread_count` int(11) DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_user_peer` (`user_id`, `peer_id`) ) ENGINE=InnoDB; CREATE TABLE `message` ( `id` int(11) NOT NULL AUTO_INCREMENT, `conversation_id` int(11) NOT NULL, `sender_id` int(11) NOT NULL, `msg_type` tinyint(1) DEFAULT '1' COMMENT '1文本 2图片 3语言', `content` text, `status` tinyint(1) DEFAULT '0' COMMENT '0未读 1已读', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_conversation` (`conversation_id`) ) ENGINE=InnoDB;

有人可能会问，为什么会话表要按用户维度存一份，而不是只存一个包含双方ID的对话记录？因为会话列表页要展示的是“我视角下的列表”，每个用户对同一个对话的未读数、置顶状态、最后一条消息的已读状态可能都不一样。如果只存一份共享数据，就会出现在A手机上已读的消息，B手机上还显示红色的未读气泡这种尴尬情况。

关于未读数，我一度想在读取消息时用 count 统计未读消息数量，真实跑下来发现数据量大了之后查询开销不可接受。更合理的做法是在会话表里维护一个未读数字段，有新消息时加一，进入聊天界面时清零。这样会话列表页一条SELECT就能取到全部会话和未读数，性能非常可控。

3.4 动态广场与互动模型

动态广场是聊天之外最核心的社交入口。用户注册完填完标签后，如果直接进入空荡荡的聊天列表，很容易流失。所以在首页放一个校园动态流，让用户能看到其他人的生活和兴趣点，才能自然地引导到私聊。

动态相关的表我建了三张：

CREATE TABLE `post` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `content` varchar(1000) DEFAULT NULL, `images` text COMMENT '图片URL，多个用逗号分隔', `topic` varchar(50) DEFAULT NULL COMMENT '所属话题', `like_count` int(11) DEFAULT '0', `comment_count` int(11) DEFAULT '0', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user` (`user_id`), KEY `idx_topic` (`topic`) ) ENGINE=InnoDB;

评论表和点赞表就不贴全套SQL了，但有一点值得提醒：点赞关系一定要单独建表，不能只维护点赞数字段。因为用户需要看到“我是否赞过这条动态”，如果只存数字，你无法判断当前用户的点赞状态，每次都要全表扫或者用内存缓存，很麻烦。用user_id + post_id建唯一索引既可以快速判断，也能防重复点赞。

互动设计上做了一个小改进：用户A点赞或评论了用户B的动态之后，B会收到一条系统通知，点击通知可以直接跳到A的个人主页。这条设计看着简单，实际对社交破冰的帮助很大，因为它把“单方面的内容消费”转化成了“双向的社交连接”，私聊的发起率会高很多。

3.5 匹配推荐的核心逻辑

推荐逻辑是整个系统的智力核心。我采用了一种基于标签权重的相似度评分方案，核心思路是对比两个用户的标签集合，按标签维度分别计算权重和。

相似度评分的计算逻辑类似这样：

// 用户A和B的标签都是数组 function calSimilarity(userA, userB) { const tagWeightMap = { '摄影': 2, '羽毛球': 2, '桌游': 3, '剧本杀': 3, '夜猫子': 1, '早睡早起': 1, '考研党': 2 }; let score = 0; const tagsB = new Set(userB.tags); userA.tags.forEach(tag => { if (tagsB.has(tag)) { score += tagWeightMap[tag] || 1; } }); return score; }

这个方案里最值得琢磨的其实是权重设计。强兴趣标签（桌游、剧本杀这类对同好需求特别强的）需要给到更高权重，而生活习惯标签权重低一些，避免出现“两个都熬夜的人被强行匹配”这种尴尬情况。我在实际调参中发现，把“考研党”单独设成高权重标签效果很好，因为考研人群对同伴的需求非常具体和强烈，匹配后产生聊天行为的概率明显更高。

匹配推荐列表的生成逻辑，在后面第4章会给出实际可运行的代码。这里先交代清楚筛选前提：推荐列表需要排除自己、排除已拉黑的用户、排除已经聊过天的用户，然后再按相似度从高到低排序。

4. 关键模块的实操实现

4.1 登录态与token会话管理

微信小程序的登录流程比较固定：前端调用uni.login拿到code，把code传给后端，后端用code换微信的openid和session_key，然后签发自定义的token返回给前端。前端把token存在本地缓存里，后续所有接口请求都带上这个token。

我封装了一个统一的请求模块，所有接口调用都走它：

// utils/request.js const BASE_URL = 'https://your-api-server.com'; function request(url, method = 'GET', data = {}) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + url, method, data, header: { 'Content-Type': 'application/json', 'Authorization': uni.getStorageSync('token') }, success: (res) => { if (res.statusCode === 401) { // token过期，重新登录 uni.navigateTo({ url: '/pages/login/login' }); reject(new Error('未登录')); return; } resolve(res.data); }, fail: (err) => { uni.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); }

关于token过期和续期，我遇到过不少问题。微信小程序端的token如果设太短，比如30分钟，用户聊着聊着突然要求重新登录，体验非常差；如果设太长又不够安全。我的做法是设置7天有效期的token，同时后端在每次请求时检查token剩余有效期，小于1天就顺延刷新并返回新的token，前端拦截响应后更新本地缓存。这样能做到无感续期，又不会让session无限延长。

4.2 WebSocket连接、心跳与断线重连

聊天消息的实时推送是整个系统里技术含量最高、也最容易出问题的地方。微信小程序原生提供uni.connectSocket，UniApp对其做了统一封装，但使用时要特别注意小程序平台的连接数限制和生命周期问题。

我封装了一个Socket服务模块：

// utils/socket.js class SocketService { constructor() { this.socketTask = null; this.isConnected = false; this.reconnectTimes = 0; this.heartbeatTimer = null; } connect(token) { uni.connectSocket({ url: 'wss://your-socket-server.com?token=' + token, success: (res) => { this.socketTask = res; } }); this.socketTask.onOpen(() => { this.isConnected = true; this.reconnectTimes = 0; this.startHeartbeat(); }); this.socketTask.onMessage((msg) => { this.handleMessage(msg); }); this.socketTask.onClose(() => { this.isConnected = false; this.stopHeartbeat(); this.reconnect(); }); this.socketTask.onError(() => { this.isConnected = false; this.reconnect(); }); } startHeartbeat() { this.stopHeartbeat(); this.heartbeatTimer = setInterval(() => { this.sendMessage({ type: 'ping' }); }, 30000); } stopHeartbeat() { if (this.heartbeatTimer) { clearInterval(this.heartbeatTimer); this.heartbeatTimer = null; } } reconnect() { // 指数退避，最大30秒 this.reconnectTimes++; const delay = Math.min(30000, 1000 * Math.pow(2, this.reconnectTimes)); setTimeout(() => { const token = uni.getStorageSync('token'); token && this.connect(token); }, delay); } }

心跳包的设计一定要有，否则运营商的NAT连接空闲超时会把你连接悄悄断掉。我用的是“客户端每30秒发一次ping，服务端返回pong”方案。服务端如果连续两次没收到心跳，就主动断开连接，释放资源。

断线重连的指数退避策略值得单独说明一下。第一个版本用的是固定3秒重连，结果出现一个线上事故：中断的那一分钟里服务端连接池被打满，其他用户全部连不上。改成指数退避之后，1秒、2秒、4秒、8秒这样递增，最大30秒，既保证恢复速度，又不会把服务端打垮。

4.3 消息列表的分页加载与本地渲染

聊天窗页面的渲染有几个细节直接决定体验好坏。第一是历史消息要分页加载，不能一次把所有记录都拉下来。第二是消息要按时间分组，显示“今天”“昨天”“周一”这样的时间头，方便用户定位上下文。第三是自己发送的消息要立即本地插入渲染，不能等服务端确认后再显示，不然用户会感觉消息有延迟。

历史消息拉取我用的是分页接口：

// 拉取历史消息 async function getHistoryMessages(conversationId, page, pageSize) { const res = await request( `/api/conversation/${conversationId}/message?page=${page}&pageSize=${pageSize}`, 'GET' ); return res.data; }

前端会把拉回来的消息按created_at做时间分组，渲染出这样的结构：

// 消息按时间分组 function groupMessagesByDate(messages) { const groups = []; let currentDate = ''; messages.forEach(msg => { const dateKey = formatDateKey(msg.createdAt); if (dateKey !== currentDate) { currentDate = dateKey; groups.push({ date: dateKey, items: [] }); } groups[groups.length - 1].items.push(msg); }); return groups; }

发送消息的流程我是这样设计的：用户按发送键后，先把消息内容插入本地的消息数组并显示发送中状态，然后通过WebSocket把消息推给服务端。服务端持久化成功后会返回一条带官方消息ID的确认帧，前端收到确认后把本地消息状态更新为已发送。如果WebSocket断线，本地显示发送失败并提供重发按钮，重发的消息不会重复入库，因为本地消息带了临时ID作为幂等标志。

4.4 个性化匹配推荐的落地实现

第3章讲了匹配的核心思路，这里给出后端实际的实现方式。推荐列表核心是一个获取候选人的SQL，加上一段相似度排序逻辑：

// 匹配推荐核心逻辑 async function getRecommendUsers(currentUser, limit = 20) { const candidates = await db.query( `SELECT u.id, u.nickname, u.avatar, u.college, u.grade FROM user u WHERE u.status = 1 AND u.id != :currentUserId AND u.id NOT IN ( SELECT peer_id FROM conversation WHERE user_id = :currentUserId ) ORDER BY RAND() LIMIT :candidateLimit`, { currentUserId: currentUser.id, candidateLimit: 200 } ); const currentUserTags = await getUserTags(currentUser.id); const scoredUsers = []; for (const candidate of candidates) { const candidateTags = await getUserTags(candidate.id); const score = calSimilarity( { tags: currentUserTags }, { tags: candidateTags } ); scoredUsers.push({ ...candidate, score }); } scoredUsers.sort((a, b) => b.score - a.score); return scoredUsers.slice(0, limit); }

这段实现里有几个细节决定的性能上限。首先，不能对全表用户做相似度计算，那样几百个用户以内还撑得住，上万用户就必然超时。所以我先从候选池里ORDER BY RAND()随机抽200人再算分，兼顾了随机性和性能。其次，标签查询不能每次都去数据库实时查，我把它做了Redis缓存，key是 user_id，value是标签ID数组，计算时直接取缓存，匹配接口的响应时间能压到200毫秒以内。

随机抽样策略对冷启动很重要。新注册用户没有任何聊天记录和足够标签时，如果直接按相似度推荐，结果几乎全是零分用户，页面会显得很空。我的方案是：标签少于3个的用户，直接走“热门用户 + 同院系优先”的兜底策略，先帮他们积累社交关系，等标签数据丰富后再切换成个性化推荐。

5. 常见问题与排查技巧实录

5.1 冷启动/前后台切换导致WebSocket频繁断开

小程序和普通Web应用有个很大的区别：用户随时可能切到后台再切回来，这个过程微信会主动回收WebSocket连接。最开始我调试的时候发现，用户切走再切回来，消息就不实时了，要杀掉小程序重开才恢复。

排查后发现需要做前后台切换的显式处理：小程序切到后台时主动关闭WebSocket并停止心跳；切回前台时立即重新建立连接，同时调用一个pullOfflineMessages接口拉取离线消息。这个方案实测下来稳定很多，不会再出现“切后台就掉线”的玄学问题。

// App.vue中处理前后台切换 onHide() { socket.close(); }, onShow() { const token = uni.getStorageSync('token'); if (token) { socket.connect(token); } }

5.2 消息乱序与重复消息

WebSocket本身是顺序传输的，但实际调试中我发现消息到达的顺序可能会颠倒。原因有两个：一是断线重连后，离线消息和实时消息会交叉到达；二是前端在发送时本地插入了消息，推送回来后又插了一次，导致同一条消息出现两遍。

解决方案分两层。第一层，前端消息渲染前按createdAt + id排序，小的在前；第二层，以服务端下发的消息ID为准，前端维护一个已渲染ID集合，重复ID直接忽略。这个处理放在消息预处理函数里统一做，不要在渲染组件里做，否则容易出现并发问题。

5.3 图片发送后不显示的路径兼容问题

聊天里发图片是个高频功能，但这里藏着一个很经典的坑：微信小程序端uni.chooseImage返回的是一个临时文件路径，比如wxfile://tmp_xxx，这个路径只有当前小程序生命周期内有效，刷新之后就会失效。

正确的做法是拿到临时路径后立即上传到云存储，拿到HTTPS永久链接后再发送。我在聊天窗里做了一个强约束：所有图片消息发送前必须经过上传流程，并且上传期间显示进度条，上传失败则禁止发送。前后端校验都加上，避免直接把临时路径存进数据库导致图片显示裂图。

5.4 小程序包体积膨胀太快

功能越加越多，小程序主包体积很容易突破2MB限制。我的心态经历了一个从“猛加功能”到“老老实实分包”的过程。实操上做了三件比较有效的事情：

1. 页面分包：把聊天窗、动态发布、个人设置这类低频页面放到分包里，主包只保留首页、登录和会话列表这几个核心页面。
2. 静态资源外置：图片、图标全部走云端URL，不打包进本地，这一项直接砍掉了几百KB。
3. 组件按需引入：UniApp自带组件库默认全量引入，改成easycom按需加载之后，体积统计数字立刻好看许多。

最后再分享一个个人体会：很多人在做这个类型的项目时，把80%的精力花在写消息收发核心代码上，我却觉得真正的产品壁垒在那些“看不见的地方”——登录断线了怎么办，消息有没有读，新用户来了推给谁。这套系统跑通之后回头复盘，最大的收获不是会写WebSocket，而是建立起了一条完整的“用户从注册到聊天”的转化链路思维。如果你也在做类似的小程序设计，我建议你先从数据库建模开始啃，把用户、标签、会话、消息、动态这几张表的关系吃透再动手敲代码，后面会顺很多。

做校园社交类小程序还有一个容易被低估的点是内容审核。虽然这个项目主要是聊天和动态，但一定不能省掉敏感词过滤和举报机制。我当时用了一个简单的敏感词库加上用户举报接口，虽然增加了一些工作量，却避免了很多后续麻烦。设计系统的时候，多花二十分钟把这类基础安全能力预留好，比上线后再来补要省事得多。