在 Scratch 里接到“画一个指定圆心和半径的圆”这种需求，往往不是基础练习题，而是真正要做项目的时候了，比如做一张表盘、模拟圆周运动轨迹、画同心圆装饰等。这时候你会很快发现，官方积木块里根本没有“画圆”这个动作，画笔只能记录角色移动的路径，而角色移动最直接的轨迹就是直线。所以绕不开的思路，就是标题里的多边形逼近法——把圆看作无数条首尾相接的短线。而要让这些短线准确落在指定的圆心和半径上，又必须吃透弧度概念：圆的周长是 2πr，把它均分给 n 条边，每一条边的长度、每一步转过的角度就全出来了。这篇文章把我从实际带项目过程中攒下来的经验完整梳理一遍，从数学原理讲到可直接复用的自制积木，再附上一份常见坑位清单，给正在做 Scratch 绘图类项目的朋友做个参考。

1. 为什么画圆必须走“多边形逼近”这条路

1.1 Scratch 画笔机制的两个关键约束

Scratch 舞台上的画笔扩展，本质上是一个“落笔后随着角色移动留下轨迹”的纪录仪。抬笔状态下随便跑，一点痕迹都不留；一旦落笔，角色每移动一步，就在舞台上画一条起点到终点的线段。这就带来两个硬约束：

第一，你没有办法让角色沿着一条真正的弧线连续移动。Scratch 只提供“移动多少步”和“面向多少度方向”以及“左右旋转多少度”，这些动作叠加出来的路径，永远是折线。换句话说，不是我们不想直接画圆，而是平台本身的画笔模型决定了：所有曲线都必须用线段去逼近。

第二，画笔轨迹只和角色移动路径有关，和角色的造型无关。你可以把角色隐藏起来，画笔依然正常工作。很多时候我在演示项目时会先把角色隐藏掉，只留画笔痕迹在舞台上，视觉效果干净很多。这一点对后面的演示作品尤其重要，因为画圆的过程中角色会在起点和终点之间反复转向，露出角色造型容易干扰观察。

理解了这两个约束，就能明白为什么“用多边形逼近法画圆”不是一种妥协，而是 Scratch 平台下唯一的通用方案。说它“通用”，是因为无论是旋转法、坐标法还是数学函数法，落到最终执行层，画出来的都是多边形，差别只在于这个多边形的边数够不够多、转折点算得准不准。

1.2 正多边形为什么可以逼近圆

把我的话换一种更“数学”的说法：圆是极限意义下的正多边形。正三角形、正四边形、正五边形……每增加一条边，形状就离圆近一点；当边数趋近无穷大时，这个图形就趋近于圆。实际做项目不需要无穷条边，只要多到肉眼分不清“转折”就行了。

在设计脚本之前，建议先建立一个直觉认知：假设我们要画一个半径 100 步的圆，用正六边形来逼近，每条边和相邻边之间的夹角是 120 度（内角），画出来一眼就能看出是六边形。改成正十二边形，好一些，但还是能看出棱角。到正三十六边形，在 Scratch 舞台上已经接近圆形了。到正一百二十边形，大部分人的肉眼很难看出它和真圆的区别。到三百六十边形，除了舞台刷新带来的细微抖动，视觉上就是正圆。

这个“多少边够用”的问题，直接对应着“精度”与“计算开销”的平衡。边数太少，逼近误差明显；边数太多，每一条边的长度变得极小，如果半径只有几十步，单边长度可能不到 1 步，角色的移动会出现明显的抖动感，而且绘制时间变长。从实操角度看，静态图形用 120 边左右最舒服，动态演示用 36 到 60 边也够。

这里有一张我整理的误差参照表，能很直观看出边数对逼近精度的影响：

这张表里的误差来源，我先卖个关子，下一节就会详细解释。你只要先记住一个结论：当 n 超过 36 之后，误差已经小到肉眼无法察觉；当 n 到 120，数据层面的精度完全可以满足绝大多数 Scratch 项目。

2. 弧度概念才是“指定半径画圆”的钥匙

2.1 从周长平均到弧度制：为什么一圈是 2π

很多教程讲画圆，直接甩给你一个脚木：移动 2×π×半径÷边数步，旋转 360÷边数度。但如果你只是照抄，遇到问题还是会卡住。我建议把背后的弧度概念搞明白，因为它能回答一个特别实际的问题：为什么半径越大，每段边的长度也要跟着变大？

