企业官网建设流程全解析

先交代一下背景。我最近在整理一套300款H5小游戏的合集，起因是接手了一个网页游戏盒子项目，需要长期维护一批能在浏览器直接打开、不用装App的游戏资源。整理工作一开始只是把收集到的文件堆到文件夹里，结果越堆越乱，后来花了整个周末重新设计分类和索引，顺便把兼容性、加载性能、移动端适配的问题都过了一遍。折腾完这轮，我最大的感受是：H5小游戏确实门槛低，但想整理出一套能长期复用、分发给别人也不翻车的合集，里面的门道比想象中多不少。

这篇内容适合三类人看：一是前端学习者，想找一批简单项目练手拆解；二是运营或站长，想快速搭一个游戏内容板块；三是H5开发工程师，想了解批量文件管理、索引生成、兼容性适配这类工程化经验。我按自己的整理思路往下说，尽量少讲虚的，多数判断都是我实际踩过坑之后换来的。

1. 整体设计：先想清楚合集是给谁用的

1.1 只有明确场景，才知道300款游戏该怎么选

很多人一听“300款小游戏”，第一反应是把网上能找到的全部塞进来，数量凑够就行。但我整理到一半就发现，如果没有使用场景约束，这个合集基本是废的。游戏文件的水平参差不齐，有的只有几千字节，有的打包了完整美术资源有几十兆，运行方式也完全不同。如果目标是做“游戏盒子”，那优先要的是体感轻、加载快、玩法明确的小型游戏；如果目标是做“教学案例库”，反而要保留一些代码结构精巧、技术栈丰富的项目。

所以我在动手前先给自己定了几条选型标准：

• 优先选单文件H5游戏，一个HTML文件包含全部结构、样式和脚本，方便分发和二次打包
• 排除需要外部服务器接口才能运行的游戏，比如依赖后端登录、排行榜、存档验证的项目
• 排除明显带商业授权风险、包含大量外部素材且未注明的游戏
• 每个文件体积控制在1MB以内，超过的要么压缩资源，要么直接砍掉

这几条标准看起来简单，实际砍掉了至少三分之一的手头资源。很多游戏单独玩没问题，但放到合集里就会变成“定时炸弹”——某个外部资源挂了，整张页面白屏。

1.2 合集的两种打开方式：列表索引和iframe容器

整理资源的时候，我同时考虑了两套使用场景：

第一种是直接把游戏文件放到服务器上，用户通过URL访问单个游戏页面。这种方式部署最简单，每款游戏就是一个独立页面，方便分享链接，也方便嵌入到其他系统里做营销活动页。

第二种是做一个聚合入口页，把所有游戏铺在列表里，点击后通过iframe在同一个站点内打开。这种模式适合“游戏盒子”产品，用户体验一致，所有操作都在同一个页面框架内完成。

我最终做了第二种，但保留了对第一种的支持。原因是：iframe容器能统一注入公共能力，比如用户系统、客服入口、全局异常上报。后面我接企业微信客服的时候，也是在这个框架层做的，不需要改任何一款游戏内部代码。

2. 分类体系设计：300款游戏不能只按名字排序

2.1 玩法类型分类：先定大方向，再做细分标签

300个文件直接铺开根本没法看。我按照主流H5游戏的玩法类型，把它们分成八个大类，每个大类下再拆细分标签。具体分类如下：

其中“儿童早教”是我后来专门加出来的。原因是这类游戏在整个合集里占比不小，而且很多是用DOM操作写的，没有复杂Canvas渲染，代码结构对新手非常友好。像热词里提到的“早读小兔子拔萝卜”这类游戏，逻辑简单、交互清晰，拿来做教学范例很合适。

2.2 技术实现分类：Canvas、DOM、WebGL的复杂度差异

整理时我还额外做了一层技术维度的标注。这层信息普通用户看不到，但对开发者价值很大。我习惯用三种标签区分：

• DOM实现：游戏画面由HTML元素和CSS控制，代码简单，适合入门阅读
• Canvas 2D实现：画面绘制在画布上，逻辑复杂一些，适合学习游戏循环和坐标系
• WebGL/3D实现：引入三维渲染，性能和画面感更强，但浏览器兼容性问题更多

