企业官网建设流程全解析

1. 为什么第一眼就卡在6MB里

做Unity转微信小游戏的团队，十有八九都会在“首包体积限制”这一关被卡住。微信小游戏主包限制是4MB，加上资源包整体不能超过20MB，而Unity导出WebGL后的默认产物动不动就是几十MB起步，遇到复杂场景几百MB也不稀奇。更关键的是，微信小游戏平台给出的是一个强制性的“首包必须能在短时间内拉完并启动”的约束，如果你把整个游戏的全部资源都塞进去，用户点开游戏的那一刻就是漫长的白屏等待，流失率直接拉满。

我自己最早做这个方向时，第一个版本就犯了这个错误。当时Unity项目里放了一整套UI图集、三套角色模型、几十个音效，打包转成小游戏后首包直接奔着36MB去了。同事在开发者工具里点预览，加载了快两分钟还没进主界面，那一刻我意识到：这条路不能靠“优化包体”硬走，得换一条路，把游戏的“壳”和“肉”彻底分开。壳是能在小游戏环境里跑起来的引擎运行时和启动脚本，肉是场景、模型、贴图、音频这些真正占体积的资源，肉放到CDN上，壳在启动时按需去拉。

这个思路后来被验证是整个Unity微信小游戏改造里最核心的一步，也是官方转换工具链、商业小游戏团队普遍采用的方案。你可以把它理解为：你的游戏不再是“一次性下载完再玩”，而是“先启动一个极小的加载器，再边玩边把资源从云端拉进本地缓存”。本文就围绕这个方案，把CDN加载的游戏包怎么设计、怎么改、怎么排坑完整拆开讲一遍。

2. 整体设计：本地核心+云端资源的架构怎么划

2.1 核心与资源的边界怎么划

划分本地和云端资源，不能拍脑袋，核心原则是：凡是启动阶段必须用到的，放本地；凡是进入具体玩法后才会访问的，放云端。

具体到Unity项目里，我建议你按这个清单去梳理：

• 本地保留：UnityWebGL的引擎运行时（这是大头，一般压缩后3MB到5MB）、index.html、启动配置文件（game.json、project.config.json）、入口场景的极小一部分必要资源（比如一个Loading界面和一张启动图）。
• 云端CDN：除了入口场景外的所有AssetBundle、Addressables分组、视频文件、音频文件、楼层模型、纹理图集、后续版本新增的所有可下载内容。

这个边界划定后，你还要给自己定一条规则：以后所有新增资源默认走云端，只有被明确标记为“启动必需”的资源才放进首包。团队协作时，这个规则最好写进打包脚本的注释里，否则过两个版本，一定会有人图省事把资源一股脑塞回本地，导致首包悄悄涨回去。

2.2 为什么首选微信云开发CDN

现在市面上CDN选择很多，阿里云、腾讯云、华为云、七牛云都有成熟的产品，但微信小游戏这个场景下，我个人强烈建议你优先考虑微信云开发自带的CDN能力，也就是云开发控制台里的“静态网站托管”或者“云存储”加CDN访问域名。

原因有几点。第一，免备案。小游戏如果想用自建服务器或商业CDN，域名备案是绕不开的一关，而云开发分配的默认域名是腾讯侧已备案的，你不需要额外操作，省去少则几天多则几周的备案周期。第二，密钥天然安全。云开发支持通过云函数调用wx-server-sdk获取临时密钥和下载链接，整个链路完全在微信生态内部，不需要在小游戏前端代码里暴露任何敏感的SecretId或SecretKey。第三，计费灵活，免费额度对中小团队足够撑过开发和早期运营阶段，等用户量上来再按量付费也来得及。

当然，如果你公司本身已有稳定的大规模CDN资源池，并且有专门的运维团队，那用自有CDN也完全可以。但需要额外做一套鉴权、缓存刷新、版本回滚方案。对多数Unity转小游戏的团队来说，用云开发是性价比较高的起点，后面流量大了再迁移也不迟。

2.3 加载链路的核心流程

把资源放到CDN之后，小游戏端的加载流程就变成了一条固定流水线：

• 用户启动小游戏，本地代码先运行一个最小的加载器。
• 加载器读取云端配置（一个JSON文件），里面记录了当前版本的所有资源清单和版本号。
• 加载器调用wx.cloud.downloadFile把所需资源下载到小游戏本地用户目录。
• 下载完成后，Unity的WebGL运行时从本地路径读取AssetBundle并加载场景。
• 资源加载完进入游戏后，后续每一个玩法模块的AssetBundle仍然走“CDN预下载到本地，再从本地加载”的方式。

