眼下小游戏特别火，不少团队也陆续启动了微信小游戏的项目，并于立项前期进行技术预研究。但从微信官方文档看 , 却能发现不少坑。
一、运行环境的坑
首先微信小游戏是一个不同于浏览器的 JavaScript 运行环境，没有 BOM 和 DOM API，所以我们第一个遇到的就是API兼容性问题。
1、API兼容性
1.1、网络API
BOM的核心是windows，表示的是一个浏览器的实例，在网页中自定义的任何一个对象、变量和函数，都以windows作为其全局对象；缺乏Dom意味着http、websocket及本地存储等通信用的API使用就会遇到问题，好在微信提供了这两个API的私有实现，我们要做的就是适配。
适配的基本思路是检测是否是运行再微信平台，然后利用JS动态语言特性, 对BOM的API进行动态重写 , 优缺点如下：
1.优点是API调用者无需做任何改动,适配成本几乎为0。对微信小游戏和浏览器之间的运行 环境差异无感知，非常友好。 2.缺点是会增加代码体积，但代码体积的增加带来的损失几乎可以忽略不计。
这种适配方案的性价比很高, 适配HTTP代码示例如下:
1.2、微信的模块化
微信小游戏提供了 CommonJS 风格的模块 API，可以通过 module.exports 和 exports 导出模块，通过 require 引入模块 . 这与浏览器引入JS文件的方式截然不同 , 中间有一个隔离层。
让我们举个例子来说明模块化带来的问题。
通常我们在浏览器上使用某个js文件里面自定义的类，通过
标记引入JS文件可以直接使用:
但在微信中不可以这样.需要把API都导入到一个对象上，使用时在加这个前缀.导致很多代码需要修改，那么如何避免增加这个前缀呢？
针对这种情况 , 解决的思路是将所有外部需要用到的方法和对象动态挂靠到window对象上去，将上面的代码稍做修改示例如下:
2、工作流变化
由于微信小游戏没有Dom和Bom，所以很多依赖Dom和Bom的库都不能直接用，比如 jquery。
微信的这套环境会或多或少会引起我们的工作流变化，使用第三方游戏开发引擎(比如Cocos Createor/Egret/Laya)可以弥补这些问题带来的损失。
二、资源限制
1、每个小游戏允许上传的代码包总大小为 4MB。
解决方法1:压缩js文件，图片资源放在服务器上做预加载。 解决方法2:使用第三方引擎的资源管理功能。
2、微信小程序要求开发者的服务器 支持https,wss协议。
解决方案:服务器启用HTTPS。实现的方式有很多,推荐Nginx反向代理。
三、发布审核
小游戏开发完成后发布上线需要具备如下的资格：
1: 服务器域名备案
2: https wss支持
3: 软件著作权证书 复印件+盖章签名
4: 微信公众平台帐号及AppID
5: 开发者工具wechat_devtools_1.02.1803210_x64
6: 游戏自审报告复印件+签名
7: iOS开发中帐号(可选,没有则填空)
8: 游戏版号(开通微信支付需要)
9:企业开发者身份+对公帐号(开通微信支付需要)
