简介随机数生成是游戏开发中最基础也最关键的环节其均匀性直接影响玩家体验。理解Math.random()的底层原理与正确使用方式是构建公平可玩的小游戏的前提。在此基础上通过CSS动画与状态锁的配合能够实现流畅且防误触的交互反馈这是轻量级游戏体验优化的核心。此类技术广泛适用于微信小程序中的抽奖、答题等互动场景兼顾性能与开发效率。本文从微信小程序原生开发视角出发完整拆解骰子游戏的工程结构、随机数算法、动画时序与真机适配并涵盖从项目压缩包导入、清理到交付的完整流程帮助开发者避开实际交付中的常见陷阱。 收到一个“微信小程序-骰子游戏.zip”的项目包第一反应是有意思。骰子游戏算是小程序开发的“hello world”级练手项目体积小、逻辑清楚、交互直观但真要把体验做得像样——动画自然、判定准确、不会误触、适配不同机型——里面还是有不少门道的。我工作室以前接过类似的练手外包也自己实现过几个版本这篇文章就把整个拆包、设计、编码、打包、避坑的过程完整记录下来给正要上手小程序游戏开发的朋友做参考。先说结论微信小程序的轻量游戏场景用原生组件加CSS动画完全够用不需要一上来就上小游戏引擎或canvas那套重方案。骰子游戏尤其典型它的核心就是“随机数生成 动画反馈 状态控制”正好对应小程序前端开发的三个基本功。而项目压缩包这个后缀.zip背后其实还藏着一套关于项目工程化、资源整理、跨设备交付的考究这一点我会在后面的章节里专门拆解。文章会包含完整的目录结构、核心代码片段、开发工具配置说明以及我在实际开发和交付zip包过程中踩过的坑比如解压报错、真机和模拟器表现不一致、动画触发无效这些典型问题都有对应的定位思路和处理方案。1. 项目整体设计与思路拆解1.1 从zip包里的目录看成色拿到任何一个“某某项目.zip”我一般不会急着双击运行先解开看目录。一个规范的微信小程序原生项目解压后应当是这种结构骰子游戏/ ├── app.js ├── app.json ├── app.wxss ├── project.config.json ├── sitemap.json ├── utils/ │ └── dice.js ├── images/ │ ├── dice1.png │ ├── dice2.png │ ├── ... │ └── dice6.png └── pages/ ├── index/ │ ├── index.wxml │ ├── index.wxss │ ├── index.js │ └── index.json └── result/ ├── result.wxml ├── result.wxss ├── result.js └── result.json如果少了 app.json 或者 project.config.json这包基本就是半成品。app.json 是小程序的全局配置和页面注册表没有它微信开发者工具压根儿不会承认这是一个合法项目project.config.json 则是开发者工具能正确识别项目、保持编译设置的关键。收到这种项目包第一步不是看代码逻辑而是确认工程结构完整工具能正常导入这一步能排除后面至少一半的“白屏”“编译报错”问题。这个包的项目名“骰子游戏”很直白核心页面就一个猜点数或者比大小。微信小程序游戏和普通小程序的差别在于真正的“微信小游戏”需要走小游戏专区用 canvas 或游戏引擎而我们这种用 Page、WXML、WXSS 写出来的严格来说是“小程序里的互动页面”或者叫轻游戏。两者没有绝对高低之分适合的场景不同而已。骰子游戏这种规模的交互原生组件方案开发速度快、调试成本低非常适合。1.2 玩法设计单骰子还是双骰子对战骰子游戏看起来简单但玩法设计直接决定代码复杂度。我见过几种常见模式单骰子猜大小用户点击摇骰子系统给出1-6的随机点数用户猜大4/5/6或猜小1/2/3猜对得分。双骰子比点数用户和电脑各摇一组骰子可以是一颗也可以是两颗比较点数总和高者胜出。骰宝式多骰子三颗骰子计算点数、组合、赔率玩法贴近现实赌场但这类内容上线审核时风险极大。我最终采用的是“双骰子人机对战”模式原因有这么几个第一交互上有一个“等待对手”的过程适合展示小程序里的异步状态管理比如 loading 动画、结果延迟展现第二积分系统天然带来数据层设计能演示全局变量或本地缓存的用法第三比大小的逻辑简单但清晰适合读者在源码基础上扩展成三局两胜制或连赢奖励玩法。如果只是单骰子“摇一摇看数字”玩一次就腻了代码上也没有太多值得展开讲解的空间。技术上最大的需求点其实是“可复现的项目结构”。我做项目有个习惯所有功能性代码会尽量从页面里抽出来放到 utils 或者独立的模块中。比如摇骰子的核心随机函数我放在 utils/dice.js 里页面只做数据绑定和交互监听这样项目可测试性高后面接单元测试也方便。1.3 技术选型为什么用原生小程序而非游戏引擎现在做小程序里的互动内容可选的方案有这几种方案优点缺点适用场景原生小程序 WXMLWXSSJS学习成本低开发快调试方便复杂动画能力弱大场景掉帧骰子、抽奖、答题等轻互动微信小游戏 canvas 引擎性能强动画丰富包体积大开发和调试门槛高动作类、RPG、复杂物理游戏WebView 嵌套 H5可复用前端代码交互体验不流畅受平台限制内部工具、特定业务场景骰子游戏这种量级用原生方案再合适不过。一颗骰子的翻转动画用 CSS transform 加 transition 就能做出不错的3D旋转效果运行在 WebView 内核上性能足够。强行上 cocos 引擎属于“杀鸡用牛刀”还会把项目体积撑大和 zip 包当初“轻量快捷分享”的初衷也相违背。那什么时候需要上引擎呢我的判断标准是单个页面需要同时运行的动画元素超过10个、有物理碰撞检测需求、或对帧率有超过60fps的要求时才考虑引擎。骰子游戏一次只有两三个骰子在动CSS动画完全应付得过来。2. 骰子游戏的核心细节与核心逻辑2.1 随机数生成别小看 Math.random()骰子游戏的根本是随机数但这里的“随机”有门道。Math.random()生成的是 [0,1) 区间的伪随机数JS 引擎底层通常是线性同余发生器或更高级的梅森旋转算法实现对游戏场景来说足够均匀。生成 1-6 的骰子点数常见的写法是// 不推荐直接四舍五入会有边界误差 const result Math.round(Math.random() * 5 1); // 推荐先放大再向下取整 const result Math.floor(Math.random() * 6) 1;为什么不推荐第一种因为Math.round(Math.random() * 5 1)会把 1 和 6 的概率分布稍稍压缩导致 1 和 6 出现频率略低于 2-5。这在数学上不属于均匀分布长时间对局后玩家会敏感地察觉“这两个数出现的次数怪怪的”。用Math.floor配合偏移量是教科书级的标准做法能保证每个点数的概率严格相等。另外如果游戏还有“连续两次不能摇出相同点数”“初始局点数有保底”这类需求就需要在随机函数外层套一层业务规则。我在这版项目里留了一个简单的防连号开关默认关闭但代码注释里写清楚了扩展方式读者拿到源码后可以自己开。2.2 动画与状态控制摇骰子不能连点骰子游戏的体验好坏七成取决于动画手感和状态控制。我在项目里实现了两个核心点一是骰子的“翻滚”动画二是防止玩家在动画进行中重复点击。动画方面骰子从开始转动到最终显示点数整个过程的视觉反馈必须有“先集气、后出结果”的节奏感。我用 CSS keyframes 实现了一个快速抖动叠加角度旋转的动画持续时间大约 600ms结束时透明度过渡到最终朝向的骰子面。代码骨架如下keyframes diceRoll { 0% { transform: rotate(0deg) scale(1); } 25% { transform: rotate(90deg) scale(0.85); } 50% { transform: rotate(180deg) scale(1.1); } 75% { transform: rotate(270deg) scale(0.9); } 100% { transform: rotate(360deg) scale(1); } } .dice-rolling { animation: diceRoll 0.6s cubic-bezier(0.25, 0.46, 0.45, 0.94); }状态控制方面我在页面的 data 里维护一个rolling布尔值。所有可能被重复触发的入口都要判断这个值防止玩家在 600ms 动画期间疯狂点按钮导致 setData 被反复调用、动画状态错乱。等动画完成或者定时器触发后再恢复rolling false。别忘了微信小程序的 setData 是异步更新视图但同步更新逻辑层数据的频繁操作会造成性能瓶颈尤其低端机明显。在骰子这种高频交互场景里“状态锁”是必须的设计不是可选项。2.3 音效与结果判定一个骰子游戏如果没有掷骰子的“骨碌碌”音效乐趣直接砍半。小程序里播放音频非常轻量只需要在 app.js 或页面 onLoad 里创建内部音频上下文const innerAudioContext wx.createInnerAudioContext(); innerAudioContext.src /audio/dice_roll.mp3; innerAudioContext.play();有一些细节容易被忽略音频文件不能太大建议控制在 200KB 以内否则首次播放会有明显卡顿iOS 对音频播放有用户手势激活要求所以第一次播放最好绑定在用户点击事件上页面 onUnload 时要记得调用innerAudioContext.destroy()否则容易出现后台播放的诡异问题。判定逻辑上这版项目采用了“玩家点数 电脑点数”直接比较总分胜、负、平三种结果分别给出不同提示。分数存储用的是wx.setStorageSync(totalScore, score)本地缓存就能满足不需要后端接口。如果以后要做在线排行榜才需要考虑把分数提交到服务端和用户身份绑定那是另一个复杂度等级的话题这里只做提示不展开。3. 实操过程从零搭出完整项目3.1 初始化项目与目录规划在微信开发者工具里新建小程序项目时选择“不使用模板”或“JavaScript - 基础模板”AppID 可以用测试号代替不影响本地功能开发。项目创建后我建议按功能模块把目录预先建好不要所有页面一股脑塞到 pages 下面后面会越来越乱。我这版项目的页面规划是pages/index/index游戏主界面包含玩家骰子、电脑骰子、操作按钮、比分展示。pages/rank/rank本地战绩页统计当前设备的胜负记录。{ pages: [ pages/index/index, pages/rank/rank ], window: { navigationBarTitleText: 骰子大作战, navigationBarBackgroundColor: #2c2c2c, navigationBarTextStyle: white, backgroundColor: #1a1a1a } }这里有一个容易被新手遗漏的点pages数组的第一项就是小程序启动后的默认首页所以要把 index 放在第一位否则每次打开都跳到别的页面去了。app.json里 window 配置的 navigationBarTitleText 是全局标题单页面如果想覆盖需要在对应页面的.json文件里单独配置两处会用“页面配置优先”的规则合并。3.2 主页面 WXML 结构设计WXML 端的结构设计直接影响后面 wxss 好不好写、广告位好不好加。我做了一个三段式布局顶部状态栏展示比分中部区域两边分别放玩家和电脑的骰子区底部操作区放摇骰子按钮和“查看战绩”入口。view classcontainer view classscore-board view classscore-item text classscore-label我/text text classscore-num{{playerScore}}/text /view view classscore-divider:/view view classscore-item text classscore-label电脑/text text classscore-num{{computerScore}}/text /view /view view classdice-area view classdice-column text classdice-owner玩家/text view classdice {{rolling ? dice-rolling : }} wx:if{{playerDice 0}} text classdice-face dice-placeholder?/text /view view classdice {{rolling ? dice-rolling : }} wx:else text classdice-face{{playerDice}}/text /view /view view classdice-column text classdice-owner电脑/text view classdice {{rolling ? dice-rolling : }} wx:if{{computerDice 0}} text classdice-face dice-placeholder?/text /view view classdice {{rolling ? dice-rolling : }} wx:else text classdice-face{{computerDice}}/text /view /view /view view classresult-tip wx:if{{roundResult}} text{{roundResult}}/text /view view classaction-area button classroll-btn bindtapstartRound disabled{{rolling}} {{rolling ? 咻... : 摇骰子}} /button button classrank-btn bindtapgoRank战绩/button /view /view结构上刻意不用image而是用文字加 CSS 样式来画骰子因为骰子面的点数用数组排列能省掉6张图片资源让 zip 包更小。当然如果你愿意准备 6 张骰子面图片会让视觉效果更好图片资源统一放 images 目录路径引用时用绝对路径/images/dice1.png不要用相对路径否则在分包或二次编译时容易出路径错乱。3.3 逻辑层实现摇骰子的完整流程下面这段是我在pages/index/index.js里的核心逻辑实现了开局初始化、单局流程、比分更新和战绩持久化const util require(../../utils/dice.js); Page({ data: { playerDice: 0, computerDice: 0, playerScore: 0, computerScore: 0, roundResult: , rolling: false }, onLoad() { this.initGame(); }, initGame() { this.setData({ playerDice: 0, computerDice: 0, playerScore: 0, computerScore: 0, roundResult: , rolling: false }); }, startRound() { if (this.data.rolling) return; this.setData({ rolling: true, roundResult: , playerDice: 0, computerDice: 0 }); // 生成双方的点数 const playerDice util.getDiceNumber(); const computerDice util.getDiceNumber(); // 延迟展示结果配合骰子动画的节奏 setTimeout(() { let roundResult ; let playerScore this.data.playerScore; let computerScore this.data.computerScore; if (playerDice computerDice) { roundResult 本局你赢了; playerScore 1; } else if (playerDice computerDice) { roundResult 本局电脑赢了; computerScore 1; } else { roundResult 平局; } this.setData({ playerDice, computerDice, playerScore, computerScore, roundResult, rolling: false }); this.saveRank(playerScore, computerScore); }, 650); }, saveRank(playerScore, computerScore) { const rank { playerScore, computerScore, lastUpdateAt: Date.now() }; wx.setStorageSync(dice_rank, rank); }, goRank() { wx.navigateTo({ url: /pages/rank/rank }); } })这版代码有几个值得解释的细节第一setTimeout的延时设成 650ms要比 CSS 动画的 600ms 长一点点。这样动画先播完然后 setData 更新点数视觉上不会有“点数先出现、动画还在跑”的撕裂感。这个“时间差”是我在多个机型上测试出来的经验值不固定但思路是动画时长必须小于等待时长。第二状态锁放在startRound第一行动画期间任何点击都会被拦截。很多教程里只写一个disabled属性但按钮 disabled 在某些情况下点击还是会触发事件比如快速双击时事件队列已经进入所以逻辑层再判断一次rolling是双保险。第三比分不是立即累加而是先算好再一次性 setData合并状态更新能减少渲染次数这在低端机上尤其明显。3.4 战绩页面与本地数据联动战绩页面rank相对简单主要做两件事从本地缓存读取数据用图表或列表方式展示胜负比例。Page({ data: { playerScore: 0, computerScore: 0, winRate: 0% }, onShow() { const rank wx.getStorageSync(dice_rank) || {}; const total (rank.playerScore || 0) (rank.computerScore || 0); const winRate total 0 ? Math.round(rank.playerScore / total * 100) % : 0%; this.setData({ playerScore: rank.playerScore || 0, computerScore: rank.computerScore || 0, winRate }); } })这里要注意页面生命周期从首页通过wx.navigateTo跳转到战绩页后返回首页时战绩页的 onShow 会在每次重新显示时触发数据自然就刷新了。如果用的是wx.redirectTo会导致页面栈变化回来就得重新创建不适合这种需要返回的场景。4. 微信小程序适配与性能优化细节4.1 安全区与顶部导航栏的适配骰子游戏不涉及复杂的原生化交互但“安全区适配”是绕不开的话题尤其是 iPhone 的刘海屏和底部 home 条区域。在app.json里可以配置window: { navigationStyle: default }在小程序基础库 2.x 之后页面会默认考虑安全区如果做沉浸式导航就要手动在 WXSS 里加.container { padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); }env()和constant()是 iOS 提供的安全区变量前者适配 iOS 11.2后者适配 iOS 11.0-11.2小程序里两者都要写顺序不能反。Android 端这块变量通常返回 0不影响布局。那顶部导航栏高度怎么处理我的经验是不要硬编码用wx.getSystemInfoSync()去取状态栏高度再结合胶囊按钮位置动态计算。这个项目里骰子游戏不需要在导航栏上做花哨操作所以直接使用默认导航栏最省事标题配好就行。4.2 真机与模拟器的差异开发中最典型的坑是“模拟器上好好的真机一打开就白屏或动画错乱”。骰子游戏里我遇到过的真机差异有CSS 动画在模拟器上跑得流畅但在部分 Android 低端机上出现闪屏解决办法是给骰子元素加transform: translateZ(0)强制开启 GPU 加速。音频资源在某些机型上无法自动播放前面说过第一次播放必须绑在用户点击事件上。字体渲染差异。骰子面用“数字 点阵”的方式时中文数字或 Unicode 字符在不同系统里形变明显所以在 WXSS 里显式指定 font-familyPingFang SC, Microsoft YaHei, sans-serif避免系统默认字体差异。如果真机出现白屏第一步先打开微信开发者工具的“真机调试”模式看 Console 里的报错。最常见的白屏原因是app.json里配置的页面路径写错了或者是引用了不存在的资源文件。白屏不等于代码完全没跑很多时候只是页面渲染环节炸了。4.3 包体积与代码分包策略微信小程序主包体积限制是 2MB超过后需要配置分包。对于骰子游戏这种项目正常情况主包体积能轻松压到 500KB 以内所以不需要刻意做分包。但如果你以后要往里面塞更多素材或者做系列小游戏合集提前了解分包机制有好处。分包配置在app.json里这样写{ subPackages: [ { root: games/dice, pages: [ pages/index/index ] } ] }分包的核心逻辑是“按需加载”主包只放首页和公共资源玩法页放到分包里用户真正点击进入时才去下载对应代码。不过分包和wx.navigateTo跳转时的路径写法会不一样分包页面路径要带 root 前缀。项目里如果要用到“分包异步化”让一个分包里的页面直接引用另一个分包里的组件或模块就需要在 js 文件里使用require异步引入或者用wx.loadSubpackage预加载这个机制适合更复杂的场景骰子游戏暂时用不上但了解原理不会有坏处。5. 项目打包成 zip 与交付的注意事项5.1 打包前一定要清理这几个文件一个好的交付包不是把整个项目压缩一下就完事的。我收到过很多乱七八糟的 zip里面全是node_modules或者.git目录体积翻了几十倍。在打包微信小程序项目前建议按下面清单清理node_modules绝大部分小程序原生项目不依赖 npm 包导致这个目录存在往往是开发者试过某些插件后留下的删掉完全不影响小程序运行。.git、.idea、.vscode等目录这些是开发环境的版本库和编辑器配置对使用者没有任何意义还可能暴露开发历史。project.private.config.json这是个人本地配置包含了开发者的个人设置和部分环境信息交付前应当删除。miniprogram_npm如果项目里通过 npm 构建过依赖这个目录是构建产物。但如果收包方那边基础库版本不一致直接带入容易出兼容问题。不做涉及 npm 的二次开发的话可以删掉保证对方导入时重新构建。测试用的临时图片、日志文件、临时音频这些是最容易被忽视的但会白白增加包体积。清理完之后用一个干净的目录结构重新压缩zip 包质量会高很多。我自己习惯在项目根目录下放一个README.md写清楚运行环境、基础库版本、开发工具版本和导入步骤。这个 README 成本极低但对收包方非常友好后续问题沟通能省一大半时间。5.2 让 Zip 包保持正常可用的反面教训我踩过这类坑收到的项目 zip 解压到一半就报错甚至解压完成后目录不完整。下面这些是真实遇到过的报错和对应解决办法“file is not a zip file”多半是下载过程中文件被截断或者文件名后缀乱写。双击解压软件报错时先用命令行验证一下文件头是不是PK开头或者干脆重新下载一遍。“invalid zip archive: could not find EOCD”EOCDEnd Of Central Directory是 zip 文件末尾的中央目录结束标记这个报错说明压缩包缺少了关键的末尾记录常规解释是压缩过程中断或文件被某些网盘/聊天工具二次处理过。解决办法是请源头重新压缩并传输或者用解压软件自带的“修复压缩包”功能试着救一下。zip 分卷文件.z01 .zip这种情况要把所有分卷文件下载到同一目录先用主 zip 文件解压解压软件会自动找到 z01、z02 等后续分卷不能只拿其中一个文件去解压那样必然失败。这里要特别提醒一句不要为了图方便用“在线解压”或“在线修复”工具去处理项目 zip项目里包含代码和路径信息有隐私风险。本地用开源压缩工具足够处理也更安全。5.3 如何在微信开发者工具里导入别人给的 zip 项目导入项目前先确认 zip 解压后的目录是否直接包含 app.json。很多压缩包在打包时把整个工程父目录一起压进去了导致解压后出现“外层目录/内层工程”的结构这时导入开发者工具选择“导入项目”目录要选到 app.json 所在的那一层。项目导入后如果出现编译报错按优先级排查先看 app.json 里注册的页面路径是否都在。再看project.config.json里的miniprogramRoot属性是否指向了正确目录。如果解压后项目结构变了这一步会出现找不到小程序代码的报错。最后检查基础库版本在开发者工具“详情-项目配置”里查看“调试基础库”尽量选择 2.x 以上较新的稳定版。如果导入后一片白屏且 console 没有任何报错先试一下“清除缓存-全部清除”再重新编译。这个问题在小程序开发者工具的历史版本中比较常见多数是工具缓存了旧的编译产物。5.4 从微信开发者工具反向打包 zip 的方法交付项目时从开发者工具里导出 zip 反而容易带出多余文件我更推荐直接在系统层面压缩cd /path/to/project zip -r dice-game.zip . -x *node_modules* -x *.git* -x *.idea*这行命令会把当前目录下所有文件压缩为 dice-game.zip同时排除 node_modules、.git、.idea 这类目录。如果你用的是 Windows也可以用右键“发送到-压缩(zipped)文件夹”但要注意如果系统开启了“隐藏已知文件类型的扩展名”压缩包名字可能是dice-game.zip而不是dice-game.zip后半段才是真的扩展名这类问题容易在传输后引起“文件格式不正确”的困惑。我还建议在压缩完成后自己解压验证一次确认页面资源和路径都完整然后再发给别人。这并非不信任工具而是操作上多花十秒钟能避免对方收到一个坏包之后回来追问的各种连环问题。6. 常见问题与排查技巧实录我把开发骰子游戏和交付 zip 过程中遇到的高频问题整理成了一个速查表覆盖协作和交付中最常见的情况可以直接对照使用现象可能原因定位思路编译报错“页面文件找不到”app.json 注册路径和实际文件路径不一致核对 pages 数组里的路径大小写也要一致模拟器正常真机白屏基础库版本差异、引用了不存在的资源打开真机调试看 console清缓存重新编译点击按钮后动画不触发rolling 值为 true 一直没复位检查 setTimeout 里 setData 是否执行状态锁是否卡死骰子动画在低端机掉帧CSS 动画未开启 GPU 加速给动画元素加transform: translateZ(0)音频第一次不出声用户没有产生点击交互把音频播放绑在 bindtap 事件里传输后 zip 解压报错文件被截断或压缩包结构损坏重新打包传输不要在线解压收取导入工具后显示非小程序项目目录选错app.json 不在所选目录内选择到 app.json 所在层级再导入本地能跑打包后丢失图片路径用了相对路径而不是绝对路径统一改为/images/xxx.png格式iPhone 底部内容被 home 条遮挡没有适配安全区wxss 中加入 env(safe-area-inset-bottom)连续快速点击导致结果错乱缺少状态锁或 disabled 未生效在逻辑层用 rolling 判断拦截重复点击补充两个在开发过程中最花时间的冷门问题第一个是某些基础库版本下wx.setStorageSync在隐私模式或存储空间满时静默失败表现在“打了几局战绩没记录”。解决方法是调用后加一个try/catch失败时提示用户清理空间而不是默默吞掉异常。第二个是“计算属性”问题。小程序里的 WXML 不支持在{{ }}里写复杂表达式也不支持直接调用方法官方新版本有 WXS 可以部分弥补但有些开发者基础库低就不能依赖。像“胜率”这种需要实时计算的字段最好在 setData 之前就算好放到 data 里而不是在 WXML 里做运算。在真实交付场景里还有一个经常被忽略的坑是微信开发者工具的“本地设置”里面每个项目有自己的调试基础库版本如果你用的是最新的基础库特性比如新的组件、新的 API而收包方打开项目时用的还是旧基础库就会出现“你这边好好的他那直接白屏”。所以 README 里务必写明“建议使用 XX 版本及以上基础库”最稳妥的是在 app.json 的libVersion字段里显式声明。做这个小游戏项目前后我最大的感受是任何一个小程序项目越是看起来简单越要在“状态控制”和“交付质量”上多花心思。骰子游戏的核心逻辑可能只有几十行代码但围绕着随机数的正确性、动画的跟手度、zip 包的整洁度和可导入性展开的是小程序开发里最常用的一整套工程能力。拿到任何一个“xxx.zip”项目包先检查结构、再挑核心逻辑、最后动手改功能这个顺序能帮你少走很多弯路。如果你照着文章里的步骤把一个骰子游戏从零跑通再试着加上连赢奖励或者多人对战逻辑对小程序列表渲染、事件绑定和数据同步的理解会扎实很多。本文还有配套的精品资源点击获取