企业官网建设流程全解析

简介：这是一套面向微信小程序开发者的多功能图片处理源码，以图片为主题，集成照片加画框、图片压缩、带壳截图、文本翻译、模糊处理、尺寸缩放、圆角与格式转换、分辨率提升等十余项实用工具，适合直接学习或二次改造上线。资源为RAR压缩包，共242个文件，包含97个js逻辑脚本、38个json配置、38个wxss样式、37个wxml页面结构及29张png素材，结构清晰，方便对照页面布局与逻辑代码快速理解微信小程序的图片处理实现思路。包体仅1.29MB，轻量易部署，已有557人学习下载。尤其值得关注的是画框合成功能内置多种自适应模板，可根据图片尺寸自动匹配；整体模块划分明确，便于提取压缩、取色、黑白处理等能力作为独立工具脚本复用，对小程序开发者、图像工具爱好者以及需要快速搭建图片类应用的读者都有较高参考价值。

1. 一款微信小程序图片处理器到底能拿来做什么

微信小程序里做图片处理器，最反直觉的地方在于：画框、合图、贴纸这些操作全在用户手机端完成，服务端完全不参与渲染。用户上传一张照片，选一个画框模板，照片被铺在底层、透明画框盖上去、再叠文字和徽标，一键合成并保存相册。整个链路不依赖服务端渲染接口，也不吃服务器带宽，所以这类源码跑起来很快，接入成本基本集中在画布适配这一块。它适合三类人：打算做头像美化、节日海报、分享图生成这类轻工具小程序的开发者；想在现有项目里嵌入“图片画框合成”能力的前端工程师；以及被 Canvas 2D 真机兼容性折腾过、想找一套稳定方案的熟手。后面的内容就按选型、落地、清晰度、避坑、模板化五条线往下拆，每一条都对应你实际动手时会遇到的决策点。

2. 为什么选择前端 Canvas 合成：三条路线与渲染管线设计

2.1 三条技术路线怎么选：服务端合成、web-view 渲染、Canvas 2D

真正动手做图片处理器，第一件事不是写绘制代码，而是决定图片在哪里合成。常见路线有三条：服务端合成、web-view 渲染、小程序原生 Canvas 2D。服务端合成是用 Sharp、Puppeteer 一类工具在接口里出图，画质稳定、手机内存压力小，但每生成一张图都要消耗服务器资源，用户量一大账单涨得很快，而且小程序里访问自建图片服务要处理合法域名、下载鉴权和超时重试，链路明显变长。web-view 渲染的做法是铺一个 HTML 页面到 WebView 里，再用截图能力把页面转成图片，这种方案在 H5 里很常见，但小程序 web-view 对页面层级、尺寸和截屏兼容性的限制很多，真机上很容易出现“预览正常、导出缺一块”的诡异问题。

剩下就是 Canvas 2D，这也是目前小程序生态里最主流的实现方式。把模板、照片、文字全部绘制到一块画布上，再用 wx.canvasToTempFilePath 导出临时文件，最后保存到相册。前端合成的优势是零服务器成本、秒级出图、用户照片不出手机，尤其适合图片质量要求中等、模板数量多、并发不确定的轻工具型场景。代价是 Canvas 2D 的真机适配坑多，不同机型对画布尺寸、像素比、导出格式的容忍度都不一样，后面两张章就是在解决这些细节。

我一般按业务形态判断：如果产品形态是“用户自己选模板、自己预览、自己保存图片”，优先走 Canvas 2D，省成本且响应快；如果是后台批量生成证书、海报、商品主图这类高并发用途，再考虑服务端合成。标题里这个多功能图片处理器显然是前者，所以整套源码的绘制逻辑都围绕 Canvas 2D 展开。

2.2 旧 canvasContext 和新 Canvas 2D 接口的取舍

微信小程序早期提供的是 wx.createCanvasContext 这套旧接口，内部维护一条异步绘制队列，开发者调用 wx.drawCanvas 把指令提交上去。问题是它拿不到真正的 Canvas 节点，拿不到像素数据，绘图能力停留在“能画但不能精控”的程度。做圆角裁剪、按像素比高清导出、图层级控制这些操作时，旧接口的坑非常多，最典型的就是导出图模糊、透明区域出现黑边。新接口 Canvas 2D 是标准 Web Canvas 的小程序实现，通过 SelectorQuery 拿到节点后，得到完整的 CanvasRenderingContext2D 对象，绘制方式和浏览器几乎一致。

