企业官网建设流程全解析

1. 项目概述：为什么在uni-app里做刮奖，不是“炫技”，而是真需求

“uni-app刮奖”这五个字，表面看是个小游戏功能，但背后是电商、营销、教育、政务类小程序里高频出现的真实业务场景。我做过6个不同行业的uni-app项目，其中4个都明确要求嵌入刮奖组件——不是为了好玩，而是因为用户参与率比普通按钮高3.7倍，核销转化率提升22%，尤其在线下核销券、抽奖活动页、会员积分兑换页中，刮奖成了默认交互方案。它解决的不是“怎么画个圆”，而是“如何在多端（iOS/Android/微信小程序/H5）一致、流畅、不卡顿地响应手指滑动，并准确识别刮开区域、实时反馈遮盖层消失效果”。关键词里反复出现的canvas、cover-view、scratch，恰恰暴露了三个核心矛盾点：canvas在小程序里渲染层级受限、cover-view无法响应touch事件、原生scratch逻辑在H5和小程序间行为不一致。很多人一上来就用<canvas>标签硬写，结果在iOS上刮不动、在微信小程序里被遮罩层盖住、在H5里手指移动延迟半秒——这不是代码写错了，是没吃透uni-app跨端渲染机制。这个项目适合两类人：一是正在开发营销活动页的前端同学，需要一个开箱即用、适配所有平台的刮奖方案；二是想深入理解uni-app底层渲染逻辑的同学，它会逼你直面canvas上下文获取时机、cover-view与view的z-index博弈、touch事件坐标系转换这些“文档里不写但天天踩坑”的细节。下面我会从设计思路开始，一层层拆解，不讲虚的，只说我在真实项目里验证过的每一步。

2. 整体架构设计：放弃“一套代码跑所有端”，选择“分端精准控制”

很多开发者一上来就想“write once, run everywhere”，结果在刮奖这种强交互场景里摔得最狠。uni-app的跨端能力是建立在“编译时平台判断+运行时条件渲染”基础上的，不是魔法。我试过三种主流方案，最终选定了“Canvas + Cover-View混合分端架构”，原因很实在：

• 纯Canvas方案（H5最优，小程序灾难）：H5里用<canvas>直接drawImage+clearRect，性能稳如老狗；但在微信小程序里，canvas是原生组件，层级永远在最顶层，刮奖遮罩层（比如一张带二维码的图片）会被canvas盖住，用户根本看不到“刮开效果”；iOS端更绝，canvas的touch事件坐标和视图坐标不一致，手指划过去，刮的却是偏移30px的地方。

• 纯Cover-View方案（小程序友好，H5失效）：cover-view支持z-index，能完美盖在图片上，用cover-image做遮罩层，再用cover-view做刮擦层，通过transform: translate模拟刮擦——但H5根本不支持cover-view，一编译就空白。

• 混合分端方案（实测全端可用）：H5端用Canvas原生绘制，小程序端用cover-view+touchmove坐标映射，App端（iOS/Android）用Canvas+原生渲染优化。关键不是“写一套”，而是“在编译时注入平台标识，在运行时动态加载对应逻辑”。uni-app提供了process.env.UNI_PLATFORM全局变量，我们用它做分支：

// utils/scratch-engine.js export const getScratchEngine = () => { const platform = process.env.UNI_PLATFORM if (platform === 'h5') { return import('./h5-canvas-engine.js') } else if (platform === 'mp-weixin' || platform === 'mp-alipay') { return import('./mp-cover-engine.js') } else if (platform === 'app') { return import('./app-canvas-engine.js') } }

这个设计的核心逻辑是：把“刮”的动作抽象成“坐标输入→区域标记→视觉反馈”三步，而具体实现交给平台最擅长的机制。H5用Canvas的像素级操作，小程序用cover-view的DOM层级控制，App端则调用原生Canvas API避免WebView渲染瓶颈。我特意没选“uni-app官方canvas组件”，因为它封装了太多层，反而掩盖了坐标系转换问题——比如微信小程序canvas的getBoundingClientRect()返回的clientX/clientY，在iPhone X以上机型会因安全区域偏移，必须手动减去window.safeAreaInsets.top。这些细节，只有自己手写引擎才能精准控制。

3. 核心细节解析：Canvas坐标系、Cover-View层级、刮开判定算法

3.1 H5端Canvas引擎：像素级刮擦与抗锯齿处理

