微信小程序证件照制作源码解析：canvas换底色与登录闭环实战

简介：这是一套证件照制作微信小程序完整源码，适合小程序开发者、创业者以及需要快速搭建图像处理类产品的团队使用。项目覆盖证件照拍摄、多尺寸制作、付费解锁、模板替换、换装美颜等完整业务链路，并内置多种流量主广告模式和微信公众号版本生成能力，便于直接二次开发并投入商业运营。压缩包共2000个文件，约39.18MB，核心代码以581个js逻辑文件、317个png界面素材、279个json配置为主，辅以php后台接口、sql数据库及axml、acss等小程序界面文件，前后端结构完整、目录清晰，方便按模块检索与修改。目前已有631人学习下载。除基础证件照功能外，还支持职业证件、公务员证件、身份证等多种类型制作，支持相册上传或相机拍摄、电子照存档，并可向其他小程序引流推荐，后台功能强大，是上线变现型工具类小程序的实用参考源码。

1. 从“证件照制作微信小程序源码”开始：先把这套代码要解决的问题说清

用户打开手机第一件事不是修图，而是翻相册有没有一张能直接交上去的证件照。这个标题里的源码，干的活就是把“拍一张普通照片 → 换底色 → 按标准尺寸裁剪 → 排版成可打印的六寸照”这条路用微信小程序完整落地。它解决的是频率不高但极其刚需的场景，适合想验证工具型付费产品的开发者，也适合摄影店、打印店老板用小程序的流量把线下冲印订单接回来。

但我要先说透一个反直觉的结论：这套源码真正难的不是“换底色”，而是“上线后还能稳定跑”。canvas 计算、微信登录获取手机号、域名校验、不同机型的顶部导航栏高度，任何一个环节没处理干净，用户都会在“保存到相册”这一步流失。源码拿到手只是起点，把边界条件补完，才是能投入运营的版本。

2. 证件照小程序的源码核心：canvas 换底色、裁剪与排版的计算方式

2.1 为什么先把底色和裁剪放在前端 canvas：后端方案的三个代价

很多人拿到源码第一反应是找后端抠图接口。真要接后端也行，但你要同时吞下三个代价。

第一个代价是延迟。用户从拍照页点“生成”到看到预览，中间跨一次公网请求，正常 300ms，高峰期可能到 1 秒。证件照这个场景里用户耐心极短，他点完按钮就等那一张图，转圈超过 2 秒基本就走了。第二是费用，按次计费的人像分割服务，免费额度只够你自己调试，用户量一起来账单涨得很快。第三是隐私，用户照片包含人脸信息，走后端就要过《个人信息保护法》那一套合规逻辑，开发者后台要加隐私协议、要说明收集目的，个人主体的小程序很容易被审核卡住。

所以我一般在源码里把“换底色”和“裁剪排版”全部放前端 canvas 完成。这样用户照片只在本地流转，生成一次底片不到 100ms，体验和成本都可控。需要说明的是，canvas 本身做不了“把人从背景里抠出来”这件事，人像分割服务仍然要接，只是分割一次之后，把透明底的 PNG 交给前端做颜色替换和排版，不再反复请求后端。很多源码“换底色后边缘有白边”，本质就是分割层没处理好，而不是 canvas 画得不对。

2.2 证件照尺寸换算成像素：295×413 与 413×579 的边界

证件照制作第一步，是把“厘米”换算成“像素”。常见做法是用 300dpi 作为输出精度，公式是像素 = 毫米 / 25.4 * dpi。一英寸证件照物理尺寸 25mm×35mm，算出来就是25/25.4*300 ≈ 295，35/25.4*300 ≈ 413。这个 295×413 几乎成了前端代码里的默认参数，看到它基本可以确定是 1 寸照。

我在参数设计上有个习惯：目标像素只作为画布输出上限，不直接决定原图缩放。因为微信小程序的 canvas 在 iOS 和 Android 上对画布最大宽高的限制并不完全一样，强行把画布设成 295×413，输出图片会很小。正确做法是把画布尺寸乘以windowInfo.pixelRatio，让物理像素跟上屏幕精度，再用wx.canvasToTempFilePath输出，这样保存在相册里的图才够清晰。你会在 2.3 节的代码里看到这个细节。

2.3 换底色与裁剪的实现：一个可以抄的 core 处理函数

下面这段是裁剪换底色链路的常用核心写法，以 canvas 2d 接口为例。注意它输入的是“已经完成抠图、背景透明的人像 PNG”，也就是分割服务返回的图。如果直接把原图扔进来，背景不会被替换，只会盖一层纯色上去。

