微信小程序找茬游戏源码全解析：从判定逻辑到上线的完整实践

简介：这是一套开箱即用的微信找茬类游戏小程序源码，面向零基础或初级小程序开发者、个人创业者及流量主变现需求者，解决从0搭建趣味性小游戏并快速上线运营的痛点。资源包共2007个文件，含1604张PNG与266张JPG游戏图片素材、36个JS逻辑脚本、20个WXSS样式文件、18个WXML页面结构文件、9个PHP后端接口及2个SQL数据库文件，完整覆盖前端渲染、用户交互、关卡管理与后台数据操作；压缩包大小为396.15MB。已有225人学习下载。开发者可直接部署运行，获得已调试通过的小程序主体功能、配套图文音效素材、可视化后台管理系统（支持新增关卡、更新题图、查看用户数据），以及详尽的安装技术文档与HTML格式管理界面（如moreGameAdd.html、kv.html等），大幅降低开发门槛与运维成本。 最近整理磁盘上的旧项目，翻出一个找茬微信小程序的完整源码包——前端页面、游戏判定逻辑、关卡素材、搭建文档全都齐了，之前有朋友一直在问这类小游戏要怎么做、怎么从零跑起来，我干脆把整个拆解过程和实操步骤整理成一篇，给准备入手微信小程序游戏开发的同学做个参考。

这个项目说大不大，但覆盖的点很全：关卡设计、图片素材、坐标判定、计时提示、进度存储，再到最终的注册、上传、审核上线，是一条完整的链路。如果你之前只写过普通的小程序页面，没碰过小游戏类项目，拿它练手非常合适；如果你想接类似的私活，这套结构也能直接复用。

1. 先摸清这套源码的整体面貌

1.1 玩法设计与功能模块拆解

找茬游戏的核心规则不用多讲：两张几乎一样的图摆在一起，玩家需要在限定时间内找出所有不同之处。这类游戏的优势在于规则零门槛，上到老人下到小孩都能玩，所以它作为小程序一直有比较稳定的用户盘子。

这套源码的玩法是经典的“关卡制+倒计时”：每个关卡展示一张场景原图和一张对比图，玩家点击认为有差异的位置，系统判断命中或 miss，找到全部差异点才能通关，通关后进入下一关。配合难度递增的设计，前面几关差异点少、差异明显，后面逐渐增加差异数量、缩小差异面积，玩家在通关过程中能持续获得成就感。

从功能模块来看，源码里包含了下面这些部分：

• 主页/关卡选择：展示关卡列表、已解锁关卡、每关得分和状态
• 游戏主页面：双图展示、点击判定、命中标记、计时器、提示按钮
• 结果页：通关展示用时和星级，未通关显示失败原因，支持重试
• 进度存储：本地缓存保存已解锁关卡和最高评分
• 分享模块：通过 onShareAppMessage 自定义分享卡片，支持附带参数跳转

整个项目没有复杂的后端依赖，关卡数据、用户进度全部在前端完成。这意味着搭建的时候不需要服务器、不需要数据库、不需要配置域名，只要有一个小程序账号和微信开发者工具就能跑起来。对第一次接触小游戏源码的朋友来说，这种纯静态的架构是最友好的一种形态。

1.2 源码目录结构与技术栈判断

拿到一个源码包，我建议第一件事不是急着导入微信开发者工具，而是先看目录结构，判断它是原生小程序还是用框架写的。这两者的导入方式、文件组织逻辑完全不同，搞错了会浪费很多时间。

原生微信小程序的源码通常长这样：

project/ ├── app.js # 小程序逻辑入口 ├── app.json # 全局配置 ├── app.wxss # 全局样式 ├── project.config.json # 项目配置，含 AppID ├── sitemap.json # 索引配置 ├── pages/ │ ├── index/ # 首页/关卡选择 │ │ ├── index.wxml │ │ ├── index.wxss │ │ ├── index.js │ │ └── index.json │ ├── game/ # 游戏主页面 │ ├── result/ # 结算页 │ └── rank/ # 排行榜（如果有） ├── assets/ │ ├── images/ # 关卡原图、对比图、图标 │ ├── data/ # 关卡配置 JSON/JS │ └── audio/ # 音效 └── utils/ └── game.js # 公共游戏逻辑

如果看到项目里有 pages.json、manifest.json、main.js 这类文件，那它多半是用 uni-app 写的；如果有 App.vue、router 之类的目录，可能是 Taro 或者其他 Vue/React 框架。这套找茬项目是原生小程序结构，所以导入流程是最简单的那种。

