Canvas实现微信找茬小游戏：从开发到流量主变现

简介：这是一份可直接部署学习的微信益智小游戏源码包，涵盖“大家来找茬”“找不同”两类玩法，并已接入流量主功能，适合微信小程序开发者、独立游戏爱好者用于研究游戏逻辑、界面交互与广告变现方案。压缩包内共2005个文件，以1642张png游戏素材、295张jpg图片为主，配合18个js逻辑脚本、13个json配置、10个wxss、9个wxml页面结构，以及mp3、html、php等辅助资源，整体容量401.76MB，目录结构完整，已有80人学习下载。源码包含完整的前端页面、游戏匹配逻辑、关卡数据与广告组件调用示例，便于开发者快速了解微信小游戏开发规范，也能在此基础上进行二次开发或功能扩展，尤其适合想从零掌握“找茬”类游戏实现思路和流量主接入流程的初学者。

1. 微信益智小游戏大家来找茬:一份带流量主的找不同源码包,到底该怎么落地

如果你拿到一份「大家来找茬」的微信益智小游戏源码包,名字里还带着「找不同微信小游戏」和「带流量主.zip」,那它的价值就不只是找茬玩法本身,而是「游戏 + 广告变现」的整套闭环。找茬类的用户行为很直接:看图、找差异、点下去、过关,天然适合用激励视频换提示、用 Banner 垫底收益。对刚接触微信小游戏的人来说,与其从空项目开始,不如先把这种 zip 解压、跑通、替换素材,再理解广告组件怎么接。这篇笔记会顺着一条完整落地路径展开:技术选型、找茬玩法实现、流量主接入、审核上架和上线后的运营验证。适合谁?想快速上线第一款微信小游戏,并且靠广告流量产生收入的小团队和个人开发者。

2. 找茬小游戏的技术选型:别让「Unity微信小游戏打包」这个大词带偏你

2.1 微信小游戏不是网页游戏:先分清运行时再动手

很多做 Web 的朋友第一次接触微信小游戏,第一反应是拿 HTML 页面改一改。结果一导入开发者工具,发现document根本不存在,白屏黑屏翻车。微信小游戏运行在微信自带的 JavaScript 运行时里,没有 DOM、没有 BOM,也没有 WXML/WXSS,唯一稳定的渲染入口是 Canvas 2D 或 WebGL。它能调用的是一套wx.*API,比如wx.createCanvas、wx.createImage、wx.onTouchStart。这和微信小程序不是一回事:小程序有页面结构,小游戏更像一个独立的游戏运行时,只是外面套着微信的壳。

所以解压 zip 之后,第一件事不是看代码,而是确认它到底是不是小游戏工程。如果压缩包里出现index.html这类文件,基本可以判断是网页版误传,不能直接在微信小游戏里跑。现在很多教程还推荐用 Unity 导出微信小游戏包,那个路线适合 3D 或中重度游戏,对找茬这种 2D 益智品类属于杀鸡用牛刀。Unity 导出的包体动辄几 MB 起步,首个场景加载慢,冷启动体验反而差。找茬游戏的核心交互就是两张图、一次点击判定,原生 Canvas 完全够用,别让「Unity微信小游戏打包」这个热搜词带偏你的技术选型。

2.2 渲染方案:Canvas 2D 就够,不需要上 WebGL

找茬游戏的画面复杂度很有限:背景图、两张对比图、提示圈、按钮和少量文本。Canvas 2D 的drawImage足够把所有素材画出来,再加上arc/fill画提示圈、fillText画倒计时。上 WebGL 只会让代码复杂度成倍增加,还要处理着色器、纹理上传,收益却很小。除非你想做图片放大镜、模糊特效、平滑过渡这些高端玩法,否则别给自己找麻烦。

实现上我一般会定一个「设计分辨率」,比如以 iPhone 6 的逻辑宽度 750 为基准,所有关卡数据、差异点坐标都按这个坐标系设计。运行时再根据实际屏幕宽度做缩放:

// 入口文件:小游戏引擎会加载 game.js 并执行 const canvas = wx.createCanvas(); // 获取主画布 const ctx = canvas.getContext('2d'); const DESIGN_WIDTH = 750; // 设计稿宽度,以 iPhone 6 逻辑宽度为基准 const DESIGN_HEIGHT = 1334; const scale = canvas.width / DESIGN_WIDTH; // 实际屏幕宽 / 设计稿宽 ctx.scale(scale, scale); // 入口只做场景分发,具体逻辑交给场景模块 const { Game } = require('./js/game'); const game = new Game(ctx); game.start();