// pages/photo/canvas.js 核心片段 function processPhoto(src, { targetW = 295, targetH = 413, bg = '#FFFFFF' }) { return new Promise((resolve, reject) => { const query = wx.createSelectorQuery() query.select('#photoCanvas') .fields({ node: true, size: true }) .exec((res) => { if (!res || !res[0] || !res[0].node) { return reject(new Error('canvas 节点不存在')) } const canvas = res[0].node const ctx = canvas.getContext('2d') const dpr = wx.getWindowInfo().pixelRatio // 画布物理像素 = 目标尺寸 x dpr，避免输出的证件照发虚 canvas.width = targetW * dpr canvas.height = targetH * dpr const img = canvas.createImage() img.onload = () => { // 第一遍 fillRect 清空上一轮残留，同时也作为人物背后的底色 ctx.fillStyle = bg ctx.fillRect(0, 0, canvas.width, canvas.height) // cover 模式：短边铺满画布，长边多余部分裁掉 const scale = Math.max(canvas.width / img.width, canvas.height / img.height) const dw = img.width * scale const dh = img.height * scale const dx = (canvas.width - dw) / 2 const dy = (canvas.height - dh) / 2 ctx.drawImage(img, dx, dy, dw, dh) // 强制输出 jpg，避免 iOS 相册对带 alpha 通道的 png 显示发灰 wx.canvasToTempFilePath({ canvas: canvas, fileType: 'jpg', quality: 0.92, success: (r) => resolve(r.tempFilePath), fail: reject, }) } img.onerror = () => reject(new Error('原图加载失败')) img.src = src }) }) }

这里有两个参数值得你细调。第一个是scale的计算。用Math.max是 cover 模式，照片会铺满整个画布，上下或左右会被裁掉一部分，适合用户已经正对镜头、头顶留白足够的自拍。如果你想把整个人像完整放进画布，那就改成Math.min，但这样两侧会出现空白，需要后端把原图扩展成目标宽高比再传回来。第二个是quality。证件照对清晰度要求高，我一般给 0.92，低于 0.85 时白色背景上容易出现可见的压缩噪点。如果生成后的 tempFilePath 还是超过 500KB，建议回头查原图尺寸，而不是继续往下压质量。

2.4 六寸排版照：坐标计算与“只缩小不放大”原则

电子证件照做好之后，用户通常需要一张排版照，拿去打印店冲出六寸照片再自己剪裁。六寸照的物理尺寸是 102mm×152mm，300dpi 下对应约 1205×1795 像素。排版就是在这个大画布里排布多张一寸照，常见是 2×2 排 4 张。

我一般不在页面里写死坐标，而是写一个排版计算函数，根据照片尺寸和间隙反推内容区，再居中放置：