选新接口要注意三点：基础库版本至少 2.9.0，WXML 里必须写<canvas type="2d">，取值用 id 选择器而不是 canvas-id。小型工具类项目可能还在用旧接口，但做图片合成我会坚持迁移到 Canvas 2D，因为后续的高清导出、逐像素控制全靠它。下面是初始化最小代码：

// WXML 里放一个 2d 类型的 canvas 节点 // <canvas type="2d" id="poster" style="width: 750rpx; height: 1000rpx;"></canvas> initCanvas() { const query = wx.createSelectorQuery().in(this) query.select('#poster') .fields({ node: true, size: true }) .exec((res) => { if (!res || !res[0]) return const canvas = res[0].node const ctx = canvas.getContext('2d') // fields.size 返回的是 CSS 逻辑像素，不是 rpx const width = res[0].width const height = res[0].height this.canvas = canvas this.ctx = ctx this.width = width this.height = height }) }

这段代码的逻辑是：通过选择器拿到 canvas 对应的节点对象和实际渲染尺寸，再调用 getContext 获取绘图上下文。fields 里的 size 很关键，它返回的 width/height 是 WXML 中 CSS 尺寸换算后的像素值，不是 rpx 数值。后续所有绘制都以这组尺寸为基准，才能在不同机型上保持比例一致。参数说明：wx.createSelectorQuery().in(this)用于自定义组件内查找节点，普通页面可以不写.in(this)；fields({ node: true, size: true })表示既要节点对象，又要尺寸信息，缺 size 就拿不到宽高。这里拿到的是逻辑像素，也就是 CSS 像素，后面讲清晰度时还会提到为什么不能直接拿它当画布缓冲尺寸。

另一个常被忽略的点：Canvas 2D 的 ctx 坐标系原点在画布左上角，和 CSS 一致；但部分安卓机型的 canvas 节点宽高必须显式写成像素值，不能只靠 rpx 撑起来。我一般会在初始化时用 wx.getSystemInfoSync().windowWidth 换算出一组确定像素值，直接赋值给节点的 style，避免布局阶段尺寸测量不稳定。

2.3 渲染管线：从素材到导出图的完整链路

不管功能多花哨，图片处理器的核心渲染管线都可以拆成五段：素材准备、尺寸规划、分层绘制、导出临时文件、保存相册。素材准备负责把本地图片、网络图片、模板素材全部转成 Canvas 可绘制的 Image 对象；尺寸规划决定画布逻辑尺寸和导出尺寸；分层绘制按“底图→照片→画框→文字→贴纸”的顺序逐层画上去，后画的覆盖先画的；导出临时文件用 wx.canvasToTempFilePath 把画布内容转成 jpg 或 png；最后保存到相册并引导用户授权。

这里有两个容易理解偏的点。第一，绘制顺序即图层顺序，不是“先画谁谁就在上面”。画框功能里用户照片应该先画，画框素材后画，照片边缘才能被画框压住；反过来照片就会盖掉画框。第二，素材准备阶段尽量把网络图片统一交给 wx.getImageInfo 处理，让它先落到本地缓存，再用 canvas.createImage() 加载。直接往 drawImage 里传网络地址，iOS 上偶发绘制空白，统一走缓存后稳定很多。

管线里的请求封装也值得单独说。小程序里图片素材要处理合法域名、超时、缓存失效三个问题。我一般会在 utils 里做一个 loadImage 封装：先用 wx.getImageInfo 看素材是否已在本地，已缓存直接返回本地路径，未缓存先请求再进入绘制；同时给请求加 10 秒超时，避免弱网环境下用户一直盯着空白画布。模板素材这类几乎不变的资源还可以在本地维护“路径 + 过期时间”的索引，一周内不重复请求，模板列表加载会明显变快。

提示：这里说的缓存指微信的图片下载缓存机制，不需要自己存 Base64。同一张模板素材重复用，第二次 getImageInfo 通常会直接命中本地，速度肉眼可见。

把管线定义清楚后，后面的画框合成、清晰度优化、模板化玩法都是在五段链路里做增强，不会出现功能越加越乱的问题。

3. 图片画框与合成最小实现：源码安装和核心绘制代码

3.1 源码包结构与安装流程：下载后怎么跑起来

