企业官网建设流程全解析

在线CAD这几年已经不是什么新鲜词，大量图纸工具都在往web端迁移。但你要是真把一个“绘圆弧”功能从AutoCAD搬到浏览器里，就会发现它比画直线、矩形麻烦得多。直线只要两个点，圆弧却要同时处理圆心、半径、起始角、终止角，还得照顾用户是用三点、圆心加角度、还是端点加半径的方式去输入。这篇文章想聊的，就是我在web端实现类似AutoCAD绘圆弧功能时的完整思路：从几何算法、命令交互，到Canvas渲染和数据导出，全部摊开讲。适合正在做在线CAD、web绘图工具，或者想在项目里加一个“有专业手感画弧工具”的开发者参考。

1. 项目概述：把AutoCAD的“绘圆弧”搬进浏览器，到底难在哪

1.1 为什么圆弧比直线复杂一个量级

很多初学者第一次接到“在线CAD画圆弧”的需求时，觉得无非就是ctx.arc()画一段曲线，没什么大不了。真上手才发现，问题根本不在渲染，而在于“用户到底想表达什么”。

在AutoCAD里，ARC命令本身就有十几种输入方式：三点定弧、起点-圆心-终点、起点-圆心-角度、起点-端点-半径、连续圆弧等等。每种方式背后都是一套独立的几何换算逻辑。更麻烦的是，用户在画第一笔时，系统并不知道他打算用哪种方式，只能根据当前输入状态动态判断。

这就引出了在线CAD开发中最核心的挑战：交互状态机的设计。画一条LINE是“两点定一线”，状态简单清晰；画一个ARC则要在多个候选输入之间切换，每一个候选都可能因为用户点的位置不同而产生合法或非法的结果。比如三点画弧，如果三点近似共线，就无法求出有效圆心；起点-端点-半径模式下，半径小于两端点距离的一半，同样无解。

所以在项目启动时，我建议先别急着写ctx.arc()，而是把交互流程、几何约束、异常分支全部列清楚。圆弧功能看起来是一个小功能，但它牵扯到的工程细节，足以撑起一个中级前端工程师一个月的开发量。

1.2 功能边界怎么定：先做几种最常见的画弧方式

AutoCAD的ARC命令输入方式实在太多，web端第一版不需要也不可能全部复刻。我的建议是优先实现三种用户肌肉记忆最深的画弧方式：

一是三点画弧，用户依次点起点、弧上任意一点、终点，这也是最直观的“过三点画圆”思路；二是起点-圆心-角度，用户先点起点，再点圆心，然后输入或拖动指定圆心角，适合画固定角度的圆弧；三是连续圆弧，自动沿用上一条圆弧或直线的结束方向，用户只需要再点一个终点就能继续画出相切的下一段弧。

选这三种不是因为简单，而是它们覆盖了绝大多数机械制图和简易施工图场景。三点画弧适合任意曲线，圆心角画弧适合规则结构，连续圆弧适合路径描摹和轮廓过渡。

功能范围确定后，接下来的技术选型才有意义。如果你一开始就想把所有ARC模式全实现，状态机复杂度会直接爆炸，后面做撤销重做、捕捉、导出时就会处处受阻。先把一条链路打通，再逐步迭代，是我个人强烈建议的节奏。

2. 圆弧的几何基础与命令交互设计

2.1 圆弧在数学上到底怎么表达

要在代码里描述一段圆弧，最常用的参数是：圆心坐标(cx, cy)、半径r、起始角startAngle、终止角endAngle，以及方向标志counterclockwise。为什么是这组参数而不是直接存起点、终点和中间点？因为无论是渲染、捕捉还是导出DXF，这套参数都是行业通用语言。

但这里有一个特别容易踩的坑：数学坐标系和Canvas屏幕坐标系的Y轴方向是相反的。数学里角度逆时针为正，而Canvas中默认顺时针为正，同时Canvas的arc()方法默认也是顺时针绘制。如果你直接把数学计算出来的弧度丢给ctx.arc()，画出来的弧方向大概率是反的。