回到定义。弧度是用“弧长”和“半径”的比值来衡量角的大小的。想象你站在一个圆的圆心，朝圆周方向走一段弧，这段弧的长度除以圆的半径，得到的数值就是这段弧对应的圆心角，单位是弧度。一个整圆，弧长等于周长 2πr，除以半径 r，结果就是 2π。所以“一整圈 = 2π 弧度 = 360 度”这个看似奇怪的等式，本质上只是用不同尺子在量同一个角。

这个关系直接给出画圆的核心公式。我要把一个半径为 r 的圆均匀切成 n 条边，每条边近似等于一小段弧，这一小段弧的长度就是整圆周长除以 n：

• 每段弧长 = 2πr ÷ n
• 每个小弧对应的圆心角 = 2π ÷ n（弧度）= 360 ÷ n（度）

这也就是我最常用的“弧长均分法”的来源。你会发现，半径 r 一旦确定，每段边长就和 r 成正比；圆心角则和半径无关，只取决于边数 n。所以“指定圆心和半径”这件事，本质上就是前面那条公式的两个输入参数。

顺便说一句，如果你想让圆弧概念在项目里继续发挥价值，可以把这个思路推广到画任意圆弧。想画一个只占整圆三分之一的小圆弧，就让角色移动的步数变成 2πr÷n×三分之一，转过的总角度也对应缩小。这也是为什么不少项目里，同一个自制积木既能画圆，又能画仪表盘刻度。

2.2 Scratch 里的“度”和数学里的“弧度”怎么换算

这里必须讲一个极其容易翻车的细节：Scratch 的旋转积木和三角运算积木，默认单位都是“度”，不是“弧度”。右转 90 度、面向 180 度方向，这些大家都熟。而数学公式里，sin、cos 这类函数在大多数文本编程语言里接收的是弧度。于是很多从别的语言转过来的同学，会把一段现成的 Python 画圆代码直接搬进 Scratch，结果画出来的多边形完全对不上。这个坑的根源，就是单位制。

Scratch 里 sin 和 cos 积木的输入框直接填“度”。想知道 sin(π/6)（也就是 30 度）的结果，你需要在积木里填 sin(30)，而不是 sin(π/6)。所以如果你在纸上推导出一个弧度制公式，比如后面要讲的正弦精确法里的 sin(π/n)，落地到 Scratch 时必须先把弧度换算成角度：

• 角度 = 弧度 × 180 ÷ π
• 弧度 = 角度 × π ÷ 180

一个 π 弧度等于 180 度，这一点不用死记。每次我写这类脚本，都会在变量区专门建一个常量“π”，填 3.14159265，然后在用到角度的积木里写上 180÷n 来代替 π÷n。因为 π÷n 弧度，恰好就等于 180÷n 度。这个转换关系非常隐蔽，但恰恰是标题里“弧度概念”在编程实操中最关键的一次落地。别小看这一步，很多学生程序“翻车”，就翻在这里。

2.3 两种边长公式，到底用哪个

说到具体的边长公式，网上流传着两种写法。一种是我前面提到的弧长均分法：边长 = 2πr÷n，简单直观。另一种是更精确的弦长公式：边长 = 2r×sin(π÷n)。两者差别在哪里？

弧长均分法的思路是“把一小段弧拉直了用”，实际画出来的弦会比弧短一点。这样的后果是：如果你严格沿着一个半径 r 的圆来画，最后多边形的顶点不会精确落在这个圆上，而是稍微偏内一点点。边数越少，这个偏差越大。

精确法的思路是“直接按弦长来算”。正 n 边形的边长和它外接圆半径的几何关系是：边长 = 2r×sin(π÷n)。这个公式在弧度制下写得很干净，但放进 Scratch 时要转换成边长 = 2r×sin(180÷n)，因为前面说过了，Scratch 的 sin 积木吃的是度数。

两张公式在实战中怎么取舍？我自己一般这么处理：

如果 n 已经到 120，两种方法画出来的图形肉眼完全一样，选哪个都行。但如果你要画一个正十二边形来模拟圆，或者做边数滑杆从 3 慢慢往上推的演示，弧长均分法在边数少时会出现明显的外扩偏离。正弦精确法在边数为 3、4、6 时依然保证每个顶点都精确落在半径 r 的圆上，只是这些顶点连起来还不像圆而已。