这里有一个容易被新人忽略的细节：Unity WebGL运行起来之后，它没法直接通过原生的XMLHttpRequest去请求小游戏环境里的本地文件路径，也不能直接加载小游戏包内的文件。所以整个链路的功臣其实是Unity官方提供的转换插件，它会在适配层把“请求远程资源”重写成“读取本地缓存文件”。你只要做好“已下载到本地的文件路径”和“Unity期望的虚拟路径”之间的映射，资源加载就不会出问题。

3. 实操：把Unity包改造成CDN加载

3.1 环境准备与官方转换工具链

开始实操前，先把工具链装齐。你需要的东西包括：

• Unity编辑器：建议使用Unity 2021 LTS及以上版本，并安装WebGL构建模块。
• 微信开发者工具：稳定版即可，注意安装路径不要带中文或空格，否则后续编译容易出诡异的问题。
• Unity官方微信小游戏转换插件：在Unity资源商店搜索“Minigame”或从微信官方文档入口下载，找到对应Unity版本的插件包。
• Node.js环境：转换过程和依赖构建过程中会用到npm命令。

安装阶段有一个高频坑：微信开发者工具需要依赖Git，很多人在初次创建小游戏项目时提示“找不到Git”，就是因为在安装微信开发者工具之前没装Git，或者Git没有加入系统环境变量PATH。这个操作不复杂，但漏掉真的很浪费时间。

环境就绪后，先在Unity里打开目标项目，把Build Target切换为WebGL，在Player Settings里把压缩格式选为Brotli或Gzip，把“Development Build”关掉。然后导入转换插件，插件会在菜单栏生成一个“微信小游戏”入口，点击后会弹出一个配置面板，里面可以设置小游戏AppID、游戏资源CDN路径、首包大小等。先不要在面板里填正式CDN路径，后面我们会通过代码动态改。

3.2 第一步：把包体瘦身到最小集

这一节是整个改造过程的地基。我在第一节提到要把“壳”和“肉”分离，具体到Unity工程侧，核心是AssetBundle的资源组织方式。

Unity正常的AssetBundle使用方式是：把资源打成很多个bundle文件，运行时统一用UnityWebRequestAssetBundle加载。但在微信小游戏环境下，这个加载过程不能走HTTP，而是要先下载到微信本地缓存目录。所以你在Unity里的编码习惯要改一改：不要再依赖UnityWebRequest直接发起远程请求，而是让插件提供的“本地文件加载”逻辑去工作。

实际操作中，我推荐的做法是：

• 在Editor下写一个打包脚本，把场景、UI、角色、特效等资源分组成若干个AssetBundle，每个bundle的命名带版本号后缀，例如scene_main_v12.bundle。
• 把bundle根目录设置成一个固定的基础路径，比如Assets/GameRes/。
• 打包完成后，再写一个“上传到云开发CDN”的脚本，按目录结构把bundle文件传到云存储的game-res文件夹下。
• 本地首包只保留启动画面、加载进度条和极少量必要脚本。

这个阶段最容易出的问题是：你觉得已经把所有资源拆出去了，结果打出来的包还是很大。原因多半是某些资源被放进了“Always Included Shaders”或“Resources”目录，Unity的Resources目录里的任何东西都会被不管三七二十一打包进主程序，这是默认行为。所以请你在项目里全局搜索一下，确认没有把整目录内容塞进Resources的习惯。我见过不止一个项目，资源已经拆干净了，但Resources里还躺着一整套图集，白白多出好几MB。

3.3 第二步：上传资源到云开发CDN

用微信云开发托管游戏资源，需要先在微信开发者工具或云开发控制台开通云开发环境。创建环境后，进入“云存储”页面，新建一个game-res目录，然后通过控制台上传文件。小规模测试时，你手动上传几个bundle文件没有问题；但项目进入常态化更新后，手动上传一定会出错，必须脚本化。

脚本化上传的方式有两条路。一是用云开发控制台的“静态网站托管”功能，它支持通过HTTP上传工具和CLI批量发布，可以在CI流程里调用；二是用“云存储”加“云函数”配合，在Node.js脚本里使用@cloudbase/cli或腾讯云COS的SDK上传。我自己更常用的是把AssetBundle文件同步到本地目录后，用@cloudbase/cli的cloudbase hosting deploy命令上传，简单直接。

上传时有一个关键配置：设置CDN缓存策略。bundle文件名带版本号，所以对带版本号的资源可以设置较长的缓存时间，比如30天；但对一些公共入口文件或JSON清单，建议缓存时间设短一些，比如300秒，或者设置成每次更新都强制覆盖。这样能保证用户下次启动时能拉到最新版本，同时又不会让同名bundle反复重新下载。

3.4 第三步：小游戏端实现CDN加载器

资源上了CDN后，小游戏端需要一个“加载器”来协调下载和通知Unity。这个加载器本质上是微信小游戏App.js或主场景里的一段JavaScript逻辑，它在Unity的WebGL运行时就绪之前运行。