“安装简单”指的是下载、解压、导入微信开发者工具三步就能在模拟器里看到画框页面。拿到源码包后，在微信开发者工具里选“导入项目”，目录指到解压后的根目录，AppID 可以先填测试号，等需要真机预览时再换自己的 AppID。编译如果报“基础库版本过低”，把详情里的调试基础库切到 2.9.0 以上；如果页面空白，先看 Console 里有没有素材路径 404，很多源码包的素材是相对路径，目录层级一变就会挂。

一个标准的图片处理器源码包，结构通常是这样的：pages 目录下放各功能页，常见划分是首页（模板选择）、编辑页（画框与合成）、我的作品页（历史记录）；utils 目录放请求封装、绘图封装和素材常量；template 目录可能是 JSON 模板数据或图片素材；如果你看到 components 目录，说明作者已经把画框画布抽成了自定义组件，这种结构二次开发更方便。先不要急着读每一行代码，跑通优先。第一次编译后直接进画框页面，素材走本地路径的话模拟器马上能出图；素材走网络地址，就在开发者工具“详情—本地设置”里勾选“不校验合法域名”临时调试，真机预览则必须在 mp 后台配置 downloadFile 合法域名。

这里还有个页面布局的细节：画框画布所在的页面通常用自定义导航栏，否则胶囊按钮会盖住画布顶部。自定义导航栏必须处理微信小程序顶部导航栏高度，不能写死 64px，要按状态栏高度加导航栏高度动态计算，否则 X 系列和普通安卓机上画布顶部控件位置会漂移。这也是安装后第一个值得顺手修的点。

3.2 用 Canvas 2D 画一张带画框的合成图

画框合成的核心就一句话：先画照片，再画一张带透明区域的 PNG 画框素材盖在上面。透明 PNG 是画框能“透出”照片的关键，千万不要用不透明的 JPG 当画框，否则照片会被整个盖住。画框素材通常是一张和画布等宽等高的图，中间挖空，四周是花纹或边框，绘制时直接铺满画布。

下面是一段完整的最小绘制函数，兼容从相册选图进入和从模板列表进入两种入口。坐标都写成相对画布尺寸计算，方便你改成自己的模板：