另外一个关键文件是 project.config.json，里面记录了 appid、项目名称、编译配置等。打开它能看到里面的 appid 是不是 touristappid（游客模式），如果是，导入后需要替换成你自己的小程序 AppID。这一步属于搭建前必须处理的点，后面实操环节我会展开讲。

2. 找茬判定逻辑：最核心的技术难点

2.1 从点击到判定命中：坐标系统和碰撞计算

找茬小程序的核心技术点只有一个：怎么判断用户点到了“正确”的位置。所有玩法都是围绕这个判定展开的，理解的深度直接决定了你后续改关卡、调手感、加功能的能力。

通常的实现思路是：开发者在制作关卡时，记录下每一处差异在图片上的坐标和容错半径，存进关卡配置。玩家点击图片后，程序把触摸坐标换算成图片坐标系里的坐标，然后遍历所有差异点，用两点间距离公式做碰撞检测。如果距离落在容错半径内，就算命中。

核心伪代码大概是这个样子：

// 关卡配置示例 const levelConfig = { id: 1, bgImage: '/assets/images/stage1/bg.jpg', diffImage: '/assets/images/stage1/diff.jpg', diffs: [ { x: 150, y: 320, radius: 30 }, { x: 480, y: 210, radius: 28 } ], timeLimit: 90 }; // 点击判定 function checkTap(tapX, tapY, diff) { const dx = tapX - diff.x; const dy = tapY - diff.y; const distance = Math.sqrt(dx * dx + dy * dy); return distance <= diff.radius; }

这套逻辑本身并不难，难点在两个延伸问题：一是坐标精度怎么保证，二是不同屏幕尺寸下如何不漂移。这两个问题处理不好，玩家点击明明是差异位置却不命中，或者偏移很远也能命中，游戏的体验会变得非常糟糕。

我在实际项目里习惯将差异点的坐标存成“相对坐标”，也就是 0 到 1 之间的小数，比如 x: 0.32 表示差异点在图片宽度 32% 的位置。这样在设计关卡时记录的是标准尺寸下的坐标，运行时再根据屏幕实际渲染尺寸换算，适配就能做到比较稳，不用给每个机型单独调数据。

2.2 坐标换算的坑：不同屏幕如何保证点击准确

很多新手改源码时会发现一个典型问题：在 iPhone 14 上点得准，换到安卓或者小屏设备上就点不准了。原因基本都出在坐标换算环节。

微信小程序的触摸事件通过e.touches[0].clientX和clientY拿到的坐标，是相对于整个页面可视区域的。而页面里的图片并不一定从页面左上角开始显示——上方有导航栏，图片上下可能还有间距，如果图片使用 mode="aspectFit" 模式缩放，图片四周甚至会出现黑边。直接用触摸坐标去比对差异点坐标，必然会产生偏移。

正确做法是在点击时动态获取图片的实际渲染位置和尺寸，再把它换算成图片坐标系：

// 获取图片实际渲染信息 const query = wx.createSelectorQuery(); query.select('#game-image').boundingClientRect(); query.exec((res) => { const rect = res[0]; const touchX = e.touches[0].clientX; const touchY = e.touches[0].clientY; // 换算到图片坐标系 const imageX = (touchX - rect.left) / rect.width * IMAGE_NATIVE_WIDTH; const imageY = (touchY - rect.top) / rect.height * IMAGE_NATIVE_HEIGHT; // 再拿 imageX / imageY 去和差异点坐标做碰撞检测 });

这里的 IMAGE_NATIVE_WIDTH 是图片文件本身的像素宽度，不是页面渲染宽度。只有把触摸坐标换算到“图片的原始像素坐标系”，和差异点配置里的坐标统一单位，判定才算真正可靠。

之所以强调这个点，是因为不少现成源码图省事，直接把触摸坐标当坐标用，在小屏上跑得通，换大屏就露馅。你拿到源码以后如果发现点击判定漂移，优先检查换算逻辑是否正确，而不是去调差异点数据。

2.3 计时、提示与通关流程的实现细节

找茬游戏里，计时器和提示系统直接影响玩家的体验曲线，源码里这几个模块也值得仔细看。

计时器这块，不是简单 setInterval 就能做完。需要考虑页面切后台、倒计时归零、剩余时间不足时 UI 变红抖动这些状态。一个成熟的实现会把剩余时间放到 data 中，用定时器每秒递减，并在 onHide 时清理定时器，onShow 时恢复和重新计时。否则玩家切出去回个微信消息，回来发现时间已经清零，体验会非常生硬。

