企业官网建设流程全解析

时间点回到我做微信小程序项目的那阵子，几乎每一个跟用户上传沾边的功能，最后都会撞上同一堵墙：图片体积太大。用户随手拍一张照片，动不动就是 5MB、8MB，甚至有些安卓机拍出来十几 MB。上传慢是一回事，更头疼的是在小程序里渲染大图，内存直接告急，iOS 上还好一点，低端安卓手机直接白屏、卡死、闪退，线上问题一个接一个。后来我把图片压缩从前端就做了，体验直接从“艰难加载”变成“秒开”。这篇文章就把我在微信小程序里做图片压缩的方案、代码和踩过的坑完整分享出来，照着抄就行。

这是给两类人看的：第一种是正在做小程序但还没处理过图片上传的开发者，你可能刚在小程序里实现完 chooseImage，正发愁怎么把用户拍的大图变小的；第二种是已经做了压缩但发现问题一堆，比如压完大小没变、安卓闪退、图片方向不对，想知道别人怎么解决这些问题的。我会从官方压缩接口、Canvas 重绘方案、参数计算、实际项目接入，到最后的问题排查，全部都讲。

1. 为什么小程序图片压缩不能只靠后端

1.1 用户的体感和服务器账单都在逼你做前端压缩

很多人第一次做小程序上传图片，第一反应是：前端随便传，后端拿到图片再压缩不就行了？理论上确实可以，但实际跑一圈你会发现，这条路代价挺高。

首先是用户体验。用户在小程序里选了一张 8MB 的照片，你直接把它往服务器传。WiFi 环境下还好，一旦用户用的是 4G/5G 流量，或者像地铁、商场这种信号不稳定的地方，上传一张大图可能得卡十几秒甚至更久。传完之后前端要展示这张图，小程序里组件直接加载高清原图，渲染大图的耗时和内存开销都上去了。用户刷个朋友圈似的页面，滑到这张图就卡顿，第一反应不是你后端多厉害，而是“这小程序做得真烂”。

然后是服务器的钱和带宽。图片这种资源，存到对象存储是按容量计费的，流量也是按使用量计费的。一张原图 8MB，压缩后 200KB，容量差了 40 倍。如果一个用户一天上传 20 张图，一个月下来光这一个模块的存储和 CDN 流量成本，就是一笔可观的数字。前端把图压小了再传，省的是真金白银。

再有就是平台本身的限制。微信小程序里，图片相关的接口和组件对大图并不友好。iOS 上加载超大图偶尔还能扛住，安卓上 WebView 的 bitmap 内存限制很严格，加载一个 4000x3000 的大图，解码出来差不多要 48MB 内存，页面直接就崩了。这些现实问题叠加在一起，结论非常明确：图片压缩必须在前端完成，至少要在进入业务链路之前完成。

1.2 前端压缩的两种主流路径：官方 API 和 Canvas 重绘

微信生态里，前端做图片压缩主要有两条路。一条是通过小程序的图片接口wx.compressImage，直接对本地图片文件进行压缩；另一条是借助wx.getImageInfo拿到图片信息后，用 Canvas 重新绘制、导出canvas.toTempFilePath实现自定义尺寸和质量的压缩。

这两条路各自有各自的特点。wx.compressImage是官方提供的接口，调用简单，参数只有一个quality，从 0 到 100 控制压缩质量，它不需要处理图片的宽高，系统会保留原尺寸。这个方案的实现成本极低，适合只想快速把体积降下来的场景，很多不需要限制图片具体尺寸的项目，用它就够了。

但它的短板也很明显。第一，compressedWidth这个可选参数是后来新基础库才支持的，老版本基础库上没有，你要考虑兼容。第二，它只压缩，不裁剪、不缩图，如果你的需求是“把图片强制变成 750x750 的正方形”，它是做不到的。第三，在某些安卓机型上，官方压缩接口对 PNG 大图的支持并不稳定，偶尔会返回压缩失败。

Canvas 方案则是完全不同的思路。你先把图片画到离屏 Canvas 上，通过canvas.toTempFilePath导出。因为导出时可以指定目标宽度（destWidth）和质量（quality），所以你能拿到精确控制尺寸和体积的图片。这个方案灵活性高，既能等比缩小，也能按比例裁剪，是真正意义上的“前端图片处理”。

