本文还有配套的精品资源点击获取简介基于微信原生开发的诗词类答题小程序开箱即用无需二次开发即可部署上线。内置3000多道精选诗词题目覆盖单选、看图猜诗、诗句填空、文字线索等主流题型每题均含标准注释、白话译文和简明赏析。支持按难度随机组卷或阶梯式闯关逻辑适配不同用户水平。用户体系完整微信一键授权登录每日签到领积分分享至好友或微信群可额外获分积分可在商城兑换道具。社交功能实用实时更新的好友排行榜、答题结果一键分享、内置客服消息入口便于用户反馈。运营能力扎实通过微信模板消息自动推送答题提醒、积分变动通知、周榜更新等后台可灵活配置积分兑换比例、题目权重系数、签到连续天数奖励规则等参数。代码已全面适配最新微信小程序审核规范修复了负分显示异常、授权页重复刷新、价格字段错位等常见问题并新增客服消息组件优化答题动效反馈与排行榜列表加载性能。1. 项目概述这不是一个“玩具demo”而是一套能跑通商业闭环的诗词答题产品我做微信小程序开发快八年了从最早帮社区居委会搭投票工具到后来给连锁书店做线上读书会系统见过太多所谓“诗词类源码”——名字起得响亮点开一看就二十道题、三个页面、连用户登录都靠本地缓存模拟。这次拿到这套「疯狂诗词大会小程序2.0」源码我特意没看文档直接拉进开发者工具里跑了一遍完整流程授权→签到→闯关→错题回顾→积分兑换→分享好友→查看排行榜→收到模板消息提醒……整个链路丝滑得让我有点意外。它不是教学Demo也不是半成品框架而是一个已经过真实小规模上线验证、逻辑自洽、边界清晰、能立刻接入你自有服务器并投入运营的最小可行产品MVP。核心关键词我拎出来讲清楚诗词小程序意味着它不是泛文化答题所有题目、交互、视觉语言都锚定在“唐诗宋词”这个明确认知域微信答题源码强调它是原生WXMLWXSSJS开发不依赖任何第三方UI库或低代码平台可读性高、可控性强、审核通过率有保障积分排行榜不是简单做个数字排序而是把用户行为答题正确率、用时、连续天数、社交关系好友关系链拉取、运营策略积分获取/消耗规则三者耦合在一起的动态系统题库管理重点在“可维护性”——3000题不是硬编码进JS里的字符串数组而是结构化JSON支持按朝代、作者、体裁、难度、是否高频考点等多维标签筛选模板消息这里不是只配个formId就完事而是整套触发时机设计比如用户答对第5题后自动触发“再接再厉”模板周日凌晨4点定时推送“本周诗词达人榜已更新”真正服务于用户留存和活跃。适合谁用如果你是个人开发者想快速上线一个轻量级文化类小程序试水变现它省掉你至少3周的前端基础搭建和题库录入时间如果你是教培机构运营人员想为线下国学班配套一个线上互动工具它内置的“诗句填空自动判卷”“看图猜诗图片懒加载”“赏析内容分段折叠”等功能都是冲着教学场景打磨过的如果你是小型出版社编辑手头有《唐诗三百首详注本》《宋词选译精讲》这类优质内容资源这套源码的题库JSON Schema完全兼容你现有的文本结构只需做一次格式转换就能导入。它解决的不是“能不能做”的问题而是“怎么做才不踩坑”“怎么上线第一天就有用户愿意玩下去”的实操问题。2. 整体架构与设计思路拆解为什么这样搭而不是用uni-app或Taro2.1 技术栈选择原生开发不是守旧而是权衡后的最优解看到“微信原生开发”这几个字很多人第一反应是“太重了”“跨端能力差”。但在这类垂直领域小程序里恰恰是原生给了我们最扎实的控制力。我对比过三种主流方案uni-app/Taro类跨端框架开发效率确实高但诗词类小程序有个致命痛点——图片资源密集且尺寸敏感。看图猜诗模块需要精确控制图片在不同机型上的缩放模式scaleToFill还是aspectFit、加载占位策略骨架屏还是纯色背景、错误兜底图片404时显示哪句诗的关键词。跨端框架的抽象层在这些细节上往往“一刀切”导致iPhone 14 Pro Max上图片完美居中到了华为Mate 50上却偏左10px这种体验在文化类产品里是灾难性的。而原生WXML里你可以为每个image标签单独写styleobject-fit: cover; width: 100%; height: 200rpx;甚至用wx.getSystemInfoSync().model做机型判断后动态调整。云开发CloudBase官方推荐免运维但题库管理后台的灵活性会严重受限。比如你需要让编辑人员在后台勾选“此题适用于小学生组”然后前端答题时自动过滤掉带该标签的题目——云数据库的查询语法虽然支持但一旦涉及多表关联用户答题记录表 题目标签表 班级权限表性能会断崖式下跌。这套源码采用“前端静态题库后端动态配置”的混合模式3000题JSON打包进小程序包首次加载稍慢但后续极速而题目权重、难度系数、是否启用等运营参数走后端API既保证了首屏速度又保留了后台的绝对控制权。原生开发的真实优势在于“审核友好性”微信最近半年对“诱导分享”“过度收集用户信息”“模板消息滥用”的审核极其严格。这套代码里所有敏感操作都有明确注释和开关app.js里wx.getSetting调用前必先检查scope.userInfo是否已授权模板消息发送前强制校验formId有效期7天内分享按钮点击事件里嵌套了wx.showModal二次确认“是否将本次成绩分享至群聊”。这些不是功能亮点而是生存底线。我去年帮一个客户改过一套Taro项目就因为分享回调里少了个e.detail.from menu判断被拒审三次。2.2 功能模块划分以用户动线为轴心拒绝功能堆砌很多源码喜欢罗列“支持XX功能”结果打开一看所有功能都挤在首页一个tab里。这套的设计哲学很朴素用户从打开小程序到离开每一步动作都要有明确目的和即时反馈。我画了个简化版用户旅程图授权登录 → 首页Banner今日签到热门挑战 → 点击“闯关模式” → 选择难度入门/进阶/大师 → 进入答题页单选/填空/看图随机出现 → 提交后立即显示解析获得积分 → 返回首页看到积分余额变化 → 点击“商城”兑换“免错卡” → 使用卡片跳过下一题 → 成绩分享到群聊 → 收到模板消息“您好友张三刚超越了您当前排名#12”每个环节都不是孤立的-签到和闯关强绑定连续签到第3天解锁“进阶模式”第7天解锁“大师模式”把行为激励转化成游戏化成长路径-积分获取与消耗闭环答题正确得基础分用时越短额外加分分享得3分但兑换道具要花10分——数值设计上确保用户必须持续参与才能积累足够积分避免“一次性薅羊毛”-排行榜不是静态榜单它调用的是实时接口/api/rank/friends?timestamp${Date.now()}后端用Redis Sorted Set存储用户分数ZREVRANGE命令天然支持按分数倒序取Top50毫秒级响应。更关键的是它只展示“你的好友”不展示全网用户既保护隐私又激发熟人社交竞争。这种设计背后是成本考量没有为“可能有用”的功能预留接口所有模块都围绕“提升单次答题完成率”和“延长用户生命周期”两个核心指标展开。比如“文字线索题”看似复杂其实只是把一句诗的关键词打乱顺序如“山/月/松/间/照”→“请按正确顺序排列”前端用拖拽组件实现后端判卷只比对字符串数组是否一致开发成本极低但用户感知上“玩法变多了”。2.3 题库结构设计3000道题如何做到“好维护、易扩展、防重复”题库不是数据堆砌而是知识工程。我扒开/data/questions.json看了结构它的设计直击行业痛点{ id: tang_00127, type: single_choice, difficulty: 2, tags: [盛唐, 李白, 五言绝句, 边塞诗], content: 下列诗句中哪一句出自《静夜思》, options: [ {text: 床前明月光疑是地上霜, is_correct: true}, {text: 举头望明月低头思故乡, is_correct: false}, {text: 小时不识月呼作白玉盘, is_correct: false}, {text: 我寄愁心与明月随君直到夜郎西, is_correct: false} ], analysis: { annotation: 床井栏非卧具疑好像。, translation: 床前洒满明亮的月光看起来像是地上结了一层白霜。, appreciation: 以朴素语言勾勒出游子深夜望月怀乡的经典意境疑字传神写出恍惚之感。 }, weight: 1.2 }这个Schema解决了三个实际问题-防重复id字段采用[朝代缩写]_[5位数字]格式如tang_00127编辑新增题目时只要查最大ID1即可杜绝人工编号冲突-易筛选tags数组支持多标签后台管理界面可以用Ant Design的Select组件多选过滤比如筛选“标签含‘杜甫’且难度≥3”的题目生成期末考卷-可演进weight字段是题目权重系数当前用于计算积分基础分×权重未来如果要做AI出题可以把它作为LSTM模型的输入特征之一预测用户答对该题的概率。更值得说的是题干生成逻辑。像“看图猜诗”题型源码里并没有真的存3000张图而是用content字段描述画面如“水墨风格远山叠嶂一叶扁舟泊于江心岸边有垂柳”前端调用/api/image/generate接口后端用Stable Diffusion API根据描述生成图片并返回CDN地址。这样做的好处是题库JSON体积控制在2MB以内微信限制主包≤2MB图片按需加载且未来更换画风比如从水墨改成工笔只需改后端提示词无需重录题库。3. 核心细节解析与实操要点那些文档里不会写的“脏活累活”3.1 授权登录与用户体系为什么不用unionId而坚持用openId微信登录方案常被误解。很多教程说“必须用unionId做唯一标识”但在这类诗词小程序里这是个危险建议。原因很简单unionId需要用户关注公众号或绑定开放平台账号而我们的目标用户是泛诗词爱好者不是公众号粉丝。强行要求关注首屏跳出率会飙升30%以上。这套源码采用“openId 自定义登录态”双保险- 前端调用wx.login()获取code传给后端/api/login接口- 后端用code换取openId注意不换unionId同时生成一个64位随机字符串session_key存入Redis过期时间2小时- 前端收到session_key后后续所有请求都在header里带上Authorization: Bearer ${session_key}- 用户信息昵称、头像通过wx.getUserProfile()在需要时主动拉取而非首次授权就强制获取。提示wx.getUserProfile()在iOS 16.4之后必须配合button组件使用源码里/pages/auth/index.wxml的按钮写法是html button open-typegetUserProfile bindgetuserinfoonGetUserInfo classauth-btn 授权获取昵称头像 /button如果你删掉这个button直接在onLoad里调wx.getUserProfile()iOS用户会看到空白页——这是无数人踩过的坑。3.2 积分商城的防刷机制一道数学题背后的风控逻辑积分商城表面是“10分换一张免错卡”实则藏着三重风控-时间维度同一用户24小时内最多兑换3次Redis key设为user:${openId}:exchange_count每次兑换后INCR并EXPIRE 86400-行为维度兑换前校验用户最近7天答题总次数是否≥10次防止新号注册就刷商城SQL语句是SELECT COUNT(*) FROM user_answers WHERE user_id ? AND created_at DATE_SUB(NOW(), INTERVAL 7 DAY)-设备维度前端提交兑换请求时携带wx.getSystemInfoSync().deviceId需用户授权后端比对历史设备列表若新设备首次兑换强制要求完成一次答题才能领取。最精妙的是“免错卡”使用逻辑它不是简单标记“本题跳过”而是生成一个临时token答题页提交时携带该token后端判卷接口/api/answer/submit会优先校验token有效性有效则直接返回{correct: true, score: 0}不计分但算答对无效则走正常判卷流程。这样设计的好处是——即使用户F12篡改前端代码把score改成100后端依然只给0分因为积分发放逻辑在服务端闭环。3.3 模板消息的触发策略不是“能发就发”而是“该发才发”模板消息被滥用是小程序被封的高危操作。这套源码的触发规则非常克制-答题提醒仅对“昨日未答题用户”发送且每天限1条模板IDAT001内容固定为“【疯狂诗词大会】您有1道待答题目点击继续闯关”-积分变动仅当单次变动≥5分时触发避免签到得1分就发消息骚扰模板IDAT002内容含具体变动值“3分”或“-10分”-排行榜更新每周日凌晨4点定时任务执行只推送给“上周排名有变动的用户”且只显示“您上升了2名”这类正向激励文案。注意所有模板消息发送前后端必须校验formId是否在7天有效期内。源码里/utils/template.js的校验逻辑是javascript const now Date.now(); const form await db.collection(form_ids).where({ openId, used: false, expireAt: db.command.gt(now) }).limit(1).get(); if (!form.data.length) throw new Error(无可用formId);更关键的是formId必须来自用户真实交互行为如button点击、input失焦不能用wx.navigateTo等非交互API获取否则微信会判定为“非法收集”。3.4 实时排行榜的性能优化从卡顿到毫秒响应的实战改造最初版本的排行榜接口/api/rank/friends在测试时1000用户并发下响应时间高达2.3秒。我们做了三步改造1.数据预计算每天凌晨3点后台脚本遍历所有用户计算其“近7天平均答题分”写入Redis Hashrank:weekly:{openId}字段为score2.关系预加载用户首次进入排行榜页时前端调用/api/friends/list后端用wx.cloud.callFunction批量拉取该用户所有好友的openId存入Redis Setuser:${openId}:friends3.聚合查询排行榜接口不再实时查库而是执行ZUNIONSTORE rank:temp ${openId} friends:${openId}合并用户自身分数与好友分数再ZREVRANGE rank:temp 0 49 WITHSCORES取Top50。最终压测结果QPS从87提升到1200P99延迟稳定在86ms。这背后是典型的“空间换时间”思想——用Redis内存空间存储预计算结果换取极致的查询速度。对于诗词类小程序用户对排行榜的刷新耐心通常不超过1.5秒超过这个阈值30%用户会直接退出。4. 实操过程与核心环节实现从零部署到上线的完整流水线4.1 环境准备与代码初始化避开Node版本陷阱部署前务必确认你的Node.js版本。这套源码基于微信开发者工具v1.05.2307070开发要求Node.js ≥ 16.14.0因用到了fs.promises.rm。我见过太多人卡在第一步用nvm装了Node 18但微信开发者工具默认调用系统PATH里的Node 14导致npm install报错ERR_UNSUPPORTED_ESM_URL_SCHEME。标准初始化流程# 1. 克隆仓库注意去掉目录名里的空格和中文 git clone https://github.com/xxx/BtySpTjc7KqgqyhbfGmc-master-cf12bba934551706f52b2fcf73b6da09c02809bc.git poetry-miniapp # 2. 进入目录安装依赖不要用cnpm微信云函数对cnpm的symlink处理有bug cd poetry-miniapp npm install # 3. 修改项目配置关键 # 编辑 project.config.json替换 appid 为你自己的小程序AppID # 编辑 app.js修改 cloudID 为你云开发环境ID如果不用云开发注释掉 wx.cloud.init() # 4. 启动本地服务用于调试后端API cd server # 这是Node.js后端目录 npm install npm run dev # 监听 localhost:3000提示wxapp_web_preview.py是个隐藏彩蛋——它是个Python脚本运行后会在本地启动一个HTTP服务把小程序前端代码转成H5页面http://localhost:8000方便非微信环境快速预览UI。但注意H5版不支持微信授权、模板消息等原生能力仅用于UI走查。4.2 题库导入与管理JSON格式校验的自动化脚本3000题手动录入不现实源码提供了/scripts/import_questions.py脚本。使用前需准备CSV文件字段必须严格对应id,type,difficulty,tags,content,options,analysis_annotation,analysis_translation,analysis_appreciation tang_00127,single_choice,2,盛唐,李白,下列诗句中...,[A选项,B选项],...,...,...脚本执行逻辑1. 读取CSV逐行解析2. 对options字段用json.loads()反序列化确保是合法JSON数组3. 对tags字段用,分割后去重生成标准数组4. 生成最终JSON对象写入/data/questions.json5. 最后调用npm run build:questions该脚本会- 检查所有题目id是否唯一用Set去重- 验证difficulty是否为1/2/3- 确保single_choice题型的options长度≥2且≤4- 输出报告“共导入2987题发现13题格式错误已跳过”。实操心得我第一次运行时因CSV里有个字段含英文逗号如盛唐, 李白导致tags解析成[盛唐, 李白]多出一个空格。后来在脚本里加了strip()处理这个细节文档里根本不会提但线上真会出问题。4.3 后台管理系统的部署用Docker一键启停后台管理系统是Vue 3 Element Plus开发部署极其简单# 进入后台目录 cd admin # 安装依赖 npm install # 修改配置重点 # 编辑 src/config/index.js替换 baseURL 为你的后端域名如 https://api.poetry.com # 替换 appId 为你小程序AppID用于微信JS-SDK签名 # 构建生产包 npm run build # 用Docker部署推荐避免环境差异 docker build -t poetry-admin . docker run -d -p 8080:80 -v $(pwd)/dist:/usr/share/nginx/html:ro --name poetry-admin poetry-admin访问http://your-server-ip:8080即可进入后台。默认账号密码在/admin/src/config/index.js里写着admin / Poetry2024首次登录后必须修改。后台核心功能截图-题库管理表格支持按tags多选过滤点击“导出Excel”生成带格式的Word文档含诗句原文注释赏析供老师打印讲义-积分配置滑块调节“签到基础分”1~5分、“分享奖励分”1~10分实时看到公式预览“连续签到N天第N天得分为1 (N-1)*0.5分”-模板消息管理上传模板消息截图微信要求系统自动提取模板ID和占位符填入{{keyword1.DATA}}等字段。4.4 微信审核避坑指南那些让你被拒三次的细节我帮客户提审这套代码时总结出微信审核员最关注的5个雷区| 雷区 | 表现 | 源码修复方案 ||------|------|-------------||诱导分享| “分享到群聊得10分”按钮旁无说明文字 | 在button下方加灰色小字“分享成绩至微信群可获额外积分每日限1次” ||价格显示异常| 商城页面“10分”显示为“10.00分” |utils/format.js里增加formatScore(score) { return Math.round(score) }所有积分显示调用此方法 ||负分提示| 用户答错扣分后积分显示“-5分”引发焦虑 | 前端逻辑改为积分最低为0扣分时显示“积分不足无法扣除”并禁用扣分按钮 ||授权页重复刷新| 用户拒绝授权后页面无限重定向 |app.js里onLaunch中增加if (!wx.getStorageSync(authed)) { wx.redirectTo({url: /pages/auth/index}) }且/pages/auth/index.js的onShow里加if (wx.getStorageSync(authed)) wx.switchTab({url: /pages/index/index})||客服消息入口不明显| 只在“我的”页面底部有个小图标 | 在首页右下角固定悬浮button open-typecontact classcontact-btn/button符合微信“随时可触达”原则 |最后一次提审从提交到过审仅用17小时——因为所有细节都提前打磨好了。5. 常见问题与排查技巧实录真实踩坑现场还原5.1 问题速查表高频故障与根因定位现象可能原因排查步骤解决方案首页白屏控制台报Cannot find module ./data/questions.json小程序包体积超2MBquestions.json被微信自动剔除1. 运行npm run build:analyze生成体积分析报告2. 查看/data/questions.json大小用npm run split:questions脚本将题库拆分为10个JSON文件questions_01.json~questions_10.json前端按需动态引入排行榜始终显示“暂无好友”用户未开启“添加好友”权限或好友未使用过小程序1. 调用wx.getFriendCloudStorage检查返回数据2. 查看Redis里user:${openId}:friends是否存在在“我的”页面增加引导文案“邀请3位好友一起玩立即解锁好友排行榜”模板消息发送失败日志显示invalid formIdformId已被使用或过期或非用户主动触发1. 检查发送消息的button是否带open-typeformSubmit2. 查看Redis里form_ids集合中该formId的used字段在/pages/result/index.js的分享成功回调里增加wx.requestSubscribeMessage二次申请仅iOS需要看图猜诗图片加载极慢后端Stable Diffusion API响应超时1.curl -v https://api.poetry.com/api/image/generate测试2. 查看Nginx access.log中该URL的耗时在server/controllers/image.js里增加超时降级if (timeout) return res.send({url: /static/default_poem.jpg})积分商城兑换后前端余额未更新前端未监听wx.onSocketMessage或WebSocket连接中断1. 在app.js里全局监听wx.onSocketMessage2. 检查/socket接口是否返回{type:balance_update,data:120}在/pages/mall/index.js里增加wx.onSocketMessage(data { if(data.typebalance_update) this.setData({balance:data.data}) })5.2 独家避坑技巧那些让项目多活3个月的经验题库热更新技巧微信不允许小程序运行时下载新JSON但我们用了一个取巧办法——把题库放在云存储如腾讯云COS前端启动时wx.downloadFile拉取最新版存入wx.setStorage下次启动优先读本地缓存。/utils/question-loader.js里封装了完整逻辑包含MD5校验防止下载中断导致JSON损坏。排行榜作弊防护有用户用Postman伪造请求刷分。我们在/api/answer/submit接口里加了设备指纹采集wx.getSystemInfoSync().model wx.getNetworkTypeSync() Date.now().toString().slice(-6)拼接后MD5存入Redisdevice:fingerprint:${md5}同一指纹10分钟内最多提交5次。这个指纹字符串前端不暴露只在服务端生成黑客无法逆向。模板消息保底方案微信模板消息送达率约85%为防重要通知丢失我们在后端加了短信兜底。当检测到某用户连续3次模板消息发送失败Redis里fail_count:${openId}≥3自动触发阿里云短信API发送内容“【诗词大会】您的周榜已更新点击查看→ [小程序码链接]”。短信费用由运营预算承担但用户留存率提升了12%。性能监控埋点在app.js的onLaunch里插入wx.reportAnalytics(app_start, {time: Date.now()})在/pages/index/index.js的onLoad里埋点wx.reportAnalytics(home_load, {duration: performance.now() - appStartTime})。这些数据接入微信数据分析后台能直观看到“首页加载3秒”的用户流失率高达47%从而驱动我们优化图片懒加载策略。最后分享一个小技巧如果你想快速验证某个功能是否生效不必每次都扫码预览。在开发者工具里点击右上角“详情”→“本地设置”勾选“不校验合法域名”然后在project.config.json里把request域名改成localhost:3000这样所有API请求都走本地后端调试效率提升5倍。当然上线前必须取消勾选并恢复正式域名。我在实际部署中发现最影响用户体验的从来不是技术多炫酷而是“签到按钮在哪里”“分享后有没有反馈”“积分花了能不能马上看到余额变化”这些细节。这套源码的价值正在于它把所有这些细节都打磨成了肌肉记忆级别的操作规范。当你把注意力从“怎么实现”转移到“用户怎么感受”上时一个真正能留住人的诗词小程序才算真正诞生。本文还有配套的精品资源点击获取简介基于微信原生开发的诗词类答题小程序开箱即用无需二次开发即可部署上线。内置3000多道精选诗词题目覆盖单选、看图猜诗、诗句填空、文字线索等主流题型每题均含标准注释、白话译文和简明赏析。支持按难度随机组卷或阶梯式闯关逻辑适配不同用户水平。用户体系完整微信一键授权登录每日签到领积分分享至好友或微信群可额外获分积分可在商城兑换道具。社交功能实用实时更新的好友排行榜、答题结果一键分享、内置客服消息入口便于用户反馈。运营能力扎实通过微信模板消息自动推送答题提醒、积分变动通知、周榜更新等后台可灵活配置积分兑换比例、题目权重系数、签到连续天数奖励规则等参数。代码已全面适配最新微信小程序审核规范修复了负分显示异常、授权页重复刷新、价格字段错位等常见问题并新增客服消息组件优化答题动效反馈与排行榜列表加载性能。本文还有配套的精品资源点击获取
微信诗词答题小程序源码｜3000+题库+多题型+积分商城+实时排行榜+模板消息推送
发布时间：2026/6/6 0:06:27
本文还有配套的精品资源点击获取简介基于微信原生开发的诗词类答题小程序开箱即用无需二次开发即可部署上线。内置3000多道精选诗词题目覆盖单选、看图猜诗、诗句填空、文字线索等主流题型每题均含标准注释、白话译文和简明赏析。支持按难度随机组卷或阶梯式闯关逻辑适配不同用户水平。用户体系完整微信一键授权登录每日签到领积分分享至好友或微信群可额外获分积分可在商城兑换道具。社交功能实用实时更新的好友排行榜、答题结果一键分享、内置客服消息入口便于用户反馈。运营能力扎实通过微信模板消息自动推送答题提醒、积分变动通知、周榜更新等后台可灵活配置积分兑换比例、题目权重系数、签到连续天数奖励规则等参数。代码已全面适配最新微信小程序审核规范修复了负分显示异常、授权页重复刷新、价格字段错位等常见问题并新增客服消息组件优化答题动效反馈与排行榜列表加载性能。1. 项目概述这不是一个“玩具demo”而是一套能跑通商业闭环的诗词答题产品我做微信小程序开发快八年了从最早帮社区居委会搭投票工具到后来给连锁书店做线上读书会系统见过太多所谓“诗词类源码”——名字起得响亮点开一看就二十道题、三个页面、连用户登录都靠本地缓存模拟。这次拿到这套「疯狂诗词大会小程序2.0」源码我特意没看文档直接拉进开发者工具里跑了一遍完整流程授权→签到→闯关→错题回顾→积分兑换→分享好友→查看排行榜→收到模板消息提醒……整个链路丝滑得让我有点意外。它不是教学Demo也不是半成品框架而是一个已经过真实小规模上线验证、逻辑自洽、边界清晰、能立刻接入你自有服务器并投入运营的最小可行产品MVP。核心关键词我拎出来讲清楚诗词小程序意味着它不是泛文化答题所有题目、交互、视觉语言都锚定在“唐诗宋词”这个明确认知域微信答题源码强调它是原生WXMLWXSSJS开发不依赖任何第三方UI库或低代码平台可读性高、可控性强、审核通过率有保障积分排行榜不是简单做个数字排序而是把用户行为答题正确率、用时、连续天数、社交关系好友关系链拉取、运营策略积分获取/消耗规则三者耦合在一起的动态系统题库管理重点在“可维护性”——3000题不是硬编码进JS里的字符串数组而是结构化JSON支持按朝代、作者、体裁、难度、是否高频考点等多维标签筛选模板消息这里不是只配个formId就完事而是整套触发时机设计比如用户答对第5题后自动触发“再接再厉”模板周日凌晨4点定时推送“本周诗词达人榜已更新”真正服务于用户留存和活跃。适合谁用如果你是个人开发者想快速上线一个轻量级文化类小程序试水变现它省掉你至少3周的前端基础搭建和题库录入时间如果你是教培机构运营人员想为线下国学班配套一个线上互动工具它内置的“诗句填空自动判卷”“看图猜诗图片懒加载”“赏析内容分段折叠”等功能都是冲着教学场景打磨过的如果你是小型出版社编辑手头有《唐诗三百首详注本》《宋词选译精讲》这类优质内容资源这套源码的题库JSON Schema完全兼容你现有的文本结构只需做一次格式转换就能导入。它解决的不是“能不能做”的问题而是“怎么做才不踩坑”“怎么上线第一天就有用户愿意玩下去”的实操问题。2. 整体架构与设计思路拆解为什么这样搭而不是用uni-app或Taro2.1 技术栈选择原生开发不是守旧而是权衡后的最优解看到“微信原生开发”这几个字很多人第一反应是“太重了”“跨端能力差”。但在这类垂直领域小程序里恰恰是原生给了我们最扎实的控制力。我对比过三种主流方案uni-app/Taro类跨端框架开发效率确实高但诗词类小程序有个致命痛点——图片资源密集且尺寸敏感。看图猜诗模块需要精确控制图片在不同机型上的缩放模式scaleToFill还是aspectFit、加载占位策略骨架屏还是纯色背景、错误兜底图片404时显示哪句诗的关键词。跨端框架的抽象层在这些细节上往往“一刀切”导致iPhone 14 Pro Max上图片完美居中到了华为Mate 50上却偏左10px这种体验在文化类产品里是灾难性的。而原生WXML里你可以为每个image标签单独写styleobject-fit: cover; width: 100%; height: 200rpx;甚至用wx.getSystemInfoSync().model做机型判断后动态调整。云开发CloudBase官方推荐免运维但题库管理后台的灵活性会严重受限。比如你需要让编辑人员在后台勾选“此题适用于小学生组”然后前端答题时自动过滤掉带该标签的题目——云数据库的查询语法虽然支持但一旦涉及多表关联用户答题记录表 题目标签表 班级权限表性能会断崖式下跌。这套源码采用“前端静态题库后端动态配置”的混合模式3000题JSON打包进小程序包首次加载稍慢但后续极速而题目权重、难度系数、是否启用等运营参数走后端API既保证了首屏速度又保留了后台的绝对控制权。原生开发的真实优势在于“审核友好性”微信最近半年对“诱导分享”“过度收集用户信息”“模板消息滥用”的审核极其严格。这套代码里所有敏感操作都有明确注释和开关app.js里wx.getSetting调用前必先检查scope.userInfo是否已授权模板消息发送前强制校验formId有效期7天内分享按钮点击事件里嵌套了wx.showModal二次确认“是否将本次成绩分享至群聊”。这些不是功能亮点而是生存底线。我去年帮一个客户改过一套Taro项目就因为分享回调里少了个e.detail.from menu判断被拒审三次。2.2 功能模块划分以用户动线为轴心拒绝功能堆砌很多源码喜欢罗列“支持XX功能”结果打开一看所有功能都挤在首页一个tab里。这套的设计哲学很朴素用户从打开小程序到离开每一步动作都要有明确目的和即时反馈。我画了个简化版用户旅程图授权登录 → 首页Banner今日签到热门挑战 → 点击“闯关模式” → 选择难度入门/进阶/大师 → 进入答题页单选/填空/看图随机出现 → 提交后立即显示解析获得积分 → 返回首页看到积分余额变化 → 点击“商城”兑换“免错卡” → 使用卡片跳过下一题 → 成绩分享到群聊 → 收到模板消息“您好友张三刚超越了您当前排名#12”每个环节都不是孤立的-签到和闯关强绑定连续签到第3天解锁“进阶模式”第7天解锁“大师模式”把行为激励转化成游戏化成长路径-积分获取与消耗闭环答题正确得基础分用时越短额外加分分享得3分但兑换道具要花10分——数值设计上确保用户必须持续参与才能积累足够积分避免“一次性薅羊毛”-排行榜不是静态榜单它调用的是实时接口/api/rank/friends?timestamp${Date.now()}后端用Redis Sorted Set存储用户分数ZREVRANGE命令天然支持按分数倒序取Top50毫秒级响应。更关键的是它只展示“你的好友”不展示全网用户既保护隐私又激发熟人社交竞争。这种设计背后是成本考量没有为“可能有用”的功能预留接口所有模块都围绕“提升单次答题完成率”和“延长用户生命周期”两个核心指标展开。比如“文字线索题”看似复杂其实只是把一句诗的关键词打乱顺序如“山/月/松/间/照”→“请按正确顺序排列”前端用拖拽组件实现后端判卷只比对字符串数组是否一致开发成本极低但用户感知上“玩法变多了”。2.3 题库结构设计3000道题如何做到“好维护、易扩展、防重复”题库不是数据堆砌而是知识工程。我扒开/data/questions.json看了结构它的设计直击行业痛点{ id: tang_00127, type: single_choice, difficulty: 2, tags: [盛唐, 李白, 五言绝句, 边塞诗], content: 下列诗句中哪一句出自《静夜思》, options: [ {text: 床前明月光疑是地上霜, is_correct: true}, {text: 举头望明月低头思故乡, is_correct: false}, {text: 小时不识月呼作白玉盘, is_correct: false}, {text: 我寄愁心与明月随君直到夜郎西, is_correct: false} ], analysis: { annotation: 床井栏非卧具疑好像。, translation: 床前洒满明亮的月光看起来像是地上结了一层白霜。, appreciation: 以朴素语言勾勒出游子深夜望月怀乡的经典意境疑字传神写出恍惚之感。 }, weight: 1.2 }这个Schema解决了三个实际问题-防重复id字段采用[朝代缩写]_[5位数字]格式如tang_00127编辑新增题目时只要查最大ID1即可杜绝人工编号冲突-易筛选tags数组支持多标签后台管理界面可以用Ant Design的Select组件多选过滤比如筛选“标签含‘杜甫’且难度≥3”的题目生成期末考卷-可演进weight字段是题目权重系数当前用于计算积分基础分×权重未来如果要做AI出题可以把它作为LSTM模型的输入特征之一预测用户答对该题的概率。更值得说的是题干生成逻辑。像“看图猜诗”题型源码里并没有真的存3000张图而是用content字段描述画面如“水墨风格远山叠嶂一叶扁舟泊于江心岸边有垂柳”前端调用/api/image/generate接口后端用Stable Diffusion API根据描述生成图片并返回CDN地址。这样做的好处是题库JSON体积控制在2MB以内微信限制主包≤2MB图片按需加载且未来更换画风比如从水墨改成工笔只需改后端提示词无需重录题库。3. 核心细节解析与实操要点那些文档里不会写的“脏活累活”3.1 授权登录与用户体系为什么不用unionId而坚持用openId微信登录方案常被误解。很多教程说“必须用unionId做唯一标识”但在这类诗词小程序里这是个危险建议。原因很简单unionId需要用户关注公众号或绑定开放平台账号而我们的目标用户是泛诗词爱好者不是公众号粉丝。强行要求关注首屏跳出率会飙升30%以上。这套源码采用“openId 自定义登录态”双保险- 前端调用wx.login()获取code传给后端/api/login接口- 后端用code换取openId注意不换unionId同时生成一个64位随机字符串session_key存入Redis过期时间2小时- 前端收到session_key后后续所有请求都在header里带上Authorization: Bearer ${session_key}- 用户信息昵称、头像通过wx.getUserProfile()在需要时主动拉取而非首次授权就强制获取。提示wx.getUserProfile()在iOS 16.4之后必须配合button组件使用源码里/pages/auth/index.wxml的按钮写法是html button open-typegetUserProfile bindgetuserinfoonGetUserInfo classauth-btn 授权获取昵称头像 /button如果你删掉这个button直接在onLoad里调wx.getUserProfile()iOS用户会看到空白页——这是无数人踩过的坑。3.2 积分商城的防刷机制一道数学题背后的风控逻辑积分商城表面是“10分换一张免错卡”实则藏着三重风控-时间维度同一用户24小时内最多兑换3次Redis key设为user:${openId}:exchange_count每次兑换后INCR并EXPIRE 86400-行为维度兑换前校验用户最近7天答题总次数是否≥10次防止新号注册就刷商城SQL语句是SELECT COUNT(*) FROM user_answers WHERE user_id ? AND created_at DATE_SUB(NOW(), INTERVAL 7 DAY)-设备维度前端提交兑换请求时携带wx.getSystemInfoSync().deviceId需用户授权后端比对历史设备列表若新设备首次兑换强制要求完成一次答题才能领取。最精妙的是“免错卡”使用逻辑它不是简单标记“本题跳过”而是生成一个临时token答题页提交时携带该token后端判卷接口/api/answer/submit会优先校验token有效性有效则直接返回{correct: true, score: 0}不计分但算答对无效则走正常判卷流程。这样设计的好处是——即使用户F12篡改前端代码把score改成100后端依然只给0分因为积分发放逻辑在服务端闭环。3.3 模板消息的触发策略不是“能发就发”而是“该发才发”模板消息被滥用是小程序被封的高危操作。这套源码的触发规则非常克制-答题提醒仅对“昨日未答题用户”发送且每天限1条模板IDAT001内容固定为“【疯狂诗词大会】您有1道待答题目点击继续闯关”-积分变动仅当单次变动≥5分时触发避免签到得1分就发消息骚扰模板IDAT002内容含具体变动值“3分”或“-10分”-排行榜更新每周日凌晨4点定时任务执行只推送给“上周排名有变动的用户”且只显示“您上升了2名”这类正向激励文案。注意所有模板消息发送前后端必须校验formId是否在7天有效期内。源码里/utils/template.js的校验逻辑是javascript const now Date.now(); const form await db.collection(form_ids).where({ openId, used: false, expireAt: db.command.gt(now) }).limit(1).get(); if (!form.data.length) throw new Error(无可用formId);更关键的是formId必须来自用户真实交互行为如button点击、input失焦不能用wx.navigateTo等非交互API获取否则微信会判定为“非法收集”。3.4 实时排行榜的性能优化从卡顿到毫秒响应的实战改造最初版本的排行榜接口/api/rank/friends在测试时1000用户并发下响应时间高达2.3秒。我们做了三步改造1.数据预计算每天凌晨3点后台脚本遍历所有用户计算其“近7天平均答题分”写入Redis Hashrank:weekly:{openId}字段为score2.关系预加载用户首次进入排行榜页时前端调用/api/friends/list后端用wx.cloud.callFunction批量拉取该用户所有好友的openId存入Redis Setuser:${openId}:friends3.聚合查询排行榜接口不再实时查库而是执行ZUNIONSTORE rank:temp ${openId} friends:${openId}合并用户自身分数与好友分数再ZREVRANGE rank:temp 0 49 WITHSCORES取Top50。最终压测结果QPS从87提升到1200P99延迟稳定在86ms。这背后是典型的“空间换时间”思想——用Redis内存空间存储预计算结果换取极致的查询速度。对于诗词类小程序用户对排行榜的刷新耐心通常不超过1.5秒超过这个阈值30%用户会直接退出。4. 实操过程与核心环节实现从零部署到上线的完整流水线4.1 环境准备与代码初始化避开Node版本陷阱部署前务必确认你的Node.js版本。这套源码基于微信开发者工具v1.05.2307070开发要求Node.js ≥ 16.14.0因用到了fs.promises.rm。我见过太多人卡在第一步用nvm装了Node 18但微信开发者工具默认调用系统PATH里的Node 14导致npm install报错ERR_UNSUPPORTED_ESM_URL_SCHEME。标准初始化流程# 1. 克隆仓库注意去掉目录名里的空格和中文 git clone https://github.com/xxx/BtySpTjc7KqgqyhbfGmc-master-cf12bba934551706f52b2fcf73b6da09c02809bc.git poetry-miniapp # 2. 进入目录安装依赖不要用cnpm微信云函数对cnpm的symlink处理有bug cd poetry-miniapp npm install # 3. 修改项目配置关键 # 编辑 project.config.json替换 appid 为你自己的小程序AppID # 编辑 app.js修改 cloudID 为你云开发环境ID如果不用云开发注释掉 wx.cloud.init() # 4. 启动本地服务用于调试后端API cd server # 这是Node.js后端目录 npm install npm run dev # 监听 localhost:3000提示wxapp_web_preview.py是个隐藏彩蛋——它是个Python脚本运行后会在本地启动一个HTTP服务把小程序前端代码转成H5页面http://localhost:8000方便非微信环境快速预览UI。但注意H5版不支持微信授权、模板消息等原生能力仅用于UI走查。4.2 题库导入与管理JSON格式校验的自动化脚本3000题手动录入不现实源码提供了/scripts/import_questions.py脚本。使用前需准备CSV文件字段必须严格对应id,type,difficulty,tags,content,options,analysis_annotation,analysis_translation,analysis_appreciation tang_00127,single_choice,2,盛唐,李白,下列诗句中...,[A选项,B选项],...,...,...脚本执行逻辑1. 读取CSV逐行解析2. 对options字段用json.loads()反序列化确保是合法JSON数组3. 对tags字段用,分割后去重生成标准数组4. 生成最终JSON对象写入/data/questions.json5. 最后调用npm run build:questions该脚本会- 检查所有题目id是否唯一用Set去重- 验证difficulty是否为1/2/3- 确保single_choice题型的options长度≥2且≤4- 输出报告“共导入2987题发现13题格式错误已跳过”。实操心得我第一次运行时因CSV里有个字段含英文逗号如盛唐, 李白导致tags解析成[盛唐, 李白]多出一个空格。后来在脚本里加了strip()处理这个细节文档里根本不会提但线上真会出问题。4.3 后台管理系统的部署用Docker一键启停后台管理系统是Vue 3 Element Plus开发部署极其简单# 进入后台目录 cd admin # 安装依赖 npm install # 修改配置重点 # 编辑 src/config/index.js替换 baseURL 为你的后端域名如 https://api.poetry.com # 替换 appId 为你小程序AppID用于微信JS-SDK签名 # 构建生产包 npm run build # 用Docker部署推荐避免环境差异 docker build -t poetry-admin . docker run -d -p 8080:80 -v $(pwd)/dist:/usr/share/nginx/html:ro --name poetry-admin poetry-admin访问http://your-server-ip:8080即可进入后台。默认账号密码在/admin/src/config/index.js里写着admin / Poetry2024首次登录后必须修改。后台核心功能截图-题库管理表格支持按tags多选过滤点击“导出Excel”生成带格式的Word文档含诗句原文注释赏析供老师打印讲义-积分配置滑块调节“签到基础分”1~5分、“分享奖励分”1~10分实时看到公式预览“连续签到N天第N天得分为1 (N-1)*0.5分”-模板消息管理上传模板消息截图微信要求系统自动提取模板ID和占位符填入{{keyword1.DATA}}等字段。4.4 微信审核避坑指南那些让你被拒三次的细节我帮客户提审这套代码时总结出微信审核员最关注的5个雷区| 雷区 | 表现 | 源码修复方案 ||------|------|-------------||诱导分享| “分享到群聊得10分”按钮旁无说明文字 | 在button下方加灰色小字“分享成绩至微信群可获额外积分每日限1次” ||价格显示异常| 商城页面“10分”显示为“10.00分” |utils/format.js里增加formatScore(score) { return Math.round(score) }所有积分显示调用此方法 ||负分提示| 用户答错扣分后积分显示“-5分”引发焦虑 | 前端逻辑改为积分最低为0扣分时显示“积分不足无法扣除”并禁用扣分按钮 ||授权页重复刷新| 用户拒绝授权后页面无限重定向 |app.js里onLaunch中增加if (!wx.getStorageSync(authed)) { wx.redirectTo({url: /pages/auth/index}) }且/pages/auth/index.js的onShow里加if (wx.getStorageSync(authed)) wx.switchTab({url: /pages/index/index})||客服消息入口不明显| 只在“我的”页面底部有个小图标 | 在首页右下角固定悬浮button open-typecontact classcontact-btn/button符合微信“随时可触达”原则 |最后一次提审从提交到过审仅用17小时——因为所有细节都提前打磨好了。5. 常见问题与排查技巧实录真实踩坑现场还原5.1 问题速查表高频故障与根因定位现象可能原因排查步骤解决方案首页白屏控制台报Cannot find module ./data/questions.json小程序包体积超2MBquestions.json被微信自动剔除1. 运行npm run build:analyze生成体积分析报告2. 查看/data/questions.json大小用npm run split:questions脚本将题库拆分为10个JSON文件questions_01.json~questions_10.json前端按需动态引入排行榜始终显示“暂无好友”用户未开启“添加好友”权限或好友未使用过小程序1. 调用wx.getFriendCloudStorage检查返回数据2. 查看Redis里user:${openId}:friends是否存在在“我的”页面增加引导文案“邀请3位好友一起玩立即解锁好友排行榜”模板消息发送失败日志显示invalid formIdformId已被使用或过期或非用户主动触发1. 检查发送消息的button是否带open-typeformSubmit2. 查看Redis里form_ids集合中该formId的used字段在/pages/result/index.js的分享成功回调里增加wx.requestSubscribeMessage二次申请仅iOS需要看图猜诗图片加载极慢后端Stable Diffusion API响应超时1.curl -v https://api.poetry.com/api/image/generate测试2. 查看Nginx access.log中该URL的耗时在server/controllers/image.js里增加超时降级if (timeout) return res.send({url: /static/default_poem.jpg})积分商城兑换后前端余额未更新前端未监听wx.onSocketMessage或WebSocket连接中断1. 在app.js里全局监听wx.onSocketMessage2. 检查/socket接口是否返回{type:balance_update,data:120}在/pages/mall/index.js里增加wx.onSocketMessage(data { if(data.typebalance_update) this.setData({balance:data.data}) })5.2 独家避坑技巧那些让项目多活3个月的经验题库热更新技巧微信不允许小程序运行时下载新JSON但我们用了一个取巧办法——把题库放在云存储如腾讯云COS前端启动时wx.downloadFile拉取最新版存入wx.setStorage下次启动优先读本地缓存。/utils/question-loader.js里封装了完整逻辑包含MD5校验防止下载中断导致JSON损坏。排行榜作弊防护有用户用Postman伪造请求刷分。我们在/api/answer/submit接口里加了设备指纹采集wx.getSystemInfoSync().model wx.getNetworkTypeSync() Date.now().toString().slice(-6)拼接后MD5存入Redisdevice:fingerprint:${md5}同一指纹10分钟内最多提交5次。这个指纹字符串前端不暴露只在服务端生成黑客无法逆向。模板消息保底方案微信模板消息送达率约85%为防重要通知丢失我们在后端加了短信兜底。当检测到某用户连续3次模板消息发送失败Redis里fail_count:${openId}≥3自动触发阿里云短信API发送内容“【诗词大会】您的周榜已更新点击查看→ [小程序码链接]”。短信费用由运营预算承担但用户留存率提升了12%。性能监控埋点在app.js的onLaunch里插入wx.reportAnalytics(app_start, {time: Date.now()})在/pages/index/index.js的onLoad里埋点wx.reportAnalytics(home_load, {duration: performance.now() - appStartTime})。这些数据接入微信数据分析后台能直观看到“首页加载3秒”的用户流失率高达47%从而驱动我们优化图片懒加载策略。最后分享一个小技巧如果你想快速验证某个功能是否生效不必每次都扫码预览。在开发者工具里点击右上角“详情”→“本地设置”勾选“不校验合法域名”然后在project.config.json里把request域名改成localhost:3000这样所有API请求都走本地后端调试效率提升5倍。当然上线前必须取消勾选并恢复正式域名。我在实际部署中发现最影响用户体验的从来不是技术多炫酷而是“签到按钮在哪里”“分享后有没有反馈”“积分花了能不能马上看到余额变化”这些细节。这套源码的价值正在于它把所有这些细节都打磨成了肌肉记忆级别的操作规范。当你把注意力从“怎么实现”转移到“用户怎么感受”上时一个真正能留住人的诗词小程序才算真正诞生。本文还有配套的精品资源点击获取简介基于微信原生开发的诗词类答题小程序开箱即用无需二次开发即可部署上线。内置3000多道精选诗词题目覆盖单选、看图猜诗、诗句填空、文字线索等主流题型每题均含标准注释、白话译文和简明赏析。支持按难度随机组卷或阶梯式闯关逻辑适配不同用户水平。用户体系完整微信一键授权登录每日签到领积分分享至好友或微信群可额外获分积分可在商城兑换道具。社交功能实用实时更新的好友排行榜、答题结果一键分享、内置客服消息入口便于用户反馈。运营能力扎实通过微信模板消息自动推送答题提醒、积分变动通知、周榜更新等后台可灵活配置积分兑换比例、题目权重系数、签到连续天数奖励规则等参数。代码已全面适配最新微信小程序审核规范修复了负分显示异常、授权页重复刷新、价格字段错位等常见问题并新增客服消息组件优化答题动效反馈与排行榜列表加载性能。本文还有配套的精品资源点击获取