提示系统的实现也比较有意思。常见做法有两种：一种是提示时弹出文字或图标，告诉玩家“还有 3 处差异未找到”；另一种是直接给玩家标记某个差异点，把位置坐标下发，然后在该位置渲染一个闪烁的圆圈。第二种更能帮玩家解围，也更考验素材和逻辑的配合。

在实际源码里，点击提示按钮后会从“未找到的差异点”数组里取第一个，把它的坐标转成渲染层坐标，用绝对定位的 view 加上 CSS 动画实现闪烁效果。同时提示次数会递减，次数用完后按钮置灰。有些改版还把这个提示次数和激励视频广告绑定，看完广告多得一次提示，这也是后面做商业化变现的一个切入点。

通关流程的逻辑相对直接：每命中一个差异点，就把它从“剩余差异”数组里移除，并打上命中标记；当剩余差异数量变成 0，停掉计时器，计算剩余时间，跳转到结果页并写入星级。关卡进度用 wx.setStorageSync 存在本地，key 一般是 user_progress，下次打开小程序可以直接读取。

3. 全套素材的准备、制作与资源管理

3.1 找茬素材清单与图片规范

这套源码能直接跑起来，核心依靠的是里面包含的一整套关卡素材。素材决定了游戏的上限——逻辑写得再好，前后两张图看起来完全不像，或者差异点毫无逻辑，玩家一样会流失。

一个完整的找茬素材包一般包含这几类文件：

• 原图：每个关卡一张，作为主展示图
• 对比图：差异版本图，和原图高度相似但存在若干改动
• 标记图（可选）：在一张透明底图上用圆圈标出所有差异位置，用于提示系统
• 关卡缩略图：关卡列表页展示
• UI 资源：按钮、背景图、图标、弹窗、命中特效
• 音效：点击、命中、通关、失败、倒计时音效

图片尺寸上，我建议按 750 的宽来设计，高度根据关卡图片的实际比例调整，比如 750×1334。为什么用 750？因为微信小程序的设计稿习惯以 iPhone 6/7/8 的 2 倍屏幕宽度（375×2=750）作为基准，rpx 单位也是以此设计的。按这个尺寸出图，套到大部分手机上都能得到相对一致的显示效果。素材格式上，照片类的用 JPG，带透明的标记图和 UI 覆盖层用 PNG。

3.2 制作差异图的完整流程

如果你要新增关卡，或者想把这套源码改造成自己的原创内容，制作差异图的流程必须跑通。实际动手做一遍之后你会发现，找茬游戏的素材制作核心不在于“做图”，而在于“精准记录差异点坐标”。

我的制作流程大概是这样：

第一步，准备一张底图。版权问题一定要重视，建议使用可商用的图库图片，或者用 AI 工具生成，避免直接抓取网上的图片。需要做两张图的话，建议先把原图定稿，再复制一份作为对比图的基础。

第二步，在 Photoshop 里修改对比图。找茬的逻辑是“几乎一样，但有细微差别”，所以改动的幅度要控制好。常见的差异类型有三种：颜色差异（某一小块区域颜色变了）、形状差异（某个物体的尺寸变大变小）、内容差异（某个小物件消失了或者多出来了）。我个人经验是每种类型混着来，难度曲线会更自然。

第三步，记录每个差异点的坐标。把原图放到 Photoshop 里，用参考线拉到你修改的位置，打开“信息”面板读取坐标值，然后除以图片的宽高，得到相对坐标。比如图片宽度是 750，差异点在横向 240 像素位置，那相对坐标就是 240/750=0.32。把这个小数写进关卡配置，容错半径建议设置在 25~40 之间，太大容易误点，太小容易点不中。

第四步，导出图片并同步更新配置。很多人改完图忘了改配置，结果图片上明显有一个差异点，程序却永远判定不到，这种情况最容易出现在新手改源码的过程中。

3.3 图片资源体积与加载优化

微信小程序对代码包有硬性限制：主包不超过 2MB，整个小程序所有分包加起来不超过 20MB（具体数值以微信公众平台最新文档为准）。找茬游戏的核心素材是图片，随便几张高清图就容易把包体积顶爆。所以素材的体积管理是让项目能正常提审上线的基本功。

图片优化有两个方向：一是压制单张体积。JPG 图片建议控制在 150KB 以内，PNG 尽量不超过 100KB。可以用 TinyPNG、Squoosh 这类工具批量压缩。二是打包策略。如果关卡比较多，不要把全部图片打包进主包，应该把素材按关卡拆到分包里，用 分包异步化 或者在小程序启动后的空闲时间加载。