H5端的Canvas是主战场，但“能画”不等于“刮得顺”。我最初用ctx.clearRect(x, y, width, height)，结果刮出毛边，像用砂纸磨玻璃。后来发现是Canvas的默认抗锯齿在作怪——clearRect清除的是矩形区域，但手指滑动是连续轨迹，相邻清除块之间有缝隙。解决方案是改用globalCompositeOperation = 'destination-out'，让新绘制的路径“挖掉”底层图像：

// h5-canvas-engine.js class H5ScratchEngine { constructor(canvasId) { this.canvas = uni.createSelectorQuery().in(this).select(`#${canvasId}`) this.ctx = null this.isDrawing = false this.lastX = 0 this.lastY = 0 } init() { this.canvas.exec((res) => { if (res && res.node) { const canvas = res.node const dpr = uni.getSystemInfoSync().pixelRatio const rect = canvas.getBoundingClientRect() canvas.width = rect.width * dpr canvas.height = rect.height * dpr this.ctx = canvas.getContext('2d') this.ctx.scale(dpr, dpr) // 高清适配 this.ctx.globalCompositeOperation = 'destination-out' // 关键！挖空模式 this.ctx.lineCap = 'round' this.ctx.lineJoin = 'round' this.ctx.lineWidth = 30 // 刮擦宽度，需根据设备dpi调整 } }) } onTouchStart(e) { this.isDrawing = true const touch = e.touches[0] this.lastX = touch.clientX this.lastY = touch.clientY } onTouchMove(e) { if (!this.isDrawing) return const touch = e.touches[0] const x = touch.clientX const y = touch.clientY this.ctx.beginPath() this.ctx.moveTo(this.lastX, this.lastY) this.ctx.lineTo(x, y) this.ctx.stroke() this.lastX = x this.lastY = y } onTouchEnd() { this.isDrawing = false } }

这里有两个易错点：第一，lineWidth不能写死为30px，必须结合pixelRatio动态计算，否则在2x屏上刮痕细得看不见；第二，globalCompositeOperation = 'destination-out'必须在stroke()前设置，且不能在每次draw前重置——我曾因漏掉这行，导致刮开后又自动“补上”，用户以为功能坏了。实测下来，lineCap = 'round'能让刮痕边缘圆润，避免尖锐锯齿，这是肉眼可辨的体验提升。

3.2 小程序端Cover-View引擎：Z-index陷阱与坐标映射校准

小程序端的难点不在“怎么刮”，而在“刮在哪”。cover-view的定位是绝对定位，但它的坐标系和页面视图不一致。我第一次写时，直接用e.touches[0].clientX作为cover-view的left值，结果在iPhone上刮的位置偏右80px。查了一整天文档才发现：微信小程序的cover-view坐标系以屏幕左上角为原点，而touch事件的clientX是以当前页面视口为原点，且受<scroll-view>滚动影响。解决方案是用wx.createSelectorQuery()获取刮奖容器的boundingClientRect，再做坐标转换：

// mp-cover-engine.js class MPCoverEngine { constructor(containerId) { this.containerId = containerId this.coverViewId = 'scratch-cover' this.isDragging = false this.offsetX = 0 this.offsetY = 0 } init() { // 获取容器位置 const query = wx.createSelectorQuery().in(this) query.select(`#${this.containerId}`).boundingClientRect() query.exec((res) => { if (res[0]) { this.containerRect = res[0] } }) } onTouchStart(e) { this.isDragging = true const touch = e.touches[0] // 校准坐标：touch.client - container.left/top this.offsetX = touch.clientX - this.containerRect.left this.offsetY = touch.clientY - this.containerRect.top } onTouchMove(e) { if (!this.isDragging) return const touch = e.touches[0] const x = touch.clientX - this.containerRect.left const y = touch.clientY - this.containerRect.top // 动态更新cover-view位置 this.updateCoverPosition(x, y) } updateCoverPosition(x, y) { // cover-view用transform位移，避免频繁修改left/top触发重排 const style = `transform: translate(${x - 15}px, ${y - 15}px); width: 30px; height: 30px; background: rgba(0,0,0,0.3); border-radius: 50%;` // 通过setData更新cover-view样式 this.setData({ coverStyle: style }) } }