以中国象棋小游戏为例，如果用的是纯HTML和JavaScript写棋盘、棋子和走子逻辑，那就是典型的DOM实现。代码通常包含一个二维数组表示棋盘状态，点击事件处理选子和走子，CSS控制棋子摆放位置。这类代码量不大，核心逻辑都在走子合法性和胜负判断上，是很好的算法练习素材。

我为什么坚持做技术栈标注？因为后续做合集升级时有很大帮助。文件越来越多，总有人会问“有没有适合改成微信小游戏的例子”，或者“有没有能直接嵌入可视化大屏的轻量级游戏”。有了技术标签，筛选就是一条命令的事，不用逐个打开文件看代码。

2.3 文件命名与版本管理：一套规范能避免无数麻烦

命名规范是整个整理过程中性价比最高的决策。现在我所有游戏文件都按下面的规则命名：

[编号]_[玩法类型]_[游戏名称]_[技术栈].html

举例：

• 001_chess_中国象棋_dom.html
• 042_puzzle_消消乐_canvas.html
• 156_action_跑酷小英雄_canvas.html

编号从001递增，不随分类变化，这样文件在文件夹里按编号排列就是固定的“合集顺序”，跟分类无关。一旦一个文件名成型，我不会再改，因为所有外部引用、索引文件、分享链接都可能依赖它。

版本管理我也做了简化处理。每款游戏保留一个稳定版本，不堆历史备份。之前吃过一次亏，为了保险把所有游戏的旧版、新版、修复版都留着，一个游戏三个文件，目录乱成一团。后来统一成“只留最新可用版”，修改前先拷贝出实验版，调完确认没问题再覆盖。单文件H5的特点是改坏了很容易发现，因为刷新页面就能看到结果，所以没必要长期保留多个版本。

3. 索引与加载器：用一份JSON管理300个文件

3.1 从手工维护到自动生成索引文件

游戏数量到一百左右的时候，手工维护游戏列表就变成了一件痛苦的事。之前我用一个静态HTML页面手写每个游戏入口，后来每加一款游戏就要复制一段结构代码，麻烦且容易出错。

后来我把所有游戏信息抽成了一份games.json，由它统一驱动列表页面和详情逻辑。每款游戏的结构大致是：

{ "id": "007", "name": "网页版中国象棋", "type": "棋牌桌游", "tech": "dom", "file": "007_chess_中国象棋_dom.html", "thumb": "thumbs/007.png", "desc": "经典中国象棋对弈，支持双人对战", "size": 182 }

这个JSON文件一体化承载了列表展示、搜索、筛选、详情页渲染等所有需求。往合集中加游戏时，我只需要在这份JSON里加一条记录，不需要动任何页面的结构代码。

3.2 批量生成索引的脚本思路

300条手写记录也太累。我写了一个Node.js脚本，直接扫描目录下的所有HTML文件，根据文件名自动解析出编号、类型、游戏名和技术栈，再读一下文件体积。遇到无法从文件名推断的信息，比如游戏描述和缩略图，就用规则补默认值，分批手工补录。

脚本部分逻辑截取如下：