另外，既然是纯前端项目，图片也可以放到 CDN 上，通过网络路径加载。这样主包体积会小很多，但代价是必须在小程序后台配置 downloadFile 合法域名，域名必须是 HTTPS 且备案过的。对于想快速跑通源码的朋友，建议先在本地用小体积图片跑通功能，再考虑 CDN 优化。

4. 从空白到上线：完整搭建与发布实操

4.1 前期准备：账号、开发者工具、AppID

要从零把源码跑起来，需要的准备我用三句话概括：注册一个小程序账号，下载微信开发者工具，拿到属于你自己的 AppID。

账号注册在微信公众平台进行，类型选择“小程序”。这里要注意主体类型的差异：个人主体注册门槛低，但小程序游戏类目在部分能力和类目审核上有限制；企业主体能用的权限更全，如果你想发布正式的游戏类小程序，建议优先用企业主体注册。

注册完成后，在“开发管理 - 开发设置”页面能看到 AppID。这个 AppID 是每个小程序唯一的身份标识，后面导入源码时要替换掉源码里自带的 AppID。

微信开发者工具可以直接从官网下载，选择稳定版即可。安装完成后用微信扫码登录，开发工具会自动关联你注册的小程序账号。

4.2 导入源码、修改配置、本地预览

准备工作做完，就到了最核心的搭建环节。我会按步骤拆开写，你对照着操作就行。

第一步，打开微信开发者工具，点击“导入项目”。在弹窗里选择源码所在的目录，AppID 填入你自己申请的 AppID，后端服务选择“不使用云服务”，然后点击确认。如果源码里自带的 project.config.json 有旧的 appid，工具会提示是否覆盖，选择“是”即可。

第二步，等工具完成编译，模拟器里应该能看到首页。如果首页白屏，大概率是页面路径配置有问题，或者代码里有报错，打开调试器 Console 面板看错误信息，定位到对应文件修复。这一步是最容易卡住的地方，后面问题排查章节我会单独讲。

第三步，检查 app.json 里的 pages 数组和 window 配置。pages 数组第一项是首页路径，决定打开小程序后第一个渲染的页面。window 里的 navigationBarTitleText 是顶部导航栏标题，可以改成你自己的游戏名。

第四步，在开发者工具左侧菜单栏点击“预览”，生成一个预览二维码，用手机微信扫码，可以在真机上体验完整流程。真机预览和模拟器表现会有差异，尤其是图片尺寸、触摸坐标这些环节，建议务必在真机上把前几关完整玩一遍，确认判定正常再继续。

整个流程走完，你的本地搭建就算完成了。如果只是自己体验，到这里就够了。但如果想让别人也能通过微信搜到、打开这个游戏，还需要走上传和审核流程。

4.3 提交审核与发布上线

上传发布的第一步，在开发者工具右上角点击“上传”按钮，填写版本号和备注信息，代码就会同步到微信公众平台的“开发管理 - 版本管理”里。

第二步，登录微信公众平台，在“版本管理”页面找到刚上传的开发版本，点击“提交审核”。提交时选择类目，找茬属于游戏类，需要按照平台要求选择对应的游戏类目并提交相关资质。如果暂时没有资质，也可以先在自己账号里体验，正式发布前再补。

第三步，审核通过后，在“版本管理”页面点击“发布”，小程序就会进入线上版本。发布后微信搜索小程序名称就能找到它。

整个提审流程里有两个容易被退回的坑：一是分享功能如果设计成“分享后解锁下一关”，会被判定为诱导分享；二是素材图片如果涉嫌版权问题或违规内容，会被直接打回。这些我在下一节详细讲。

5. 搭建路上的常见问题和排查速查表

5.1 白屏、页面空白、图片不显示

这类问题在搭建初期最常遇到，原因通常集中在以下三个方面。

页面路径配置错误。app.json 里的 pages 数组和实际目录不匹配，小程序启动时找不到入口页面，表现就是白屏。解决方法是打开 app.json，确认 pages 数组里的每个路径都能在项目里找到对应文件，路径大小写也要完全一致。微信开发者工具对路径大小写敏感，Windows 上不区分大小写、macOS/Linux 上区分，很多跨平台协作的项目在这个上面翻过车。

图片不显示。如果页面结构出来了但图片区域是空白，先检查图片路径是不是相对路径写对了，再检查文件名大小写和扩展名。小程序本地图片路径必须放在项目目录下，不能用绝对磁盘路径，也不能直接引用项目外的文件。还有一种情况是图片体积太大导致加载慢，看起来像没显示，可以观察 Console 有没有资源加载失败的提示。

