1. 项目定位与需求拆解为什么做考研资源共享平台1.1 考研资料市场的真实痛点每年考研季大量考生面临同一个困扰资料收集比复习本身还累。公共课真题、专业课笔记、名师网课、院校报录比、复试经验贴散落在各个QQ群、百度网盘、公众号和二手交易渠道里你根本不知道哪个版本是完整的、哪个链接是有效的。有些资料明明全公开因为信息差还是有人愿意花几百块去买。做过考研社群的人应该都有体会群里最活跃的永远是求一份XX资料。这个平台的出发点就是要把这些散落的资源聚合起来做一个有审核、有分类、有积分激励的共享社区。目标用户很明确应届考研生、二战脱产备考者、考研机构助教或资料收集爱好者。对考生来说平台解决的是找不到、不可信、不集中三个问题对贡献者来说平台提供一个按贡献获取回报的积分体系对运营者来说后台能完成内容审核、分类维护和用户管理不需要技术团队时刻人工介入。这个项目从技术上看并不复杂但它覆盖了一条很完整的业务链路小程序端是用户入口Spring Boot 服务端负责数据和业务逻辑管理后台负责审核和配置。如果只把它当增删改查练习来做那就浪费了。真正值钱的部分是审核流程、积分策略和文件处理这几个模块的设计这些才是能落地的关键。1.2 功能模块规划整个系统按角色拆成三个端微信小程序端用户、Web管理后台管理员、Spring Boot 服务端API与存储。用户端的功能模块主要包含几个大的方向。资源广场是核心列表页要支持分类筛选、关键字搜索、按热门或最新排序详情页展示资源介绍、封面图、文件大小、下载次数、上传者信息和积分价格下方是收藏和下载按钮。个人中心需要展示我的上传、我的收藏、我的下载记录和积分明细同时包含意见反馈入口。分类模块我建议做两级大类如公共课、专业课、复试调剂小类如高数、英语、政治、408、法硕等等后端用parent_id关联即可。管理后台是我后来单独搭的 Vue3 工程。核心功能是资源审核——后台管理员对待审核资源进行预览、通过或驳回驳回要写原因并回传用户端消息其次是分类管理、用户管理禁用、扣积分、积分规则配置和上传统计。还有一个容易忽略但很重要的模块是资源失效反馈因为网盘链接会过期用户反馈失效后管理员介入替换这个机制能避免平台出现大量死链。1.3 角色权限与业务流程权限设计上我没有做太重的 RBAC因为角色只有三类游客、普通用户、管理员。游客可以浏览资源列表和详情但点击下载时会拉起wx.login登录登录后的用户拥有上传、下载、收藏、评论举报的完整权限管理员通过后台登录不占用小程序端的名额。比较关键的是业务流程这里最值得留意的是资源上架链路。我在设计时把上传和上架拆成了两步用户上传文件后先写入待审核表管理员在后台通过后才进入正式资源库审核不通过的资源状态置为REJECTED用户端能收到一条审核未通过原因xxx的通知。这个流程看起来多了一道手续但对考研类内容非常必要因为涉及版权和版权外的低质量资源混入问题。审核的压力其实没想象中大常见的敏感词和文件类型在提交时先自动过滤一轮管理员只需要处理剩下的每天大概几十条。2. 技术选型解析Spring Boot 3 MyBatis-Plus uni-app 的取舍2.1 服务端为什么选 Spring Boot 3.2 而不是 2.6.x接这个项目的时候我第一件事是定 Spring Boot 版本。网上大量教程还在用 2.3.x 或 2.6.x但说实话新项目直接上 Spring Boot 3.2 更值。Spring Boot 3 基于 Jakarta EE 9最低要求 JDK17好处是长期支持、性能提升、GraalVM 原生镜像支持。虽然 JDK8 生态更保守但考研平台这种中轻量系统根本没有历史包袱没必要守着旧版本。搭配方面持久层我用 MyBatis-Plus 3.5.x原因很简单单表操作几乎不用写 SQLBaseMapper自带的selectPage、selectList足够覆盖绝大多数场景代码生成器能一次性生成 entity、mapper、service、controller省下大量机械劳动。但我的原则是复杂查询还是得手写 XML——比如资源列表的联合查询需要关联分类表、用户表和积分表这种情况用 MyBatis-Plus 的 Wrapper 会写出很别扭的 nested 条件不如直接写 JOIN 来得清晰。有几个版本坑大家可以记一下Spring Boot 3.2 对应 MyBatis-Plus 要用 3.5.5 以上版本否则mybatis-plus-spring-boot3-starter会有兼容问题另外如果你准备部署到低配服务器JDK17 比 JDK8 更吃内存堆内存至少给它 512M。要是手头服务器还是 JDK8 环境又不想升级那就老老实实用 Spring Boot 2.7.18这是2.x最后一个维护版本也能安全运行只是后面升级要花时间。对比项Spring Boot 3.2 JDK17Spring Boot 2.7.18 JDK8支持周期至2026年已进入维护末期内存占用偏高约500M起步相对低适合1G小内存云服务器生态兼容新版starter基本适配老教程多踩坑资料多新项目推荐推荐仅当服务器受限时选2.2 小程序端原生还是 uni-app小程序端我一开始在 uni-app 和原生之间犹豫过。如果你只做微信小程序我建议原生开发理由很直接调试工具成熟、组件性能好、发布审核路径短不会遇到开发者工具里正常、真机白屏这种跨端编译问题。uni-app 的优势是一套代码可以同时出 H5 和 App但考研资源平台的核心场景就只在微信生态里没必要多端分发。不过搜索热词里很多人在问uni-app 微信小程序打包 source size 2612kb exceed max limit 2mb说明不少人是用了 uni-app 才开始遇到包体积问题。后面我会在第5节专门讲这个。原生开发的话页面多用WXML WXSS JS直接写底部 TabBar 用原生组件第二级页面走普通页面栈整体结构清爽对新手也更友好。2.3 文件存储本地磁盘、对象存储还是网盘转存考研资料最大的特点就是文件大、类型杂。一个数学真题合集可能 50MB一套专业课视频几十上百 GB 都很正常。存储方案我前后对比了三种。第一种是直接存服务器本地磁盘。实现最简单文件上传后写进/data/files/目录下载时走 Spring Boot 接口输出流适合个人学习用小流量场景。但它有两个致命问题一是服务器磁盘扩容贵二是服务端读写文件会占带宽和内存并发一高就卡。我测试过5MB 的 PDF 并发下载 50 次Tomcat 线程就被占满了。第二种是接入第三方对象存储比如阿里云 OSS、腾讯云 COS上传后拿到 URL 直接给小程序用。这是最省心的方案但按量付费考研视频动辄上百 G流量费会吓到个人开发者。我算过一笔账如果平台有 200 个视频资源平均每个 2GB每月被下载 100 次流量费大几千块完全顶不住。第三种也是我最终采用的思路核心文件走对象存储大文件以网盘转存方式为主。具体来说上传者把资料传到自己的百度网盘在平台提交分享链接和提取码用户下载时先点击转存到网盘这样服务器只维护链接和元数据不实际保存大文件。平台自身的对象存储只存放小体积的文档类资源真题、笔记、经验贴 PDF。这套方案既控制了成本又保证了核心资源可控是我觉得最贴合考研资源共享场景的做法。3. 服务端核心实现接口设计与数据库建模3.1 数据库表结构设计这个项目的表没有超过 8 张核心是resource、user、category、user_collection、user_download、user_points_log。resource表我设计的字段包括id、title资源标题、description简介、file_url文件地址或网盘链接、extract_code提取码、file_size字节数、file_typepdf/video/note等、cover_url封面、category_id、uploader_id、points所需积分、download_count、status0待审核 1已上架 2已下架 3已驳回、audit_msg审核备注、create_time、update_time、is_deleted。特别注意extract_code这个字段要么设为可空要么默认空字符串因为不是所有资源都需要提取码如果数据库表字段默认 NOT NULL前端提交没有提取码的资源时很容易报错这是个细节坑。user表要保存openid、nickname、avatar_url、phone、points总积分、status账号状态。手机上岛时通过wx.login拿 code服务端调微信接口换 openid这个我在下面的登录小节展开。user_points_log表记录积分变化流水字段有user_id、change_type1上传奖励 2被下载收益 3下载消费 4管理员调整、change_value正负值、remark。积分流水必须设计成只增不改的流水表千万别直接在 user 表上改个数字就完事不然后面对账、处理纠纷时没有任何依据。3.2 登录鉴权wx.login JWT 手机号绑定小程序端登录流程我推荐这样设计用户点击微信一键登录按钮前端调用wx.login获取临时code把 code 传给后端/api/auth/login后端用 code 请求微信接口https://api.weixin.qq.com/sns/jscode2session换回openid和session_key。注意这一步必须在服务端完成绝对不能在小程序端拿 code 去直接调微信接口因为session_key属于敏感信息暴露出去会被中间人利用。拿到 openid 后后端先查 user 表如果 openid 已存在直接签发 JWT 给前端如果不存在自动注册一个新用户默认送 100 积分作为新人奖励然后再签发 JWT。JWT 我设置了 7 天有效期小程序端拿到后存入 storage每次请求在 header 里带Authorization: Bearer token后端用一个拦截器统一解析。这里建议 JWT 的 secret 放到application.yml的环境变量里不要写死在代码中否则一旦源码泄露所有用户的 token 都能被伪造。手机号绑定则走getPhoneNumber按钮。用户点击后微信返回加密的code后端调用getuserphonenumber接口换取真实手机号。这个接口今年调整了几次返回结构最好以官方文档为准但无论如何手机号字段不建议做成注册必填考研用户对隐私比较敏感只在需要接收复试调剂通知场景下引导绑定即可。3.3 文件上传、下载与预览的实现文件上传这块我把小文件和大文件分开处理。小于 10MB 的资源走普通单文件上传接口/api/resource/upload使用 Spring 的MultipartFile接收上传到 OSS 或本地目录后返回file_url。大文件比如几百 MB 的视频上传体验很差我建议对接微信云存储或直接引导用户提供网盘链接避免在小程序里做分片上传的复杂逻辑。下载接口要重点考虑权限校验和计数实时性两个问题。用户在详情页点下载前端携带资源 ID 请求/api/resource/download后端先检查用户积分是否足够、资源是否处于上架状态然后执行扣积分、记录user_download表、给资源download_count 1。最后我们把下载地址返回给前端前端再走wx.downloadFile或复制网盘链接。这里我有一次踩了坑刚开始是后端直接把文件流吐回小程序但大文件容易超时中断后来改成预签名 URL会员用户在有效期内可以直接通过 URL 拉取服务端不再经手文件流压力小了很多。预览功能同样重要。PDF 和图片可以走 WebView 直接预览但要注意微信小程序的业务域名必须在 mp 后台配置且在开发工具里勾选不校验合法域名才能看到效果。视频资源我用的是video组件服务端只要保证文件是 MP4 格式并支持范围请求即可否则拖到进度条会黑屏。3.4 资源检索与积分下载逻辑列表接口GET /api/resource/list我设计的入参是categoryId分类ID、keyword标题模糊搜索、orderBylatest/hot、pageNum、pageSize。实现上用 MyBatis-Plus 的LambdaQueryWrapper拼条件keyword 搜索用like注意如果在 MySQL 里直接like %关键字%会导致索引失效资源量过万之后性能会变慢。更稳妥的方案是引入 Elasticsearch但考研平台初期数据量几千条真的没必要为这个上 ES。我的折中方案是在resource表加一个keyword_index字段上传时把标题、简介、分类名拼接好存进去搜索时用 MySQL 全文索引或者like匹配这个单字段性能能接受。积分逻辑是平台能够持续运转的关键我设计成一套闭环上传一份资源审核通过后上传者获得 20 积分奖励每次被其他用户下载上传者额外获得 10 积分由系统从下载者的消费里分成用户下载资源需要支付该资源标价的积分。为了防止恶意刷积分同一个用户对同一个资源 24 小时内多次重复下载只扣一次积分这个规则我用user_download表的create_time和资源 ID 联合查询来判断并加了唯一索引(user_id, resource_id, date)避免并发下重复扣款。4. 小程序端关键功能落地从 WXML 到组件踩坑4.1 首页资源列表与微信小程序下拉加载首页布局我用了顶部搜索框 横向分类滑动栏 纵向资源卡片列表的经典结构。分类滑动栏直接用scroll-view加scroll-x这比用 swiper 做横滑方案更轻量也不容易触发 setData 的性能问题。资源卡片由封面图、标题、简介、积分和下载量组成封面图统一用 3:4 比例裁剪视觉效果整齐很多。下拉加载和触底加载是微信小程序考察的重点。我第一次实现时写了一个 bug每次触底都多请求一页数据页面不断往下翻但loading状态没有控制好导致重复请求。后来我用了一个标准写法监听onReachBottom时先判断isLoading和hasMore两个状态只有满足条件才发起下一页请求并且请求返回前把isLoading设为true防止重复触发。onPullDownRefresh则重置pageNum1并拉取第一页结束后调用wx.stopPullDownRefresh()关闭动画。注意onReachBottom的触发跟scroll-view的高度很有关系如果页面不是整页滚动而是把列表放在自定义scroll-view里onReachBottom不会触发这时候要用scroll-view的bindscrolltolower事件代替。4.2 详情页、收藏与下载流程详情页数据来源有两种一是从列表页带resourceId过来后请求详情接口二是分享卡片进入时同样带 ID 请求。详情页需要渲染资源简介、文件大小、下载量、上传者头像昵称、积分价格。收藏功能我用user_collection表记录前端在详情页顶部收藏按钮上展示已收藏/未收藏状态后端提供POST /api/resource/collect和DELETE /api/resource/collect两个接口按钮点击后立即切换图标并通过请求结果回滚。这样用户体验好即使请求失败也不会留下错乱的状态。下载流程分两类场景小文件在详情页点击下载后先判断是否登录未登录拉起wx.login流程已登录则请求下载接口成功后再调wx.downloadFile将文件临时保存到本地通过wx.openDocument打开预览。网盘链接型资源则直接弹出引导弹窗用户复制提取码后去网盘转存。这里我要提醒一点小程序wx.downloadFile下载的文件默认在临时目录用户下次进入会失效如果要持久保存必须配合wx.saveFile或wx.getFileSystemManager().saveFile不过saveFile有 10MB 的存储上限大文件还是老老实实引导用户去网盘。4.3 顶部导航栏高度适配与自定义导航栏项目里我把首页做成了自定义导航栏把搜索框嵌在胶囊按钮左边视觉上很像主流内容类 App。但这个自定义导航栏坑非常多核心就是要精确计算状态栏高度和胶囊按钮位置。计算方式如下利用wx.getWindowInfo()获取statusBarHeight状态栏高度再用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的top和height。那么自定义导航栏的高度就是(menuButton.top - statusBarHeight) * 2 menuButton.height左右间距则由menuButton.right与屏幕宽度的差值决定。不同机型差异很大尤其是刘海屏和折叠屏必须在onLoad里动态计算后写入 data再通过styleheight: {{navBarHeight}}px绑定到导航栏容器上。为了适配所有页面我把这段逻辑封装成了一个getNavBarInfo()工具函数放在utils目录下每个需要自定义导航栏的页面都调用一次。另外你还要在app.json里给对应页面配置navigationStyle: custom否则系统自带的导航栏会叠在自定义栏上面看起来就像有两个标题。我当时没配这个字段调试了半天还以为是高度计算错了。4.4 单选框、柱状图等组件的实现细节资源分类筛选页我用到了原生radio-group组件。这里有一个体验优化radio-group默认的选中态样式很丑而且不同平台渲染有差异。我建议不用默认的 radio 小圆圈改用view自绘的标签块。具体实现是给每个分类项绑定一个selected状态点击时更新当前选中项并在标签上增加一个高亮 class。视觉效果统一交互反馈也更符合用户习惯。统计柱状图我用的ec-canvasECharts 小程序版用来展示平台各分类下的资源数量也可以展示用户积分增长趋势。ECharts 在小程序里初始化比较特殊需要在echarts.init(canvas, null, { width, height })前等 canvas 节点渲染完成否则会报 Component is not found 错误。另外柱状图的tooltip在小程序端默认是被 canvas 遮住的建议把tooltip关掉改用点击柱状图后弹窗展示数值这算是性能与体验的折中。5. 部署上线日志与常见问题排查实录5.1 小程序包体积超限从 2MB 到分包加载热词里出现的source size 2612kb exceed max limit 2mb我几乎天天在开发者工具里见到。微信小程序的单包限制是 2MB整个小程序所有分包不超过 16MB主包 分包。我的处理方案很明确主包只放 TabBar 页面、公共组件和工具库分类详情页、资源详情页、个人中心等非首屏页面全部挪进分包在app.json里通过subpackages配置。分包配好后还要配合资源压缩。图片素材压缩到 80% 质量以下能放云存储的尽量不本地打包字体图标改用 iconfont 的 svg 格式不要一整个图标库全引入。另外如果用了uni-app打包时要注意是否引入了没用的插件和组件这也是热词里很多人爆出 2612kb 的直接原因——默认模板自带了大量组件。我把分包和资源清理都做完后主包从 1.8MB 减到了 900KB总算留出余量了。5.2 抓包调试微信小程序请求小程序上线前开发者工具里的网络面板可以满足大部分调试需求但真机环境下的请求问题是工具模拟不出来的这时就要借助抓包工具。Charles 或 Fiddler 都可以我这里用 Charles 为例。抓包小程序请求有一个关键点小程序默认不走系统代理必须开启开发环境不校验合法域名才能被抓包。具体步骤是电脑和手机连同一 Wi-Fi电脑上 Charles 打开 SSL Proxying手机关联代理后微信开发者工具里勾选不校验合法域名再用微信打开小程序开发版页面Charles 里就能看到完整的请求 URL、header 和响应体。如果你发现 HTTPS 请求显示乱码说明需要安装 Charles 的 CA 证书到手机。需要提醒的是这些操作只在开发调试阶段使用正式发布的版本要全部走合法 HTTPS 域名这是微信的强校验规则。5.3 live-player、PDF 预览与域名白名单的几个坑热词里提到 live-player 全屏按钮在 PC 端支持问题。live-player 组件的全屏功能在移动端支持很好但在 PC 端微信小程序里经常不生效表现为点击全屏按钮无响应。官方文档其实写了 PC 端只支持有限 API这种情况我只能做降级处理在 PC 端显示请用移动端查看/下载回放的提示卡片而不是强行适配。做教育类小程序时这种平台差异要提前在设计评审里考虑不要开发完才发现 PC 和移动端行为不一致。PDF 预览的坑也有几个。小程序里wx.openDocument可以直接打开 PDF但前提是下载的文件格式正确且文件名后缀必须匹配。我在这个上面踩过坑临时文件的扩展名是.pdf但实际内容可能是加密 PDF打开时直接黑屏。另外还有一部分用户手机上没有适配的 PDF 查看器openDocument打开后提示无法打开。我的方案是提供在线预览下载备用双入口在线预览失败时给出提示引导下载到本地查看。还有一点域名白名单里不仅要有 API 域名还要有下载文件所在的存储域名否则downloadFile会报 url not in domain list 错误。5.4 多账号池轮换与内容运营建议热词中微信小程序多账号池轮换更多是素材号运营场景不过在内容资源共享平台里要做的是多内容来源而不是利用系统漏洞。我的运营建议是平台内容可以来自多个渠道用户自传、合作机构授权、公开渠道整理的资料每个渠道打上不同的来源标签。这样一方面降低了单一来源的审核压力另一方面也能防止大量同质化内容集中出现。审核上一定要严格涉及版权争议的资源先下架处理审核备注写给用户明确的原因被驳回超过两次的上传账号触发人工复核。这个机制能让平台在合规前提下跑得更稳。我以前在别的项目里见到过多账号轮换上传用来绕过频率限制的操作如果你是个人维护者在收集资料时少量、分批操作没问题但不要把它设计成系统功能风险太高。5.5 一些部署环境参数备忘最后分享一组我实际用的配置参数供大家参考。服务器配置是 2核4G 的云主机CentOS 7 Docker 部署 Spring Boot 3.2 应用内存启动参数-Xms256m -Xmx512mMySQL 8.0 放在宿主机Redis 用来做验证码和热点缓存。小程序端 API 统一走 Nginx 反向代理配置了 HTTPS 证书client_max_body_size设置为 20m不然上传稍大的 PDF 会被 Nginx 拦截。如果你也扛流量不大这套配置足够支撑千人在线量级。我个人在实际操作中的最大体会是这个项目的难点根本不在 Spring Boot 和微信小程序这些技术本身上而是资源审核流程的边界设计、文件存储成本控制、以及小程序平台各种组件限制的适配。做共享类小程序前期多花时间想清楚内容从哪来、审核怎么过、存储怎么不烧钱后期上线就会省很多事。另外数据库表的索引和唯一约束最好建模时就设计好别等数据量上来再改我已经在user_download表上吃过重复数据的大亏。如果你正在做类似的项目建议先把资源分类、积分策略和使用协议这三件事定下来再写第一行代码。