我推荐的实操组合是：教学场景先用弧长均分法建立直觉，再做一次正弦精确法的对比实验，让学生亲眼看到差别。这样比直接背公式有效得多。

3. 完整实操：用自制积木实现指定圆心和半径的画圆工具

3.1 参数设计：为什么需要四个参数

“指定圆心和半径”这句需求翻译成程序语言，其实就是四个变量：圆心的横坐标 cx、纵坐标 cy、半径 r、边数 n。cx 和 cy 负责定位，r 负责定大小，n 负责定精度。你可能会问：为什么圆心坐标要两个变量，不能直接让角色走到某个地方画吗？因为在真正的项目里，你可能需要用同一个画圆积木在不同位置画出多个圆。比如画一个表盘，几个同心圆、一圈刻度，每个圆都有自己的圆心和半径。把 cx、cy、r 都做成参数，这个画圆工具才能被反复调用而不需要改内部代码。

Scratch 里实现参数最优雅的办法就是自制积木。在“自制积木”面板点“制作积木”，名称填“画圆”，然后加四个数字参数：cx、cy、r、n。这样每次调用它，只需要告诉它圆心在哪、半径多大、边数多少，它就能独立完成任务，不污染主程序的全局变量。这个习惯非常建议养成——哪怕是画一个圆，也把它封装成一个独立模块，后面调试起来会轻松很多。

下面把完整的自制积木脚本用伪代码形式展示给你：

定义 画圆(cx, cy, r, n) 全部擦除 抬笔 移到 x: (cx + r) y: (cy) 面向 90° 方向 落笔 重复 (n) 次: 移动 (2 × 3.14159265 × r ÷ n) 步 右转 (360 ÷ n) 度 抬笔

看着很短，但每一行都有讲究。

第一步“全部擦除”可加可不加，如果你希望这个积木每次调用都重新绘制，就放在开头。它会把舞台上之前所有画笔痕迹清掉，省的因为残留线条误判图形。

第二步“抬笔”必须有。很多人画出来的圆总是多一条莫名其妙的直线，多半就是因为上一条流程结束时笔还压在舞台上。干脆在每个画圆过程的开始都显式抬笔，把画笔状态拉回安全位置。

第三步“移到 x: (cx + r) y: (cy)”，这是把角色放到圆上最右侧的顶点。注意这里不是把角色移到圆心，而是圆心右侧距离 r 的那个点。如果直接移到圆心再画，第一笔就会从圆心画到圆上，留下一条半径线，那是典型错误。用计算积木组合出“cx + r”这一步，等价于在 Scratch 的“移到 x: y:”积木里嵌入一个“加法”积木，脚本会自动计算。

第四步“面向 90° 方向”。Scratch 里 90 度方向是正右方。角色面向正右，落笔后往前走，第一条边就是水平的弦。配合“右转 360÷n 度”，整个多边形会顺时针方向一笔一笔围出来。

第五步“落笔”，从此开始记录轨迹。

第六步循环里“移动 (2×π×r÷n) 步”，这是弧长均分法的边长。注意我在这里把 π 写成了 3.14159265，不要偷懒只写 3.14。舞台坐标的数值运算精度有限，用 3.14 在边数多时累积误差会变大，圆的终点和起点可能会对不齐。

第七步“右转 360÷n 度”，这是正多边形的外角。每次画完一条边就转向一次，循环重复 n 次后，角色一共转了 360 度，正好回到起始方向，图形闭合。

3.2 起点的选定和转向方向的细节

起点选在最右侧而不是正上方，这个选择是有讲究的。因为 Scratch 里“面向 90° 方向”是正右，角色从右侧开始，第一笔水平向右，画完一条边后右转 n 分之一圈，继续画第二条。整个过程非常自然，不需要额外处理角色的初始旋转角。如果你想让图形从正上方开始，只需要把起点坐标改成 (cx, cy + r)，面向 0° 方向，第一笔向上画，其他逻辑完全一样。

还有一个细节：整体画完以后，角色会回到起点位置，方向也归位到 90°，但不是必须的。因为每一次调用画圆积木的开头都会重新设置起点和朝向，所以留在原地不会影响下一次调用。真正需要注意的反而是循环结束后的“抬笔”。如果循环结束后没有抬笔，下一次调用画圆积木时，第一步抬笔之前角色还压着笔，从当前位置移到新起点的过程会莫名其妙多画一条线。因此，把抬笔放在循环结束之后，是一次防御性编程，强烈建议保留。