const fs = require('fs'); const path = require('path'); const gameDir = './games'; const result = []; const files = fs.readdirSync(gameDir).filter(f => f.endsWith('.html')); files.sort().forEach(file => { // 文件名格式：001_chess_中国象棋_dom.html const match = file.match(/^(\d+)_([a-z]+)_(.+)_([a-z]+)\.html$/i); if (!match) return; const stat = fs.statSync(path.join(gameDir, file)); result.push({ id: match[1], type: match[2], name: match[3], tech: match[4], file: file, size: Math.round(stat.size / 1024 * 10) / 10, desc: '', thumb: '' }); }); fs.writeFileSync('./games.json', JSON.stringify(result, null, 2), 'utf-8'); console.log(`已生成 ${result.length} 条游戏索引`);

这脚本写得不复杂，但它解决了一个很实际的问题：每次收集一批新游戏，先丢进目录，跑一遍脚本，索引自动对齐。文件名如果不符合规范，脚本会跳过并打印一条提醒，相当于用脚本反过来强制维护命名规范。

3.3 列表页与iframe加载器的实现

游戏列表页我用了一个轻量方案：左侧分类筛选，右侧游戏卡片网格。点击卡片后，弹层内部用iframe加载对应的游戏文件。代码如下：

<iframe id="gameFrame" src="about:blank" frameborder="0"></iframe>

点击游戏时通过脚本修改iframe的src值：

function openGame(entry) { document.getElementById('gameFrame').src = '/games/' + entry.file; showOverlay(); }

这里有一个我之前踩过的坑：iframe加载本地路径时，如果直接用file://协议访问，大多数现代浏览器会限制内部脚本执行，很多游戏运行失败。所以这个合集必须放到HTTP服务下访问，本地调试用http-server这类工具开个静态服务就行。我当时就是踩了这个坑，开始以为游戏文件坏了，排查了半天才发现是本地直接双击打开导致的浏览器安全限制。

3.4 缩略图方案：能省则省，别追求完美

300个游戏的缩略图是整理过程中最耗时的一环。我之前尝试过用无头浏览器给每个游戏页面截图，但很多游戏页面加载前需要有用户交互才展示有效画面，自动截图经常截到空白或者loading状态。

后来我放弃了截图工具，改用人工在游戏运行后截取关键画面，统一压缩成350px宽的小图，保存到thumbs目录。再后来连人工截图都懒得做了，因为有些游戏本身页面背景和标题就足够好看，直接裁剪页面顶部区域即可。如果你也想做一个类似合集，我的建议是：缩略图前期用统一渐变背景加游戏名称文字代替，等合集验证有价值之后，再分批补截图。不要一开始在这里消耗大量时间。

4. 构建合集的实操流程：从收集到上线

4.1 收集与去重是第一步，也是最容易被忽略的

收集游戏时，我从内部素材库、开源项目、个人分享多个渠道搞到大量资源。汇总后第一件事不是分类，而是去重。很多游戏在不同渠道被多次分享，文件名不同，但文件哈希完全相同；还有一些是同一个游戏改了个标题就再次发布。

去重我用一个简单的脚本扫描所有文件MD5值：

md5sum games/*.html | sort | awk '{print $1}' | uniq -d

通过对比哈希值，快速找出完全重复的文件。对于内容相似但哈希不同的游戏，只能靠人工抽查判断。这类判断通常看三点：页面标题、核心玩法、代码结构。如果三个都高度相似，就只保留一个体验最好的版本。

这里必须多说一句：版权和安全问题一定要重视。我收集资源时严格只保留明确标注可免费使用、开源或已获授权的项目，不清楚来源的游戏一律不放进去。做一个300款合集容易让人忽视版权风险，但分发之后一旦出问题就很难收场。

4.2 运行验证：每款游戏至少完成一轮完整操作验证

整理工作中最花时间的不是收集，而是验证。我给自己定的标准是：每款游戏至少完成一轮完整操作，确认主流程能玩通。比如中国象棋游戏，我要至少走完几步棋、确认胜负判断逻辑正常；跑酷游戏，我要实际跳跃几次、触发一次碰撞或得分事件；三消游戏，我要完成一次消除操作。

验证过程中记录三类问题：

• 白屏类：打开后页面空白，通常是脚本报错或资源路径不对
• 逻辑类：按钮无响应、分数不增加、关卡无法切换
• 兼容类：在电脑浏览器正常，但手机端点击偏移、布局错位

为了提升验证效率，我用了一个技巧：在同一台电脑上，用不同浏览器分别打开同一批游戏快速过一遍。Chrome过功能，Safari过兼容，手机浏览器再过一遍触碰交互。不是每款游戏都要三端全测，而是分批抽样。抽样时优先覆盖技术标签里“webgl”和“canvas”类型的，因为它们最容易出兼容性问题。

4.3 移动端适配的统一处理

H5游戏一大半流量来自手机端，所以移动端问题必须统一处理。我在每个游戏页面的模板头部统一加入viewport设置：

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

user-scalable=no这项可以阻止用户双击页面放大。对游戏来说很有必要，因为很多游戏交互依赖精准点击，页面被放大后按钮位置和触摸点会错位。但也要注意，禁用手势缩放这个做法一定程度上牺牲了可访问性——视力较弱的用户可能确实需要放大查看。我的取舍是：游戏类内容锁住缩放，保证玩法体验优先；如果后续做内容页面，则放开缩放。

热词里提到的“H5图片在手机端支持手指放大缩小”，是针对一些带图片浏览场景的页面设置。如果游戏里包含地图、棋盘、卡牌等需要用户仔细查看的内容，我会单独给对应的图片容器加touch-action: pinch-zoom，允许双指缩放特定区域，而不是全局缩放。中国象棋这类游戏就是典型，棋盘小、棋子密，允许局部放大能明显提升体验。

4.4 从HBuilderX到uniapp：打包成独立H5应用时注意什么

热词里提到“怎么使用HBuilderX制作H5程序”和“uniapp封装H5如何指向两个域名”，这个场景应该是有人想把合集打包成独立应用，或者嵌入到已有的小程序/App体系中。我简单说下我的经验。

HBuilderX打包H5应用的本质，是把你写好的前端项目通过构建工具编译成一套纯静态资源。如果你只是做一个游戏合集，不需要强行走HBuilderX，直接本地写HTML+JavaScript，用Vite或Webpack构建也行。HBuilderX的好处是它对uniapp项目支持完善，方便后续发布到App和各家小程序平台，坏处是如果不熟悉uni-app那一套生命周期和组件规范，学习成本会高一些。

关于“指向两个域名”的需求：本质上就是同一个H5应用，在某些页面或接口请求时要根据环境动态切换域名。常见做法是打包时配置环境变量，或者运行时从URL参数读取域名配置。我的建议是运行时读取URL参数更灵活，比如：

const config = { gameBase: getParam('gameBase') || 'https://default.example.com/games', apiBase: getParam('apiBase') || 'https://default.example.com/api' };

这样同一个包部署到不同环境，只需要在入口URL上加不同的参数，不用改代码重新打包。如果是uniapp项目，还可以在manifest.json里配置h5.router.base，配合运行时判断做动态切换。

4.5 数据安全与隐私合规注意点

整理游戏合集时，凡是涉及用户输入、账号登录、埋点统计的功能都要特别小心。我见过有些H5游戏集成了第三方统计SDK，在没有明确告知用户的情况下收集设备信息，这类做法在合规层面风险很高。

我的原则是：

• 不集成任何来源不明的统计脚本
• 不向第三方服务器发送用户行为数据
• 游戏中如果需要用户输入昵称、手机号等信息，一律本地保存，不上传服务端
• 如果一定要接入客服或用户系统，单独设置清晰的隐私说明入口

“H5接入企业微信客服”是另一个典型场景，做游戏合集的运营商常有这个需求。接入企业微信客服通常需要在前端拉起企业微信的客服会话组件，这种集成涉及用户身份识别和消息会话转发，必须在产品设计阶段就明确哪些信息会传给企业微信侧，并取得用户授权。不要为了功能方便，把用户信息在页面里到处传递。

5. 常见问题与排查技巧实录

5.1 微信内置浏览器打开H5游戏白屏

整合集分发过程中，最多人反馈的就是“在微信里打开游戏白屏”。排查后发现原因集中在几个方向：

“iOS微信H5公众号重复刷新”的热词也对应一个大坑：部分手机在公众号内打开的H5页面，因为页面跳转或者业务逻辑中执行了location.reload()，会导致页面加载两遍。排查思路是先在代码全局搜索reload和location.href的重复赋值，确认没有重复触发逻辑；如果还出现重复加载，考虑在入口处加一层sessionStorage标记，防止同一时刻多次初始化。

5.2 iframe容器中的键盘和滚动问题

合集用iframe加载游戏后，最常见的交互问题集中在键盘和滚动上。

app内嵌H5页面点击input，自动滑动到对应input，显示键盘，这个其实是移动端页面的经典问题。H5页面里有输入框，用户点击后浏览器会尝试把输入框滚动到可视区域。但如果在iframe里，表现会不稳定，有时候键盘弹出来把输入框盖住，有时候页面滚动过了头。

我的处理思路是：

• 输入框外层容器用position: fixed固定在合适位置，避免被键盘顶起
• 监听focusin和focusout事件，手动调整容器位置
• 安卓和iOS的键盘表现不同，需要分别调参

input.addEventListener('focus', () => { setTimeout(() => { document.activeElement.scrollIntoView({ block: 'center', behavior: 'smooth' }); }, 100); });

iOS键盘弹起通常会把页面顶起，但滚动事件不触发，所以这里用smooth手动滚动到输入框居中位置，比依赖浏览器默认行为稳定得多。

5.3 音频自动播放被浏览器拦截

很多H5游戏打开时会播放背景音乐，但在现代浏览器里，如果用户没有点击页面就直接播放音频，会被自动拦截。这就是为什么很多玩家反馈“进游戏没声音”，其实游戏的声效代码没问题，是浏览器的自动播放策略在拦截。

解决办法就是让游戏在用户完成第一次点击后再初始化音频。常见做法：

const audioCtx = new AudioContext(); document.addEventListener('touchstart', function initAudio() { if (audioCtx.state === 'suspended') { audioCtx.resume(); } document.removeEventListener('touchstart', initAudio); }, { passive: true });

如果游戏用了<audio>标签，做法类似，在用户首次点击时调用audio.play()。这个处理对合集分发特别重要，因为用户可能直接从列表页跳进游戏，没有任何点击页面的动作。

5.4 iOS下文件下载变成预览的问题

“H5在iOS下载文件变成了预览”这个困惑在游戏合集里其实不常见，但如果是游戏内置了资源下载功能就会遇到。iOS的Safari对下载类响应有特殊行为，服务端返回Content-Disposition: attachment也不一定触发下载，相当一部分类型会在浏览器内直接打开预览。

游戏场景里更常见的做法是：把资源下载改成一个明确的“复制链接”按钮，或者展示资源说明页面。不要在移动端H5里依赖下载行为，这是平台限制，前端再折腾也很难绕过去。

5.5 跨域与防盗链：外部资源只做锦上添花

H5游戏大量使用外部图片、音频、字体资源。做合集时，这些外部资源是最容易挂的。我遇到过游戏里用的图片服务器设置了防盗链，页面在合集域名下打开后图片全部403。排查半天才发现单独打开游戏文件正常，放进合集域名下就不行，是来源服务器根据Referer做了限制。

这类问题的处理方案有两个方向：

• 把外部资源下载到本地，替换为相对路径加载
• 放弃外部资源，在页面内用样式或Canvas绘制替代

我的原则是：核心功能所需资源必须本地化，外部资源只允许用于非关键的装饰元素。这个决定的代价是多花了些时间在资源下载上，但换来了合集整体的稳定性。

5.6 性能问题：为什么有些游戏打开很卡

300款游戏里，有一批老游戏打开后操作明显卡顿。排查后发现主要原因包括：

• 游戏主循环里频繁操作DOM，没有做批量更新
• 大量使用setInterval做动画，时间片不稳定
• 音频对象反复创建未释放，内存持续增长
• 页面内嵌了超大图片，解码耗时阻塞渲染

我处理性能问题有一个优先级清单：先看是否存在无限创建对象的循环，再看动画帧是否使用requestAnimationFrame，最后看资源体积是否超标。绝大多数H5小游戏卡顿不是引擎问题，而是代码写法粗糙。对于合集项目，除非游戏运行有明显可感知的卡顿，否则我不建议花大力气去改游戏内部代码，因为工作量无限大，而且容易改坏原始逻辑。我通常只在索引里打一个“性能一般”的标签，提示后续访问者降低预期。

6. 合理利用合集：营销场景和工程化扩展

6.1 游戏合集的运营玩法

合集整理完，不只是自己收藏用的。我见过挺多玩法，比如：

• 游戏盒子网站：把合集包一层导航和会员体系，通过广告变现
• 公众号嵌入H5游戏：文章底部放一个游戏入口，增加用户停留时长
• 企业微信客服场景：用户咨询后系统自动推一款裂变小游戏，增加参与感
• 线下活动物料：印刷二维码，扫码直接玩游戏，替代传统纸质互动

每个场景对合集的诉求不同。做活动物料时，我只从合集中挑选四五款玩法轻、视觉好看、App内打开性能稳定的游戏单独提出来，做成独立的二维码入口。不要试图把300款游戏全部丢到某个活动里，用户面对过多选择反而不会点击。

6.2 从合集到平台：存档、排行榜、客服系统

如果想把合集做成一个长期运营的平台，单纯套iframe是不够的。至少要补齐三个模块：

第一是存档系统。很多休闲游戏玩家希望进度不丢，这个功能可以在iframe层做统一注入：监听游戏内的得分事件，用localStorage和用户标识绑定，下一次进入时读取历史进度。

第二是排行榜。H5游戏排行不一定要做实时服务端排名，轻量方案是用云开发或服务端API，把用户分数上报后拉取前十名列表即可。极限量级下，一天几万次写入不会有压力，初期完全够用。

第三是客服系统。这里回到热词“H5接入企业微信客服”。如果要做客服，我建议在合集框架层统一接入，而不是每个游戏单独接。用户在游戏里遇到问题，点一个通用反馈按钮，客服会话组件弹出来，带着当前的游戏ID和用户标识发起上下文。这样处理的好处是客服不用知道用户玩了游戏就能直接进入问题回复，运营后台也能按游戏维度统计问题量。

6.3 用uniapp重构合集的思考

如果你想把H5合集往小程序和App方向推，用uniapp重新实现是一个可考虑的路线。但这条路并不简单，最大的问题是：uniapp不能直接跑传统的H5游戏单文件，所有游戏资源要按uniapp的组件规范重新封装。300款游戏都重写不现实，可行的做法是抽出一部分高价值游戏，在uniapp里通过web-view组件嵌入H5页面。也就是说，uniapp壳负责导航和用户体系，游戏本身仍然运行在web-view里。

这中间有一个经典矛盾：web-view在微信小程序里要求域名必须在小程序后台配置白名单，而且域名需要HTTPS。如果游戏资源放在国内服务器，域名备案和HTTPS证书都是硬性要求。纯静态的H5合集可以通过对象存储加CDN搞定，但域名备案这个环节绕不开。

6.4 标签系统的进阶：支持任意维度组合筛选

索引里除了基础字段，我后来加了一个tags数组，用来支持更灵活的筛选：

{ "id": "042", "name": "消消乐", "type": "休闲益智", "tech": "canvas", "tags": ["单机", "宝石", "高分挑战", "移动端适配良好"] }

有了标签系统，运营同事要“找几款适合女性用户的可爱画风游戏”，就不需要我逐个人工搜索，直接在后台按标签组合筛。我后来甚至把是否支持双人对战、是否支持键盘操作、是否支持触屏、是否包含音效都做成了标签。这个设计让合集从“300个文件”升级成了“可运营的内容库”。

7. 实战总结：合集维护的经验与心得

整理到目前的状态，我收获最大的几点总结如下：

7.1 命名规范和索引结构是合集的命脉

再回头说一次命名。合集的体量一旦超过100个文件，所有手工操作都变得不可维护。命名规范加上自动索引脚本，让“往合集里加一款游戏”变成三分钟的事：放文件、跑脚本、补缩略图和描述。如果文件名乱起，每个游戏都要手动处理索引字段，300款游戏的维护成本就高到让人放弃。

7.2 验证环节省不得，但可以分批做

我最开始尝试一款一款验证所有功能，实在太慢。后来改成分批加抽样的策略：每批新收录的游戏做全量运行验证，存量游戏只在重大兼容性改动后做抽样回归。这么做的代价是偶尔会有一两款游戏因为浏览器版本升级突然出问题，但因为索引里有联系方式和技术标签，用户反馈后能快速定位修复。如果要把所有游戏每周全量回归一遍，时间成本不可承受，抽样验证是更现实的平衡点。

7.3 兼容性永远是H5游戏的长期话题

从桌面浏览器到手机微信，从iOS到各种安卓定制系统，每个环境都可能出现意想不到的表现差异。H5技术本身已经足够成熟，但运行环境的碎片化问题短期不会消失。做合集时，不要假设代码能在一个环境验证后到处通用。每款游戏完成开发后，至少要在Chrome手机模拟器、微信开发者工具和真实手机上各过一遍。

我个人在实际操作中的体会是，这300款H5小游戏合集，本质上不是技术问题，而是管理问题。技术方案都是公开的，难的是坚持维护规范、坚持记录元数据、坚持做验证。如果你也想整理一份素材库，我的建议很简单：先做100款，跑通流程，再决定要不要做到300款，不要在第一天就想着“凑满300”。

如果后续要继续扩展，我计划的方向有两个：一是给合集加一个简单的数据统计看板，记录每款游戏的打开次数、平均停留时长，用真实数据判断哪些游戏值得深度运营；二是从合集中提取通用组件，把一些反复出现的玩法逻辑（碰撞检测、计时计分、存储进度）沉淀成可复用模块。这个合集越到后面越会发现，值得沉淀的不是游戏本身，而是它们背后那些共通的工程经验。