我的做法是定义一套统一的世界坐标系，业务计算全部使用“角度逆时针为正”的数学约定，只在调用Canvas渲染接口时做一次转换：ctx.arc(cx, cy, radius, -startAngle, -endAngle, true)，或者直接给arc()的最后一个参数传布尔值来控制方向。这样业务层不用到处写取反逻辑，错误率会低很多。

另外还要注意角度单位问题。用户界面里显示“角度”倾向于用度，而Math.sin、Math.cos只认弧度。我专门封装了一个degreeToRadian()工具函数，并且在内部统一使用弧度计算，避免混用。

2.2 复刻ARC命令的交互状态机

在线CAD的交互手感，很大程度靠状态机撑起来。我把画圆弧的过程拆成了五个状态：

第一个是空闲状态，此时没有激活ARC命令，鼠标移动不产生预览；第二个是等待起点状态，用户执行“画圆弧”命令后进入，点击或输入坐标确定起点；第三个是等待第二点状态，具体含义取决于画弧方式，可能在等弧上点，也可能在等圆心；第四个是等待第三点状态，通常用于确定终点或角度；第五个是完成状态，收集完所有必要参数后生成弧实体，回到空闲状态。

每个状态都监听三类事件：鼠标移动时刷新预览，鼠标点击时推进状态，键盘事件时处理数字输入、回车确认和ESC取消。

有一个细节容易被忽略：AutoCAD用户习惯了命令行交互，web端最好也提供一个命令提示栏。状态切换到“等待第二点”时，提示文字同步更新为“指定圆弧的第二个点或 [圆心(C)/端点(E)]”，这能大幅降低桌面端用户迁移过来的学习成本。我自己实现时就因为一开始没做命令行提示，被几个用惯AutoCAD的朋友吐槽“完全不知道下一步该点什么”。

2.3 坐标拾取与端点捕捉：让光标变得“专业”

绘圆弧的第二个隐藏难点是坐标拾取。用户鼠标点击的是屏幕上的像素坐标，而图形存储在世界坐标中，中间隔着一层视图变换。如果当前画布支持平移和缩放，就必须把屏幕坐标乘以视图矩阵的逆矩阵，换算回世界坐标。

最容易被忽视的是捕捉系统。AutoCAD用户画弧的时候，几乎必然依赖端点捕捉、圆心捕捉和切点捕捉。web端如果连最基本的端点捕捉都不做，画出来的弧就永远“差一点”，图纸精度无从谈起。

捕捉的基本思路是：鼠标移动时，遍历当前画布上所有实体的关键点，比如线段的起点终点、圆弧的圆心和弧上等分点，计算它们与鼠标位置的距离。如果距离小于某个阈值，比如10像素，就把鼠标位置强行吸附到这个关键点上，同时显示一个醒目的捕捉标记。

在实现圆弧捕捉时，我还额外加了一个“圆弧中点”的捕捉点，也就是弧线的中点，这样用户画连续圆弧时会顺手很多。当然，捕捉也不是越多越好，阈值太大会误吸，太小又吸不上，我实际测试下来，在100%缩放下8到12像素是体感比较好的范围。

3. 核心算法与代码实现

3.1 先写一个“能画弧”的基础渲染函数

无论交互怎么设计，最终都要落在一段渲染代码上。下面这个函数是我在项目里实际使用的圆弧渲染核心，基于Canvas 2D实现。