一个简化版的加载流程是这样：

1. 启动时读取本地配置文件，拿到当前资源根地址（默认指向云开发CDN域名）。
2. 通过wx.cloud.callFunction调用一个云函数，云函数返回该用户当前应使用的资源版本号以及对应CDN临时链接。
3. 加载器对比本地缓存的版本号，如果不一致，则把需要更新的文件逐个调用wx.cloud.downloadFile下载到wx.env.USER_DATA_PATH目录下。
4. 下载完成后，把文件路径和版本信息写入本地Storage。
5. 最后通过插件提供的适配层，把Unity的资源请求路径替换成实际下载后的本地文件路径，再启动Unity游戏循环。

这段代码里值得多说一句的是wx.cloud.downloadFile。这个API在云开发中扮演的角色，可以类比成“带鉴权的下载请求”，它需要你提前在云函数端用wx-server-sdk生成下载链接，或者在小游戏端直接使用云文件ID。注意，不要把云文件ID硬编码在代码里，每次启动时动态获取，否则一旦你在云存储里移动了目录结构，老版本客户端会直接无法下载资源。

3.5 第四步：资源版本与更新策略

Unity转小游戏上线后，最频繁的更新场景是“修Bug换UI换数值”，这些改动通常只涉及几个bundle文件，而不想推整包。所以你的版本管理策略必须能支持精细化更新。

我推荐的做法是：维护一个JSON格式的资源清单，每个版本都有一个全局版本号，清单里记录每个bundle的文件名、大小、MD5和CDN路径。游戏启动时先获取最新清单，然后逐个比对本地缓存中的MD5值，不一样才下载。这样做的好处是，绝大多数用户下次启动时只需要下载几十KB到几百KB的增量内容，而不是重新下载整个资源包。

有一个坑要特别提醒：微信小游戏本地缓存空间和普通文件系统权限是有限制的，开发者工具里可以配置缓存大小，但真机上系统可能会在某些极端情况下清理你的本地缓存。如果发生“文件被清理但本地版本号没更新”的情况，Unity会尝试加载不存在的bundle导致报错。所以加载器里不仅要比较版本号，还必须校验关键bundle是否存在以及文件大小是否符合预期，如果不满足就重新下载一次。这种兜底逻辑看起来很笨，但在真实用户设备上非常管用。

4. 几个绕不开的渲染与播放问题

4.1 阴影半分辨率问题

Unity转微信小游戏之后，最直观的渲染变化是：同样的光照配置下，手机上的阴影看起来比PC上“淡”了很多，或者干脆边缘有很多锯齿。原因不复杂——小游戏环境默认的渲染分辨率也许没变，但阴影贴图的采样分辨率在移动端设备和微信WebGL环境里会被大幅压低，很多场景还跑在half分辨率下，阴影边缘自然就糊了。

解决办法，我建议从几个层面同时下手：

• 在Quality Settings里针对微信小游戏的平台设置，把Shadow Resolution至少提升到High，部分高档机型可以调成Ultra。
• 如果场景里有大片动态阴影（比如角色脚下），考虑改用更高分辨率的实时阴影或改用烘焙光照贴图，动态阴影全部关闭。
• 如果阴影边缘仍然有严重闪烁，多半是Shadow Near Plane Offset值太小，稍微调大一些能缓解。

这个问题的排查思路是：先在微信开发者工具里单独跑一个大太阳直射场景，逐步调高阴影质量和偏移量，找到当前机型的上限。不要试图让所有机型都开最高档阴影，否则发热和帧率会让你后悔。

4.2 Renderer包围盒导致的剔除问题

Unity转小游戏后还有一个非常常见的显示问题：物体明明在屏幕上，但就是看不到，转一下镜头又突然出现。这种情况大概率不是Shader问题，而是Renderer的包围盒计算错误，导致Unity的视锥剔除把它误杀了。

微信小游戏的WebGL环境里，有一些模型的网格数据流式加载或蒙皮动画会改变顶点的实际位置，但引擎在计算Renderer包围盒时只用了原始网格数据的范围，没有包含蒙皮变形后的大范围偏移。常见于角色身上挂了飘带、头发或裙摆物理模拟的场景，原始网格是静态的，动画却把顶点推出包围盒之外，于是相机一拍，这个角色就“凭空消失”了。

解决方式有几种，从粗到细递进：

• 最简单的方法：在蒙皮网格的根节点上添加一个适当的Bounds扩展器，或者在导入设置里手动把网格的Bounds放大。
• 也可以在运行时通过代码调整Renderer.localBounds来覆盖默认包围盒。
• 如果是跟CDN加载相关的资源，需要注意不要用“减面优化”工具把原始网格的Bounds信息自动重算掉，否则每次加载都会出现剔除问题。

