简介：一套基于微信小程序的LOL（英雄联盟）战绩查询项目源码，面向小程序初学者和前端开发者，解决数据查询类应用从零搭建的常见问题。压缩包共157个文件，大小仅4.21MB，涵盖JS逻辑、WXML页面、WXSS样式、JSON配置等源码文件，同时配有大量PNG图片、GIF演示和MD说明文档，目录层级明确，结构清晰完整。项目调用LOL官方API，通过异步请求获取玩家战绩、比赛历史等数据，并利用setData更新视图；包含加载状态、失败重试、历史记录、热门选手推荐、战绩分享等实用功能，界面还针对不同屏幕做了适配，兼顾美观与易用性。已有960人学习，适合课程设计或个人实战，可帮助读者掌握小程序开发从页面搭建、数据请求到展示的完整流程；无论是课程作业还是实际项目，这套源码都能提供可直接复用的界面与逻辑参考，帮助缩短学习曲线。
1. 微信小程序里的 LOL 战绩查询：一个能直接跑起来的完整源码包
这套「LOL战绩查询.zip」是一个完整的微信小程序工程，核心链路就是三件事：输入召唤师名字做模糊搜索、拉取最近对战记录、点进去看单局 KDA 和胜负详情。压缩包解压后用微信开发者工具直接导入，改一下 request.js 里的接口地址就能跑通全流程。工程里已经处理好了搜索防抖、列表分页、数据清洗和缓存策略，不是那种只有一两个页面的半成品。适合两类人：一是正在做小程序毕设、需要一套完整业务流当素材的学生；二是想搞明白「查询类小程序到底怎么组织请求和渲染」的前端开发。接下来我从数据链路、核心代码、踩坑记录和上线前优化四个方向拆一遍。
2. 数据链路与工程结构：先看清“查战绩”的数据是怎么回来的
拆这套工程之前，先把「战绩数据从哪来」这个问题说清楚。很多人在小程序里直接请求第三方接口，结果一上线就白屏，原因在于微信小程序对 request 有合法域名白名单限制：在开发者工具里勾选「不校验合法域名」可以临时绕过，但真机上这个选项不存在。所以这套工程里的请求不是页面直接发出去的，而是先打到自己的后端服务或者小程序云函数，由后端去聚合游戏数据，再返回给前端。理解这条链路，是后面所有配置的基础。
2.1 三种数据来源的选型：官方 API、第三方聚合、脱机构造
先说结论：国服《英雄联盟》没有一个对个人开发者完全开放的官方战绩接口，能稳定拿到数据的通常是三类方案。
第一类是第三方数据平台的开放接口，例如海外有 Riot API，国服则有一些数据站提供的 JSON 接口。这类接口普遍有调用频率限制，多数需要申请 token，而且返回字段和微信小程序的渲染需求不一定对齐。第二类是自建采集服务，自己定时抓取并清洗数据，优点是数据可控、字段完全自定义，缺点是维护成本高，游戏版本一更新字段就可能有变化。第三类是开发阶段用 mock 数据先跑通页面，等后端就绪再替换真实接口。
这套源码包里采用的是「后端代理 + 前端 request 封装」的结构：小程序端只负责把 summonerId、region、page 这些参数拼上去，后端统一处理签名、时效和限流。这样做的直接好处是前端代码里不保存任何密钥，签名参数也不会暴露到小程序包里，用户通过开发者工具抓包也拿不到真正有价值的东西。
2.2 工程目录结构：页面、工具函数与配置文件的职责
解压后你会看到典型的微信小程序目录结构，核心包含 app.js、app.json、app.wxss 三个全局文件和 pages 目录下的页面文件。pages 下面按业务拆成三个页面：搜索页、战绩列表页、对局详情页，每个页面都有独立的 wxml、wxss、js、json 四个文件。
先看 app.json 的路由配置：
{ "pages": [ "pages/index/index", "pages/search/search", "pages/detail/detail" ], "window": { "navigationBarTitleText": "LOL 战绩查询", "navigationBarBackgroundColor": "#10142a", "navigationBarTextStyle": "white", "backgroundColor": "#f5f6fa" }, "style": "v2", "sitemapLocation": "sitemap.json" }pages 数组里的第一项就是小程序的启动页，这里把搜索页设计成了入口，因为用户使用战绩查询的第一步必然是输入召唤师名字。window 配置里导航栏标题和背景色属于视觉层，没有太多技术门槛，但 navigationBarTextStyle 只支持 black 和 white 两个取值，如果你配了深色背景却写成 black，标题就会看不清。style: v2 表示启用新版组件样式，这会在部分基础库版本上影响组件的默认外观，后面做自定义样式时需要留意。
再看 utils 目录里的工具函数。这套工程里把请求都收拢到了 utils/request.js，原因很简单：小程序每个页面都要发请求，如果不统一封装，签名逻辑、错误码处理、token 刷新就会散落在各个页面里，后期维护基本靠搜索。下面这个是 request 封装的核心片段：
// utils/request.js const BASE_URL = 'https://your-server.example.com/lol-api' function buildSign(params, timestamp) { // 常见的签名规则：将参数按 key 排序后拼接，再附加盐值做 md5 const sortedKeys = Object.keys(params).sort() const rawStr = sortedKeys.map(key => `${key}=${params[key]}`).join('&') const salt = 'your-salt-value' return md5(`${rawStr}×tamp=${timestamp}&salt=${salt}`) } function request(path, data = {}, method = 'GET') { const token = wx.getStorageSync('access_token') const timestamp = Date.now() return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method: method, data: Object.assign({}, data, { timestamp }), header: { 'X-Token': token, 'X-Sign': buildSign(data, timestamp) }, success(res) { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data) } else if (res.statusCode === 401) { // token 失效，跳转登录页重新授权 wx.removeStorageSync('access_token') wx.navigateTo({ url: '/pages/login/login' }) reject(new Error('登录状态已过期')) } else { reject(new Error(res.data.message || '请求失败')) } }, fail(err) { reject(err) } }) }) } module.exports = { request }这段代码里有两个值得注意的参数设计。第一个是 timestamp，把它放进每个请求里，后端可以判断请求是否过期，防止重放攻击；第二个是 X-Sign 签名头，把参数按 key 排序后拼接再 md5，这是一个非常通用的签名做法。实际项目中我一般会把盐值和签名算法收敛到后端配置里，前端只负责计算和传递。这里的 promise 化很关键：wx.request 本身是回调式的，如果每个页面都写 success/fail 回调，会很容易陷入嵌套地狱，封装成 promise 之后页面里就能用 async/await 来写数据请求了。
2.3 全局登录态与用户信息的存储策略
查询类小程序通常不需要强制登录，但高频查询场景下，接口会限制每个 IP 或每个设备的请求次数。这套工程的做法是首次查询时获取微信的 code，通过后端换取 openid 并下发一个 access_token，之后的每次请求都带上这个 token。这样做有两个作用：后端可以用 token 做用户维度的限流，也可以统计每个用户查询了多少次。
代码里用 wx.getStorageSync 来读写 token，而不是直接放在全局变量里。原因在于小程序页面切换时全局变量不一定能保持稳定，而 storage 是持久化的，哪怕用户退出小程序再进来，只要 token 没过期就不需要重新登录。
提示：小程序端所有涉及密钥和盐值的逻辑都只做“计算并附带”，不要做“生成和保存”。密钥一旦打进代码包，任何人解包都能看到。
到这里，数据链路、工程结构和请求封装这三层算是理顺了，接下来进入核心功能实现。
3. 核心功能落地：搜索、战绩列表与对局详情
这一章真正进入业务代码。三个功能点分别对应三个页面，每段代码我都按实际拆包时的顺序来讲：先处理输入，再处理后端返回的数据，最后落到渲染。
3.1 搜索页：防抖、模糊匹配与路由参数传递
搜索页的逻辑比较单纯，但其实是最容易写出 bug 的一个页面。用户在 input 里输入名字，每敲一个字符就会触发 Input 事件，如果每个字符都去请求接口，后端扛不住，用户也会看到搜索建议一直在跳动。
这段代码用了防抖：只有用户停止输入 400ms 后才真正发起请求。
// pages/search/search.js let debounceTimer = null Page({ data: { keyword: '', suggestions: [], loading: false, recentSearches: [] }, onLoad() { const recent = wx.getStorageSync('recent_searches') || [] this.setData({ recentSearches: recent }) }, onInput(e) { const keyword = e.detail.value.trim() this.setData({ keyword }) clearTimeout(debounceTimer) debounceTimer = setTimeout(() => { this.searchSummoner(keyword) }, 400) }, async searchSummoner(keyword) { if (!keyword) { this.setData({ suggestions: [] }) return } this.setData({ loading: true }) try { const res = await request('/summoner/search', { keyword }) this.setData({ suggestions: res.list || [] }) } catch (err) { console.log('搜索失败', err) } finally { this.setData({ loading: false }) } }, onSelectSummoner(e) { const { id, region } = e.currentTarget.dataset const keyword = this.data.keyword // 写入本地搜索历史，最多保留 5 条 const recent = this.data.recentSearches const next = [{ name: keyword, time: Date.now() }].concat( recent.filter(item => item.name !== keyword) ).slice(0, 5) wx.setStorageSync('recent_searches', next) wx.navigateTo({ url: `/pages/detail/detail?summonerId=${id}®ion=${region}` }) } })这里我把 400ms 作为防抖窗口，但实际项目中，这个值通常取决于后端响应速度。后端响应在 200ms 以内的，可以缩短到 300ms；响应超过 600ms 的，建议放大到 500ms，避免用户已经输入完还在等待上一次请求返回。搜索历史用 storage 保存并限制为 5 条，这是所有查询类小程序都值得做的小优化，能明显降低后端压力——用户在搜索历史里点一下，就不需要再走一次模糊搜索逻辑。
3.2 战绩列表页：清洗后端字段、分页与上拉加载
搜索之后进入战绩列表页。后端返回的对局数据通常非常冗长，Riot 风格的原始数据里可能包含几十个字段：玩家等级、符文、天赋、出装、对位信息等等，但列表页需要的只有几个字段。
把原始数据清洗成渲染模型，是这套工程的核心技巧。我不会在 setData 里传原始数据，而是先经过格式化再交给视图层：
// pages/detail/detail.js const GAME_TYPE_MAP = { 'RANKED_SOLO': '单双排', 'RANKED_FLEX': '灵活排位', 'NORMAL': '普通匹配', 'ARAM': '极地大乱斗' } function cleanMatch(raw) { const player = raw.player || {} const side = player.team === 100 ? 'blue' : 'red' const win = player.win === 1 const durationMin = Math.floor(raw.gameDuration / 60) const durationSec = raw.gameDuration % 60 return { gameId: raw.gameId, championName: raw.champion ? raw.champion.name : '未知英雄', championIcon: raw.champion ? raw.champion.iconUrl : '', side, win, kda: `${player.kills}/${player.deaths}/${player.assists}`, gameMode: GAME_TYPE_MAP[raw.gameMode] || raw.gameMode, durationText: `${durationMin}:${durationSec.toString().padStart(2, '0')}`, timestamp: formatTimestamp(raw.gameTimestamp) } }这里有几个值得展开的点。第一是 GAME_TYPE_MAP 映射表，后端只返回一个 RANKED_FLEX 这样的枚举值，界面必须显示成用户认得的中文，这个映射放在一个文件里而不是内联写在各页面中，方便游戏模式新增或改名时统一修改。第二是 durationSec 使用 padStart 补零，因为 3 分 5 秒如果显示成 3:5，用户一眼就看出没处理过。第三是原始字段的防御性处理，raw.player 和 raw.champion 可能在某些历史对局里缺失，直接取属性会抛异常，用空对象和默认值兜底是最简单有效的做法。
清洗完成之后，列表页的数据请求和分页逻辑长这样：
// pages/detail/detail.js 的分页请求部分 Page({ data: { matches: [], page: 1, pageSize: 20, hasMore: true, loadingMore: false }, onLoad(options) { this.summonerId = options.summonerId this.region = options.region this.loadMatches(true) }, async loadMatches(reset = false) { const { page, pageSize } = this.data const currentPage = reset ? 1 : page if (!reset && this.data.loadingMore) return this.setData(reset ? { loading: true } : { loadingMore: true }) try { const res = await request('/matches', { summonerId: this.summonerId, region: this.region, page: currentPage, pageSize: pageSize }) const cleanedList = res.list.map(cleanMatch) this.setData({ matches: reset ? cleanedList : this.data.matches.concat(cleanedList), page: currentPage + 1, hasMore: res.hasMore }) } catch (err) { console.log('加载战绩失败', err) } finally { this.setData({ loading: false, loadingMore: false }) } }, onReachBottom() { if (this.data.hasMore) { this.loadMatches() } } })这里用 loadingMore 做请求互斥，核心原因是 onReachBottom 事件在快速滚动时会连续触发多次，如果不加锁，同一个 page 会被请求两次，列表里就会出现重复数据。还有一个细节是 page 从 1 开始计数，而不是 0，这是为了和后端分页语义保持一致，换来换去容易出 bug。
3.3 对局详情页：KDA 计算与表现评级的边界处理
点进单局详情，用户关心的核心指标无非三个：KDA、胜负、装备。KDA 计算的坑藏在死亡数为 0 的场景里——如果直接把(击杀+助攻)/死亡数，除数为 0 会得到 Infinity，渲染到页面只能显示成一个诡异的数字。
// utils/kda.js function calcKDA(kills, deaths, assists) { if (deaths === 0) { return { ratio: kills + assists, perfect: true } } return { ratio: Number(((kills + assists) / deaths).toFixed(2)), perfect: false } } function judgePerformance(kills, deaths, assists, win, damagePercent) { const kda = calcKDA(kills, deaths, assists) if (kda.perfect && win) return 'carry' if (kda.ratio >= 4 && win && damagePercent >= 25) return 'carry' if (kda.ratio >= 3 && !win) return 'try-hard' return 'normal' } module.exports = { calcKDA, judgePerformance }死亡数为 0 时直接返回击杀加助攻作为 KDA 值，perfect 标记为 true，这是符合用户直觉的处理方式——0 死亡会被理解为「这把没被抓到」。表现评级里我额外参考了 damagePercent 伤害占比，原因是只看 KDA 会误判很多局，例如辅助位死得多但伤害占比很低，单纯看 KDA 直接判定为坑是不公平的。这套工程的判定逻辑虽然简单，但方向是对的。
详情页的装备渲染也是一处容易踩坑的地方。装备图标通常由后端返回一个 itemId，前端需要拼接成图片 URL。但不同数据源的拼接规则不同，有的需要 itemId，有的需要 itemKey，拼错之后图片直接裂掉：
<!-- pages/detail/detail.wxml 中装备区域片段 --> <view class="item-section" wx:if="{{equipList.length}}"> <image wx:for="{{equipList}}" wx:key="itemId" src="{{item.iconUrl}}" class="item-icon" mode="aspectFit" /> </view>这里的 wx:key 用 itemId 而不是 index，是因为在列表插入或删除时，用 index 会导致渲染错位。这一点对微信小程序来说尤其重要：setData 更新数组时，框架是根据 wx:key 来优化 diff 的。
4. 避坑清单：鉴权、跨域、缓存与渲染的五个真实翻车现场
这一章把我在带这套工程时实际踩过的坑列出来，都按「现象 → 原因 → 解决」三个步骤写，方便定位。
4.1 真机预览白屏：服务器域名没配进白名单
现象：在开发者工具里一切正常，一点「预览」扫码在手机上打开，页面白屏，network 面板里所有请求都是 fail。
原因：微信小程序真机环境下，wx.request 只能请求「小程序后台 → 开发 → 服务器域名」里配置过的 https 域名。开发者工具勾选了「不校验合法域名」能绕过限制，但这个勾选不会同步到真机。
解决：在小程序后台把后端接口域名加进 request 合法域名列表。注意这个域名必须是 https 且 ICP 备案过的，而且不能带端口号。如果后端还没备案，临时办法是用云开发环境，云函数发起请求不受域名白名单限制。
注意：这个坑最容易出现在团队协作场景。后端同学在本地起了个服务，前端在开发者工具里关了域名校验跑通了，结果提测时测试手机上一片白。我现在的习惯是拉代码后先看一眼 request.js 里的域名有没有配进后台白名单，再开始调接口。
4.2 战绩数据和实际对不上：大区映射与服务器参数混乱
现象：查询一个艾欧尼亚的召唤师，返回的对局列表里混着其他大区的数据，胜率和段位也对不上。
原因：游戏数据接口里的 region 字段和用户所在大区不一致。国服有几十个大区，背后的服务器 ID 一直有对应关系，如果搜索时没把大区 ID 传给后端，或者后端没有用 region 做过滤，就会返回默认区服的数据。
解决：在搜索接口里返回 region 字段，前端在跳转详情页时把 region 放进 URL 参数，后端按这个参数过滤。同时建议在代码里维护一份大区 ID → 大区名的映射表，在 UI 上展示「艾欧尼亚」而不是 ID，这样调试时一眼就能看出问题。实际工程里我见过把 region 写在全局变量里、切页面就丢的情况，所以一定要走页面参数传递。
4.3 列表滚动卡顿掉帧：setData 塞入的字段太多
现象：战绩列表滑动时明显卡顿，真机上掉帧严重，页面加载耗时超过 3 秒。
原因：把后端返回的原始对象直接丢进 setData，一条数据几十个字段，一页 20 条就上千个字段。微信小程序的 setData 是逻辑层和视图层之间的串行通信，数据量一大，性能瓶颈立刻出现。
解决：先经过 cleanMatch 清洗，只保留渲染需要的字段再 setData。另外把大数组拆成小块，一次请求 20 条而不是 100 条，列表用 view 而不是用 scroll-view 嵌套，因为 scroll-view 内部的长列表渲染效率比 page 级滚动低。还有一点容易被忽略：不要在 setData 里传函数或带有循环引用的对象，序列化会失败并且很慢。
4.4 接口返回 401：签名参数和服务器对不上
现象：开发阶段接口能通，部署到测试环境后所有请求都返回 401 unauthorized，后端日志里提示 sign invalid。
原因：签名规则拼接顺序不一致。比如前端把 timestamp 放在 query 参数里，但后端验签时要求 timestamp 参与签名计算放到最后，两端各写各的，签出来的值永远对不上。
解决：把签名规则抽象成后端的一个配置文件，前端只按规则计算，不重复实现逻辑。我一般会在后端的验签函数里打印出期望的签名值，前端在 request.js 里 console.log 实际的签名值，两边一对比，差异立刻可见。常见问题还有 URL 编码：参数值里一旦有特殊字符，前端拼签名用的 rawStr 和后端收到的参数值不一致，务必用同样的编码规则后再拼接。
4.5 上拉加载出现重复数据：请求竞态没做互斥
现象：快速上拉到底部，列表里出现相邻两页重复的数据，而且页面跳数不稳定。
原因：onReachBottom 触发频率高，前一次请求还没返回，第二次请求又发出去了。如果后端按 page 语义返回数据，两次请求拿到同一页数据，setData 里执行 concat 时就会把重复数据追加进列表。
解决：在请求方法里加 loadingMore 互斥锁。已经在请求中时，直接 return 掉新的触发，等当前请求结束后再允许下一次。另外推荐在 loadMatches 里过滤一遍已存在的 gameId，防止某次请求超时重试导致重复插入：
// 合并数据前做一次去重 const existingIds = new Set(this.data.matches.map(item => item.gameId)) const uniqueNewList = cleanedList.filter(item => !existingIds.has(item.gameId)) this.setData({ matches: this.data.matches.concat(uniqueNewList) })这里 Set 的查找是 O(1)，列表长度在几百条以内时性能没有问题。如果你列表已经上千条，建议直接改用分页组件并简化 setData 频率，不要把去重放在渲染层。
5. 进阶：给查询链路加上本地缓存、骨架屏与重试策略
到这里，整个查询主链路已经完整运行了。真正要让它接近上线状态，还需要做三件事：缓存、骨架屏、请求重试。
先说缓存。战绩查询有很高比例的重复查询，同一个召唤师在短时间内的对局记录变动不大，完全没有必要每次都拉全量数据。合理的做法是在前端加一层 TTL 缓存，以 5 分钟为界，5 分钟内同一个 summonerId 加 region 的查询直接读缓存，超过 5 分钟再去请求后端。
// utils/cache.js const CACHE_TTL = 5 * 60 * 1000 function getCache(key) { const cached = wx.getStorageSync(key) if (!cached) return null if (Date.now() - cached.time > CACHE_TTL) { wx.removeStorageSync(key) return null } return cached.data } function setCache(key, data) { wx.setStorageSync(key, { time: Date.now(), data: data }) } module.exports = { getCache, setCache }缓存对象里必须存写入时间，这是 TTL 判断的基础；读取时发现过期要顺手移除，否则缓存文件会越来越大。我会把 TTL 从 30 秒到 10 分钟做成可配置项，测试阶段调短一点，上线后调长，避免测试时数据一直不更新。
第二件是骨架屏。战绩列表加载期间白屏会让用户觉得小程序卡死了，微信小程序里的做法是在 wx:if 外面套一层 loading 态，用 CSS 动画填充：
<view wx:if="{{loading}}" class="skeleton-list"> <view class="skeleton-item" wx:for="{{[1,2,3,4,5]}}" wx:key="index"> <view class="skeleton-block skeleton-champion"></view> <view class="skeleton-block skeleton-line"></view> <view class="skeleton-block skeleton-kda"></view> </view> </view> <view wx:else class="match-list"> <!-- 正常列表渲染 --> </view>骨架屏的核心不是动画效果，而是保证首屏在数据到达之前就有一个稳定的高度占位，避免数据返回后页面跳动，这种跳动在移动端会直接导致用户误触。我在第三件重试策略上也吃过亏。小程序端网络环境复杂，弱网下 wx.request 经常超时，直接在 fail 回调里提示用户失败是很粗糙的体验。常见做法是加一层指数退避重试，最多重试两次：
function requestWithRetry(path, data, retries = 2) { return request(path, data).catch(err => { if (retries <= 0) throw err const delay = 800 * Math.pow(2, 2 - retries) return new Promise(resolve => setTimeout(resolve, delay)) .then(() => requestWithRetry(path, data, retries - 1)) }) }第一次重试延迟 800ms，第二次 1600ms，总等待时间控制在 3 秒内，配合界面的 loading 提示，弱网体验基本能接受。从那以后，我每次给小程序加查询类功能时都会强制走一遍这三件事：缓存是否命中、首屏是否有占位、请求失败是否重试。这三件事做完，功能才算真正能交到用户手里。希望帮到你。
本文还有配套的精品资源，点击获取