async function drawFramePhoto(canvas, ctx, { bgPath, framePath, radius = 0 }) { const dpr = wx.getSystemInfoSync().pixelRatio || 2 const w = canvas.width / dpr const h = canvas.height / dpr // 清空画布，不清会导致上一帧残影叠加 ctx.clearRect(0, 0, w, h) // 第一层：用户照片，按覆盖比例铺满，多余部分裁掉 const photo = await loadImage(bgPath) const scale = Math.max(w / photo.width, h / photo.height) const dw = photo.width * scale const dh = photo.height * scale ctx.drawImage(photo, (w - dw) / 2, (h - dh) / 2, dw, dh) // 第二层：画框 PNG，透明区域露出下面的照片 const frame = await loadImage(framePath) ctx.drawImage(frame, 0, 0, w, h) // 第三层：圆角遮罩，让成品边缘更柔和 if (radius > 0) { ctx.save() roundRect(ctx, 0, 0, w, h, radius) ctx.clip() ctx.drawImage(frame, 0, 0, w, h) ctx.restore() } } function loadImage(src) { return new Promise((resolve, reject) => { wx.getImageInfo({ src, success(res) { const img = canvas.createImage() img.onload = () => resolve(img) img.onerror = reject img.src = res.path }, fail: reject }) }) }

代码里最需要注意的是照片铺满逻辑。Math.max(w / photo.width, h / photo.height)算的是覆盖比例，保证照片至少有一边填满画布，多余的部分通过负偏移被裁掉。如果换用 Math.min，得到的是包含效果，图片完整显示但四周留白。做画框通常用覆盖，做留白便签玩法才用包含，需求预判要提前做好。loadImage里先走 wx.getImageInfo 再 createImage，是为了绕开 iOS 上直接加载网络图片偶发的白屏问题。参数说明：bgPath 可以是临时路径或网络地址；framePath 建议总是用本地素材或已下载路径；radius 为 0 时不画圆角，大于 0 时按像素值切圆角。

这段代码适合放在 utils 里，页面只负责拿模板数据和调用函数。有个真机细节：部分安卓机型第一次 drawImage 会闪一下白屏，常见做法是先ctx.fillStyle = '#fff'; ctx.fillRect(0, 0, w, h)铺一层底色，再开始正式绘制，比 clearRect 更稳。至于代码里的 roundRect，小程序 Canvas 2D 基础库不一定内置，需要自己用 arcTo 或 arc 拼，这个不影响画框主流程。

3.3 多玩法的扩展边界：贴纸、文字和比例切换

画框只是地基，“多玩法”通常指贴纸、多图拼接、文字气泡和比例预设。实现上不需要另起炉灶，还是同一个 Canvas 2D，只是多定义几层绘制函数。贴纸本质是另一个 drawImage 调用，区别在于贴纸要有坐标、缩放、旋转三组参数；文字用 ctx.fillText，需要设置 font、textAlign、textBaseline；比例切换则是把画布按 1:1、3:4、9:16 预设重算。

支撑多玩法的关键是把玩法模板化。不要在代码里为每个玩法写死坐标，而是把玩法定义成模板结构：模板 JSON 里有一个图层数组，每个图层声明 type、src、x、y、width、height、rotate、radius 字段。绘制引擎遍历数组，按 type 分发到 drawImage 或 fillText，新增玩法就是新增一条模板数据，代码不用动。比例切换在页面上我一般用微信小程序的单选框组件让用户选，一组 radio 绑三个比例值，切换时重算画布尺寸和元素坐标。

比例切换时有个容易忽略的点：用户已经手动调整过贴纸或文字位置，切完比例这些元素会跑到画布外。常见做法是记录每个元素坐标与画布宽高的比例值，切换后乘上新的宽高，循环重算一遍坐标。这个细节决定体验，用户切完比例发现贴纸飞了，基本就不会再点第二次。

4. 清晰度与性能：把导出图从模糊调到高清的实操参数

4.1 像素比与画布尺寸：为什么默认导出都会糊

大多数人第一张合成图都有同一个问题：模拟器里挺清晰，保存到相册后一放大全是马赛克。这不是绘制的锅，而是画布物理像素没有跟上屏幕像素比。WXML 里 canvas 的 style 宽高是逻辑像素，canvas 内部 width/height 属性决定实际像素缓冲，两者不一致时绘制内容会被拉伸。微信小程序的逻辑像素和物理像素之间隔着一个 pixelRatio，普通屏是 2，部分安卓机是 3。如果不把 canvas.width 设为 style 宽度的 dpr 倍，导出图就只有 1 倍像素，自然糊。

正确的初始化方式是拿到节点的宽高后，立刻乘 dpr 重设画布内部尺寸，再执行 ctx.scale(dpr, dpr)。后续绘制代码仍按逻辑像素坐标写，ctx 会自动放大到物理像素。这段逻辑抽成公共函数，所有需要合成图的页面共用：

initHighDprCanvas(node, styleWidth, styleHeight) { const dpr = wx.getSystemInfoSync().pixelRatio || 2 const canvas = node canvas.width = styleWidth * dpr canvas.height = styleHeight * dpr const ctx = canvas.getContext('2d') ctx.scale(dpr, dpr) return { canvas, ctx, dpr, width: styleWidth, height: styleHeight } }

参数说明：styleWidth/styleHeight 是 SelectorQuery 返回的逻辑尺寸；canvas.width 是物理像素缓冲，直接决定导出图细节量；ctx.scale(dpr, dpr) 让后续 drawImage 的坐标单位保持逻辑像素。注意，如果 styleWidth 是 375，dpr 是 3，画布缓冲就是 1125px 宽，一张 9:16 海报高度超过 2000px，再加多层高清素材，内存占用会明显上升。所以 dpr 不是越大越好，普通图片 2 倍足够，追求画质的海报场景再用 3 倍，低端真机顶不住时要做降级。

4.2 导出参数与压缩策略：quality、destWidth 和 fileType 的组合

绘制完成只是第一步，导出才是清晰度的最后一道关口。wx.canvasToTempFilePath 的参数里，最容易踩坑的是 x/y/width/height 与 destWidth/destHeight 的关系。前者定义从画布哪个区域截取，后者定义导出图尺寸。希望导出图和画布一致时，destWidth 应该等于 canvas.width，也就是物理像素，而不是 styleWidth，否则会被二次压缩。fileType 用 png 保留透明通道但体积大；用 jpg 体积小但会丢弃透明通道，画框素材的透明区会变成黑底或白底。

我一般会提供两档导出：预览档和成品档。预览档用 quality 0.7 的 jpg，宽度不超过 800px，用于页面里快速展示；成品档用 quality 0.92 的 jpg 或 png，按物理像素原尺寸导出。两档互不影响，用户不用等高清图生成完才看到效果。核心导出代码：

function exportCanvas(canvas, ctx, { fileType = 'jpg', quality = 0.92 } = {}) { return new Promise((resolve, reject) => { wx.canvasToTempFilePath({ canvas, x: 0, y: 0, width: canvas.width, height: canvas.height, destWidth: canvas.width, destHeight: canvas.height, fileType, quality, success: (res) => resolve(res.tempFilePath), fail: reject }) }) }

参数说明：x/y/width/height 用 canvas.width 物理像素而不是逻辑像素，是为了截取完整缓冲而不留边；destWidth/destHeight 与 width 保持一致，等于放弃二次缩放；quality 只对 jpg 有效，png 会忽略。注意 wx.canvasToTempFilePath 在自定义组件里要在第二个参数传入组件实例 this，否则真机上可能找不到 canvas。如果导出发现透明区域变黑，先检查 fileType 是否误设成 jpg，透明通道必须用 png。

这里再补一个和体验直接相关的方案：图片素材缓存。微信小程序设置缓存时间本质上是 wx.setStorage 配合时间戳实现的，模板素材这种几乎不变的资源，可以在本地建“路径 + 过期时间”索引，一周内不重复请求，明显减少模板列表的网络等待。新建的请求封装里顺便把超时重试也做了，弱网下不至于一张图卡十秒。

4.3 内存治理：大图、离屏 Canvas 与绘制次数

Canvas 合成最怕的不是慢，而是内存持续上涨。真机上表现是页面卡顿、切换模板变慢，严重的直接黑屏闪退。治理内存的第一原则是每次重绘前清空画布，这个已经在绘制函数里做了；第二原则是图片对象用完后置空引用。Canvas 的 Image 对象即使绘制结束，也会一直占用解码后的像素缓冲，不及时置空，内存峰值会非常可观。

第三原则是避免重复加载同一张素材。模板列表每点一次就 getImageInfo 一次，虽然微信有缓存，但创建 Image 对象和解码仍有开销。常见做法是做一个内存 Map，key 是图片路径，value 是 Image 对象，重复使用直接取。第四原则是超大底图先降采样再绘制：把一张 4000px 的原图先用离屏 Canvas 缩到画布宽度，再 drawImage 到主画布，内存占用大幅下降。

离屏 Canvas 的做法和主画布一样，只是不挂到 WXML，直接通过wx.createOffscreenCanvas({ type: '2d', width, height })创建，绘制完再把内容画回主画布。这个 API 在低版本基础库可能不存在，要做能力检测，不存在就走临时 Canvas 节点方案。内存治理没有银弹，建议真机上连续切换 20 个模板，用开发者工具的 Performance 面板观察内存曲线，不崩不卡才算基本合格。

5. 避坑记录：真机上的 5 个翻车现场

5.1 素材画不出来，画布一片白

现象：模拟器正常，真机上部分网络图片画不出来，对应区域是空白。原因基本有两个：网络图片地址没在小程序后台配置 downloadFile 合法域名，真机上 wx.getImageInfo 直接失败；或者拿网络地址直接传给 canvas.createImage()，iOS 上加载时机不可控，onload 没触发就开始了绘制。解决：统一走 wx.getImageInfo 转成本地路径再 createImage，并在 utils 层加失败兜底——素材加载失败时给一张内置占位图，而不是让整张画布白掉。还有个小概率原因是图片是 WebP 格式，部分安卓旧机型的 Image 对象不支持，把模板素材统一转成 PNG 或 JPG 能避开这个坑。

5.2 导出图透明区域变成黑底

现象：PNG 画框素材带透明区域，导出后透明部分变成纯黑，整张图没法看。原因：wx.canvasToTempFilePath 的 fileType 设成了 jpg，jpg 不支持透明通道，透明像素被填成黑色；另一种情况是 iOS 上 ctx 没有预设画布底色，即使用 png，透明像素也可能被系统导出成黑。解决：需要透明就强制用 png；不需要透明且想压缩体积，则在绘制第一层前用 fillRect 铺白底，再导出 jpg。铺底色这个动作要放在所有绘制之前，如果放在 drawImage 之后会盖掉已经画好的内容。判断依据很简单：画框素材边缘允许有透明渐变就用 png，底色是纯色模版就铺底转 jpg。

5.3 安卓机型画布上限与内存溢出

现象：同一套代码，iPhone 上顺畅，某几款安卓手机一点“生成”就黑屏或者提示内存不足。原因：部分低端安卓机型对 canvas 物理像素缓冲有上限，常见阈值是 4096×4096px。当 dpr 设为 3、画布逻辑尺寸超过 1365px 时，缓冲直接越界。解决：初始化时加机型判断，canvas.width 超过 4096 就强制 dpr 降到 1.5；导出大图前先把不再用的 Image 引用置空，释放内存再走导出流程。如果项目还同时加载了多张 2000px 以上的素材，建议把底图降采样到 1280px 宽度再绘制，视觉差异很小，但内存峰值能降一半。

5.4 保存相册授权一直被拒

现象：点击“保存到相册”，真机弹出授权框，用户拒绝之后再点就静默失败，没有任何提示。原因：小程序对相册写入权限收紧，wx.saveImageToPhotosAlbum 第一次拒绝后，短时间内不会再次弹授权框，需要用户去设置页手动打开。解决：fail 回调里判断错误信息包含 auth deny 或 authorize no response，用 wx.showModal 说明原因，按钮引导跳转 wx.openSetting；同时把保存按钮文案设计成“保存并授权”，让用户第一次点击时更明确用途。还要注意不要在 onLoad 里直接调用授权接口，小程序要求授权弹窗必须由用户点击触发，程序主动弹会被拦截。

5.5 开发工具正常、真机错位的怪异问题

现象：模拟器里画框、贴纸、文字位置完全正确，真机预览时所有元素整体向右下角偏移。原因：Canvas 2D 节点尺寸时序问题。SelectorQuery 返回尺寸时 canvas 节点可能还没完成布局，拿到的 width/height 是 0 或默认值，后续绘制坐标全部被带偏。真机布局时序和模拟器差异很大，所以只在开发工具里测是发现不了的。解决：初始化放在 wx.nextTick 或 setData 回调之后执行，先用固定 style 尺寸兜底，等节点布局完成再重读真实尺寸重绘；初始化时直接用 px 设置 canvas 的 style 宽高，不要只写 rpx，减少布局阶段的不确定性。这个坑处理完，画框页面基本再没出现过错位投诉。

6. 进阶玩法：把图片处理器做成模板化批量生产线

6.1 模板数据结构与渲染引擎解耦

等玩法超过五个，你会发现每加一个玩法就改一次绘制函数是条死路。正确做法是把“模板”作为一等公民：用户选中的每个画框、贴纸、文字组合，都是一份 JSON 配置，渲染引擎只负责解释配置。下面是一个模板片段，代表“底图 + 画框 + 标题文字 + 徽标贴纸”四层：

{ "name": "春节贺卡", "ratio": "3:4", "layers": [ { "type": "image", "src": "/assets/bg_spring.png", "x": 0, "y": 0, "w": 750, "h": 1000 }, { "type": "image", "src": "/assets/frame_spring.png", "x": 0, "y": 0, "w": 750, "h": 1000 }, { "type": "text", "content": "新春快乐", "x": 60, "y": 120, "size": 48, "color": "#D32F2F", "font": "bold 48px sans-serif" }, { "type": "image", "src": "/assets/badge.png", "x": 560, "y": 720, "w": 120, "h": 120, "rotate": 12 } ] }

渲染引擎顺序遍历 layers，按 type 分发绘制：image 层走 drawImage 并支持旋转，text 层用 fillText 并支持换行。新增玩法时只需要扩展一个 type 分支，比如增加 rect 类型画圆角底色，模板作者加数据，代码不用动。核心是保持引擎无状态，每次渲染都从模板数据重新计算。

6.2 批量生成海报的队列与验证

批量生成场景还要加一个串行队列，避免并发导出把内存打爆。我一般写一个简单任务队列，每次只跑一张图的绘制与导出，完成再推下一个，每张导出完立即清理临时文件。验证时连续切换模板、连续保存二十次，确认内存曲线平稳后再放上线。

我的一个习惯是永远把“导出清晰度”作为全局配置放在 app.js 里，固定成两档常量，不在每个页面里重复定义；用户反馈模糊或导出太慢时，只需要改两个数字，不用逐个页面翻。还要留意低端安卓机和鸿蒙设备的 Canvas 行为差异，发布前找几台真机各跑一遍。Canvas 的机型兼容性是那种不踩一遍就不服气的玄学问题，等踩完了你会发现，问题基本都出在尺寸时序和 dpr 处理上。希望帮到你。

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