不过 Canvas 方案也有门槛。它需要你理解 Canvas 绘制的机制，还要处理图片旋转、像素比、内存峰值等问题。我个人的习惯是：如果只是压体积，优先用官方 API，简单省事；如果需要指定目标尺寸或者官方接口压出来的图还是太大，再上 Canvas。

2. 说干就干：基于 wx.compressImage 的压缩实现

2.1 先摸清这个接口的脾气

wx.compressImage算是微信官方接口里比较“小气”的一个，参数少得可怜。它是wx.compressImage，注意不是 Canvas 那个，也不是图片编辑器，它就是个纯压缩工具，可以理解为把一张大图用 JPEG 编码器重新编码一遍，去掉冗余信息。

我用下来，它的表现大概是这样的：一张 8MB 的照片，quality 设为 80，压完大约在 400KB ~ 1MB 之间，具体要看原图内容。纯色、平滑的图片压缩率高很多；噪点多、纹理复杂的夜景照片，压缩率就低。官方说明里 quality 的取值范围是 0~100，数值越小体积越小，但清晰度也会下降。

这里有一点必须提醒：wx.compressImage不支持compressedWidth参数的时代，它只能压质量，不能改尺寸。后来版本虽然支持了，但由于基础库限制，使用时最好做能力判断。另外，这个接口的 src 参数只支持本地临时文件路径，不支持网络 URL。所以你在用之前，必须先通过wx.chooseImage或者wx.chooseMedia拿到本地路径，不能拿一个https://开头的在线地址直接塞给它。

实际使用中还有一个容易踩的坑：wx.compressImage返回的是一个新临时文件路径tempFilePath。它不会覆盖原图。所以压缩完成后，你要把新的路径存好，后续上传、预览都用新路径。千万别把压缩结果忘掉，然后又去传原图，等于白干。

2.2 一个能直接抄走的压缩函数

下面这段代码是我在项目里一直沿用的压缩函数。它处理了比较多的边界情况，可以直接复制到你的工具文件里。