function calcLayout(photoW, photoH, cols, rows, gap, pageW, pageH) { const contentW = cols * photoW + (cols - 1) * gap const contentH = rows * photoH + (rows - 1) * gap const scale = Math.min(pageW / contentW, pageH / contentH) // 只缩小不放大，保证照片的物理尺寸不虚标 const safeScale = Math.min(1, scale) const startX = (pageW - contentW * safeScale) / 2 const startY = (pageH - contentH * safeScale) / 2 return { startX, startY, scale: safeScale } }

以 1205×1795 输出、4 张 295×413 照片、间隙 20px 为例：内容区宽约 610，高约 846，整体远小于画布，safeScale为 1，照片不会被强行放大。这里最容易被忽略的是Math.min(1, scale)这一步。有些排版源码直接用放大后的 scale，结果一张一寸照被放大成满面幅，打印出来尺寸完全不对。排版的原则是宁留白边，不放大照片，这个习惯我在所有证件照源码里都保留。

3. 微信小程序登录获取手机号：把授权和付费放进同一个闭环

3.1 微信小程序登录获取手机号：为什么这是上线跑通的第一道门槛

证件照做免费体验很容易，但做运营就绕不开账号体系和反羊毛。用户在页面里拍完照、生成了图、保存到相册，这一整套流程如果不需要任何身份标识，服务端的存储和第三方分割调用就全白费了。而用户对“上传照片”本身有天然的隐私顾虑，不愿意随便授权手机号，所以常见做法是“先用微信登录获取 openid，下载或冲印前再用手机号解锁”。

微信小程序登录获取手机号这个能力有两个前提要注意：小程序主体必须是非个人，并且完成微信认证。个人开发者的小程序拿不到getPhoneNumber授权，只能走wx.login换 openid，然后在付费场景里引导用户留下手机号，用会员卡或线下打印作为交付方式。这一点在选型时就要确认，否则源码里写好的手机号按钮在提审时会被驳回。

3.2 登录与手机号授权的最小可用工程

下面这段是前端登录链路的常用骨架。wx.login负责拿登录 code，后端拿 code 换 openid；手机号则是用户点击open-type="getPhoneNumber"按钮后，后端用返回的 code 换真实手机号。整个过程中，手机号数据不应该返回到前端展示，只在后端记录后回传一个“已绑定”标识。

// pages/login/index.js Page({ data: { phoneBound: false }, onLoad() { // 冷启动时先建立 openid 会话，作为后续请求的用户标识 this.ensureLogin() }, ensureLogin() { return new Promise((resolve) => { wx.login({ success: ({ code }) => { wx.request({ url: 'https://your.server.example.com/wx/login', method: 'POST', data: { code, // 这个 code 只能用一次，不能缓存复用 }, success: ({ statusCode, data }) => { if (statusCode === 200 && data.openid) { this.setData({ session: data }) resolve(data) } }, }) }, }) }) }, onGetPhone(e) { if (!e.detail || !e.detail.code) { wx.showToast({ title: '手机号授权已取消', icon: 'none' }) return } wx.request({ url: 'https://your.server.example.com/wx/phone', method: 'POST', data: { code: e.detail.code, // 手机号动态令牌 }, success: ({ data }) => { this.setData({ phoneBound: true }) }, }) }, })

对应的 WXML 是一个按钮：

<button open-type="getPhoneNumber" bindgetphonenumber="onGetPhone"> 使用手机号登录并解锁下载 </button>

这段代码里有两个边界要留意。第一，wx.login返回的 code 有效期约 5 分钟，且只能使用一次。如果你在ensureLogin里拿到的 code 被后端消费后，又在手机号回调里拿同一个 code 去换，就会遇到“invalid code”。正确做法是每次onGetPhone触发时重新走ensureLogin，或者在后端把两个动作合并成一个接口，前端只提交一次 code。第二，开发者工具里调试手机号授权时，返回的是模拟数据，真机行为以“手机预览”里的结果为准。很多源码在开发者工具里跑得好好的，一上真机就报错，就是因为工具环境不能替代真机授权链路。

3.3 免费预览、付费下载、每天限一次：把工具变成可运营的状态

证件照小程序里最常见的运营模型是“免费试拍，付费下载原图”。但小程序对虚拟支付有严格限制，证件照这种虚拟商品直接在微信小程序里发起支付，很容易被拒。我见过靠谱的落地路径有两种。

一种是走“线下交付”：用户在小程序里完成排版，生成一张包含订单号和二维码的预览图，用户拿着这张图去门店冲印，门店扫码核销并收费。这样小程序只承担营销和引流，钱在线下收，不碰虚拟支付限制。另一种是“引导加企业微信”：用户想保存无水印原图，需要添加门店企微客服，客服发放打印券。这套玩法对个人开发者或者没有小程序支付资质的小商家特别适用。整体思路是：小程序负责把“拍证件照”这件事做快做好，把付费动作挪到法律和平台都允许的渠道里，而不是在源码里硬接一个支付组件。

4. 证件照小程序源码避坑清单：10002、域名校验和真机 canvas 黑匣子

4.1 微信小程序 10002 登录玄学：code 被重复消费

现象：用户第一次打开小程序一切正常，反复切换页面后再触发登录，后端日志报“invalid code”，前端偶发errno 10002。原因：wx.login返回的 code 被前端缓存，第二次请求时拿同一个 code 再去换 openid，微信服务端自然拒绝。这种情况在工具类小程序里特别常见，因为用户经常从相册页跳回首页，登录函数被重复调用。解决：把wx.login封装成带状态锁的 Promise，登录中重复调用直接返回同一个会话，并且保证每次向后端提交的都是新 code。日志里如果出现 10002，先查是不是代码里把上一次的 code 存了 globalData。

4.2 开发工具里正常，真机 request 全挂：request 合法域名校验

现象：开发者工具里勾选“不校验合法域名”后，点击生成按钮能正常请求后端；取消勾选再用手机预览，请求直接fail url not in domain list。原因：微信小程序正式环境强制要求所有wx.request的域名必须在小程序管理后台完成配置，且必须是 HTTPS，不能带端口。解决：登录微信公众平台，在“开发管理-开发设置-服务器域名”里把 request 合法域名加进去。调试期可以临时勾选“不校验合法域名”，但上线前一定要关掉。用抓包工具看时会发现，这类失败请求根本没有发出到服务器，是微信客户端拦在了前端。

提示：调试期的“不校验合法域名”不是上线配置，忘了关会在真机上翻车。

4.3 生成的人像边缘带白边或旧底色残留

现象：用户上传一张白色背景照片，换红底后，人像头发边缘出现一圈白色描边。原因：多数人像分割服务返回的透明图层，在发丝区域只保留部分 alpha，直接把透明 PNG 画到纯色背景上，半透明像素会和背景混出一圈亮边。解决：在处理透明图层之前，先给原图做一次边缘收缩。常见做法是在分割时开启 mask 的“边缘羽化”参数，或者在 canvas 里用ctx.drawImage前先把人像画到一个临时离屏 canvas，用ctx.globalCompositeOperation = 'destination-in'把 alpha 磨掉一圈。我自己更常用的土办法是：在输出前再铺一遍纯色底色，让边缘像素统一落入背景色，视觉上看不到白边。

4.4 iPhone 保存到相册后偏灰偏暗

现象：iPhone 上点击“保存到相册”，相册里照片明显发灰，Android 手机却正常。原因：生成结果默认带了 alpha 通道，iOS 相册对透明通道的处理方式不一致，直接把带透明的 PNG 以 jpg 方式存储，会出现灰度覆盖。解决：wx.canvasToTempFilePath里强制fileType: 'jpg'，并且保证画布底色不透明。只要换底色这一步先 fillRect 铺满，再绘制人像，输出路径就不会带透明通道。如果发现输出文件后缀还是 png，检查一下fileType参数是否被拼接传参覆盖。

4.5 页面顶部按钮在不同手机上高低不一

现象：设计稿里拍摄按钮距离顶部 64px，iPhone 上正常，Android 带挖孔屏的机型上按钮被状态栏或胶囊按钮遮住。原因：不同机型的 statusBar 高度和胶囊按钮位置不同，自定义导航栏写死高度就会错位。解决：在app.js启动时读取wx.getMenuButtonBoundingClientRect()和wx.getSystemInfoSync()，把导航栏高度做成全局变量，所有页面统一引用。具体计算方式下一章会给出，这里先提醒一个关键点：不要用windowHeight - canvasHeight来反向推导导航栏高度，刘海屏机型会算出一个负数。

5. 把源码塞进微信小程序的边界：2MB 分包、顶部导航栏和 uniapp 打包

5.1 source size 2612kb 超限：分包与资源压缩的落地配置

开发者工具报“source size 2612kb exceed max limit 2mb”这个错误，说明整个主包体积超过了 2MB，代码根本传不上去。证件照类小程序特别容易踩这个坑，因为拍照页、预览页、历史记录页、打印门店页全塞在一起，再加上几张证件照规格图标，轻松超过限制。

解决方向不是压缩代码，而是把页面拆分到分包。主包只保留首页、登录页和公共工具，照片制作、预览、历史、打印页全部放进subPackages：

{ "pages": ["pages/index/index", "pages/login/index"], "subPackages": [ { "root": "pages/photo", "pages": ["maker", "preview", "history"] }, { "root": "pages/print", "pages": ["shop", "order"] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["pages/photo", "pages/print"] } } }

分包配置里最难理解的是preloadRule。它的作用是进入首页后，在后台预下载指定分包。如果删掉这段，用户首次点击“制作证件照”时会先进入分包加载白屏，体验很差。分包之后还有两项硬优化要做：一是把证件照规格列表从代码里的常量改成远程配置，二是所有图标和示例图尽量用 WebP 压缩。此外，不要在小程序包里放任何一张底色素材图，纯色底色用十六进制色值生成就好，一张不必要的图片可能吃掉 100KB 还拉低启动速度。

5.2 顶部导航栏高度与 iPhone 安全区：拍照页的 canvas 对齐问题

证件照制作页的核心操作区是取景框和拍摄按钮，这两个元素通常都放在自定义导航栏下面。微信小程序的胶囊按钮在不同机型上的位置并不是固定的，iPhone 刘海屏的 statusBar 高度是 47px 左右，普通 Android 是 24px 左右。把导航栏高度计算成全局变量后，所有页面都能保持一致：

// app.js 或 utils/env.js const systemInfo = wx.getSystemInfoSync() const menuButton = wx.getMenuButtonBoundingClientRect() const statusBarHeight = systemInfo.statusBarHeight const navBarHeight = (menuButton.top - systemInfo.statusBarHeight) * 2 + menuButton.height export { statusBarHeight, navBarHeight, menuButton }

这个公式的逻辑是：胶囊按钮到状态栏底部的距离，就是导航栏上下 padding；乘以 2 是因为上下对称，最后加上胶囊自身高度，得到整个导航栏的高度。页面里使用padding-top: {{statusBarHeight}}px，再把内容高度设置为height: {{navBarHeight}}px，就能在真机上和胶囊按钮对齐。这里要特别提醒：wx.getSystemInfoSync在小程序里已经标记为 deprecated，但很多基础库版本仍然可用，新项目建议直接用wx.getWindowInfo()获取窗口信息，不过getMenuButtonBoundingClientRect始终是胶囊坐标的唯一来源，二者要配合使用。

5.3 uniapp 微信小程序打包：canvas 节点获取和条件编译

如果你拿到的是原生微信小程序源码，但打算用 uniapp 维护，那最大的坑在 canvas 节点获取方式。uniapp 里不能直接用wx.createSelectorQuery()，必须通过uni.createSelectorQuery()，并且要加.in(this)指定当前组件实例。下面这段是跨端兼容的常见写法：

// #ifdef MP-WEIXIN const query = uni.createSelectorQuery().in(this) query .select('#photoCanvas') .fields({ node: true, size: true }) .exec((res) => { const canvas = res[0].node const ctx = canvas.getContext('2d') }) // #endif

#ifdef MP-WEIXIN是 uniapp 的条件编译，只有编译到微信小程序时才会保留这段代码，H5 端不会执行。另外，uniapp 打包微信小程序时，默认会注入一套运行时 polyfill，所以同样代码在原生里只有 1.8MB，经过 uniapp 打包后很容易到 2.6MB。解决方法是打开manifest.json里的“压缩代码”选项，再把第三方组件库按需引入。如果你只需要证件照这一个功能，我更建议直接坚持原生小程序，后期迁移成本反而低。

6. 最后一章：用一套 10 分钟自测脚本把源码跑成可上线状态

源码交付后，我最看重的是“能不能在真机上跑通”。模拟器永远测不出 iPhone 的相册偏色，也测不出 Android 挖孔屏的导航栏高度。我的习惯是在工程里放一个环境调试函数，所有页面onLoad时调用一次，把关键环境信息打出来：

// utils/debug.js function debugEnv() { const info = wx.getSystemInfoSync() const menu = wx.getMenuButtonBoundingClientRect() const pages = getCurrentPages() const current = pages[pages.length - 1] console.log('[env]', { model: info.model, windowWidth: info.windowWidth, windowHeight: info.windowHeight, statusBarHeight: info.statusBarHeight, menuTop: menu.top, menuHeight: menu.height, route: current && current.route, }) }

打印出来的这些值，直接反映了当前机型的真实布局参数。我曾在交付时见过一个页面在 iPhone 15 上正常、在旧款 iPhone 8 上按钮下沉的案例，后来发现就是 menuButton 的 top 值在不同基础库版本里差 4px。提前打印环境信息，省掉的是一次次让用户录屏的心力。

自测时按这几个重点过一遍：换底色分别测白底、红底、蓝底，检查边缘白边和发丝残留；同一张原图生成 1 寸和 2 寸，确认头部占比没有明显拉伸；保存到相册后，在相册里查看图片清晰度和是否偏灰；手机号授权从开发者工具和真机各跑一次，后端日志里确认 code 没有被重复消费；最后在 Android 和 iOS 各走一遍分包加载，确保首次点击拍照页不会长时间白屏。如果这些项都通过，这套源码基本具备上线条件了。

我印象最深的一次返工，是用户反馈“生成的图很清楚，但人脸有点变形”。排查发现不是 canvas 计算公式的问题，而是因为原图本身是超广角自拍，脸在边缘出现透视畸变，源头照片就已经歪了。后来我在拍照页加了一个“轻微美颜 + 重新构图”的引导，让用户把脸放进取景框中央再拍，这个问题肉眼可见地变少。证件照这种工具，留住用户的不是滤镜多高级，而是每一步都让他觉得“这张图交出去不会丢人”，这个原则从源码到验收都适用。希望帮到你。

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