我的建议是，每个角色模型在正式进包之前都做一次“旋转镜头扫描测试”，尤其关注角色离镜头较近、从画面边缘入画这两个场景，最容易暴露出包围盒过小导致瞬间消失的Bug。

4.3 视频播放方案

Unity里直接播放视频，在PC和手机上各有各的逻辑，但放到微信小游戏环境里，统统会撞上“VideoPlayer不支持或性能极差”的墙。微信小游戏本质是浏览器内核，它对视频播放有自己的限制，尤其是自动播放和音频焦点策略。指望Unity导入一段mp4然后VideoPlayer.Prepare()就能顺畅播放，基本不可行。

成熟的替代方案是“原生视频组件覆盖层”：在小游戏前端页面用

这里有一个细节值得注意：视频的音频焦点处理。先让Unity里的所有音频静音，再启动原生视频播放器，否则小游戏运行环境中两个音频上下文会互相打架，导致播放出来只有图像没有声音，或者声音忽大忽小。另外视频文件的编码格式尽量统一用H.264 High Profile，不要用H.265，很多小游戏运行环境的软解H.265性能很差，在低端机上会出现音画不同步。

5. 常见问题与排查速查表

5.1 Loading阶段黑屏或白屏

小游戏启动后一直在加载动画里转圈，或者直接白屏，是最常见的现象。排查顺序建议先确认下面三件事：

• 首包里的index.html和适配脚本路径是否正确，特别是你用CDN加载后，这些文件的相对路径不能错，微信小游戏对路径解析非常严格。
• 云函数是否成功返回了资源清单，如果云函数返回异常，加载器就会卡在“等待配置”状态。
• Unity插件的启动配置里resources路径是否与实际上传到CDN的路径一致。

这三件套都正常，则再看开发者工具的Console面板有没有报错。绝大多数白屏问题都能在Console里找到关键错误信息。

5.2 首包进去了，资源却加载失败

如果你已经能看到游戏logo或加载进度条，但进入游戏场景时报“Unable to load asset bundle”或“file not found”，基本可以断定是资源路径映射的问题。排查时打开开发者工具Network面板，看Unity在尝试请求什么路径，然后对比这个路径是否能在你的加载器里找到对应的本地文件。

常见原因有两个方向：一个是Unity侧AssetBundle加载代码里用的虚拟路径跟插件适配层的映射规则不一致；另一个是bundle文件下载不完整，尤其是网络较差时wx.cloud.downloadFile返回的临时文件被系统清掉。面对第二个方向，我建议你在加载器里对下载完成的文件做一次大小校验，不满足预期就重新下载一次。

5.3 云开发控制台那些容易踩的坑

云开发控制台本身很稳定，但使用姿势不对也会卡住。比如很多人上传文件到云存储后，直接在控制台复制了CDN链接，填到Unity的配置里，结果发现部分安卓机型能访问，部分iOS机型死活加载不出来。这个问题的根源是签名URL有效期设置过短，或者URL带了特殊字符导致微信小游戏环境的请求被拦截。正确的做法是不要在前端拼接静态URL，而是走云函数动态获取下载地址。

另外，云开发环境的“静态网站托管”默认会开启CDN加速，但要注意，本地上传的文件命名如果有中文或空格，会导致URL编码不一致，加载时容易404。我的团队里定了一条规矩：所有上传CDN的文件名一律使用小写英文、数字、下划线，禁止空格和中文。这个习惯能省掉大量无意义的排查时间。

6. 写在最后的一点经验

Unity转微信小游戏这套流程，技术链路其实并不复杂，难点全在细节。我踩过的坑里，最有代表性的是“本地开发一切正常，真机上一跑就废”——后来排查了半天，发现是开发者工具里调试时微信环境默认关闭了缓存，而真机上启用了CDN缓存，导致旧版本bundle和新版本代码不匹配。这个问题之后，我养成了一个习惯：任何资源更新后，先清除开发者工具缓存做验证，再用普通用户的路径做一次真机测试，两条链路都通过才算完成。

另外，团队里如果有多人同时做Unity转小游戏开发，我建议把“CDN资源版本号”和“小游戏发布版本号”分开管理。资源版本号负责asset的更新，小游戏发布版本号负责代码的更新，二者独立，才能让“只改资源不发版”这件事成为常态。配合云开发控制台的版本管理，基本能做到当天修改当天生效。

最后再从资源规划的角度提醒一句：CDN资源也不是越多越好，能合并的bundle尽量合并，单个bundle文件控制在几百KB到2MB之间对加载体验最友好；太碎的文件会导致大量小文件请求，CDN和本地IO都撑不住。平衡好文件个数和单文件大小，比盲目追求极致拆包更有价值。