这里的关键是transform: translate而非left/top，因为cover-view的style更新是异步的，用left/top会导致明显卡顿。另外，background: rgba(0,0,0,0.3)是模拟刮擦效果——不是真的“刮开”，而是用半透明圆点覆盖遮罩层，视觉上形成“刮开”感。我试过用cover-image做刮痕，但图片资源加载慢，手指一划一片空白，用户体验极差。用纯CSS圆点，启动快、响应即时，这才是小程序该有的做法。

3.3 刮开面积判定算法：不是“刮了就算”，而是“刮到阈值才生效”

刮奖的业务逻辑核心是“刮开多少才算中奖”。很多人用ctx.getImageData()读取像素，算透明度占比，但H5里getImageData在跨域图片上会报错，小程序里根本没这个API。我的方案是：用Canvas的isPointInPath()做区域采样，避开像素读取。原理很简单——把刮开区域抽象成多个圆形路径，每个路径中心点记录为“已刮点”，当已刮点数量超过阈值（比如总点数的30%），就触发中奖回调：

// 刮开点管理器 class ScratchAreaManager { constructor(width, height) { this.width = width this.height = height this.scratchedPoints = new Set() this.gridSize = 20 // 网格大小，用于去重 } addPoint(x, y) { // 网格化去重：同一网格内只记一个点 const gridX = Math.floor(x / this.gridSize) const gridY = Math.floor(y / this.gridSize) const key = `${gridX},${gridY}` this.scratchedPoints.add(key) } getCoverageRate() { const totalGrids = Math.ceil(this.width / this.gridSize) * Math.ceil(this.height / this.gridSize) return this.scratchedPoints.size / totalGrids } isScratchedEnough(threshold = 0.3) { return this.getCoverageRate() >= threshold } } // 在onTouchMove中调用 onTouchMove(e) { const x = e.touches[0].clientX const y = e.touches[0].clientY this.areaManager.addPoint(x, y) if (this.areaManager.isScratchedEnough(0.3)) { this.$emit('scratch-complete', { coverage: this.areaManager.getCoverageRate() }) } }

这个算法的优势是：零依赖图片资源，不涉及跨域，全平台兼容；计算量小，Set操作O(1)，1000个点也毫秒级；阈值可配置，运营同学要改成50%刮开率，改个参数就行。我刻意没用“刮开像素面积”这种方案，因为Canvas的getImageData在iOS Safari里性能极差，滑动时帧率直接掉到20fps，用户会觉得“卡”。

4. 实操过程详解：从零搭建可复用的刮奖组件

4.1 组件结构设计：slot插槽+props配置+事件总线

一个工业级刮奖组件，必须支持“任意内容刮奖”，而不是只能刮固定图片。我设计的组件结构是：

<!-- components/uni-scratch.vue --> <template> <view class="scratch-container" :style="{ width: width, height: height }"> <!-- 背景内容（可放图片、文字、二维码） --> <slot name="content"></slot> <!-- 遮罩层 --> <view v-if="showMask" class="mask-layer" :style="maskStyle"> <slot name="mask"></slot> </view> <!-- 刮擦层（H5用canvas，小程序用cover-view） --> <template v-if="platform === 'h5'"> <canvas :id="canvasId" class="scratch-canvas" @touchstart="handleTouchStart" @touchmove="handleTouchMove" @touchend="handleTouchEnd" ></canvas> </template> <template v-else> <cover-view :id="coverViewId" class="scratch-cover" :style="coverStyle" ></cover-view> </template> </view> </template> <script> import { getScratchEngine } from '@/utils/scratch-engine.js' export default { name: 'UniScratch', props: { width: { type: String, default: '300px' }, height: { type: String, default: '200px' }, showMask: { type: Boolean, default: true }, maskOpacity: { type: Number, default: 0.8 }, scratchThreshold: { type: Number, default: 0.3 } }, data() { return { platform: process.env.UNI_PLATFORM, canvasId: `scratch-canvas-${Date.now()}`, coverViewId: `scratch-cover-${Date.now()}`, coverStyle: '', maskStyle: {} } }, mounted() { this.initMaskStyle() this.initEngine() }, methods: { initMaskStyle() { this.maskStyle = { 'background-color': `rgba(0,0,0,${this.maskOpacity})`, 'width': this.width, 'height': this.height } }, async initEngine() { const engineModule = await getScratchEngine() this.engine = new engineModule.default(this.canvasId || this.coverViewId) this.engine.init() this.engine.on('complete', (data) => { this.$emit('complete', data) }) }, handleTouchStart(e) { this.engine?.onTouchStart?.(e) }, handleTouchMove(e) { this.engine?.onTouchMove?.(e) }, handleTouchEnd(e) { this.engine?.onTouchEnd?.(e) } } } </script>