interface ArcEntity { cx: number; cy: number; radius: number; startAngle: number; // 弧度，逆时针为正 endAngle: number; // 弧度，逆时针为正 counterclockwise: boolean; } function drawArc( ctx: CanvasRenderingContext2D, arc: ArcEntity, options: { lineWidth?: number; strokeStyle?: string } = {} ) { const { lineWidth = 1, strokeStyle = '#000' } = options; ctx.save(); ctx.beginPath(); ctx.lineWidth = lineWidth; ctx.strokeStyle = strokeStyle; // Canvas 的 arc 默认按顺时针角度计算， // 业务层统一用逆时针角度，因此这里取反并设置方向标志。 ctx.arc( arc.cx, arc.cy, arc.radius, -arc.startAngle, -arc.endAngle, !arc.counterclockwise ); ctx.stroke(); ctx.restore(); }

注意ctx.arc()的最后一个参数anticlockwise，很多教程里讲得比较含糊。这里的关键是：当你传入的起始角和终止角是负数、并且希望方向符合业务语义时，必须反推一遍。我的习惯是先在纸上画一个坐标轴，把Math坐标系和Canvas坐标系的关系标清楚，再决定是否加负号。

这个基础函数虽然短，但它承担了所有类型圆弧的最终输出。后面三点画弧算出的圆心角、连续圆弧延续的方向，都会先转换成ArcEntity，再交给它渲染。

3.2 三点画弧：圆心反算是核心

三点画弧的输入是三个点：起点P1、弧上点P2、终点P3。几何上说，三点确定一个圆，圆心就是P1P2和P2P3这两条线段的垂直平分线的交点。

实现时，我先计算向量v1 = P2 - P1，再计算向量v2 = P3 - P2，然后求出各自的中点mid1、mid2。垂直平分线方程可以写成参数形式：

function getCircleFromThreePoints( p1: { x: number; y: number }, p2: { x: number; y: number }, p3: { x: number; y: number } ): { cx: number; cy: number; radius: number; angle1: number; angle2: number; angle3: number } | null { const ax = p1.x, ay = p1.y; const bx = p2.x, by = p2.y; const cx = p3.x, cy = p3.y; const d = 2 * (ax * (by - cy) + bx * (cy - ay) + cx * (ay - by)); if (Math.abs(d) < 1e-8) { // 三点共线或近似共线，无法确定唯一圆 return null; } const ux = ((ax * ax + ay * ay) * (by - cy) + (bx * bx + by * by) * (cy - ay) + (cx * cx + cy * cy) * (ay - by)) / d; const uy = ((ax * ax + ay * ay) * (cx - bx) + (bx * bx + by * by) * (ax - cx) + (cx * cx + cy * cy) * (bx - ax)) / d; const radius = Math.hypot(ux - ax, uy - ay); const angle1 = Math.atan2(ay - uy, ax - ux); const angle2 = Math.atan2(by - uy, bx - ux); const angle3 = Math.atan2(cy - uy, cx - ux); return { cx: ux, cy: uy, radius, angle1, angle2, angle3 }; }

这个函数返回的angle1、angle2、angle3分别是起点、弧上点、终点在圆上的角度。注意，它们并不保证顺序，虽然用户按起点、中间点、终点的顺序点击，但三段角度可能是逆时针也可能是顺时针。所以在生成ArcEntity时，必须根据角度的绕向动态判断：如果从angle1到angle3经过angle2是逆时针，则counterclockwise=true，否则为false。

很多初版实现就是在这里出错，画出来的弧走了“远路”，明明三点之间是短弧，偏偏绕了快一整圈。判断绕向的代码如下：

function isCounterClockwise(start: number, mid: number, end: number): boolean { // 将角度归一化到 [0, 2PI)，判断 mid 是否落在 start -> end 的逆时针区间内 const norm = (a: number) => ((a % (2 * Math.PI)) + 2 * Math.PI) % (2 * Math.PI); const s = norm(start); const m = norm(mid); const e = norm(end); if (s < e) { return m > s && m < e; } return m > s || m < e; }

3.3 起点-圆心-角度：圆心角换算

这种画弧方式对用户来说非常直观：先点起点S，再点圆心O，然后指定圆心角。AutoCAD默认逆时针为正角度，用户输入正数得到逆时针弧，输入负数得到顺时针弧。

实现时，已知圆心O、起点S，半径就是r = |OS|，起始角是向量OS的角度，用Math.atan2(sy - oy, sx - ox)就能得到。接下来是关键：用户随后输入的角度，到底是终止角还是“增量角”？

AutoCAD这里用的是增量角，也就是圆心角。如果用户输入90度，则表示从起始角开始逆时针扫过90度，终止角为startAngle + PI/2。这个设计和“指定终止点”不一样，很多web实现想当然地把第二次点击的位置当作终止点，会让用户非常不习惯。

我的实现是：第二次点击确定圆心后，第三次点击不是直接确定终点，而是先实时计算鼠标位置相对于圆心的角度，再用这个角度减去起始角，得到当前预览的圆心角。这样用户拖拽时能直观看到“弧张开了多少度”，键盘输入数字时则直接作为圆心角更新预览。

代码如下：

function buildArcByCenterAngle( start: { x: number; y: number }, center: { x: number; y: number }, angleDelta: number // 弧度, 逆时针为正 ): ArcEntity { const dx = start.x - center.x; const dy = start.y - center.y; const radius = Math.hypot(dx, dy); const startAngle = Math.atan2(dy, dx); const endAngle = startAngle + angleDelta; return { cx: center.x, cy: center.y, radius, startAngle, endAngle, counterclockwise: angleDelta >= 0, }; }

这个函数唯一需要小心的是angleDelta可能非常大，比如用户输入720度，渲染出来的效果和360度一样，但后续计算中点、捕捉等可能出问题。我一般在生成实体之前对角度做一次归一化，限制在[-2PI, 2PI]范围内。

3.4 连续圆弧：如何自动延续上一条实体的方向

连续圆弧是AutoCAD里非常实用的功能，但在web端复刻时需要额外多存一点信息。它的规则是：新圆弧的起点就是上一条圆弧或直线的终点，新圆弧在起点处的切线方向，等于上一条实体在终点处的切线方向。

换成人话说，就是“接着上一笔的方向继续画，并保持相切”。

为了方便计算，我定义了一个全局对象来记录“上一条实体的结束方向和结束点”：

interface ContinueContext { endPoint: { x: number; y: number }; endTangentAngle: number; // 弧度，表示终点处的切线方向 }

如果是上一条直线，endTangentAngle就是直线的倾斜角；如果是上一条圆弧，endTangentAngle需要通过圆弧在终点处的导数来计算。圆弧在任意一点的切线方向，等于半径方向旋转90度。圆心指向终点的向量角度是终点对应的角度endAngle，切线角就是endAngle + PI/2。

用户执行连续圆弧时，点击的第一个点不是新弧的起点，而是新弧的终点。起点固定为上一条实体的终点，所以真正需要算的只有圆心。这里我用的方法是：已知起点S、切线角theta、终点E，因为圆心到起点的半径方向与切线方向垂直，所以圆心一定在过S且方向为theta + PI/2的直线上；同时圆心到S和到E距离相等，又得到一条垂直平分线。两条直线求交，圆心就出来了。

这个逻辑用数学描述不复杂，但代码实现时要小心两条直线平行的情况，恰好说明用户把终点点在了同一直线上，此时应该提示“无法生成圆弧”。

3.5 渲染选型：Canvas、SVG、WebGL的对比

实现圆弧功能前，必须先定渲染方案。我在实际项目里对比过三条路线。

Canvas 2D是最均衡的选择：学习成本低，arc()原生态支持圆弧，重绘整幅图纸在几百个实体以内完全流畅。缺点是Canvas没有DOM节点级别的拾取能力，命中检测要自己算。

SVG的优势在于每个元素都是DOM，天然支持事件绑定和CSS动画，拾取非常方便。但缺点是元素数量超过几千个时，DOM节点暴增，内存和渲染性能都会明显下降。画少量圆弧没问题，做完整版CAD就不太够。

WebGL性能最强，适合上万实体的复杂图纸，但开发成本高，画圆弧需要用三角形逼近或着色器实现曲线，代码量会翻好几倍。除非你的在线CAD目标就是“大规模图纸浏览”，否则第一版不建议直接上WebGL。

我最终选的是Canvas 2D加上自己实现一套“几何拾取”逻辑。圆弧的命中检测其实就是计算鼠标点到圆心距离是否等于半径，同时判断鼠标角度是否落在起始角和终止角之间，整个过程几十行代码就能完成。对第一版工具来说，这个性价比最高。

4. 工程化落地的关键点

4.1 实体数据模型：所有圆弧都用同一个结构

在线CAD项目里，最忌讳的是每种图形都写一套独立的变量和渲染函数。弧、圆、椭圆、样条曲线看起来不同，但底层都可以统一到“圆心+半径+起始角+终止角”这个模型里。

我定义了一个基础接口：

interface Entity { id: string; type: 'LINE' | 'ARC' | 'CIRCLE' | 'RECT'; layer: string; color?: string; visible: boolean; }

圆弧实体则在Entity基础上扩展ArcEntity字段。这样做的最大好处是：撤销重做、序列化、图层管理、批量导出这些横切功能可以完全和具体图形类型解耦，只需要针对type做分发即可。

比如撤销重做，我只需要维护一个实体数组的快照栈，任何操作成功后执行push(entity)，撤销时弹出并重绘。因为所有实体结构一致，重绘函数只需要遍历数组，逐个判断type再调用对应绘制函数即可，不需要为某种图形单独写一套撤销逻辑。

4.2 撤销重做与拾取命中：Canvas方案怎么弥补

前面说过Canvas没有DOM级拾取能力，所以我实现了一个轻量级的命中检测函数。对圆弧来说，鼠标点P是否命中某条弧，分三步判断。

第一步判断距离，计算P到圆心的距离与半径之差的绝对值，小于容差才算“落在圆上”；第二步判断角度，计算P相对圆心的角度angleP，看它是否在startAngle和endAngle围成的区间内；第三步对角度区间做归一化，因为startAngle可能大于endAngle，也可能跨过0度边界。

命中检测后，我会高亮命中的实体，并且显示三个控制柄：起点、终点、圆心。拖动控制柄可以实时修改圆弧参数，这就完成了最基本但非常有用的“编辑圆弧”能力。建议把命中检测的容差设置成“屏幕像素”而不是“世界坐标”，否则缩放后会忽大忽小。我的做法是把6像素的屏幕距离通过当前视图缩放比例换算成世界坐标容差。

4.3 导出DXF和JSON：让图纸能带走

在线CAD画完图，总得让用户能导出。JSON格式适合自己平台的存档和恢复，DXF格式则是和AutoCAD生态互通的硬通货。

DXF的ARC实体有一种标准的文本格式，核心字段包括图层名、圆心坐标、半径、起始角、终止角。导出时只需从ArcEntity里取出这些值，写入DXF文本即可。这里有两个坑：一是DXF里的角度单位是度而不是弧度，导出前必须做一次换算；二是DXF约定逆时针为正，如果业务里已经统一为逆时针，那么直接转换即可，如果业务里用了Canvas坐标系的顺时针方向，导出时就要加负号。

JSON导出则简单得多，直接序列化ArcEntity数组就行。不过建议在JSON里加一个version字段，方便以后结构升级时做兼容，这个细节能省掉很多线上问题。

5. 常见问题与排查实录

5.1 浮点误差让圆弧“合不拢”

在线CAD里，用户经常画完一段弧再去捕捉它的端点画线，如果浮点误差积累，就会看到明明该闭合的图形却有个头发丝一样的缝隙。

问题根源是重复计算：从三个点求圆心时用了Math.atan2和Math.hypot，从另一个实体的角度再次计算端点时，结果和原值不同。解决办法是统一精度，在ArcEntity生成后，所有派生数据都从ArcEntity本身计算，而不是从原始的屏幕坐标二次推导。

我还在实体生成处做了一次数值修正：把startAngle和endAngle归一化到[0, 2PI)范围，把圆心坐标保留到小数点后六位。这个量级的精度对工程制图足够，又不会产生明显的累积误差。

5.2 坐标转换：屏幕坐标与世界坐标

很多人画圆弧时出现“画出来位置不对”的bug，八成是坐标转换没做对。浏览器里鼠标拿到的坐标是相对Canvas元素的CSS像素，而业务层使用的是世界坐标，中间隔着两个步骤：先减去Canvas元素左上角偏移，得到Canvas坐标系下的像素坐标；再乘上当前视图变换的逆矩阵，得到世界坐标。

如果画布有缩放，这个转换里还不能漏掉缩放因子。我自己写的时候用了一个简单工具类：

function screenToWorld( sx: number, sy: number, view: { offsetX: number; offsetY: number; scale: number } ): { x: number; y: number } { return { x: (sx - view.offsetX) / view.scale, y: (sy - view.offsetY) / view.scale, }; }

另外，Canvas的devicePixelRatio在高DPI屏上会让图形发虚。渲染之前要设置canvas.width = canvas.clientWidth * devicePixelRatio，然后ctx.scale(devicePixelRatio, devicePixelRatio)，这样曲线边缘才会清晰。

5.3 高频mousemove的性能优化

画弧时的预览功能要求在鼠标每移动一像素就重绘一次。如果每次mousemove都直接清空画布并遍历所有实体重绘，实体一多就会卡顿。

我的优化方案是：鼠标移动时，只记录最新的坐标并存入预览状态，不立即重绘；通过requestAnimationFrame统一在下一帧执行重绘。这样即使一秒钟触发60次mousemove，实际重绘也只有60次。同时重绘时只做增量处理：先绘制底层不变的所有实体，再把预览弧画在最上层，预览弧的绘制单独用一个离屏Canvas缓存，减少重复计算。

实测在两千个实体以内，这个方案能保持流畅的交互体验。如果图纸再大，就得考虑把重绘区域限制在鼠标周围的一个矩形范围内，不过第一版没必要做这么深入。

5.4 触摸屏与不同浏览器的兼容适配

在线CAD天然适合平板和触屏设备，但触摸事件和鼠标事件的行为差异很大。touchmove不会自动触发mousemove，而且触摸时手指会遮挡屏幕，预览体验比鼠标差。我的做法是同时监听pointerdown、pointermove、pointerup，用Pointer Events统一处理鼠标和触摸。

Safari在这个问题上比较特殊，老版本不支持Pointer Events，需要降级到touch事件。另外，触摸画布时浏览器默认会滚动页面，必须在CSS里加上touch-action: none才能避免。

画弧这个功能在触屏上还有一个交互细节：双击确认。桌面端双击不是一个常用操作，但触屏上“点两点”容易误触，我建议在弧完成前提供一个显式的“完成”按钮，避免用户因为误触而丢掉已经输入的两个点。

5.5 画弧时“方向反了”的排查思路

几乎每个做圆弧功能的开发者都会遇到“方向反了”的问题。我的排查顺序固定为三步。

第一步检查业务层的角度定义：我约定逆时针为正，那么从向量(1,0)转到(0,1)是正90度。如果代码里用了顺时针为正，第一步就会露馅。

第二步检查ctx.arc()的参数：Canvas的arc()方法内部角度的正方向是顺时针，我把业务角度取反传入，同时把anticlockwise参数设置成业务方向的取反，这一点非常容易写反。

第三步检查导出：DXF文件里角度用度而且从X轴正方向开始逆时针为正，如果导出时没有把弧度转度，或者没有统一方向，在AutoCAD里打开就是反的。

如果这三步都查了还是反的，那大概率是状态机里传错了点，比如把终点当成起点传进了圆心计算函数。这种bug最好排查的方式是加一个临时的断点日志，把每次点击生成的ArcEntity完整打印出来，人工核对角度和方向。

做完整套圆弧功能后，我最大的感受是：web端CAD真正难的不是图形学算法本身，而是那些看不见摸不着的交互细节。圆弧从算法到交互到渲染再到导出，每一步都有至少一个“想当然就翻车”的地方。尤其是角度方向和坐标转换这两处，几乎决定了你后面所有功能的稳定性。如果你也在做在线CAD的绘图工具，建议从圆弧这个功能入手打磨团队对几何计算和状态机的理解，这个模块做稳了，后面做多段线、样条曲线、标注测量都会顺手很多。等你把三点画弧和连续圆弧跑通，再回头看这套实现，基本就能形成一个可复用的“在线CAD绘图内核”了。