这段代码有两个关键点。一是wx.createCanvas()只能拿一次主画布,后续要创建离屏画布可以再调,但不要用它做离屏渲染,否则会干扰主画面。二是ctx.scale(scale, scale)会让所有绘制命令自动换算,你写代码时按 750 宽的坐标想问题就行。代价是点击坐标和绘制坐标不再一致,这个我在第 5 章展开讲,它是找茬小游戏最典型的偏移坑。

2.3 解压 zip 后先认目录结构,再导入开发者工具

拿到「带流量主.zip」,不要急着双击导入。先用解压工具解开,最好放到纯英文路径,比如D:\wechat\find_diff。因为微信开发者工具对中文路径的兼容性时好时坏,资源引用偶尔会因为路径编码炸掉。解压后先看根目录有哪些内容:

# 建议整理成这样的工程结构 game.json game.js project.config.json images/ level_001_a.png level_001_b.png js/ game.js level.js ad.js audio/ click.mp3

如果解压出来是嵌套的一层目录,比如find_diff-master/game.json,直接导入会报「找不到 app.json」或「找不到 game.json」,因为工具把外层目录当成了工程根目录。解决办法是把内层文件移动出来,让game.json位于你即将导入的目录顶层。game.json是小游戏最重要的配置文件,字段不多,但决定运行方向:

{ "deviceOrientation": "portrait", "showStatusBar": false, "networkTimeout": { "request": 10000 } }

deviceOrientation固定为portrait,强制竖屏,符合找茬的阅读习惯;showStatusBar控制是否显示微信状态栏,游戏类一般关掉,让画面铺满;networkTimeout.request是网络请求超时时间,默认单位毫秒,10 秒比较保守。后面接流量主和上报数据都要走wx.request,这个字段会直接影响到广告拉取和数据上报的失败速度。导入时记得在开发者工具里选「小游戏」项目类型,而不是「小程序」,否则连wx.createCanvas都会报错。

3. 找茬玩法的核心实现:用 Canvas 和 JSON 把找不同做成可扩展关卡

3.1 找茬玩法的最小实现:两张图、一个点击区域

找茬的最小闭环可以拆成三件事:画左图、画右图、判断用户点的位置是不是差异点。听起来简单,但代码组织不好就变成一团乱麻。我一般会建一个独立的FindDiffScene场景类,构造函数接收游戏上下文和当前关卡数据,内部维护游戏区域的位置和尺寸:

class FindDiffScene { constructor(ctx, levelData) { this.ctx = ctx; this.level = levelData; // 图片显示区域,坐标基于 750 设计稿 this.gameArea = { x: 0, y: 120, width: 750, height: 500 }; } draw() { const ctx = this.ctx; const a = wx.createImage(); a.src = this.level.imageA; a.onload = () => { ctx.drawImage(a, this.gameArea.x, this.gameArea.y, this.gameArea.width, this.gameArea.height); }; const b = wx.createImage(); b.src = this.level.imageB; b.onload = () => { // 右侧留 20 像素间距,避免两边贴死 ctx.drawImage(b, this.gameArea.x + this.gameArea.width + 20, this.gameArea.y, this.gameArea.width, this.gameArea.height); }; } }

这里有个细节:两张图如果完全一样大并排,用户余光扫过去容易晕。所以我一般会把右侧图整体往右偏移一点,或者中间留一条固定的间隔带。drawImage的五个参数分别是图片对象、目标 x、目标 y、目标宽、目标高,所有值都按 750 设计稿来,因为入口已经ctx.scale过了。图片加载是异步的,如果同时加载几十张素材,首帧会全空,所以素材预加载要单独做,不要把资源请求直接放在draw里。找茬游戏的素材预加载,我会在启动阶段用wx.createImage+onload计数器把图片全部拉进内存,再进入关卡,否则用户会看到白底闪一下,体验很差。

3.2 用 JSON 描述每个关卡:差异点坐标、容差半径和提示文案

找茬最常见的翻车设计,是每关中把差异点坐标写死在代码里。比如if (x > 100 && x < 120)这种判断,第一版跑得通,等你想加关卡、调难度、做 A/B 测试,只能改代码重新发版,审核周期长得让人崩溃。正确做法是把关卡当作纯数据,差异点和判定参数全部放进 JSON:

{ "levelId": "level_001", "width": 750, "height": 500, "imageA": "images/level_001_a.png", "imageB": "images/level_001_b.png", "diffRadius": 30, "timeLimit": 60, "diffs": [ { "x": 120, "y": 80, "radius": 30, "hint": "帽子颜色" }, { "x": 300, "y": 220, "radius": 30, "hint": "少了只耳朵" } ] }

x和y是差异点中心相对于图片显示区域左上角的坐标,不是整张屏幕的坐标。radius是判定容差半径,单位也是设计稿像素。这个值直接决定游戏难度:半径越大越容易点到,适合前期关卡;后期可以缩小到 20 或 15,让玩家精确点击。timeLimit是关卡限时,找茬这类益智小游戏一般控制在 60 到 90 秒,太长失去紧张感,太短用户没耐心。hint是看激励视频后展示的提示文案,比如「帽子颜色」,用来缩小寻找范围。

为什么要单独给每个差异点配radius,而不是统一用全局diffRadius?因为每张图的元素密度不一样。密集区域差异点靠得近,容差大了会一次匹配多个;稀疏区域差异点离得远,容差小了又太难。运营后期调难度,直接改 JSON 比改代码高效得多,这也是我之前踩过的坑:第一版把所有差异点半径写死 30,结果有一张图元素特别小,玩家点半天点不中,流失率很高。后来改成每个点独立半径,曲线舒服很多。

3.3 点击判定、计时与关卡进度:三个模块别耦合在一起

点击判定是找茬游戏的核心准确性来源。监听触摸事件后,先把触摸坐标换算成图片显示区域内的相对坐标,再遍历当前关卡所有未被找到的差异点,做距离判断:

function hitTest(touchX, touchY, diff) { const dx = touchX - diff.x; const dy = touchY - diff.y; return Math.sqrt(dx * dx + dy * dy) <= diff.radius; } function onTap(e) { const touch = e.touches[0]; // 注意:这个坐标需要根据你的缩放策略做换算,第 5 章细说 const px = (touch.clientX - this.gameArea.x) / this.scale; const py = (touch.clientY - this.gameArea.y) / this.scale; const matched = this.level.diffs .filter(d => !d.found) .find(d => hitTest(px, py, d)); if (matched) { matched.found = true; this.drawCircle(matched.x, matched.y); wx.vibrateShort({ type: 'medium' }); } else { this.wrongCount += 1; } }

判定逻辑用勾股定理算两点距离,小于等于半径就算命中。filter(!found)是为了避免同一个差异点被反复点击计数。命中后画一个圆圈标记,并且震动一下,给用户明确的物理反馈。wx.vibrateShort的type参数在部分安卓机型上不支持medium,会静默失败,所以别把震动当作唯一反馈,圆圈和音效也要有。

计时模块我吃过亏:第一版用setInterval每秒减 1,用户切后台再回来,剩余时间还停留在切出前的值,等于白送时间。正确做法是记录开始时间,在定时器里用Date.now()差值计算剩余秒数:

class Level { constructor(data) { this.diffs = data.diffs.map(d => Object.assign({}, d, { found: false })); this.timeLimit = data.timeLimit; this.remaining = data.timeLimit; this.startedAt = 0; this.timer = null; this.status = 'idle'; } start() { this.startedAt = Date.now(); this.status = 'running'; this.timer = setInterval(() => { this.remaining = this.timeLimit - Math.floor((Date.now() - this.startedAt) / 1000); if (this.remaining <= 0) { this.fail(); } }, 250); } useHint() { const target = this.diffs.find(d => !d.found); if (target) { // 只展示提示文案,不直接标为 found this.showHintText(target.hint); } } fail() { clearInterval(this.timer); this.status = 'failed'; } checkComplete() { return this.diffs.every(d => d.found); } }

setInterval间隔设 250 毫秒而不是 1000 毫秒,是为了让倒计时显示刷新更平滑,避免用户感觉数字「跳了一下」。useHint不会把差异点直接标成found,只展示文案,因为激励视频换提示的本质是「缩小搜索范围」,不是「替你完成游戏」。如果直接标记,用户会失去后续点击的成就感和互动性,反而降低留存。fail和checkComplete分开,关卡状态机保持简单,后面接复活看广告的逻辑会清爽很多。

4. 带流量主的变现接入:Banner 加激励视频的参数、写法与上线切换

4.1 流量主是什么,以及开通前要满足什么条件

流量主是微信广告平台面向小程序和小游戏开发者的变现能力。你在游戏里放广告位,用户看到广告、产生曝光或点击,平台结算广告收益给你。微信小游戏流量主的开通,一般要求累计独立访客数量达到一定门槛,常见说法是累计 UV 不低于 1000,具体数字以微信公众平台后台为准。所以别一拿到源码就开始设计广告位,先把游戏跑通、让别人玩起来,达到门槛再去「流量主」模块申请开通。开通后在后台新建广告位,会拿到一个形如adunit-开头的广告位 ID,这个 ID 要填进代码里。

找茬类小游戏为什么适合流量主?因为它天然有「卡住」的时刻:玩家找不到最后一个差异点,焦躁、卡关、想放弃。这时候弹一个激励视频「看广告获得提示」,用户接受度高,广告完播率也高。Banner 则适合放在底部或结果页,不打断主流程,靠多页面曝光积累收入。激励视频是找茬游戏的变现主力,Banner 是补充,两者别反过来。

4.2 Banner 广告和激励视频广告的最小接入代码

广告接入最好独立成一个模块,不要散落在游戏场景里。我一般会写一个adManager,统一初始化和错误上报:

const adManager = { bannerAd: null, videoAd: null, init(adUnitIds) { // 横幅广告:创建后不立即 show,等页面布局稳定再展示 this.bannerAd = wx.createBannerAd({ adUnitId: adUnitIds.banner, style: { left: 0, top: 0, width: 320 } }); this.bannerAd.onError(err => this._log('banner error', err)); this.bannerAd.onResize(size => { // 根据实际渲染尺寸重新定位,通常放在屏幕底部安全区上方 const info = wx.getSystemInfoSync(); const left = Math.floor((info.windowWidth - size.width) / 2); const top = Math.floor(info.windowHeight - size.height - (info.safeArea ? info.safeArea.bottom : 0)); this.bannerAd.style.left = left; this.bannerAd.style.top = top; }); // 激励视频:只能由用户主动点击触发 this.videoAd = wx.createRewardedVideoAd({ adUnitId: adUnitIds.video }); this.videoAd.onError(err => this._log('video error', err)); this.videoAd.onClose(res => { if (res && res.isEnded) { EventBus.emit('on-reward'); } }); }, showVideo() { this.videoAd.show().catch(() => { this.videoAd.load().then(() => this.videoAd.show()); }); }, _log(tag, err) { console.warn('[ad] ' + tag, err); } };

这段代码有几个参数值得细看。wx.createBannerAd的style.width是 Banner 的渲染宽度,但微信会按实际广告物料做等比调整,所以别硬算高度,用onResize回调里返回的size来重新定位。onResize在初始化时也会触发一次,正好用来把 Banner 放到屏幕底部安全区上方。windowHeight - size.height - safeArea.bottom本质是确保广告不被 iOS 底部横条遮挡。

激励视频的show()返回 Promise,失败时常见原因是广告还没加载完成,所以 catch 里先load()再show()是标准补救手法。onClose返回对象里的isEnded是判断用户是否完整看完视频的关键:只有完整看完才发奖励,中途退出不发。找茬游戏里「提示」就是奖励,可以在同一局多次看广告,但一定要做频控,后面会讲。

4.3 广告位测试与正式广告的切换:开发阶段最容易翻车的点

很多新手把代码里的adUnitId填成占位符,比如adunit-xxxx、adunit-test,结果后台又没有对应的广告位,上线后平台无法填充广告,收益当然是 0。我一般用一张表约束自己:

测试广告位和正式广告位的核心差别是:测试 ID 不会产生真实收益,而且可以随时失效。提审前必须全局搜索adunit-字符串,逐个核对。另一个坑是 Banner 广告在开发者工具里经常加载不出来,这很正常,不代表真机有问题。真机预览时如果也加载不出来,优先看onError返回的错误码,常见的是广告位无效或当前账号未开通流量主。广告的填充率在冷启动阶段很低,不是代码坏了,是平台还需要时间学习你的用户群体。

4.4 广告与玩法的平衡:别为了收入把留存做没

流量主的收入公式大致是曝光、点击、eCPM 的综合结果,但前提是用户还在你的游戏里。找茬小游戏最容易出现的错误是 Banner 盖住图片区域,用户找差异点找得正投入,一抬头广告挡住了关键位置,直接关游戏。Banner 只放在底部、结算页和失败页,不要放在游戏画布中间。激励视频的入口要放在「提示按钮」和「失败后复活」这两个位置,这是用户最需要帮助的心理节点,转化率远高于主界面常驻广告。另外要给激励视频做每日次数上限,比如每天最多看 10 次,防止个别用户刷广告换提示,既抬高广告成本,又让游戏失去挑战性。这些参数不适合写死在代码里,建议放到服务端远程配置,紧急情况下可以远程关停所有广告,不用重新发版。

5. 从 zip 解压到审核上架:找茬小游戏最常见的 5 个坑与排查思路

5.1 zip 解压后目录层级不对:报「找不到 game.json」

现象:导入微信开发者工具,直接报错说找不到game.json,或者编辑器里白屏,没有任何代码加载。原因:绝大多数 zip 包在压缩时把工程放在了一个嵌套目录里,比如大家来找茬-带流量主/game.json,开发者工具把外层文件夹当成了工程根目录,导致配置缺失。另一个常见原因是压缩包来自 Windows 平台,中文文件名在 macOS 或 Linux 上解压后乱码,资源路径对不上。解决:先解压到英文路径,确认game.json在根目录;如果有多层嵌套,把文件复制出来重新整理;乱码文件用支持编码转换的解压工具重新解压,或者干脆全部重命名成小写英文名。这类问题占所有「打不开」原因的六成以上,先看目录,别急着改代码。

5.2 点击坐标偏移:模拟器正常、真机点不准

现象:在开发者工具模拟器里,点差异点一找一个准;换到 iPhone 或安卓真机,点击位置偏上或偏下,甚至完全没反应。原因:这是找茬小游戏最典型的翻车点。入口文件里做了ctx.scale(scale, scale),绘制坐标被缩放了,但触摸事件的clientX/clientY还是物理像素坐标,没有做逆变换。加上刘海屏、底部安全区存在,clientY的零点在不同机型上并不一致。解决:用wx.getSystemInfoSync()拿到windowWidth/windowHeight和safeArea,在触摸回调里把坐标换算回设计稿坐标系:

function toLogicalPoint(clientX, clientY) { const info = wx.getSystemInfoSync(); const scaleX = info.windowWidth / DESIGN_WIDTH; const logicalX = (clientX - gameArea.left) / scaleX; const logicalY = (clientY - gameArea.top - (info.safeArea ? info.safeArea.top : 0)) / scaleY; return { x: logicalX, y: logicalY }; }

注意scaleY不一定等于scaleX,因为不同机型纵横比不同;严谨做法是宽和高的缩放分别算。这个坑特别适合用「血泪经验」形容:我第一次上线时,模拟器全对,真机 iPhone 8 也全对,结果 iPhone X 刘海屏上所有点击都往下偏了 44 像素。后来统一用safeArea.top修正,才彻底解决。

5.3 资源路径大小写问题:本地正常、线上图片 404

现象:开发工具里图片正常显示,上传代码后用手机预览,部分图片变成空白或灰块。原因:开发工具运行在 Windows 或 macOS 上,文件系统对大小写不敏感,但小游戏在上传后运行在微信客户端资源系统里,对大小写是敏感的。代码里写Images/level_001_a.png,实际目录是images/level_001_a.png,本地能跑,线上就直接 404。另一个原因是图片路径使用了绝对路径或带../的越级引用,在小游戏包里不被允许。解决:统一资源目录和文件名全部小写加下划线,比如images/level_001_a.png;全局搜索代码里出现的.png、.jpg,逐个和目录核对;导入图片时不要把图片放在工程外部的路径,小游戏会把整个工程目录打包,越级引用会全部失效。

5.4 流量主收入为 0:先自查这四步

现象:游戏上线了两三天,后台广告收益一直显示 0。原因通常不在游戏代码本身,而是链路某处断了。第一步检查后台是否真的开通了流量主,并创建了广告位;第二步全局搜索adunit-,确认代码里的 ID 是后台的正式 ID,不是占位符;第三步真机打开游戏,用 vConsole 或开发者工具的真机调试看onError有没有输出告警,如果报「广告位无效」,说明 ID 和当前账号不匹配;第四步确认激励视频入口真的存在,而且用户能主动触发。找茬游戏如果提示按钮做得太隐蔽,激励视频曝光可能为 0,收入自然也归零。还有一个容易忽略的点:冷启动阶段平台广告填充率低,尤其新游戏没有用户画像,经常没有广告可展示。这不是 bug,继续正常运营积累用户,一般几天后会慢慢稳定。

5.5 审核被拒:隐私、资质和广告体验各占三分之一

现象:提审后收到驳回,常见理由包括「类目选择不对」「缺少隐私保护指引」「广告组件影响正常使用」。原因:微信小游戏对游戏类目有资质要求,提审时选择的类目需要匹配对应资质文件;如果你的代码调用了wx.getUserInfo、wx.getLocation这类隐私接口,但后台没有配置《用户隐私保护指引》,也会被驳回;还有一种情况是 Banner 广告挡住了核心玩法区域,审核人员觉得广告干扰了正常游戏。解决:提审前到 MP 后台完善《用户隐私保护指引》,哪怕代码里只调用了wx.getSystemInfo,也要检查一下接口是否在隐私声明覆盖范围内;游戏类目需要的资质文件按要求上传;Banner 广告位改成可关闭或移动到非交互区域。审核期间尽量关闭测试广告,用正式广告位,但不要用强制弹出广告干扰审核体验。这类问题没有统一修法,被拒后看驳回理由照做就行。

6. 上线后做什么:用埋点、A/B 难度和广告数据把找茬游戏养起来

6.1 先埋点,再看留存:别把感觉当依据

游戏上架只是开始,真正的运营动作是看数据。找茬小游戏最值得埋点的位置是关卡开始、关卡胜利/失败、提示按钮点击、广告关闭、复活按钮点击。把这些事件上报到自己的统计服务,比事后拍脑袋分析靠谱得多。最省事的做法是用wx.request自己的接口:

function trackLevelEnd(levelId, result, usedTime, hintUsed) { wx.request({ url: 'https://your-domain.com/api/events', method: 'POST', data: { game: 'find_diff', levelId: levelId, result: result, usedTime: usedTime, hintUsed: hintUsed }, header: { 'content-type': 'application/json' } }); }

注意wx.request的域名必须在 MP 后台配置为合法请求域名,否则线上会直接请求失败。这个坑比想象中普遍:很多人在开发者工具里勾选了「不校验合法域名」,就以为服务器配置没问题,上线后静默失败。埋点数据里usedTime是用户完成关卡用时,hintUsed是是否使用了提示,这两项直接反映关卡难度是否合理。如果某关失败率超过 70%,且平均用时接近时间上限,说明难度曲线太陡,该调了。

6.2 用匿名分组做关卡难度 A/B 测试

找茬游戏的最佳难度不是开发者自己拍脑袋定的,而是用对比数据试出来的。我一般会在本地生成一个匿名用户 ID 存到wx.setStorageSync,然后按 ID 奇偶分两组:A 组用默认差异点半径 30,时间 60 秒;B 组用半径 28,时间 50 秒。跑一周对比两组的通关率和次日留存,清晰得出哪个难度更合适。这个手法不需要接入任何第三方 SDK,就是游戏启动时读一下分组参数,关卡加载时套用不同 JSON 字段。

我自己的习惯是把关卡 JSON 和难度参数都放在服务器端,客户端每次启动拉取一次,这样调难度不需要提审发版。早年第一版找茬游戏把差异点坐标写死在代码里,每次调难度都要重新经历审核周期,等到能改,用户已经流失得差不多了。后来改成远程配置,试错成本低了一个量级,广告数据也稳定不少。这个教训一直留到现在:游戏源码的价值不只是能跑,而是能不能被快速调整、快速验证。如果你手上这份「带流量主.zip」也是把广告模块和关卡模块分开放的,那它的可运营性就很好;如果全揉在一坨,建议尽快按我上面说的结构拆开,否则后续所有调优都会很痛苦。希望帮到你。

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