这个设计的精妙之处在于：用<slot>解耦内容与逻辑，用props暴露业务参数，用$emit传递结果。运营同学要换刮奖背景，只需在父组件里写：

<uni-scratch width="100%" height="300rpx" :scratch-threshold="0.5"> <template #content> <image src="/static/prize-bg.jpg" mode="aspectFill" class="bg-img"></image> </template> <template #mask> <text class="mask-text">刮一刮，赢大奖</text> </template> </uni-scratch>

完全不用碰组件内部代码。scratch-threshold传0.5，就是刮开50%才触发中奖，比硬编码灵活十倍。

4.2 H5端Canvas初始化避坑指南：DPR适配与内存泄漏

H5端Canvas初始化最容易犯两个错误：一是忽略设备像素比（DPR），导致高清屏上模糊；二是Canvas节点复用时未清理，造成内存泄漏。我踩过的坑：

• DPR适配必须做两件事：① 设置canvas.width/height为rect.width * dpr；② 用ctx.scale(dpr, dpr)缩放绘图上下文。漏掉第二步，drawImage会拉伸变形。

• 内存泄漏陷阱：页面跳转时，Canvas的touch事件监听器没移除。uni-app的onUnload钩子里必须手动解绑：

// h5-canvas-engine.js class H5ScratchEngine { constructor(canvasId) { this.canvasId = canvasId this.canvas = null this.ctx = null this.touchStartHandler = null this.touchMoveHandler = null this.touchEndHandler = null } init() { this.canvas = document.getElementById(this.canvasId) // ... 初始化代码 // 绑定事件 this.touchStartHandler = this.onTouchStart.bind(this) this.touchMoveHandler = this.onTouchMove.bind(this) this.touchEndHandler = this.onTouchEnd.bind(this) this.canvas.addEventListener('touchstart', this.touchStartHandler) this.canvas.addEventListener('touchmove', this.touchMoveHandler) this.canvas.addEventListener('touchend', this.touchEndHandler) } destroy() { // 必须解绑，否则页面销毁后事件还在 this.canvas?.removeEventListener('touchstart', this.touchStartHandler) this.canvas?.removeEventListener('touchmove', this.touchMoveHandler) this.canvas?.removeEventListener('touchend', this.touchEndHandler) } }

在组件beforeDestroy钩子中调用this.engine.destroy()，这是保命操作。我曾有个项目，用户反复进入刮奖页，内存占用每页涨2MB，三天后APP直接闪退——根源就是Canvas事件没解绑。

4.3 小程序Cover-View动态样式优化：减少setData频次

小程序里频繁调用setData更新cover-view样式，会触发WXML重渲染，滑动时卡顿明显。我的优化方案是：用CSS变量+动态class替代内联style。先在WXML里定义多个预设class：

<!-- cover-view支持class，但不支持动态class绑定，所以用条件class --> <cover-view :class="['scratch-cover', coverClass]" :style="coverStyle" ></cover-view>

/* 定义10个预设位置class */ .scratch-cover.pos-0 { transform: translate(0px, 0px); } .scratch-cover.pos-1 { transform: translate(10px, 10px); } .scratch-cover.pos-2 { transform: translate(20px, 20px); } /* ... 一直到pos-9 */

然后在JS里用Math.round(x/10)映射到0-9区间，只更新class名，不触发动态style：

updateCoverPosition(x, y) { const posX = Math.round(x / 10) const posY = Math.round(y / 10) const posIndex = Math.min(9, Math.max(0, posX + posY)) this.setData({ coverClass: `pos-${posIndex}` }) }

实测下来，滑动帧率从30fps提升到58fps，用户感知明显。这个技巧在小程序动画优化中通用，不只是刮奖。

5. 常见问题与排查技巧实录：那些文档里找不到的答案

5.1 iOS端Canvas刮不动？检查安全区域与事件穿透

问题现象：iPhone上手指划过，Canvas毫无反应，但console里touch事件正常打印。
排查路径：

1. 先确认Canvas是否被其他元素遮挡——用document.elementFromPoint()测试，发现Canvas上层有个透明<view>；
2. 这个<view>是uni-app自动生成的，用于处理安全区域，但它的pointer-events: auto阻止了touch事件穿透；
3. 解决方案：给Canvas加style="pointer-events: auto"，并确保父容器没有overflow: hidden（它会裁剪事件区域）。

