这几天在编程学习群里，看到有人打卡到“Day3 矩形移动”这个练习。在这个阶段，多数人会觉得这就是“画一个方块，然后用方向键控制它”——听起来像是最简单的一课。但真正动手写之后，问题会连续出现：为什么方向键按下去没有反应？为什么松开键之后矩形还在跑？为什么画面会闪烁？为什么到了屏幕边缘矩形会被推出画布？解决这些问题的过程，恰好会触碰到游戏开发、动画编程、交互应用里最重要的一套思维框架——无限循环里的“读输入、改状态、画画面”。这篇文章就把矩形移动这件事拆开讲透，从最小实现、键盘状态管理、坐标系与时间步长，一直聊到这个练习之后该怎么往下走。
1. 为什么一个“会动的矩形”是编程里最重要的一课
1.1 矩形移动背后藏着哪三个核心机制
表面上看，“矩形移动”只是一个图形学入门作业。实际上它一次性把三个核心机制压进了一段非常小的代码里。
第一，循环机制。程序不是“执行一次就结束”，而是要持续运行、持续刷新。无论是用requestAnimationFrame还是while循环，本质都一样：每一帧做三件事——处理输入、更新状态、重新绘制。
第二，输入机制。要让矩形响应键盘，不能只在按下那一瞬间改坐标，因为那样只会移动一次。你需要记录“哪些键正处于按下状态”，再在每一帧里去检查这个状态表。
第三，状态机制。矩形的位置不是一个常量，而是一个会随时间变化的状态。x和y在每一帧都可能被更新，而绘图函数必须基于最新状态去输出画面。这个“状态与绘制分离”的思路，是所有图形界面和游戏程序的地基。
这三个机制都不复杂，但很多人是第一次在一个程序里同时遇到它们。所以矩形移动不是“太简单”，而是“刚好简单到能看清框架，又刚好复杂到能暴露思维盲区”。
1.2 先想清楚：你想学的是绘图 API，还是交互逻辑
不同技术栈做矩形移动，侧重点差别很大。如果用 HTML5 Canvas，重点会落在 JavaScript 的事件处理、坐标更新和requestAnimationFrame上；如果用 Python 的 pygame，重点会落在游戏循环和pygame.Rect的封装上；如果只是用 CSS 的transform或transition，那其实没有真正练习到“状态更新”，只是让浏览器帮你完成动画。
这里有一个在学习上容易被忽略的判断：矩形移动这个练习的真正价值，不在“用什么框架画出矩形”，而在“你是否亲手实现了主循环里的状态更新”。如果只是通过 CSS 动画把方块从左移到右，那学到的是样式，不是交互逻辑。反过来，哪怕你用最简单的命令行字符画，只要自己维护坐标、处理按键、循环刷新，就完成了同样的训练。
所以，在开始写代码之前，先决定你的目标，是“会用某个绘图库”，还是“理解交互程序的结构”。前者可以直接照着 API 文档写；后者建议选择 Canvas、pygame 这类需要自己管理主循环的方案，因为它们能在最小代码量里暴露最多细节。
2. 让矩形动起来的最小实现：先跑通再理解
2.1 用 HTML5 Canvas 写一个能移动的矩形
这里以 HTML5 Canvas 为例，因为它不需要安装任何依赖，浏览器直接打开就能跑。先把最小可运行版本写出来，再去逐行拆解。
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>矩形移动</title> <style> canvas { border: 1px solid #ccc; } </style> </head> <body> <canvas id="game" width="480" height="320"></canvas> <script> const canvas = document.getElementById('game'); const ctx = canvas.getContext('2d'); let rect = { x: 100, y: 100, w: 40, h: 40, speed: 3 }; const keys = {}; document.addEventListener('keydown', (e) => { keys[e.code] = true; }); document.addEventListener('keyup', (e) => { keys[e.code] = false; }); function update() { if (keys['ArrowLeft']) rect.x -= rect.speed; if (keys['ArrowRight']) rect.x += rect.speed; if (keys['ArrowUp']) rect.y -= rect.speed; if (keys['ArrowDown']) rect.y += rect.speed; } function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.fillStyle = '#2d7dd2'; ctx.fillRect(rect.x, rect.y, rect.w, rect.h); } function loop() { update(); draw(); requestAnimationFrame(loop); } loop(); </script> </body> </html>这个文件保存为rect.html，直接用浏览器打开，点击画布区域后用方向键就能控制矩形移动。
2.2 逐行拆解：坐标、速度、绘制是怎么配合的
先看数据部分。矩形被定义成一个对象：
let rect = { x: 100, y: 100, w: 40, h: 40, speed: 3 };这里的x和y不是矩形中心的坐标，而是它的左上角坐标。w和h是宽高，speed是每帧移动的像素数。这个细节很重要：很多人第一次调试时，发现矩形的位置和预期差了一个矩形自身的宽度或高度，就是因为没有分清“左上角坐标”和“中心坐标”的区别。
再看输入部分。keydown和keyup做的事情，不是直接修改矩形坐标，而是维护一个按键状态表：
const keys = {}; document.addEventListener('keydown', (e) => { keys[e.code] = true; }); document.addEventListener('keyup', (e) => { keys[e.code] = false; });为什么要多这一步？因为键盘事件是“一次性”的。按下方向键时，keydown只触发一次；如果你在事件里直接写rect.x -= rect.speed，按一下只移动一次，松开再按下又移动一次，矩形会一顿一顿地走，而不是持续移动。按键状态表把“瞬间事件”转换为“持续状态”，才能在每一帧的update里判断“当前这个键是否一直被按着”。
最后看循环部分。loop通过requestAnimationFrame不断调用自己，每一次调用就是一帧。update根据按键状态更新坐标，draw先清空画布再绘制矩形。清空这一步不能省，否则上一帧的矩形会残留在画布上，形成拖影。
注意：
requestAnimationFrame的触发频率通常与屏幕刷新率一致，大多数显示器是 60Hz。这里先不用纠结帧率细节，后面会专门讲时间步长问题。
3. 从“能动”到“能控制”：键盘输入与状态管理
3.1 为什么 keydown 和 keyup 不能直接操作坐标
上面提过，直接在键盘事件里修改坐标会让矩形“按一下动一下”。这里再深入一点：如果真的这么写：
document.addEventListener('keydown', (e) => { if (e.code === 'ArrowRight') rect.x += 3; });会发生什么？按下右方向键，矩形往右移动 3 像素，然后事件结束。你需要反复按下、松开、再按下，矩形才会一步一步移动。这种体验更像“打字”，而不是“移动”。
更隐蔽的问题是键盘重复触发。在大多数操作系统里，长按一个键会触发多次keydown，但第一次触发和后续重复触发之间的间隔并不稳定，而且如果你同时按两个方向键，两者的触发频率还会互相干扰，让矩形移动速度忽快忽慢。按键状态表直接绕开这个问题：事件只负责记录“按下/松开”这个事实，至于要不要移动、移动多少，完全交给update在每一帧里统一计算。
3.2 按键状态表是第一个“程序状态”
keys对象就是最简单的状态管理。它虽然只是一个普通对象，却体现了交互程序里非常核心的模式：
- 事件发生时，不立刻产生业务行为。
- 事件只负责更新状态。
- 每帧从状态推导出要执行的逻辑。
这个模式在更复杂的项目里，会演变成各种状态机、行为树、实体组件系统等架构。矩形移动当然不需要那么复杂，但你已经可以用同样的思维去解释：为什么游戏中会有“主循环”这个概念——因为所有行为都由状态在每一帧驱动，而不是由分散的事件函数驱动。
在这个阶段，还有两个细节值得注意。
第一，要阻止浏览器默认行为。方向键在页面里默认会滚动页面，如果你的画布嵌在一个可以滚动的页面里，按方向键页面会发生滚动，矩形反而不动。常见的处理是在keydown里加e.preventDefault()：
document.addEventListener('keydown', (e) => { if (['ArrowUp', 'ArrowDown', 'ArrowLeft', 'ArrowRight'].includes(e.code)) { e.preventDefault(); } keys[e.code] = true; });第二，要注意页面焦点。键盘事件只在页面获得焦点时才能触发。如果点击了浏览器地址栏或开发者工具，再按方向键，页面收不到事件。这个现象在调试时经常被误判为“代码写错了”。
4. 真正决定成败的细节：坐标系、帧率与边界检查
4.1 坐标系和矩形的边界判断
Canvas 的坐标系原点在左上角，x向右增大，y向下增大。这个“y 轴向下”的方向和数学课上的坐标系正好相反，是新手最容易绕晕的地方。按上方向键，坐标应该减小而不是增大：
if (keys['ArrowUp']) rect.y -= rect.speed;如果写反了，按上方向键矩形会往下走。这不是“bug”，而是坐标系定义问题。
边界判断也是一个容易出问题的点。默认情况下，矩形可以移出画布，移出后你只能通过修改坐标把它拉回来。更好的做法是在update里直接限制坐标范围：
function update() { if (keys['ArrowLeft']) rect.x -= rect.speed; if (keys['ArrowRight']) rect.x += rect.speed; if (keys['ArrowUp']) rect.y -= rect.speed; if (keys['ArrowDown']) rect.y += rect.speed; rect.x = Math.max(0, Math.min(canvas.width - rect.w, rect.x)); rect.y = Math.max(0, Math.min(canvas.height - rect.h, rect.y)); }这里的关键点是canvas.width - rect.w而不是canvas.width。因为x是左上角坐标，矩形最右边其实是x + w。如果允许x等于canvas.width，整个矩形就会完全移出画布。这是矩形移动练习里最常见的边界错误之一。
4.2 帧率不稳定导致速度不一致：从帧率独立到时间步长
之前的写法是“每帧移动固定像素”。在 60Hz 屏幕上，这个速度是speed * 60像素/秒。但如果显示器是 120Hz，或者浏览器因为某个耗时任务导致掉帧，同样的代码在不同设备上速度差别会很大。更准确的做法是用“时间步长”：
let speed = 200; // 单位改成 像素/秒 let lastTime = 0; function loop(timestamp) { const dt = Math.min((timestamp - lastTime) / 1000, 0.1); // 换算成秒，并设置上限 lastTime = timestamp; if (keys['ArrowRight']) rect.x += speed * dt; if (keys['ArrowLeft']) rect.x -= speed * dt; if (keys['ArrowDown']) rect.y += speed * dt; if (keys['ArrowUp']) rect.y -= speed * dt; rect.x = Math.max(0, Math.min(canvas.width - rect.w, rect.x)); rect.y = Math.max(0, Math.min(canvas.height - rect.h, rect.y)); draw(); requestAnimationFrame(loop); }dt是上一帧到这一帧的时间差，单位是秒。speed * dt表示在这一帧内，矩形应该移动“每秒 200 像素”乘以“流逝的时间”。帧率高时dt小，每次移动量小；帧率低时dt大，每次移动量大。综合下来，一秒钟的移动距离基本恒定。
这里有一个进阶注意点：dt不能无限制地大。如果页面在后台挂起了一会儿，回到前台时dt可能非常大，矩形会“瞬移”一大段距离。常见做法就是上面的Math.min(dt, 0.1)，把单帧时间差限制在 100 毫秒以内。这样即使从后台恢复，也不会出现跨屏瞬移。
4.3 排查链路：矩形不动、乱跳、卡住怎么办
如果按方向键矩形不移动，不要急着改代码，按这个顺序排查。
第一步，确认画布获得了焦点。先点击画布区域，再按方向键。如果之前在开发者工具里点击过，页面可能没有焦点。
第二步，确认keydown事件有没有触发。在事件回调里加一个console.log(e.code)，看控制台是否输出了ArrowRight。如果没输出，问题在事件绑定或页面焦点；如果输出了，问题在状态更新逻辑。
第三步，确认requestAnimationFrame循环是否每帧都在执行。可以在update里加一行console.log('tick')。如果只在第一次运行，说明循环中断了，检查控制台是否有报错。
第四步，确认矩形坐标有没有变化。在draw里打印rect.x和rect.y。如果坐标在变但画面不动，问题出在绘图逻辑；如果坐标不变，问题出在按键状态更新。
第五步，确认ctx.clearRect是否执行。不清理画布时，矩形每帧都在重画，看起来像在原地抖动或产生拖影。
按这个顺序排查，大部分问题在几分钟内就能定位，不至于在同一个地方反复折腾。
5. 矩形移动之后，下一步该往哪里走
5.1 从单矩形到多对象：数据结构是分水岭
在矩形移动这个练习里，你只有一个rect对象。当你开始做两个、三个甚至几十个移动对象时，继续用单独的变量就不现实了，你很快会引入数组：
const rects = []; for (let i = 0; i < 10; i++) { rects.push({ x: i * 50, y: i * 30, w: 40, h: 40, speed: 2 + i }); }然后在update里遍历数组更新，在draw里遍历数组绘制。这个转变看起来只是“把变量放进数组”，实际上是把“单一对象逻辑”扩展成“批量对象管理”。再往后，你可能需要给每个对象增加类型、生命值、运动方向、动画帧等字段，对象字段越加越多，代码就会自然推动你去设计更清晰的结构。
我更愿意把矩形移动看作一个“主动扩展”的训练。进步快的人，往往不是因为记得 API，而是因为他们主动把一个对象扩展成多个对象，又主动把多个对象的管理逻辑重构成更清晰的函数或类。这才是这个练习真正的进阶路线。
5.2 碰撞检测、场景管理和状态机
矩形移动之后，紧接着的经典练习就是碰撞检测。两个矩形相遇时应该停下来、弹开还是消失？碰撞检测会逼着你重新审视坐标更新顺序：先移动再检测，还是先检测再移动？如果矩形贴到画布边缘，是否允许它和墙体重叠？
再往后是场景管理。一个稍完整的程序里通常不只有一个“无限循环”，还有开始界面、运行界面、暂停界面、结束界面。你可能会写一个scene变量，用字符串或枚举表示当前场景，在不同场景里执行不同的更新和绘制逻辑。这就是状态机的雏形。虽然听起来比矩形移动复杂得多，但底层仍然是你已经练熟的那套“每帧更新状态并绘制”的框架。
5.3 学习路径建议与适用边界
针对“Day3 矩形移动”这个阶段，我的建议是：
第一，先用单一技术栈跑通。不管是 Canvas、pygame 还是其他图形库，先完整实现“按键控制矩形移动”这个闭环，不要同时学两个框架。
第二，跑通之后，马上加一个边界限制。只移动不限制边界，说明还没有真正考虑坐标系和画面尺寸之间的关系。
第三，主动给矩形加一个“速度变化”场景。比如按住 Shift 键加速，或者按空格键瞬间改变位置。这样你会更深刻地理解速度、时间、坐标三者之间的关系。
第四，如果觉得速度在不同设备上表现不一致，主动改为基于时间步长的移动。这一步能提前规避很多后续动画和游戏开发中的性能陷阱。
也说说边界。矩形移动这个练习不适合用来深入学习图形渲染细节，比如 GPU 管线、着色器、抗锯齿，这些已经超出它的范围。它也不适合过度工程化——有人会在这个阶段引入完整的游戏引擎或者复杂的架构模式，反而冲淡了主线训练。它的最佳应用范围，就是让学习者用最小代码量理解“事件、状态、循环、绘制”这条主链路。看清这条主链路之后，后面无论是写一个小游戏、做一个数据可视化，还是转向更复杂的图形应用，地基都已经在这里打好了。