3.3 核心加速技巧：运行时不刷新屏幕

很多人第一次用这个脚本画 360 边的圆，会看到角色在舞台上慢慢转圈，画了大半天才完成。原因是 Scratch 默认每一帧都会刷新舞台显示，角色每移动一步、旋转一次，舞台都要重新渲染。画一个 120 边的圆，就意味着舞台要刷新 120 次，自然很慢。

解决方法藏在自制积木的细节里：在自制积木编辑区右上角，右键点击你已经建好的“画圆”积木定义块，菜单里有一项“运行时不刷新屏幕”，勾选它。这样在执行这个自制积木期间，Scratch 会暂停舞台刷新，所有移动和旋转动作都在后台算完，直到积木运行结束才把最终结果一次性显示出来。效果非常夸张：120 边的圆原本要转半天，勾选后几乎瞬间画完。

这个技巧是 Scratch 绘图类项目里性价比最高的优化。不过要注意，勾选后用户看不到绘制过程动画。如果你是做教学演示，想让学生观察多边形是怎么一步步逼近圆的，就不要勾选，反而应该把角色显示出来、放慢边数，让动画慢慢转；如果你只是要最终结果，加快处理速度，那就果断勾选。

3.4 让画圆工具支持“任意圆弧”

既然已经走进弧度概念了，再往前迈一步就会特别自然：如果我只想画一段圆弧，而不是完整圆，怎么改？

回看核心公式。整圆对应的圆心角是 360 度，分成 n 段。如果我只想画一个圆心角为 α 的圆弧，可以把总角度设成 α，同时把总弧长从 2πr 改成 2πr×（α÷360）。更优雅的做法是给自制积木再加一个参数“总角度”，例如画一个半圆就传 180。循环次数可以按总角度除以每步转角来算，比如每步转 3 度，画 60 次就是 180 度圆弧。这个能力在画仪表盘、花瓣图案、雷达扫描效果时特别有用，是“画圆”这个基础能力的直接延展。

4. 现场改造：做一个可调节精度和参数的多边形画圆演示器

4.1 边数滑杆：动态观察多边形逼近圆

理论说一百遍，不如亲手拖一次滑杆。在 Scratch 里新建一个变量 n，右键变量把它显示为滑杆，然后设置最小值为 3、最大值为 360。主程序写一个简单的循环：拖动滑杆，调用一次画圆积木，画完后等待一小段时间。这样你就能实时看到同一个半径下，正三角形、正六边形、正十二边形……逐渐“演化”成圆的过程。

我做这个演示时，最喜欢让学生从 n=3 开始慢慢拖。三边形时很明显是三根直线围成的三角形；拖到 6，是个六边形，但已经开始有点“圆滑”的雏形；到 12，棱角比较柔和但依然可见；到 30，形状已经接近圆；再到 120，几乎没有人能看出转折点。这个过程本身就是对“多边形逼近法”这个标题最好的诠释，比任何语言都直接。

脚本实现起来非常简单：

当绿旗被点击: 重复执行: 全部擦除 画圆(cx, cy, r, n) 等待 0.2 秒

这里的 cx、cy、r 可以先用固定值。注意在重复执行里调用画圆积木时，别忘了勾选不刷新屏幕，否则每一帧都要重画一遍几百条边，拖滑杆会非常卡。如果勾选了不刷新屏幕，重绘几乎是瞬时的，滑杆体验非常流畅。

4.2 圆心和半径滑杆：让“指定圆心和半径”变成可视参数

如果你想完全对应标题里的“指定圆心和半径”，不妨再新建三个滑杆变量：cx（范围 -240 到 240）、cy（范围 -180 到 180）、r（范围 10 到 200），分别控制圆心的横坐标、纵坐标和半径。Scratch 舞台的坐标系里，x 范围约 -240 到 240，y 范围约 -180 到 180，这些范围可以灵活调整。只要 cx、cy、r 都能用滑杆控制，“指定圆心和半径画圆”这件事就从一句口号变成了真正可交互的工具。