提示：iOS端Canvas事件失效90%源于安全区域遮罩或父容器overflow，不要一上来就怀疑Canvas API。

5.2 微信小程序刮痕断续？校准touch事件坐标系

问题现象：刮的时候痕迹断断续续，像信号不好。
根本原因：微信小程序touch事件的clientX/clientY在<scroll-view>内滚动时，会随滚动位置变化，而cover-view的定位是绝对的。
解决方案：不用clientX，改用pageX/pageY，再减去页面滚动距离：

onTouchStart(e) { const touch = e.touches[0] // pageX/pageY是相对于整个页面的坐标 const scrollY = uni.getStorageSync('scrollTop') || 0 // 存储滚动位置 this.offsetX = touch.pageX - this.containerRect.left this.offsetY = touch.pageY - this.containerRect.top - scrollY }

注意：pageX/pageY在部分安卓机上不准确，所以必须配合getSystemInfo判断设备，iOS用pageX，安卓用clientX——这是跨端兼容的无奈之举。

5.3 刮开后内容显示不全？Cover-View层级与z-index博弈

问题现象：刮开后，背景图片只显示一半，上半部分被其他组件盖住。
原因分析：cover-view的z-index是独立于Webview的，但它受<cover-view>父容器的z-index影响。如果父容器z-index是10，cover-view即使设z-index:999，也会被z-index:11的普通view盖住。
终极解法：

• 确保刮奖容器的父级view z-index设为1；
• cover-view自身z-index设为999；
• 所有同级非cover组件z-index必须小于1；
• 如果必须有高z-index组件（如导航栏），用position: fixed脱离文档流，避免层级冲突。

5.4 H5端刮痕边缘发虚？关闭Canvas抗锯齿

问题现象：刮开边缘有半透明毛边，不像实物刮奖那么干脆。
技术根源：Canvas默认开启抗锯齿，lineWidth=30实际绘制的是29-31px渐变区域。
解决方案：用ctx.imageSmoothingEnabled = false关闭插值，再配合ctx.lineWidth = 30：

this.ctx.imageSmoothingEnabled = false this.ctx.lineWidth = 30 this.ctx.lineCap = 'square' // 方形端点，杜绝圆角毛边

实测对比：开启抗锯齿时刮痕宽度浮动±2px，关闭后严格30px，边缘锐利如刀切。

5.5 刮奖组件白屏？检查Canvas ID唯一性与编译缓存

问题现象：H5端首次加载白屏，刷新后正常。
根因：Canvas ID重复。uni-app编译时会复用组件实例，若canvasId用静态字符串（如scratch-canvas），多个刮奖组件会共用一个ID，后加载的覆盖前加载的。
修复方式：ID必须动态生成，且保证页面内唯一：

data() { return { canvasId: `scratch-canvas-${Date.now()}-${Math.random().toString(36).substr(2, 9)}` } }

注意：Date.now()在快速连续创建时可能重复，必须拼接随机字符串。这个坑我花了3小时才定位到，文档里完全没提。

6. 进阶扩展：从刮奖到互动营销组件库

刮奖只是起点，这套架构可以无缝扩展成营销组件库。我在上一个电商项目里，基于此做了三个延伸：

• 进度刮奖：刮开面积实时驱动进度条，刮到80%显示“再刮一点”，刮满100%弹出优惠券——用areaManager.getCoverageRate()实时更新进度，比轮询性能好10倍。

• 多层刮奖：第一层刮开显示“谢谢参与”，第二层刮开显示“再来一次”，第三层才是真实奖品。实现方式是叠加三层cover-view，每层用不同opacity，刮开一层就setData({ layer1Opacity: 0 })，视觉上层层剥离。

• 刮奖+AR融合：H5端接入Three.js，刮开区域触发3D模型旋转；小程序端用wx.createCameraContext()调起摄像头，刮开后显示AR特效。核心还是“刮开事件”作为触发器，内容可无限替换。

最后分享一个小技巧：刮奖组件的加载性能优化。我把Canvas初始化逻辑放到onReady之后，用setTimeout(() => { this.initEngine() }, 100)延迟执行，避免阻塞页面首屏渲染。实测LCP（最大内容绘制）从2.3s降到1.1s，Google PageSpeed评分从62升到89。技术没有银弹，但每一个100ms的优化，都在为用户多留一秒。