前阵子给个人主页加了一个相册模块，第一反应肯定是直接用CSS动画轮播，试了一圈发现自己心里过不去——图片切换、缩放、粒子背景这些效果用CSS做起来，要么卡在兼容性上，要么写出的代码连自己都不想维护。后来索性自己用canvas写了一版动态相册，前后大概三百行代码，效果反而比预期好很多。这篇文章就把整个实现过程拆开来讲，包括方案选型、核心API、绘制思路和踩坑记录，适合那些已经会一点JavaScript、但还没怎么碰过canvas的读者。这个方案不需要依赖任何框架，纯原生JS加一个canvas标签就能跑。
1. 为什么选择Canvas做相册：选型思路与效果拆解
1.1 三套方案对比：CSS、DOM操作与Canvas各自的边界
做动态相册前，我先把三个技术方案摆在桌上对比了一遍。纯CSS动画方案最直接，给图片容器设置transition和transform，就能做出位移、缩放、旋转这些效果，很多轮播组件都是这么实现的。但CSS方案有两个硬伤：一是复杂效果需要大量嵌套容器和动画关键帧，代码结构和样式表会迅速膨胀；二是粒子特效、逐像素处理这类操作，用CSS几乎无法完成。当你想让图片边缘飘出光点，或者做图片碎片化重组，只能换工具。
第二种方案是操作DOM节点，配合JavaScript逐帧修改元素属性。这个方案比纯CSS灵活一些，但问题同样明显：频繁修改DOM节点会触发大量重排与重绘，图片一多、动效一复杂，性能就崩。尤其是移动端，几十个节点同时做位移动画，帧率很容易掉到30以下。
最后是Canvas方案。Canvas本质上是一块画布，所有内容都由JavaScript直接绘制到像素上，浏览器不再关心你画的是什么，只负责把画布内容合成到页面。这意味着动画过程中没有DOM参与，性能损耗被降到最低，而且你能精确控制每一个像素。动态相册里常见的进场旋转、缩放、透明度渐变、粒子背景、鼠标视差，用Canvas做起来就是一套requestAnimationFrame循环里的事情。当时我就确定：这个项目用Canvas，把绘制逻辑统一放在一个渲染循环里，代码结构最清晰，性能也最可控。
当然，Canvas不是万能药。它的缺点是没有DOM结构，难以做SEO，可访问性也比较差；画面里的文本无法被选中；还需要自己实现事件系统和布局逻辑。但相册这个场景，恰恰是Canvas擅长的领域：内容以图片为主，不需要被搜索引擎收录，交互集中在点击和拖拽上，完全可以通过坐标计算自己处理。
1.2 效果清单：这次做的“动态”具体指什么
一个相册页面，如果只是把图片平铺在Canvas上静态展示，那用图片标签就够了，没必要上Canvas。这里的“动态”我拆成了四个层面的效果，每个效果的复杂度都控制在合理范围内，既能让读者看到Canvas的能力，又不至于把代码搞到几百行让人劝退。
第一个层面是图片的进场动效。每张图片在切换时不是生硬地突然出现，而是带着旋转、缩放和透明度变化进入画面。我这里选择的是“新图从略大尺寸和轻微旋转状态逐渐归位，旧图同时淡出并略微偏移”的组合效果。这种效果常见于幻灯片和产品展示页，视觉上比较柔和，实现逻辑也不算复杂。
第二个层面是切换交互。用户点击画面左侧或右侧可以切换到上一张或下一张，点击中间区域则不做响应，避免误触。配合自动轮播，可以定时切换图片，整套交互逻辑在Canvas中通过判断点击坐标来实现。
第三个层面是鼠标视差。鼠标在画布上移动时，当前显示的图片会朝向鼠标位置产生轻微偏移，背景的粒子层也会跟着移动，产生一种“画面在呼吸”的质感。这个效果成本很低，但能明显提升页面的高级感。
第四个层面是粒子背景。在图片下层绘制一些缓慢漂浮、大小不一、半透明的小光点，模拟星空或尘埃效果。粒子系统是Canvas最经典的玩法之一，和很多canvas游戏里的特效属于同一套逻辑，理解了这一个，以后做烟花、雨雪、碎片飞散都是同一个思路。
这四个效果组合在一起，就是一个完整的“动态canvas相册简单效果展示”。整个项目里没有引入任何库，所有代码都是原生JavaScript，你可以把代码复制到本地，换掉图片路径就能直接跑。
2. 基础先行：坐标系、drawImage和图片加载，绕不开的三个点
2.1 坐标系与绘图模型，先搞清楚这些再动手
很多人写Canvas代码容易懵，就是因为坐标系的理解没有过关。Canvas的坐标系很简单：原点在画布左上角，x轴向右为正，y轴向下为正，单位是像素。所有绘制操作都是在这个坐标系里进行。举个例子，ctx.fillRect(100, 50, 200, 150)表示在离左边界100像素、离上边界50像素的位置，绘制一个宽200像素、高150像素的矩形。
但真正容易坑人的是Canvas的绘图状态模型。Canvas不是“画完一笔就生成一个独立图层”，而是像一张真实的宣纸，后来的绘制会直接覆盖之前的像素，除非你使用全局透明度或者清除画布，否则旧内容不会被自动清理。所以在动画循环里，每一帧开头基本都要执行一次ctx.clearRect(0, 0, width, height)清空画布，再重新绘制当前状态下的所有内容。
Canvas的绘制状态是由一组属性组成的，包括当前变换矩阵、透明度、填充样式、描边样式、阴影等。这些属性在Canvas里是“有记忆”的，你用ctx.globalAlpha = 0.5设置半透明之后，如果不主动改回来，后面所有绘制都会保持半透明。因此我习惯在每次绘制前，显式设置好需要的状态，避免上一帧的状态残留到下一帧，产生“灵异效果”。这个细节在我后面调试动画时帮了不少忙。
关于绘图模型，还有一点值得说：默认情况下Canvas是非保留绘制模式的，也就是说浏览器只保存你的绘制结果，不保存绘制操作本身。如果你想做局部更新，比如只清除屏幕上某个矩形区域，可以通过ctx.save()和ctx.restore()配合坐标系变换来实现。save()会将当前绘图状态压入栈中，restore()会弹出并恢复之前保存的状态，这两个方法成对出现，是做复杂动画时最常用的状态管理手段。
2.2 drawImage的三种用法，以及图片适配裁剪的核心
ctx.drawImage()是相册项目里用的最多的API，它一共有三种重载形式。第一种是drawImage(image, x, y)，把图片原始大小绘制到指定位置，适合图标这类不需要缩放的素材。第二种是drawImage(image, x, y, width, height)，把图片缩放到指定宽高后绘制，适合已知目标尺寸的简单场景。第三种是九参数版本：drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh)，先按源矩形从原始图片里裁剪出一块区域，再把这部分绘制到画布的目标矩形中。
第三种子矩形裁剪方式是实现图片“cover模式”的关键。CSS里的object-fit: cover语义大家都熟悉：图片保持宽高比，填满容器，超出部分裁掉。Canvas里没有现成的cover方法，但通过九参数版本可以手动实现。
具体思路是这样的：假设目标绘制区域的宽高是w和h，原始图片的宽高是imgWidth和imgHeight。如果图片的宽高比大于目标的宽高比，说明图片偏宽，需要按高度对齐，把两侧多余部分裁掉；反之则按宽度对齐，把上下多余部分裁掉。计算源矩形后，直接用九参数版本绘制即可。这个工具函数几乎在所有Canvas图片项目里都会用到，我在后面实现部分会给出完整代码。
2.3 图片加载的时序坑：没有加载完就绘制等于画了个寂寞
浏览器加载图片是异步的，这个问题在纯DOM页面里不太容易暴露，因为<img>标签会在图片字节流到达后自动渲染。但在Canvas里，如果你用new Image()创建图片对象后立刻调用drawImage()，画布上只会出现一片空白，因为此时图片的width还是0，数据还没从网络或本地文件里拿到。
解决这个问题的标准方式是在img.onload回调之后再绘制。更稳妥的做法是把所有图片的加载状态统一管理起来：每张图片对应一个Image对象，记录已加载完成的图片数量，当所有图片都加载完毕后再启动动画循环。这样能避免动画运行到一半还有图片在加载，导致画面突然闪出占位空白的情况。
如果图片来自其他域名，还需要设置img.crossOrigin = 'anonymous'，否则Canvas画布会被视为“被污染”，后续无法执行canvas.toDataURL()等导出操作。我本地测试时用的是同目录图片，没踩这个坑，但部署到线上以后如果图片走CDN，这个问题大概率会冒出来，建议从一开始就加上这一行。
3. 完整实现：从初始化到动效，一个能直接跑起来的相册
3.1 页面骨架与画布初始化，注意高DPI适配
HTML部分非常简洁，整个页面只需要一个canvas标签，以及一组CSS来让画布铺满视口。CSS里我把canvas设置成display: block并指定宽高为视口尺寸，避免canvas被当作行内元素而产生莫名间隙。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>动态Canvas相册</title> <style> body { margin: 0; overflow: hidden; background: #101014; } canvas { display: block; width: 100vw; height: 100vh; } </style> </head> <body> <canvas id="albumCanvas"></canvas> <script src="album.js"></script> </body> </html>这里有一个很多新手会忽略的高DPI适配问题。Canvas有两个尺寸属性：width和height，它们表示画布的像素分辨率；而CSS的width和height表示画布在页面上的显示大小。在Retina屏等高像素密度设备上，如果两者相等，Canvas会用过低的分辨率拉伸到显示尺寸，画面会明显模糊。
目前主流的适配方法是读取window.devicePixelRatio，将Canvas的物理像素尺寸乘以这个倍数，再通过ctx.setTransform(dpr, 0, 0, dpr, 0, 0)将所有后续绘制操作的坐标系缩放回CSS像素单位。这样你写代码时仍然以逻辑像素为单位思考，但实际渲染是高清的。我把这段初始化逻辑封装成了resizeCanvas()函数，页面尺寸变化时自动重设画布，同时保持视差和粒子不因窗口缩放而错位。
3.2 图片加载与基础绘制函数，为动效打好底子
图片管理部分，我定义了一个images数组存放所有Image对象，一个imageUrls数组存放图片路径。通过loadImages()函数统一加载，每加载完一张就在回调里更新计数器，等全部加载完成再执行后续的启动逻辑。
const canvas = document.getElementById('albumCanvas'); const ctx = canvas.getContext('2d'); const imageUrls = ['img/photo1.jpg', 'img/photo2.jpg', 'img/photo3.jpg', 'img/photo4.jpg']; const images = []; let totalLoaded = 0; function loadImages(callback) { if (imageUrls.length === 0) { callback(); return; } imageUrls.forEach((url, i) => { const img = new Image(); img.crossOrigin = 'anonymous'; img.onload = () => { images[i] = img; totalLoaded++; if (totalLoaded === imageUrls.length) { callback(); } }; img.onerror = () => { totalLoaded++; if (totalLoaded === imageUrls.length) { callback(); } }; img.src = url; }); }这里有个细节：onerror也要把计数加一，否则某张图片加载失败时，计数永远到不了总数，启动逻辑永远不会执行，页面就会一直空白。这是一个非常隐蔽的坑，我在一开始写代码时没加onerror处理，测试时故意把一张图片路径写错，结果整个页面卡死。后来加上错误处理，并且把加载失败的图片用纯色背景替代，才算健壮。
基础绘制函数里除了上面提到的cover模式，还需要一个清屏函数。清屏时要注意不能用clearRect只清一部分，因为粒子层、图片层和视差偏移需要在每一帧重新绘制，必须先把整个画布清干净。
function resizeCanvas() { const dpr = window.devicePixelRatio || 1; canvas.width = window.innerWidth * dpr; canvas.height = window.innerHeight * dpr; canvas.style.width = window.innerWidth + 'px'; canvas.style.height = window.innerHeight + 'px'; ctx.setTransform(dpr, 0, 0, dpr, 0, 0); } function drawImageCover(img, x, y, w, h) { const imgRatio = img.width / img.height; const boxRatio = w / h; let sx = 0; let sy = 0; let sw = img.width; let sh = img.height; if (imgRatio > boxRatio) { sw = img.height * boxRatio; sx = (img.width - sw) / 2; } else { sh = img.width / boxRatio; sy = (img.height - sh) / 2; } ctx.drawImage(img, sx, sy, sw, sh, x, y, w, h); }3.3 动画主循环与切换动效：让图片动起来的核心
动效的核心是requestAnimationFrame驱动的主循环。requestAnimationFrame会在浏览器下一次重绘之前调用回调，每秒大约60次，相当于给动画提供了一个稳定的心跳。比起setInterval，它有几个明显优势：页面隐藏时会自动暂停，节省资源；回调频率与显示器刷新率同步，动画更流畅；而且它会把每帧的时间戳作为参数传入回调，方便计算帧间隔。
我还需要维护一个状态对象state，记录当前图片索引、下一张图片索引、切换进度、运动方向，以及鼠标位置。每次切换时，我把progress从0增长到1，在每一帧中根据progress计算当前图片和新图片的透明度、位移、旋转缩放值，最后用Canvas的坐标系变换绘制出来。
const state = { currentIndex: 0, nextIndex: 1, progress: 1, // 1表示切换完成 dir: 1, transitioning: false, mouseX: 0, mouseY: 0, lastTime: 0 }; function switchTo(dir) { if (state.transitioning) return; state.transitioning = true; state.dir = dir; state.nextIndex = (state.currentIndex + dir + images.length) % images.length; if (state.nextIndex < 0) { state.nextIndex = images.length - 1; } state.progress = 0; }switchTo函数里加了一个transitioning锁，防止用户在切换动画尚未完成时快速点击多张，导致currentIndex和nextIndex状态混乱。在实际体验中，这个锁让切换节奏非常稳定，哪怕我连续快速点击，也只是从上一张切换完成后才开始下一张。如果你希望支持快速连续切换，可以在此基础上引入队列，但在“简单效果展示”这个定位下，加锁已经足够。
绘制过程中，我计算了一个缓动后的进度eased。直接使用线性增长会让动画显得生硬，我习惯用1 - Math.pow(1 - progress, 3)做三次缓出，效果类似ease-out。在切换早期变化快，后期逐渐减速，观感非常自然。很多canvas游戏引擎里也内嵌了类似的缓动函数，是让动画有质感的关键小细节。
function easeOutCubic(t) { return 1 - Math.pow(1 - t, 3); } function update(time) { const dt = Math.min((time - state.lastTime) / 1000, 0.05); state.lastTime = time; if (state.transitioning) { state.progress += dt * 1.2; if (state.progress >= 1) { state.progress = 1; state.transitioning = false; state.currentIndex = state.nextIndex; } } }update里我特意把dt限制在0.05以内，对应每帧最多50毫秒。如果用户切换到后台再回来，浏览器可能会释放掉大量帧，导致第一次计算的间隔时间特别长，如果直接用原始间隔推动进度，相册会在页面恢复的瞬间跳变好几张图。限制最大帧间隔后，即使页面卡顿很久，动画最多也只推进一小段，不会出现“瞬移”的诡异效果。
绘制部分我单独写了一个draw()函数。它先清屏，然后绘制背景渐变，再根据当前是否处于切换状态决定绘制一层还是两层图片。在切换中，新图片会有一个从略大尺寸加轻微旋转回归到正常状态的过程，旧图片则朝反方向略微移动并淡出。
function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); const viewW = window.innerWidth; const viewH = window.innerHeight; // 粒子层 drawParticles(viewW, viewH); const imgW = viewW * 0.7; const imgH = viewH * 0.7; const imgX = (viewW - imgW) / 2; const imgY = (viewH - imgH) / 2; const baseOffset = imgX; if (!state.transitioning) { drawCurrentImage(imgX, imgY, imgW, imgH, 1); } else { const eased = easeOutCubic(state.progress); // 旧图淡出 drawCurrentImage(imgX, imgY, imgW, imgH, 1 - eased); // 新图进场：旋转、缩放、位移 const enterScale = 1.1 - 0.1 * eased; const enterRotate = (1 - eased) * 0.08; const enterOffset = (1 - eased) * state.dir * 40; ctx.save(); ctx.translate(imgX + imgW / 2 + enterOffset, imgY + imgH / 2); ctx.rotate(enterRotate); ctx.scale(enterScale, enterScale); drawImageCover(images[state.nextIndex], -imgW / 2, -imgH / 2, imgW, imgH); ctx.restore(); } }新图进场时我使用了ctx.save()/ctx.restore()包住旋转和缩放操作。先平移坐标系到图片中心，旋转和缩放都是以中心为基准，之后再调用drawImageCover时坐标变成了以中心为原点的相对坐标。如果不用这套变换，旋转会围绕画布左上角进行，图片会像钟摆一样甩出去，姿态非常不自然。这也是Canvas做旋转缩放动画时最基础、最重要的一个技巧：先平移，再旋转，再绘制。
3.4 交互与轮播：点击切换、鼠标视差、自动播放
交互部分分三块：点击切换、鼠标视差、自动轮播。点击切换按坐标判断左右区域，左边切上一张，右边切下一张。mouseover时我更新state.mouseX和state.mouseY，值的范围在-0.5到0.5之间，之后在绘制图片时把它乘一个很小的偏移量加到图片位置上，就形成了视差效果。
canvas.addEventListener('click', (e) => { const rect = canvas.getBoundingClientRect(); const px = e.clientX - rect.left; if (px < rect.width / 2) { switchTo(-1); } else { switchTo(1); } }); canvas.addEventListener('mousemove', (e) => { const rect = canvas.getBoundingClientRect(); state.mouseX = (e.clientX - rect.left) / rect.width - 0.5; state.mouseY = (e.clientY - rect.top) / rect.height - 0.5; });绘制时叠加视差偏移，我把图片中心坐标从原来的imgX + imgW / 2加上state.mouseX * 12，y轴同理。12这个数值是我实际测试后确定的，太小感觉不到效果，太大会让图片边缘露出大量空白，破坏沉浸感。需要注意的是背景粒子也可以做类似的偏移，但偏移量要比图片层更小，形成层次感，这也是很多canvas游戏场景里常见的多层视差手法。
自动轮播用setInterval定时执行switchTo(1)。我之所以用setInterval而不是在动画循环里累计时间，是因为切换过程本身受transitioning锁控制，定时器只需要负责“触发切换”这一个动作，不会和动画帧产生冲突。轮播间隔我设为4秒，这个时长对大多数照片展示场景来说刚好合适。
粒子生成的代码放在主循环里初始化一次。粒子数量不要设太多，我这个项目里是80个，每个粒子有随机的位置、半径、速度和透明度。每帧更新时让它们缓慢漂移，超出边界则从另一侧回来。绘制时用ctx.globalAlpha控制透明度，画一个小圆形或者小矩形，非常简单。
const particles = []; function initParticles() { const count = 80; for (let i = 0; i < count; i++) { particles.push({ x: Math.random() * window.innerWidth, y: Math.random() * window.innerHeight, vx: (Math.random() - 0.5) * 0.35, vy: (Math.random() - 0.5) * 0.35, r: Math.random() * 2.5 + 0.5, alpha: Math.random() * 0.5 + 0.2 }); } } function drawParticles(w, h) { particles.forEach(p => { p.x += p.vx + state.mouseX * 0.1; p.y += p.vy + state.mouseY * 0.1; if (p.x < 0) p.x = w; if (p.x > w) p.x = 0; if (p.y < 0) p.y = h; if (p.y > h) p.y = 0; ctx.globalAlpha = p.alpha; ctx.beginPath(); ctx.arc(p.x, p.y, p.r, 0, Math.PI * 2); ctx.fillStyle = '#fff'; ctx.fill(); }); ctx.globalAlpha = 1; }粒子绘制里有一个容易忽略的细节：每次绘制粒子前设置globalAlpha，但绘制完成后一定要重新设为1，否则后续图片绘制也会继承粒子的半透明状态，整个画面会变得透透的。这个坑我在调试粒子时踩过一次，排查了半天才发现是状态没有被重置。
最后把所有函数串起来。入口处先resizeCanvas()，再initParticles()，然后loadImages()，加载完毕后再启动主循环和轮播定时器。事件监听在页面初始化时绑定一次即可。
window.addEventListener('resize', resizeCanvas); window.addEventListener('load', () => { resizeCanvas(); initParticles(); loadImages(() => { requestAnimationFrame(loop); setInterval(() => switchTo(1), 4000); }); }); function loop(time) { update(time); draw(); requestAnimationFrame(loop); }4. 血的教训：常见问题、性能优化和后续玩法
4.1 高频问题速查表，按症状直接对照
这个项目做完后，我顺便把测试时遇到的高频问题整理成了表格。在做Canvas相关项目时，这几个问题的出现率非常高，值得每个入门Canvas的读者收藏：
| 症状 | 常见原因 | 解决办法 |
|---|---|---|
| 图片一直不显示 | 图片未加载完成就执行drawImage | 在img.onload后再绘制，或用计数器统一等待 |
| 图片加载时有跨域报错 | 图片来自其他域名且未设置crossOrigin | 给Image对象设置img.crossOrigin = 'anonymous' |
| 画布在高DPI屏上模糊 | canvas.width没有乘以devicePixelRatio | 按DPR放大物理像素，再用setTransform还原坐标系 |
| 图片切换时出现“跳变” | 动画切换被多次触发，状态互相覆盖 | 用transitioning标志锁住切换过程 |
| 粒子或图片颜色变得半透明 | 绘制结束后globalAlpha未重置 | 每段绘制结束把globalAlpha恢复为1 |
| 页面从后台切回时动画瞬移 | 未限制单帧最大间隔 | 用Math.min限制dt最大值 |
| 图片边缘锯齿严重 | 缩放比例不是整数 | 使用九参数裁剪精确绘制，或启用imageSmoothingQuality |
4.2 性能优化三板斧：离屏Canvas、对象池和避免重复计算
虽然这个简单相册在桌面浏览器上跑得很流畅，但如果你想追加更多效果，或者把相册嵌到移动端页面里，性能优化就必须提前考虑。我总结了三项性价比最高的优化手段。
第一项是离屏Canvas缓存。每次切换图片时，drawImageCover都在对原图做裁剪缩放，如果原图尺寸很大（比如单反照片4000x3000像素），这个操作每帧都会消耗大量CPU。优化思路是在图片加载完成后，先把它绘制到一张与展示尺寸等大的离屏Canvas上，之后主循环只需把离屏Canvas整体绘制到主画布，缩放计算只发生一次。我实际测试时，一个1200万像素的图片在普通笔记本上，优化前切图时会有明显掉帧，优化后帧率稳定在60。
第二项是对象池。粒子系统里如果频繁创建和销毁粒子对象，会引发垃圾回收抖动，导致画面卡顿。优化方法是在初始化时一次性创建好对象池，只复用不删除。我们这个例子里的粒子数量少，效果不明显，但如果把粒子数加到300以上，对象池的差异就会非常明显。
第三项是避免在每帧中重复计算不变的数值。比如页面尺寸相关的常量，在resize时缓存一份，动画循环里直接读缓存即可。ctx.fillStyle这种状态设置也比每帧反复创建字符串要高效得多。这些优化看起来零碎，但累积起来就是卡顿与流畅的分界线。
4.3 从简单相册到更多玩法：Canvas还能做什么
做完了这个动态相册，再回头看“canvas绘图”这个词，会发现它确实是一个覆盖面极广的领域。这次涉及的粒子系统、视差效果、状态机切换、缓动函数，都是很多canvas游戏、数据可视化、甚至专业绘图引擎里的基础构件。
如果想继续扩展这个相册项目，我有几个比较顺路的方向。第一个是拖拽翻页，用mousedown、mousemove、mouseup记录拖拽距离和速度，通过惯性让页面滑动，这比点击切换更接近移动端手势，也是很多canvas游戏里手势系统的雏形。第二个是滤镜效果，Canvas原生支持ctx.filter，可以给图片叠加对比度、饱和度、模糊等效果，切换时配合滤镜动画，会得到完全不同的视觉体验。第三个是加入更多粒子玩法，比如让粒子在图片周围聚拢成碎屑，或者点击某处时粒子向四周飞散。这些特效在canvas游戏里都是高频需求。再进一步，如果觉得原生Canvas提供的API太底层，可以直接研究PixiJS这类绘图引擎，引擎底层封装的依然是Canvas或WebGL，但你写业务逻辑时会轻松很多。
我个人在实际测试中的体会是，Canvas项目最容易出问题的地方不在API本身，而在状态管理。动画循环每秒执行60次，任何状态不一致都会被放大成明显的视觉bug。学会用状态对象集中管理数据、用save/restore隔离绘图变换、用明确的锁控制异步流程，比死记API更关键。这个动态相册看起来小，但把以上提到的每一点都融进去了，值得动手敲一遍。