我实际测试下来，当 r 设成 200 且 cx 也偏到边缘时，圆很容易超出舞台边界，超出的部分会被截断，看起来像缺了口。这是正常现象，但如果你要做演示，最好加一个简单的边界提示。比如判断如果 cx+r 大于 240 或 cx-r 小于 -240，就让角色说一句“圆超出舞台范围”，或者弹一个提示。在高阶一点的项目里，还可以自动把 r 缩减到安全值。这个边界检查虽然只有几行判断积木，但能避免学生在拖滑杆时突然看到半个圆而误以为程序出错了。

4.3 画多个圆验证“同一个圆心”

验证“指定圆心和半径”是否真正生效，最简单的方式是画一组同心圆。固定 cx 和 cy，先用 r=60 画一个红色的圆，再用 r=120 画一个蓝色圆，再用 r=180 画一个绿色圆。如果三个圆的圆心坐标都正确，它们会完美共享一个中心，间距均匀。如果圆心算错了，你会发现三个圆的相对位置偏移，一眼就能看出来。

画不同颜色的圆很简单，在调用画圆积木之前设置画笔颜色和粗细即可。比如：

将画笔的颜色设为 (0) (0) (255) 将笔的粗细设为 (3) 画圆(cx, cy, 60, 120)

注意 Scratch 里“将画笔的颜色设为”通常需要你输入 RGB 三个通道值，或者直接选色板。建议在画每组圆之前先设置一次颜色，画完后再把颜色改回来，避免不同图形之间互相覆盖看不清。这个多圆验证技巧，是我在课堂项目里检查学生圆心坐标是否理解正确的标准方法。

4.4 从小工具到项目：怎样扩展成可应用的作品

不要小看这个画圆演示器，它稍微改一改就能变成实际可用的作品。比如把画笔颜色设置成不同分段，配合圆心角参数，可以做圆形仪表盘；用多个不同半径的圆叠加，可以做雷达扫描的底座；甚至在每个顶点处落一笔，就能生成正多边形星形。我在一次项目中，就用这个自制积木给同学做了一张渐变圆环的桌面壁纸生成器，原理不过是循环调用画圆积木，每次半径增减、颜色变化。当你把画圆这件基础能力封装成可靠的工具积木后，后续所有创意都变得非常顺畅。

5. 常见问题与排查技巧实录

5.1 画出来的图形不闭合，或首尾接不上

这是一个出现频率极高的问题。先说结论：最常见的原因是循环次数和边长公式的乘积不等于圆周长。

如果你用弧长均分法，循环次数 n 和单边长度 2πr÷n 相乘，总长刚好等于圆周长，理论上是闭合的。但如果循环次数写成 360（很多新手容易觉得“转 360 度就是一遍，所以循环 360 次”），边长却用的是 2πr÷n，这就会要么走多了、要么走少了，最终图形不闭合。

还有一种情况是单边长度过小。当半径 r 只有 50 步、边数 n 拉到 360 时，单边长度约 0.87 步。Scratch 角色移动底层虽然支持小数坐标，但在小步长下移动精度和渲染表现都会下降，常见症状就是边与边之间有细小的缝隙，看起来像没闭合。解决办法是降低边数到 120 左右，或者增大半径。如果必须用 360 边且半径很小，可以考虑把整张图放大后再缩小，但那就比较绕了。

5.2 为什么圆的位置总是不对，多了一条半径线

这个问题几乎一定出在起笔前没有抬笔，或者起点坐标写成了圆心坐标。

我之前见过一个学生，他写“移到 x:(cx) y:(cy)”，然后在“面向 90°”之后直接落笔画圆。结果笔画从圆心向右画了一条半径到圆上，然后再开始围圈，最后的成品是一个圆加一条直线。这种错误特别迷惑，因为圆本身看起来没问题，只是多了一条“尾巴”。排查方法也很简单：检查落笔前最后一次移动的目标点，必须是 (cx+r, cy)，而不应该是 (cx, cy)；同时确认从上一个状态到起点之间，笔一直处于抬起状态。

更稳的做法是在画圆积木开头先把笔抬起来、移动到起点、面向正确方向，然后一个落笔，把这个顺序固化下来。这样即使前一个程序状态很混乱，画圆积木也能强制恢复到一个干净的初始状态。

5.3 圆的大小比指定半径偏大，或者偏小