代码报错导致页面中止渲染。打开调试器 Console 面板，如果有红字报错，把报错信息复制到搜索里查一下，基本都能定位到具体文件。常见的是 app.js 里初始化数据时引用了不存在的字段，或者某个库文件没引入完整。

5.2 点击判定不准、位置偏移

点击判定不准，通常是坐标系没有换算对。可以按下面的排查顺序逐一检查。

先确认图片的渲染模式。wxml 里的 image 组件如果设置了 mode="aspectFit"，图片会在容器内等比缩放并留边。此时触摸坐标换算必须用图片实际显示区域的 rect，而不是外层容器的 rect。可以把 mode 改成 aspectFill 或者让图片容器和图片完全贴合，减少换算误差。

再检查坐标换算公式。触摸坐标 clientX/clientY 要减去图片 rect 的 left 和 top，再乘以图片原始尺寸和渲染尺寸的比值。很多源码里漏掉了“原始尺寸/渲染尺寸”这步，导致差异点坐标和触摸坐标不在同一个坐标系。把这一步补上，绝大多数偏移问题都能解决。

最后检查差异点配置数据。如果用的是相对坐标，确认存的是 0~1 的小数；如果用的是绝对像素坐标，确认和图片原始像素尺寸匹配。不要混用两种坐标系，混用必出问题。

5.3 审核被拒的常见原因

小程序提审被拒主要集中在两个方向：类目资质和内容规范。

游戏类小程序对版号和软件著作权有明确要求，尤其是涉及虚拟支付的功能。找茬这类休闲游戏，如果只是展示广告、不提供内购，相对容易过审；但如果加了道具购买、金币充值这类虚拟支付功能，就必须先补齐相关资质。个人开发者想上线游戏类目会辛苦一些，建议提前在微信公众平台查看最新的类目资质要求。

内容规范方面，最容易踩的是诱导分享和侵权。文案里出现“分享给好友才能继续玩”“转发后解锁”这类话术，属于典型的诱导分享，会被拒。图片素材用了未经授权的版权图片，可能会因为投诉而下架。建议在准备素材时留好来源凭证，UI 和音效也尽量使用可商用授权素材。

这里也整理一个遇到问题时的排查速查表，方便你快速定位：

5.4 一个提升排查效率的习惯

再多说一个习惯：改代码之前先把源码复制一份备份，或者直接用 Git 初始化一个仓库，每改一个功能提交一次。找茬小游戏的判定逻辑牵一发动全身，改素材、改配置、改页面样式都有可能互相影响。有版本管理兜底，改崩了还能回滚，省下来的时间远比初始化仓库花掉的那几分钟多。

6. 后面的优化和扩展方向

源码跑通只代表开始，要让这个找茬小游戏真正具备运营价值，还可以在几个方向上继续扩展。

第一个方向是做关卡编辑器。把差异点坐标配置从代码里抽出来，做成一个内部工具页面，直接在真机上点选坐标、设置容错半径、预览命中效果。这样新增关卡就不用反复修改 JSON 文件然后重新上传，运营效率会显著提升。

第二个方向是接入云开发做排行榜和用户体系。找茬游戏的用户天然有竞争心理，加上好友排行之后，次日留存会有明显提升。用微信云开发可以快速实现用户登录、分数提交、排行榜查询，不需要自己搭建服务器。

第三个方向是广告变现。找茬小游戏很适合接入微信流量主。比较自然的广告位有两个：通关结果页放 Banner，提示次数用完时放激励视频广告，看完广告增加提示次数。这样既不打断核心体验，又能形成稳定收益。开通流量主需要满足微信的 UV 门槛，达到之后在公众平台自助申请即可。

第四个方向是内容运营。找茬游戏的内容就是关卡本身，定期更新新关卡、节日主题关卡，保持在微信群和朋友圈的分享热度，玩法可以一直延续下去。

我个人在实际操作中的体会是：源码跑通只算开头，真正有价值的是你把判定逻辑和素材制作流程吃透之后，可以完全按照自己的思路去二次开发。找茬这个品类看着简单，但差异点设计、难度曲线、提示时机这些细节，直接决定玩家的去留。特别是素材制作，我建议你一定要亲手做一关试试——从选图、改图、记录坐标到最终在真机上命中，完整走完这个过程，你对这个项目的理解会有质的提升。

最后再分享一个小技巧：改完素材或者调完坐标后，不要只在开发者工具模拟器里测试，一定要用真机预览把每一关从头到尾过一遍。模拟器的触摸事件和真机差异不小，坐标判定、图片渲染、音效播放这些环节都可能有细微差别。真机测试通过，这个版本才算真正做好了。

本文还有配套的精品资源，点击获取