简介这是一份微信小程序多功能工具箱集合源码面向小程序开发者和编程学习者定位在无需服务器、无需域名、无需API接口的轻量工具型应用模板。资源包共104个文件包含31个js逻辑脚本、24个png图片素材、16个wxss样式表、16个json配置以及15个wxml页面结构文件压缩包整体仅1.6MB文件组织清晰可直接导入微信开发者工具运行调试也方便按功能模块替换或扩展。目前已有432人学习/下载。源码内置游戏扫码登录、亲戚关系计算器、手机清灰、手机检测、手持弹幕、空白昵称、字数统计及简易画板等8项功能覆盖热门手游扫码、家庭称谓查询、手机硬件检测、屏幕弹幕互动等真实场景所有功能均免服务器、免后端接口不用担心失效。模块间耦合度低适合作为微信小程序实用工具集合的起步模板也方便初学者逐段研读JS逻辑与页面交互。1. 从游戏扫码登录到多功能工具箱这套小程序源码到底在解决什么游戏扫码登录并不是新概念PC 端打开游戏客户端手机端扫一下 QRCode 完成授权这个流程在端游和云游戏里已经跑了十几年。但当这套逻辑出现在微信小程序里事情开始变得不一样小程序既是扫码端又是工具箱的载体同一个二维码既能拉起登录态又能承载后续的查询、辅助、数据统计功能。所谓“多功能工具箱集合”本质上就是把游戏登录扫码、账号信息解析、战绩查询、礼包兑换提醒、周边工具等一堆能力塞进一个小程序壳子里共享同一套登录态和用户体系。本文要拆的这套“小程序源码游戏扫码登录多功能工具箱集合”是一种常见于游戏社区、游戏工作室、陪玩平台的源码方案。它的核心价值在于用户扫一次码完成身份绑定后续所有工具模块都能直接拿 openid 换游戏内身份令牌不用重复授权。源码不是某一家独有而是开源社区里反复出现的组合套路涉及的模块包括扫码登录组件、后端 token 校验、游戏官方开放 API 或第三方数据接口对接、以及前端工具页面的统一脚手架。适合有微信小程序开发经验、想快速搭建游戏向工具产品的团队或个人参考也可以作为游戏账号体系对接微信登录的落地范本。直接说结论这套东西的难点不在扫码本身难点在扫码之后这堆工具模块如何靠一套身份体系串起来。下面从整体架构开始一步步拆。2. 先拆架构微信小程序里“扫码登录”的三种落地姿势和多工具共享登录态的设计2.1 扫码登录在小程序里的真实角色不是只有“扫一下”这么简单微信小程序要完成扫码登录通常不是让小程序去扫而是让小程序生成或展示二维码用户用微信扫这个码然后在微信里授权登录。但在“游戏扫码登录”这个场景里角色发生了反转小程序承载的是被扫端。用户在电脑或游戏客户端上看到二维码用微信扫一扫后进入小程序完成授权随后客户端轮询或长连接拿到登录 token。这在技术上属于微信开放平台里的“扫码登录”能力走的是https://open.weixin.qq.com/connect/qrconnect这条链路和小程序自身的wx.login并不是一回事。常见的做法是这套源码在小程序端实现一个专用页面用户从游戏客户端点击“微信扫码登录”弹出二维码微信扫码后跳到小程序的一个授权落地页小程序通过wx.login获取 code再结合游戏侧传入的 scene 参数通常携带一个随机的 login_ticket后端拿着 code 换 session_key 和 openid再查这张 login_ticket 对应的游戏账号请求确认后标记为已扫码、已确认。游戏客户端那边通过短轮询或 WebSocket 感知状态变化获取正式的登录凭证。这里有个关键点扫码登录的核心是 login_ticket 的状态流转而不是微信侧的授权结果。微信侧只负责确认“这个人是谁”游戏侧需要的是“这个人被允许登录哪个账号”。代码片段小程序端发起wx.login并将 code 连同登录票据交给业务后端。// pages/scanLogin/scanLogin.js Page({ data: { ticket: , status: WAITING_SCAN, // WAITING_SCAN - SCANNED - CONFIRMED - EXPIRED }, onLoad(options) { // options.scene 是扫码进入小程序时携带的场景值 // 游戏客户端生成的二维码里会把这个值拼进去形如 login_ticketxxx this.setData({ ticket: options.scene || }); this.ensureLogin(); }, async ensureLogin() { const loginRes await wx.login(); const code loginRes.code; wx.request({ url: https://api.example.com/game/scan/confirm, method: POST, data: { code, // wx.login 返回的临时凭证 ticket: this.data.ticket, // 二维码里带过来的登录票据 }, success: (res) { if (res.data.code 0) { this.setData({ status: CONFIRMED }); } }, }); }, });这段代码里wx.login拿到的 code 有效期只有 5 分钟而且只能用一次。实际场景中游戏客户端生成的二维码也会有有效期通常在 2 到 5 分钟之间后端收到 code 后要先查 ticket 是否存在、是否已过期再做code2Session换取 openid最后把状态更新为已扫码。这个顺序不能反反了会出现“人登录了但游戏侧收到的凭证对不上号”的问题。2.2 工具箱集合的模块划分方式登录态统一业务逻辑彻底隔离工具箱集合源码里常见的组织方式是一个主包负责登录和首页其他工具全部做成分包。分包不是随便分的而是按“是否依赖游戏内身份”来切。比如战绩查询、角色信息解析这类功能拿到 openid 后还要去游戏开放平台换 game_token属于强身份模块而礼包提醒、攻略查询这类功能只认 openid属于弱身份模块。两种模块对后端的要求不同。强身份模块需要后端有一个 token 中继层负责把微信侧的身份凭证映射成游戏侧的身份凭证。这一步通常放在后端服务里而不是前端直接调游戏 API。原因是游戏开放平台的密钥不能暴露在小程序包里而且有些游戏 API 对来源 IP 有限制必须要服务端转发。弱身份模块可以直接调云开发或自建后端数据结构也简单openid 做主键就行。源码里比较常见的设计是把这些模块的页面放在subpackages/目录下每个工具一个子目录配置好app.json里的subpackages字段。分包的好处是首包体积变小扫码进入时加载速度更快。对于扫码登录场景首屏速度直接决定用户是否愿意继续用这个工具。下面是一个典型的分包配置示例{ pages: [ pages/index/index, pages/scanLogin/scanLogin ], subpackages: [ { root: subpackages/query, pages: [ pages/roleInfo, pages/battleHistory ] }, { root: subpackages/tools, pages: [ pages/giftReminder, pages/damageCalculator ] } ], preloadRule: { pages/scanLogin/scanLogin: { network: all, packages: [subpackages/query] } } }preloadRule的配置值得多说一句。扫码登录确认之后用户大概率会立刻去看角色信息所以预加载subpackages/query可以让跳转几乎无感。但预加载会消耗流量和内存如果扫码落地页本身已经很重就不要配预加载否则启动时间会不降反升。这里有一个经验值分包预加载的包体总大小控制在 300KB 以内对首屏的影响可以忽略。2.3 登录态在多个工具间的串联方式不只是 token还有状态同步工具箱集合里最容易翻车的就是登录态不同步。有的页面走微信原生登录态有的页面走后端自定义 token用户在一个工具里显示已登录切到另一个工具就变成未登录原因通常是各页面没有统一使用同一个会话存储。常规做法是把会话信息统一放在wx.setStorageSync或全局变量里并封装一个auth.js作为唯一出口。// utils/auth.js const SESSION_KEY game_tool_session; function setSession(session) { wx.setStorageSync(SESSION_KEY, { ...session, expireAt: Date.now() session.expiresIn * 1000, }); } function getSession() { const session wx.getStorageSync(SESSION_KEY); if (!session) return null; if (Date.now() session.expireAt) { wx.removeStorageSync(SESSION_KEY); return null; } return session; } function clearSession() { wx.removeStorageSync(SESSION_KEY); } module.exports { setSession, getSession, clearSession };这个封装解决了两个问题一是所有工具模块都通过getSession()拿登录态不会出现各写各的存储键名二是把过期判断收敛到一个函数里登录态过期时统一走清理逻辑。实际使用中后端应该在校验 token 时把过期时间随响应体返回前端不要自己拍脑袋定过期时限。游戏扫码登录场景中openid 对应的是游戏账号的绑定关系而不是游戏内角色本身所以会话里最好存下 game_token 和绑定角色 ID避免每次查询工具都重新拉角色列表。3. 从扫码到拿游戏数据API 层的设计、签名和鉴权必须一次到位3.1 后端接口设计扫码确认、状态轮询、令牌换发三条链路缺一不可小程序端负责扫码和展示状态但真正控制登录流程的是后端接口。一套合格的扫码登录方案最少需要三个接口发起扫码、确认扫码、轮询状态。游戏客户端展示二维码前先调用“发起扫码”接口后端生成 login_ticket 并缓存小程序进入落地页后调用“确认扫码”接口游戏客户端通过“轮询状态”接口直到拿到最终凭证。接口路径可以这样设计POST /game/scan/create、POST /game/scan/confirm、GET /game/scan/status。其中 confirm 接口的入参是 wx.login 的 code 和 login_ticket出参是确认结果status 接口的入参是 login_ticket出参是当前状态和登录凭证。用表格把这几个接口的参数和应用场景列清楚方便对照实现接口入参出参调用方典型时序POST /game/scan/creategame_id, device_infoticket, expires_in, qrcode_url游戏客户端用户点击扫码登录时POST /game/scan/confirmcode, ticketstatus, openid(脱敏)小程序端用户在小程序确认授权时GET /game/scan/statusticketstate, user_info(脱敏), game_token游戏客户端客户端每 2 秒轮询一次注意 confirm 和 status 的返回值里都不能直接泄露完整 openid。openid 是用户在小程序生态里的唯一标识一旦被游戏客户端拿到就相当于别人可以拿着这个 ID 去匹配同一用户的其他应用数据。常见做法是只返回脱敏后的 openid比如oK9****abc或者干脆返回一个自增 user_id 作为游戏客户端侧的用户标识。3.2 签名校验code 换 token 之前先验证 ticket 归属扫码登录有一个安全死角小程序端任何人都可以调用 confirm 接口只要他手里有一个 ticket。如果 ticket 本身没有做来源绑定攻击者可以把自己生成的 ticket 发给受害者扫码然后偷偷替换 ticket 来绑定自己的微信身份。解决这个问题的标准做法是在 create 接口生成 ticket 时记录设备信息confirm 时再校验 ticket 是否处于“待确认”状态且未被绑定。# backend/services/scan_service.py import hashlib import time import secrets def create_ticket(game_id: str, device_info: str, expires_in: int 300): ticket secrets.token_urlsafe(32) # device_info 是客户端设备指纹用于后续风控校验 # 这里只演示结构实际应存入 Redis 并设置过期时间 scan_session { ticket: ticket, game_id: game_id, device_info: device_info, state: PENDING, # PENDING - SCANNED - CONFIRMED - EXPIRED created_at: int(time.time()), expires_at: int(time.time()) expires_in, openid: None, game_token: None, } redis_set(fscan:{ticket}, scan_session, exexpires_in) return ticket def confirm_scan(code: str, ticket: str): session redis_get(fscan:{ticket}) if not session: raise ScanError(ticket not found or expired) if session[state] ! PENDING: raise ScanError(ticket already processed) # wx.code2Session 是后端调微信接口换取 openid 的唯一入口 openid wx_code2session(code)[openid] session[state] SCANNED session[openid] openid redis_set(fscan:{ticket}, session) return {status: SCANNED}这段代码里secrets.token_urlsafe(32)生成的是 32 字节随机数碰撞概率可以忽略。wx_code2session这一步必须放在后端因为code2Session接口需要用到小程序的 AppSecret这个密钥一旦暴露在小程序包里别人就能冒充小程序后端换取任意用户的 openid。还有一点容易被忽略code2Session返回的 openid 是和 AppID 绑定的同一个用户在不同小程序里 openid 不同如果工具箱后期要跨小程序打通身份需要额外引入 UnionID 机制。3.3 轮询还是长连接两种状态同步方案在游戏扫码场景下的取舍游戏客户端怎么知道用户已经扫码确认了两种方案常见短轮询和 WebSocket。短轮询简单前端每 2 秒调一次 status 接口直到状态变成 CONFIRMED 或 EXPIREDWebSocket 省流量但实现复杂客户端和服务器都要维护长连接而且手游客户端和 Web 游戏客户端对 WebSocket 的支持程度不一致。游戏扫码登录场景下我一般推荐短轮询理由有三点一是扫码登录的等待时间短用户 99% 会在 30 秒内完成扫码轮询几次就结束了不会有持续的资源浪费二是后端实现简单不需要维护连接状态三是可以顺带把风控逻辑放进 status 接口里比如轮询频率超过每秒 3 次直接拒绝避免有人写脚本刷接口。下面是轮询接口的一个健壮性设计// backend/handlers/scan_status.go func GetScanStatus(c *gin.Context) { ticket : c.Query(ticket) session, err : redisGetScanSession(ticket) if err ! nil { c.JSON(404, gin.H{code: 404, msg: ticket expired}) return } // 轮询频率控制同 ticket 每秒最多 2 次 rateKey : fmt.Sprintf(rate:scan:%s, ticket) if !redisAllow(rateKey, 2, 1) { c.JSON(429, gin.H{code: 429, msg: too many requests}) return } c.JSON(200, gin.H{ code: 0, data: gin.H{ state: session.State, game_token: session.GameToken, // 仅在 CONFIRMED 状态返回 }, }) }代码里有一个容易被忽视的细节game_token只有在 state 为 CONFIRMED 时才返回其他状态下返回空字符串。如果后端在 SCANNED 状态就把 token 返回给客户端用户还没有点“确认登录”游戏侧就已经能用 token 拉数据了这会形成一个越权窗口。另一个细节是轮询接口也要做频率限制否则同一张二维码可以被多人同时轮询放大服务器压力。4. 工具箱里的多功能模块怎么接角色查询、战绩分析、礼包提醒的通用数据管线4.1 强身份模块的角色信息查询game_token 换角色列表的标准姿势工具箱里最常用的是角色查询模块。用户在扫码登录后绑定过的游戏角色会出现在列表里点击后能看到等级、区服、战力等基础信息。这一步调的是游戏开放平台的角色信息接口但小程序端不能直接调原因还是 AppSecret 和签名算法不能暴露在小程序包内。常规做法是后端封装一个统一网关小程序端只需要带上登录时拿到的 game_token后端校验 token 后去游戏侧拉数据再按前端需要的字段结构返回。这里有一个容易踩的坑游戏侧接口返回的角色 ID 和用户绑定角色 ID 可能不一致。游戏侧的角色 ID 是游戏内唯一标识但用户可能在多个区服有角色工具里显示的“当前角色”和扫码登录时选择的角色不一定相同。所以后端在返回角色列表时不要只在内存里比对角色 ID而是把扫码登录时用户确认的那个默认角色 ID 存在数据库里每次查询时以它为准。如果 game_token 对应的角色列表和本地记录不一致就以列表为准同时更新本地默认角色。4.2 弱身份模块怎么轻量化战绩分析工具优先走公开接口战绩分析类工具不一定需要游戏内身份令牌。部分游戏开放了公开查询接口只要提供角色名称或角色 ID 就能拿到对战记录。这种接口的调用成本低适合放在工具箱里做成“无需登录也能用”的引流模块。但公开接口通常有频控限制单位时间内的调用次数有限制多个用户同时查询时容易触发限流。源码里常见的应对方案是加一层缓存。把最近 10 分钟的查询结果按角色 ID 缓存起来同一个角色再次被查询时直接返回缓存不重复打游戏侧接口。缓存之外还要做接口降级当游戏侧接口连续返回限流错误时前端自动切换到“基础模式”只展示最近 5 场战绩而不是完整的 50 场详情。4.3 多功能集合的模块注册机制不写死页面跳转用配置驱动工具箱里的功能模块越来越多页面间的跳转关系如果全部写在代码里后期加一个工具就要改多处地方。源码里通常会维护一份模块配置表把每个工具的名称、图标、路由、是否依赖登录态统一登记。// config/tools.js const TOOL_MODULES [ { id: role_info, name: 角色查询, icon: /assets/icons/role.png, path: /subpackages/query/pages/roleInfo, requiresAuth: true, authLevel: strong, // strong: 需要 game_token; weak: 只需要 openid }, { id: battle_history, name: 战绩分析, icon: /assets/icons/battle.png, path: /subpackages/query/pages/battleHistory, requiresAuth: false, authLevel: none, }, { id: gift_reminder, name: 礼包提醒, icon: /assets/icons/gift.png, path: /subpackages/tools/pages/giftReminder, requiresAuth: true, authLevel: weak, }, ];配置驱动带来的好处是主页面的工具列表可以通过wx:for渲染新增工具只需要往配置表里加一条记录。这里需要注意权限字段的设计requiresAuth决定页面是否要求用户已扫码登录authLevel决定调用数据接口时是带openid还是带game_token。前端拿到配置后根据用户的登录态动态过滤可展示的工具而不是把所有工具都渲染出来再做权限拦截。5. 真机调试和发布避坑wx.login 静默失败、二维码被拦截、request 域名备案5.1 真机调试时扫码登录失效先查这三项配置小程序开发者工具里扫码登录跑得通一到真机就失效这个问题在游戏扫码登录场景里特别常见。原因不出在代码逻辑而是出在真机环境和开发者工具环境的差异上。第一项要查的是request合法域名。开发者工具里勾选“不校验合法域名”后任何 HTTPS 接口都能调通但真机上这个开关不起作用。如果小程序的 request 域名没有在小程序管理后台的“开发管理 - 服务器域名”里配置真机请求会直接被拦截报错是url not in domain list。游戏扫码登录通常还会用到长连接或者 WebSocket同样需要在 socket 合法域名里配置。第二项要查的是wx.login的调用环境。wx.login在开发者工具里走的是模拟环境返回的 code 是工具模拟出来的后端拿这个 code 去调code2Session会失败。所以真机调试时一定要保证后端接的是真机环境传过来的 code。有些源码会同时打印 code 到 console 和后端日志方便对比。第三项是二维码携带的参数。小程序码和小程序码之间不同普通二维码可以带任意参数但scene参数有长度限制最长 32 个可见字符而且不能包含某些特殊符号。如果游戏客户端生成的 login_ticket 太长或含特殊字符扫码进入小程序后参数可能被截断或编码错乱。5.2 小程序发布审核和备案对游戏工具类小程序的特殊要求涉及游戏信息的小程序类目审核会额外严格。工具箱集合如果包含战绩查询、角色信息展示等模块通常会被要求提供游戏厂商的授权文件或开放平台对接证明。如果只是展示公开数据需要有明确的数据来源说明不能让人误以为小程序是游戏官方产品。这里最容易踩的坑是小程序名称和头像不能带游戏官方 Logo 或近似标志否则会被判定为仿冒。另外小程序备案时“备注信息”虽然只有一行但一定要写清楚用途。常规写法是“本小程序用于提供游戏数据查询服务数据来源于游戏官方开放平台”不要只写“游戏工具箱”几个字。审核人员看不出来具体是什么服务备案备注不清晰会被驳回。注意如果工具箱里涉及用户之间发送消息、分享内容、组队等互动功能类目会判定为社交需要补充社交类目资质单靠工具类目是不够的。5.3 版本发布时的灰度策略先放体验版再放安卓最后放 iOS扫码登录涉及微信、游戏客户端、后端三方协作任何一方升级都可能出问题。发布的常规节奏是先在开发者工具里上传体验版让测试人员通过二维码进入小程序完成扫码登录验证通过后发布安卓版本因为安卓端微信的 webview 和 JSAPI 兼容性更接近开发工具最后再放 iOS。iOS 端有两个特殊问题第一是微信内置浏览器对 LocalStorage 的清理策略更激进用户杀进程后登录态容易丢失需要在代码里对getSession()的返回做兜底判断为空时跳转到重新登录页第二是 iOS 上小程序的网络请求默认使用 HTTP/2如果后端服务器只支持 HTTP/1.1 或 TLS 配置不标准会出现安卓可用、iOS 请求超时的经典问题。6. 进阶技巧把扫码登录的重复代码收敛成组件减少 80% 的多余请求工具箱集合里登录状态检查的代码会在很多页面重复出现。常见做法是写一个公共的requireAuth逻辑但更干净的方式是把它封装成组件或自定义 hook。以 Vue 或 Taro 项目为例可以写一个useScanAuth的 hooks统一处理“检查登录态、发起扫码、轮询状态、失败场景跳转”这四个步骤。// hooks/useScanAuth.js import { useState, useEffect } from react; export function useScanAuth(ticket) { const [status, setStatus] useState(IDLE); useEffect(() { if (!ticket) return; wx.login({ success: async (res) { const result await requestConfirm(res.code, ticket); if (result.expiresIn) { startPolling(ticket, result.expiresIn); } }, }); }, [ticket]); function startPolling(ticket, expiresIn) { const pollCount Math.ceil(expiresIn / 2000); let current 0; const timer setInterval(async () { current 1; const res await requestStatus(ticket); setStatus(res.state); if (res.state CONFIRMED || res.state EXPIRED || current pollCount) { clearInterval(timer); } }, 2000); } return { status }; }这段 hooks 的核心是轮询次数的收敛逻辑pollCount由后端的expires_in决定不是写死循环 N 次或无限轮询。有效期内未确认就等过期这样游戏二维码失效后的第一时刻就能反馈到 UI 上。需要注意这个 hooks 里startPolling和wx.login之间缺少状态清除与组件卸载保护实际使用要再补一层clearInterval和useRef做组件卸载时的清理避免页面跳转后定时器仍在跑。还有一个容易被忽略的性能优化点扫码落地页不做任何额外的网络请求专心处理登录。很多源码为了“让用户有东西看”落地页会额外拉取公告、游戏列表、热门工具等数据。这些请求和登录流程毫无关系而且会拖慢确认扫码的响应速度。扫码登录的转化率对时间敏感用户扫完码还要等数据加载才能确认会直接放弃。正确的做法是落地页只做三件事调wx.login、请求 confirm 接口、展示当前状态。如果想把工具箱集合的整体体验再推进一步可以在确认扫码成功跳转首页时带上游戏角色 ID 作为 URL 参数让首页直接定位到用户上次查看的工具模块。角色 ID 不要走eventChannel传因为页面重新加载后参数会丢URL 参数更可靠。至此从扫码登录到多功能工具模块的数据串联已经全部跑通。实际做的时候建议先只接一个工具模块完整走通再横向复制到其他模块这样调试成本最低。本文还有配套的精品资源点击获取