如果你用的是弧长均分法，边数又较少，你会看到实际图形比预期半径稍微大一点。原因就是前面讲过的那张误差表：边长是弧长拉直的结果，弦比弧短，所以为了凑满同样的中心角，多边形的外接圆半径会略微变大。n=6 时偏大 4.7%，n=12 时偏大 1.15%，肉眼能看出来，但不会太明显；n=30 以下建议用正弦精确法来保证半径准确。

如果你用的是正弦精确法，但实际画出来的半径仍然不对，最常见的坑是 sin 积木的角度单位没换算。请注意，Scratch 的 sin 积木吃的是“度”，所以公式里的 sin(π÷n) 要写成 sin(180÷n)。我见过有人直接填 sin(π÷n)，Scratch 会把它当 sin(180÷n) 吗？不会，它只是把 π÷n 这个数值当成角度去算，结果完全错乱，画出来的多边形边长会严重偏小，所有顶点缩成一团。这个问题一旦出现，先检查角度单位，十有八九就解决了。

5.4 绘制速度慢得让人着急

绘制慢，前面说过的“运行时不刷新屏幕”是首选解法。如果已经勾选还是不理想，第二优先是减少边数。静态圆形 120 边完全够，动态演示 60 边已经接近视觉效果上限。第三，检查你是否在循环内部插入了多余的动作，比如每次循环都改变颜色、改变粗细、播放音效，这些都会拖慢整体速度，尤其是刷新屏幕被关闭后，所有计算都要等积木结束才渲染，中间步骤白白占据 CPU。真正高效的做法是：画图期间只做移动和旋转，其他操作全部放到画图循环之外。

一个附加技巧：图形画完后立刻把角色隐藏，可以减少舞台重绘负担，尤其在多圆嵌套、需要频繁重绘的画布项目中效果明显。

5.5 画笔颜色和粗细偶尔失灵，残影怎么处理

画笔扩展偶尔会出现颜色设置不生效的情况，原因是你要么在抬笔状态下设置颜色，要么上一个图形的颜色还没“用完”就被新图形覆盖了一部分。我的习惯是每次画新图形之前，先设置颜色，再设置粗细，然后抬笔到位、落笔绘制。顺序固定，可以避免很多莫名其妙的画笔状态混乱。

残影问题大概率不是画笔出了 bug，而是上一轮图形没有“全部擦除”。如果项目里希望并存多个图形，就不该在每次画圆时调用“全部擦除”。可以把“全部擦除”单独放到主程序的某个初始化按键里，比如按空格键才清屏，而画圆积木内部不负责清屏。这样画多个圆的时候不会互相擦除，需要重画时也就一键清空。

5.6 一个容易忽略的方向细节：左转和右转的选择

正常情况下，不管是左转还是右转，只要每步都按同一个方向转，画出来的多边形都是一样的，只是绘制方向相反。但如果你想跟其他角色的路径配合，比如让一个小球沿着圆轨迹移动，那么转向方向就必须和移动方向一致。在 Scratch 里，“右转”是顺时针方向，在小舞台坐标系里是从屏幕上方开始向右转。如果你希望角色逆时针沿圆运动，就用“左转 360÷n 度”。

有一次我在做圆周运动演示时，圆画好了，小球移动方向却和预期相反，原因就是调用了同一个画圆积木，而画圆积木里用的是右转，小球脚本里却用了左转。把旋转方向统一，问题立刻解决。这个细节虽然不致命，但在项目整合阶段会花掉不少排查时间，提前统一约定会省事很多。

最后再说几句实操体会

这套“多边形逼近法 + 弧度概念”的组合，我已经在好几个项目里反复使用。最开始我也跳过原理，直接用一个固定脚木画圆，结果一旦要换圆心、换半径、换边数，就不得不重新翻开脚本去调一堆变量。后来把画圆封装成带参数的自制积木，又把弧度和角度换算关系理清之后，整个效率提升了一个量级。

如果你只是偶尔画一次圆，用文章里的弧长均分法脚本就够了。但如果你想真正搞懂这个圆是怎么来的，我强烈建议你亲手拖一遍边数滑杆，把 n 从 3 慢慢拖到 360，同时把半径设成一个大一些的整数，比如 120。看着六边形长成十二边形、二十四边形，最后变成流畅的圆，那种“原来圆是这样逼近出来”的感觉，比背一百遍公式都管用。再往后，任何需要画圆弧、画仪表盘、画圆环的项目，你都会比别人多一层底气：圆的每一段边到底从哪里来，心里有数，代码自然就写不歪。