/** * 微信小程序图片压缩 * @param {string} src 图片本地路径 * @param {number} quality 压缩质量 0-100，默认 75 * @param {number} maxSize 目标文件大小上限，单位 KB，超过则继续降质量重试 * @returns {Promise<string>} 压缩后的临时文件路径 */ function compressImage(src, quality = 75, maxSize = 500) { return new Promise((resolve, reject) => { if (!wx.compressImage) { // 低版本基础库没有这个接口，直接返回原图或者走 Canvas 方案 console.warn('当前基础库不支持 wx.compressImage'); resolve(src); return; } wx.compressImage({ src, quality, success: (res) => { const tempFilePath = res.tempFilePath; // 压缩后校验文件大小，如果还是大于 maxSize，就把质量调低再压一次 wx.getFileSystemManager().getFileInfo({ filePath: tempFilePath, success: (info) => { if (info.size > maxSize * 1024 && quality > 30) { compressImage(src, quality - 15, maxSize).then(resolve).catch(reject); } else { resolve(tempFilePath); } }, fail: () => resolve(tempFilePath), }); }, fail: (err) => { reject(err); }, }); }); } module.exports = { compressImage };

这个函数做了一件很重要的事：压缩后主动校验文件大小。官方接口虽然给了 quality，但你没法预测某个 quality 下具体能压到多大，因为图片内容不同，同样 75 的质量，有人能压到 200KB，有人还是 1MB。所以我设计了一个递归重试机制：如果压完还是超过目标值，就把质量降低 15，继续压，直到小于目标或者质量低于 30 为止。这样能保证最终结果一定在可接受范围内。

调用很简单：

const { compressImage } = require('../../utils/image.js'); wx.chooseMedia({ count: 1, mediaType: ['image'], success: async (res) => { const src = res.tempFiles[0].tempFilePath; try { const compressedPath = await compressImage(src, 75, 500); // 这里 compressedPath 就是压缩后的图片路径，接下来就可以预览、上传 console.log('压缩完成', compressedPath); } catch (err) { console.error('压缩失败', err); } }, });

2.3 为什么还要做二次校验：交互降级策略

上面代码里的二次校验，是我在一段时间被用户反馈“图片传不上去”之后才加上去的。官方接口的success回调只表示“压缩这个动作执行了”，不代表“压缩结果一定符合你的心理预期”。比如你给了一张本身就是压缩过的、噪声特别多的 JPEG 图片，quality=75 压完还是有 600KB，如果你有个“图片必须小于 500KB”的上传限制，直接上传就会失败。

加了二次校验后，逻辑就变聪明了：压完称重，超了就再压，直到达标。但也不能无限降质量，所以我设置了一个底线 30。如果降到 30 还是超过目标体积，多半是图片分辨率太大了，单纯压质量已经救不回来，这时候就要交给 Canvas 方案去缩尺寸。

这里还有一个交互层面的降级策略：如果 wx.compressImage 接口不存在，或者压缩失败，不要直接给用户报错。很多用户并不理解“压缩失败”是什么意思。我在失败时会做两件事：一是把原图路径返回，保证功能链路不断；二是上传时在后端放一个兜底压缩，如果前端传上来的图太大，后端用图形库压一遍再存储。前端能压就压，压不了让后端兜底，双保险。

3. Canvas 重绘方案：当官方接口不够用时

3.1 Canvas 压缩的原理：重绘就是重新编码

Canvas 方案听起来高深，本质就三件事：把图片画到 Canvas 上，调整 Canvas 的尺寸，导出新的图片文件。可以把它类比为一个图片“中转站”：原图先进来，你在中转站里把它缩小、裁切、重新排版，最后从出口出去的时候，拿到的已经是一张完全不一样的图了。

在小程序里的实现路径是：

1. wx.getImageInfo获取原图的宽高和路径。
2. 创建离屏 Canvas。小程序里用wx.createOffscreenCanvas（基础库 2.16.1+）或者传统的方式wx.createCanvasContext配合页面中的 canvas 节点。
3. 设置画布尺寸为目标尺寸，把原图画上去。
4. 调用wx.canvasToTempFilePath将 Canvas 内容导出为图片文件。

这里有个概念必须先分清楚：wx.createCanvasContext是老式 Canvas 2D 接口，它导出的路径是临时文件；wx.createOffscreenCanvas是离屏 Canvas，不占用页面节点，性能更好，但对基础库版本有要求。我在项目里优先用离屏 Canvas，兼容不了就回退到页面内 Canvas。

离屏 Canvas 的用法大致是这样的：

const canvas = wx.createOffscreenCanvas({ type: '2d', width: targetWidth, height: targetHeight }); const ctx = canvas.getContext('2d'); const img = canvas.createImage(); img.src = tempFilePath; img.onload = () => { ctx.drawImage(img, 0, 0, targetWidth, targetHeight); wx.canvasToTempFilePath({ canvas, destWidth: targetWidth, destHeight: targetHeight, fileType: 'jpg', quality: 0.8, success: (res) => { console.log(res.tempFilePath); }, }); };

注意canvas.createImage()的写法不同于网页里的new Image()。这和旧版wx.createCanvasContext相比，最大的优势是可以指定canvas实例，而旧接口需要页面中真实存在一个<canvas>标签节点，还要处理节点 id 和 context 的匹配，麻烦不少。

3.2 关键参数计算：目标尺寸和质量怎么定

使用 Canvas 压缩，最让人纠结的是：目标宽度设多少？质量设多少？我见过很多人随手填数值，结果导出的图要么还是很大，要么糊得没法看。

先看目标宽度。如果图片最终要展示在列表或者九宫格里，目标宽度不需要太大。微信小程序的页面逻辑宽度是 750rpx，大部分手机屏幕逻辑宽度在 375px 左右，2 倍屏显示需要 750px 的实际像素。所以你生成一张宽度为 750px 的图片，在普通列表里已经非常清晰了。如果是头像或者小图，150 ~ 300px 完全够用。如果是详情页大图，建议 1080px 左右，不要超过 1280px，再大在手机上看不出区别，只会白白增加体积和内存压力。

确定目标宽度的计算逻辑，我会按原图比例缩放：

const getTargetInfo = (srcWidth, srcHeight, maxWidth = 1080) => { let targetWidth = srcWidth; let targetHeight = srcHeight; const ratio = srcWidth / srcHeight; if (srcWidth > maxWidth) { targetWidth = maxWidth; targetHeight = Math.round(maxWidth / ratio); } return { targetWidth, targetHeight }; };

源图宽 4000px，高 3000px，maxWidth 设置为 1080px，算出来的目标尺寸是 1080x810。这样等比缩放，不会拉伸变形。

再看质量。Canvas 导出时，quality参数的取值范围是 0~1，对应 0%~100%，默认 0.92。经过无数轮测试，我推荐 0.8。因为 0.8 和 0.92 在手机屏幕上肉眼看不出明显差别，但体积通常能再小 20%~30%。如果原图内容比较敏感（比如有人脸、文字边缘），0.8 依然能保持较好的锐利度。

这里还要注意一个比较容易忽略的点：导出时我用的是fileType: 'jpg'。如果原图是 PNG，仍然可以导出为 jpg，这样能大幅减小体积。但前提是你接受透明背景变白。如果必须保留透明通道，就只能导出 png，压缩率会差很多。

3.3 处理图片旋转的坑：iOS 的 EXIF 方向问题

Canvas 方案里有非常多的人踩过一个隐藏坑：明明原图是正常的，画到 Canvas 再导出后，图片旋转了 90 度。这个问题在 iOS 上尤其常见，原因是 iPhone 拍出来的照片，并不总是“像素本身就是正的”存储，而是通过 EXIF 信息里的 Orientation 字段标记方向。图片实际像素可能是横向的，但查看器会根据 Orientation 自动旋转。

wx.getImageInfo返回结果里原本有一个orientation字段。但在某些基础库版本上，通过 Canvas 绘制时并不能自动处理 exif 方向。解决方法是：绘制前读取 orientation，如果是 90、270 这类旋转值，就把画布的宽高交换，再把 Canvas 整体旋转。

为了省事，我封装了一个处理方向并绘制的方法：

async function drawCorrectedImage(canvas, ctx, img, targetWidth, targetHeight, orientation) { if (orientation === 'up') { ctx.clearRect(0, 0, targetWidth, targetHeight); ctx.drawImage(img, 0, 0, targetWidth, targetHeight); return; } const needSwap = ['right', 'left'].includes(orientation); const w = needSwap ? targetHeight : targetWidth; const h = needSwap ? targetWidth : targetHeight; canvas.width = w; canvas.height = h; ctx.save(); if (orientation === 'right') { ctx.translate(w, 0); ctx.rotate(Math.PI / 2); } else if (orientation === 'left') { ctx.translate(0, h); ctx.rotate(-Math.PI / 2); } else if (orientation === 'down') { ctx.translate(w, h); ctx.rotate(Math.PI); } ctx.drawImage(img, 0, 0, targetWidth, targetHeight); ctx.restore(); }

这里 head 里保存一下状态再恢复，是因为旋转之后绘制坐标系会变，如果不回复，后面画别的东西会错位。这套处理逻辑覆盖了微信 getImageInfo 常见的 orientation 值：up、down、left、right。如果遇到特殊值up-mirrored这类，不常见，我直接按普通处理，避免过度复杂化。

4. 从选图到上传：把压缩流程接到真实项目里

4.1 完整流程串起来：选图、压缩、上传一步到位

只有零散的压缩函数是不够的，真正到项目里，你需要一个完整的链路：用户点击上传 → 选择图片 → 压缩 → 预览 → 上传到服务器。

我习惯在业务代码外面再包一层，做成一个通用的uploadImage函数。它接收用户选择的临时文件路径，内部完成压缩和上传，最后返回服务器地址。这样页面代码会非常干净。

大致结构如下：

async function uploadImage(tempFilePath) { // 1. 获取图片信息（用于 Canvas 方案的尺寸判断） const info = await new Promise((resolve, reject) => { wx.getImageInfo({ src: tempFilePath, success: resolve, fail: reject }); }); const fileManager = wx.getFileSystemManager(); const fileInfo = await new Promise((resolve) => { fileManager.getFileInfo({ filePath: tempFilePath, success: resolve, fail: resolve }); }); // 2. 先试用官方接口压缩 let finalPath = tempFilePath; if (fileInfo.size > 300 * 1024) { try { finalPath = await compressImage(tempFilePath, 75, 300); } catch (e) { // 压缩失败，继续使用原图，交给后端兜底 } } // 3. 如果还是太大，走 Canvas 缩尺寸 const finalInfo = await new Promise((resolve) => { fileManager.getFileInfo({ filePath: finalPath, success: resolve, fail: resolve }); }); if (finalInfo.size > 300 * 1024) { try { finalPath = await canvasCompress(finalPath, info.width, info.height, 1080, 0.8); } catch (e) { // 这里如果 Canvas 也失败，可能需要提示用户重新拍照 } } // 4. 上传 const uploadUrl = await wxUploadFile(finalPath); return uploadUrl; }

这个函数体现了完整的降级策略：先用官方接口，不行再上 Canvas，最后上传时后端还有兜底压缩。三级防线，图片体积基本能控制住。

4.2 上传后端联调的细节：文件名、临时路径和附件的坑

压缩完的图片是个临时路径。微信小程序里临时路径的有效期是本次启动期间，也就是说，如果你把压缩结果存到一个常量里，用户下次冷启动小程序的时候，这个路径就失效了。上传时必须在拿到临时路径后的有效期内完成。

我在上传时用wx.uploadFile：

function wxUploadFile(filePath) { return new Promise((resolve, reject) => { wx.uploadFile({ url: 'https://your-api.example.com/upload', filePath, name: 'file', formData: { scene: 'avatar' }, success: (res) => { const data = JSON.parse(res.data); if (data.code === 0) { resolve(data.data.url); } else { reject(new Error(data.msg)); } }, fail: reject, }); }); }

这里有几个容易被忽略的细节：

• filePath一定要是压缩后的新路径，不要写成原图路径。
• name字段要和后端接口定义的字段名一致。后端用$_FILES['file']接收，你前端 name 写错了，拿不到文件。
• formData可以额外传递业务信息，比如上传场景、用户标识，不过敏感数据最好还是放 header，也别硬放在 formData 里裸奔。

4.3 uniapp 项目里怎么复用这套逻辑

如果你用的是 uniapp 而不是原生微信小程序，上面的代码也能直接用。只需注意 uniapp 的uni.compressImage和uni.uploadFile是跨端的，但wx.getFileSystemManager这类只能在微信小程序环境下用，H5 上是没有的。

所以我在 uniapp 项目里会做一层兼容判断：

// #ifdef MP-WEIXIN const compressImage = (filePath, quality) => { return new Promise((resolve, reject) => { wx.compressImage({ src: filePath, quality, success: (res) => resolve(res.tempFilePath), fail: reject }); }); }; // #endif // #ifdef H5 const compressImage = (filePath, quality) => { // H5 上用 canvas 实现前端压缩 return compressByCanvasH5(filePath, quality); }; // #endif

H5 上的前端压缩，本质也是 Canvas，把文件对象读取进 Image，再导出为 blob。有很多文章问“h5有没有前端压缩图片的方式”，其实是有的，就是借助 canvas.toDataURL 或 canvas.toBlob。原理和小程序 Canvas 导出是同一个思路，只是 API 从 wx 前缀换成了浏览器原生 API。

5. 我踩过的坑：问题排查实录

5.1 压了等于没压：大小为什么没变化

这是一个出现频率极高的问题。我在排查一些同学代码的时候经常发现，明明调用了compressImage，但上传到服务器上的图片大小还是 5MB。仔细看代码才发现，问题出在“上传原图”而不是编译后的路径。他们打印日志时显示压缩成功，但上传的时候却用了chooseImage返回的原始路径。

还有一个原因就是 PNG 图片。wx.compressImage对 PNG 的压缩效果非常差，因为 PNG 本身是无损格式，你降低 quality 它也不是很在意。我在实际测试里，一张 3MB 的 PNG，quality 调到 50，压完还有 2.8MB，大小几乎没变。这时候必须用 Canvas 方案转成 JPEG，才能有效减小体积。

如果压完大小没变化，请务必检查两件事：你是不是传了原图路径？原图是不是 PNG？

5.2 大图直接卡死、闪退：内存峰值的根源

用 Canvas 处理超大图的时候，最容易遇到的就是闪退。比如一张 12000x9000 的全景照片，源文件可能才 10MB，但 Canvas 把它加载到内存里解码后，会占据 12000 x 9000 x 4（RGBA）字节，也就是大约 412MB 内存。这种内存峰值在手机上不闪退才怪。

解决思路有两个。第一个是避免一次性加载超大原图。微信小程序的 canvas 绘制大图是有内存压力的，你可以在绘制前先对原图做一次官方接口的预压缩，把尺寸降下来再画。比如先用wx.compressImage压一轮，得到一个大概几百 KB 的中间图，再画到 Canvas 上，内存压力就小很多。第二个是检测图片尺寸，如果宽度超过 2560px，直接放弃 Canvas 方案，先用官方接口把质量压到极低，或者提示用户选择更小的图片。

我见过不少团队牺牲了清晰度，也要保住稳定性，这是合理的。一个上传头像的功能，用户不会放大看细节，稳定不崩比清晰重要。

5.3 setData 和大图片内存峰值

这个坑很有意思，很多人没意识到和压缩有关系。我在项目里遇到过一次奇怪的崩溃：上传一个 8MB 的图片，压缩也做了，上传也成功了，但页面在预览大图的时候闪退。

排查到最后发现，问题是出在this.setData。一些同学会把压缩后的图片临时路径直接通过setData塞到 data 里，然后页面上的<image>立即加载。如果这张图片分辨率过大，setData本身的数据传输量不小，再加上 image 组件解码，内存峰值就爆了。

这里有一个很实用的建议：在setData里只存图片的临时路径字符串，不要在 data 里存整个 File 对象或者 base64 字符串。base64 编码字符串比二进制体积大 33%，放大图片后非常夸张。还有一些人会在 data 里保存图片的像素宽高，这也是多余的，用wx.getImageInfo按需获取就行。

5.4 基础库版本导致的兼容差异

小程序的基础库版本更新很快，你的代码部署后，跑在用户手机上的基础库版本可能千差万别。wx.compressImage是在基础库 2.4.0 开始支持的，wx.createOffscreenCanvas是 2.16.1 才支持的，wx.getFileSystemManager的某些接口也不同。

所以，代码里对所有用到的新 API 都要做能力判断。比如：

if (wx.createOffscreenCanvas) { // 使用离屏 Canvas } else { // 回退到页面内的 Canvas 节点 }

如果你实在担心低版本用户，可以在 app.json 里设置"libVersion": "2.30.4"，或者在开发者工具详情面板设置调试基础库版本。但注意，微信官方要求的最低基础库版本每个时期不一样，你设得太低，就没法用新 API；设得太高，老用户打不开小程序。

我的建议是，不要在代码里写死只走最新 API 的路径，尽量做降级。这一点特别是在做 Canvas 压缩时尤为重要。离屏 Canvas 好用，但不是所有机器都支持，页面内 Canvas 虽然是老方法，但兼容性最好。

5.5 抓包看不到压缩后的图？

经常有人在开发者工具或者手机上抓包，发现上传的图片体积还是很大，导致怀疑压缩没生效。这里有一个很常见的原因：wx.uploadFile上传时，你用抓包工具看到的 body 数据，是文件的二进制数据流，抓包工具对二进制大小展示本来就有限制。有些抓包工具只显示文件头部信息，让你误以为还是原始大小。

更靠谱的验证方式是在代码里打印wx.getFileSystemManager().getFileInfo的size字段，或者用wx.compressImage的回调结果里的路径，再对这个路径获取一次文件信息。只要返回的 size 比原图小，压缩就生效了。我通常会在上传前做一个 console.log，把压缩前和压缩后的大小都打出来，非常直观。

6. 写在最后的经验之谈

图片压缩这件事，看起来只是一个小小的工具函数，但真正做好，需要你把整条链路的细节都考虑到。前端压缩是一次性的成本，但换来的流畅体验、节省的带宽和存储费用，在整个项目生命周期里意义重大。做的时候宁可多写几种降级策略，也不要让用户在上传图片这种高频操作里遇到白屏、卡死或者上传失败。

我个人最满意的方案组合是这样的：官方wx.compressImage负责快速压体积，Canvas 负责处理官方接口搞不定的高分辨率大图，后端再放一个兜底，保证前端因为兼容问题没压住时也能收尾。每层都不完美，但组合起来，几乎覆盖了所有真实场景。

后续你还可以在这个基础上扩展更多的能力。比如用 Canvas 给图片加水印、生成圆形头像、做九宫格拼图；或者加上图片方向校正，让 iOS 用户上传的图永远是正的；再进一步，还可以结合你的业务场景，对商品图应用更大倍数的压缩，体验和成本都能兼顾。先把基础的压缩做好，你会发现后面这些扩展都是顺水推舟的事。