校园吐槽吧这套系统说起来其实是一个很典型的校园轻社区项目。前端用uniapp vue开发跑在微信小程序里后端提供接口学生的核心诉求就是一个字说。食堂难吃要说图书馆占座要说考研教室暖气太干要说。这个项目做完我对“校园社交产品”的理解也改变了不少——论坛不一定要做得多大、多全关键是让用户有地方说话而且说得没有负担。下面我把这套系统的设计思路、前端实现、调试方法、打包上线的完整链路都梳理一遍项目代码不算复杂但坑确实不少尤其是微信小程序独有的那些限制建议先收藏再慢慢看。1. 项目整体解题思路1.1 校园交流论坛到底在解决什么问题校园论坛并不是新物种从以前的BBS时代就存在但传统的学校官方论坛最大的问题就是“太正经”。学生发个吐槽要先考虑实名暴露风险内容还要过审讲话压力一大自然就没有人发言。所以“校园吐槽吧”在设计初期我们内部讨论过无数次最后达成的共识是这不是一个信息效率工具而是一个情绪出口。基于这个定位产品的核心并不是“内容管理”或“信息分类”而是“降低发言门槛”。最直接的手段就是匿名。我们拿了几份学生问卷调查接近70%的人表示“只要匿名就愿意发帖参与讨论”。于是MVP版本的功能模块就变得非常明确匿名发帖、话题广场、点赞、评论、个人中心。复杂的功能比如关注关系、私信、积分等级全部砍掉。1.2 功能模块与核心优先级功能规划阶段我用一张表来管理开发时也严格按优先级执行避免做太多无效功能。功能模块核心能力优先级备注登录授权微信code换token维护登录态P0所有接口的前置条件吐槽广场信息流展示、下拉刷新、分页加载P0首屏体验最关键发帖文本图片、匿名开关、话题标签P0核心内容生产入口互动点赞、评论、收藏P0撑起社区活跃度个人中心我的发帖、我的评论、消息通知P1用户留存闭环管理后台内容审核、帖子删除、敏感词过滤P1过审和运营的底线话题标签也做了但只做了固定的几个分类比如“食堂”“宿舍”“图书馆”“考研”“校园活动”“日常”。不做用户自定义标签原因是避免标签泛滥给后端的推荐和筛选增加没必要的复杂度。1.3 交互和页面结构设计页面结构上底部Tab用了四个广场、发帖、消息、我的。中间的“发帖”按钮做了一个特殊样式视觉上凸出来用户一进来就知道这是个可以“说话”的地方。广场页是核心信息流顶部放话题分类的横向滚动标签下面就是吐槽卡片列表。卡片只展示内容摘要和图片缩略图点击进入详情页再加载完整内容和评论。页面路径规划如下pages/index/index广场信息流pages/publish/publish发帖页pages/message/message消息通知pages/mine/mine个人中心pages/detail/detail吐槽详情与评论这样的结构对小程序来说非常友好页面层级少跳转路径清晰从进入到完成发帖只需要两步。2. 技术选型为什么是uniappvue2.1 原生小程序和uniapp怎么选如果只做一个微信小程序用原生微信小程序语法做当然没问题但实际开发中你会遇到很多难受的点。原生小程序的语法是它自己的一套东西每个页面要写js、wxml、wxss、json四个文件数据更新还要手动this.setData开发体验跟Vue、React相比确实落后不少。最关键的是如果将来想把产品搬到支付宝小程序、百度小程序、抖音小程序或者打包成App原生代码几乎要重写。uniapp最大的价值在于“一套代码多端编译”。它基于Vue语法写起来就是标准的前端工程化思路组件化、生命周期、数据绑定都是熟悉的那套东西。项目中我们主要编译到微信小程序端但调试阶段经常直接编译到H5在浏览器里看效果速度和调试效率都高很多。2.2 Vue2还是Vue3的取舍技术选型时我们纠结过Vue2还是Vue3。当时uniapp对Vue3的支持已经不是Demo级别很多正式项目都在跑。最后选了Vue3的组合式API主要是团队后续技术栈统一到Vue3不想再维护一套旧语法。但这里有一个很重要的建议如果你的团队刚接触uniapp或者需要大量使用插件市场里的第三方组件建议先从Vue2入手。原因很现实——插件市场上大量老组件还停留在Vue2写法拿到Vue3项目里会直接报错改起来成本不低。如果用Vue3组件的写法大概是script setup import { ref } from vue; const page ref(1); const list ref([]); const loading ref(false); async function loadList() { if (loading.value) return; loading.value true; // 请求接口 loading.value false; } /script