1. 为什么我会动手写一个动漫社区而不是套一个现成论坛模板你打开微信开发者工具输入自己的 AppID准备跑一个从 Gitee 拉下来的动漫社区项目结果发现页面还停留在上一个人的版本首页轮播图改了半天都不换——这个问题不是代码有错而是“运行到微信小程序模拟器”后依然读取了旧的小程序ID。我这次要聊的项目代号 _9ln684ti正是一个踩了这一整排坑之后才跑通的微信小程序动漫社区交流系统。这个项目最初的出发点特别朴素漫展散场后同好群里永远在刷“有没有人拼车回市区”“谁拍到那张 cos 返图了”“今晚有人写新番闲聊吗”。这些零散消息没有沉淀过三天就被聊天记录淹没。于是我照着动漫圈子的真实动线把所有功能拆成了四件事发帖子、刷内容、约活动、找同好。说白了一个社区系统真正难的地方不在于代码量而是搞清楚“交流”这个动作发生在哪些场景再去设计对应的页面和接口。1.1 项目代号 _9ln684ti 的由来和真实需求_9ln684ti 原本只是我本地工程文件随手敲出来的临时代号后来懒得改就一直用到了现在。系统做出来以后我发现它的功能边界比一开始设想的收敛得多没有做即时聊天室也没有做复杂的好友关系链而是围绕“内容”来做互动。用户的真实需求不是让你做一个贴吧翻版而是要有一个可以晒同人作品、分类浏览新番讨论、报名漫展线下活动的园地。所以在项目里我把首页设计成信息流而非传统 BBS 版块列表每个帖子带一个主标签比如“同人图”“漫展返图”“求物”“组队拼车”发帖时必须通过单选确定主分类再通过多选补充副标签。这套标签体系看起来简单但是后来做精准筛选和首页分流时省了特别多力气比一些动辄十几个版块的论坛更容易让新用户上手。标题里的“交流系统”也不是空话。帖子的二级评论、点赞、关注和活动报名都围绕同一个对象展开漫展或作品。也就是说用户不是“关注了一个人”而是“关注了一个正在进行的讨论话题”。这种设计比较适合小圈层不会出现普通社交App那种人一多内容就失控的情况。1.2 用 uni-app HBuilderX而不是原生微信小程序选 uni-app 加 HBuilderX纯粹是效率问题。我平时主要写 Vue如果全部用原生微信小程序语法来写社区那一堆页面状态管理、组件复用和生命周期处理会明显拖慢节奏。uni-app 编译到微信小程序后代码运行逻辑虽然多了一层编译但日常开发体验比硬写原生舒服很多尤其是从 H5 端同步调试 UI 时。HBuilderX 跟微信开发者工具的配合方式需要先说清楚。在 HBuilderX 里打开项目后点击“运行到小程序模拟器”它会先编译把产物放到unpackage/dist/dev/mp-weixin然后自动唤起微信开发者工具加载这个目录。很多新手在这步会犯一个错把 HBuilderX 里的项目整个当作微信开发者工具的项目反复导入结果微信开发者工具报了各种模块找不到的错误。正确做法是不要让微信开发者工具直接打开源码根目录而是让 HBuilderX 去负责编译再用“运行”命令让两个工具自动联动。另一个共性问题是“小程序ID还是原来的”。从 Gitee 或 GitHub 拉取别人的 uni-app 项目后源码里的 AppID 并不会自动替换成你的。你需要打开manifest.json在“微信小程序配置”里填入自己的 AppID类似下面这样mp-weixin: { appid: wx1234567890abcdef, setting: { urlCheck: false, es6: true, minified: true } }urlCheck: false只是开发阶段为了绕过域名校验而开的千万别以为上架后也能一直靠这个开关运行。真机预览如果还是提示“不在以下 request 合法域名列表中”那就是这个设置没有变成正式环境配置后面我会在第 6 章重点讲上线前检查。1.3 开始前一定要确认的页面结构和代码管理做社区类小程序我建议一开始就把页面目录分清楚不然后面动辄几十个页面时真的会乱。我这里采用的是四段式结构页面层、组件层、API 层、工具层。页面层主要放这几个首页信息流、发布页、帖子详情、个人中心、活动列表、线下地图、聊天入口。组件层放帖子卡片、评论列表、图片九宫格、自定义顶部导航、自定义 tabBar。API 层统一封装所有后端请求工具层放登录态、图片压缩、蓝牙打印、网络监听这些跨页面逻辑。从 Gitee 克隆项目到本地时还有两个隐性成本第一node_modules一般不进 Git 仓库所以拿到手要先执行依赖安装第二如果原项目用了 uni_modules 插件建议升级插件到匹配当前 HBuilderX 的版本否则经常出现“组件找不到”的诡异报错。我特别推荐把后端接口文档和前端字段名在立项时先对齐一次。动漫社区这种系统帖子、评论、标签、活动各个表之间的关联非常多前端如果晚改一个字段名联调时往往要花好几个晚上排查。所谓“题目难”很多时候不是某个知识点难而是前后端各退半步最后变成模糊地带。2. 社区内容线从发布到信息流再到互动的实现思路社区系统的核心不是用户头像和昵称而是“发出去的内容能不能被看到、能不能产生反馈”。这一章我按一条主链路来聊发布内容、浏览信息流、评论点赞这三件事如果做顺了社区基本就活了。当初设计这个系统时我特意把“发布”放在整个链路最前面因为一个没有发布入口的社区只是一个内容展示页。发布页要考虑的不只是文本框还有图片、分类、原创声明和审核状态一个都不能漏。2.1 发帖页的富文本、图片压缩和分类单选微信小程序里做富文本是一件很别扭的事。它没有网页里的contenteditable也没法直接在textarea里插入图片。所以我没有试图去做一个完整富文本编辑器而是采用“文本加图片列表”的方案正文用textarea收集纯文本表情通过一套以[哈哈]这种短码表示的规则做客户端解析图片单独上传后存在内容数组里。详情页展示时小程序自带的rich-text组件能渲染节点数组这条链路稳几乎不踩坑。图片上传前压缩是必须做的一步。社区用户发的漫展返图一张原图能到七八兆如果每次都原样上传服务器带宽和存储都要报警。我采用 canvas 压缩的常用方案function compressImage(tempFilePath) { return new Promise((resolve, reject) { uni.getImageInfo({ src: tempFilePath, success: (info) { const maxSide 1200; const ratio Math.min(maxSide / info.width, maxSide / info.height, 1); const width Math.floor(info.width * ratio); const height Math.floor(info.height * ratio); const ctx uni.createCanvasContext(compressCanvas); ctx.drawImage(tempFilePath, 0, 0, width, height); ctx.draw(false, () { uni.canvasToTempFilePath({ canvasId: compressCanvas, width, height, destWidth: width, destHeight: height, quality: 0.8, success: (res) resolve(res.tempFilePath), fail: reject, }); }); }, fail: reject, }); }); }压缩宽度上限设为 1200、质量 0.8是我实测下来在清晰度和文件体积之间比较平衡的组合。如果再往下压作品图的线条会明显发虚漫展返图的氛围感也出不来。分类单选我用了小程序radio-group。这里有个容易忽略的坑radio的value必须传字符串不能传数字否则在某些 iOS 基础库版本里会被判定为undefined。我之前因为这个问题发布页选中“同人图”后提交后端收到的一直是旧的默认分类查了半天才发现是类型没转成字符串。2.2 首页信息流的筛选与触底加载首页是社区的门面我采用“顶部标签筛选 下拉刷新 触底分页”的组合。标签筛选的数据直接从已发布的帖子主标签取不用写死这样以后新增分类不需要发新版。列表请求需要明确的参数约定page、pageSize、type、sort。每次请求都返回总数或 hasMore 标志。触底加载的逻辑很简单但容易写错错误集中在重复请求上onReachBottom() { if (this.isLoading || !this.hasMore) return; this.isLoading true; this.page; this.loadPosts().finally(() { this.isLoading false; }); }这段代码的关键是isLoading锁。没有锁时快速上滑会同一时间发出两三个重复请求最后评论区出现大量重复帖子给用户一种“卡了又突然加载很多”的错觉。图片列表的渲染体验也要注意。信息流里的图片必须设置容器宽高否则图片加载过程中滚动位置会一直跳。漫展返图这种强视觉内容我习惯用小卡片统一宽高比比如 4:5然后用image的modeaspectFill裁切这样整体看起来整齐不同作者拍的横图竖图都能稳定展示。如果想在社区里做“自动标签”最靠谱的路径不是在小程序端跑深度学习模型而是把模型放在后端或云函数里。小程序端只负责上传图片后端推理完把标签返回前端把标签渲染成筛选项。端上跑模型看着很酷但模型包体积、耗电和旧手机兼容性都够喝一壶的动漫图片这种复杂视觉内容尤其不适合。2.3 点赞与评论的实时性处理点赞的实时反馈实际做下来是体验和性能的平衡。社区里不需要做全站 WebSocket 推送否则活动报名、私信和通知全部要重新设计。我更推荐“乐观更新”用户点下红心先立刻在前端把数量加一、点亮图标再向服务端发请求失败时回滚。这样用户在多数网速良好场景下感觉不到延迟。点赞操作必须加锁。我用一个likeLock布尔值控制在请求返回前不响应后续点击防止用户手抖连点了十几次数据库里被写入十几条重复记录。后端同样做唯一约束同一用户对同一帖子只能有一条点赞记录。评论结构我保留了两层一级评论是“回复帖子”二级评论是“回复某条评论”。为什么不做无限楼中楼因为楼中楼的深层递归在数据库查询上很难做索引而且移动端展示一深嵌套非常反人类。二级评论在 UI 上用昵称开头后端只多存一个parentId详情页一次请求就能拿到。3. 小程序特有交互的适配记录自定义导航、tabBar 和页面回退微信小程序跟普通 H5 最大的不同在于它有系统级导航、原生 tabBar、右滑返回手势这些“默认能力”。默认能力省事但当你想做个性化社区时每一个默认能力都可能变成瓶颈。我做动漫社区时想达到的效果是顶部是色彩鲜明的动漫主视觉底部是一个中心带凸起“发布”按钮的 tabBar。原生的标题栏和 tabBar 都没法灵活支持这种设计于是只能走自定义。3.1 自定义导航栏高度计算只要页面设置了navigationStyle: custom微信就不再画标题栏。这时所有内容会从屏幕顶部算起如果不在页面顶部避让你的标题文字就会跟状态栏电量、时间叠在一起。导航栏高度的计算我反复用了这个公式const windowInfo uni.getWindowInfo ? uni.getWindowInfo() : uni.getSystemInfoSync(); const menuRect uni.getMenuButtonBoundingClientRect(); const statusBarHeight windowInfo.statusBarHeight || 20; let navBarHeight 44; if (menuRect menuRect.height) { navBarHeight (menuRect.top - statusBarHeight) * 2 menuRect.height; }原理其实很好理解微信小程序右上角