数学函数图像绘制这件事看起来像是中学课堂里的老话题但真动手做一个能用的工具坑比想象中多得多。我上一篇文章聊了整体思路和界面框架这次接着往下说——把能画图变成画得准、画得快、画得让人愿意用中间隔着的那些具体问题。关键词就三个函数解析、采样策略、坐标变换。适合两类人看一是想用AI辅助自己搓小工具但卡在数学计算环节的开发者二是对绘图工具内部原理好奇、想自己改一改的技术爱好者。下面全是我在实际迭代中踩出来的经验代码片段可以直接拿去跑。1. 从字符串到可计算表达式解析层为什么不能图省事很多人做函数绘图工具第一反应是丢给eval()或者Function构造函数输入sin(x)直接执行。我一开始也这么干五分钟跑通然后花了整整两天填坑。解析层是整个工具的地基这里偷的懒后面会以十倍代价还回来。1.1 直接执行字符串的四个致命问题第一个问题是作用域污染。用户输入x的时候eval在全局作用域里找变量如果你的页面里恰好有个全局变量叫x结果就完全不可预期。我实测过一次输入x1画出来的是一条水平线排查半天发现是某个第三方脚本在全局挂了个x。第二个问题是安全边界。哪怕这是个本地工具用户可能从别处粘贴一段表达式进来里面夹带while(true){}或者访问window.location轻则卡死页面重则数据被带走。工具类产品一旦开放输入框就必须假设输入是不可信的。第三个问题是错误定位。eval(sin(x)抛出的SyntaxError只告诉你Unexpected end of input不告诉你缺的是哪个括号、在第几个字符。用户看到这种报错只会觉得工具坏了而不是自己输错了。第四个问题是性能。每次重绘都要重新解析一遍字符串拖动视图的时候一秒钟重绘几十次解析开销直接吃掉帧率。正确做法是解析一次、缓存 AST重绘时只做求值。提示如果你的工具只给自己用、输入永远可信eval确实能省事。但只要有一丝可能让别人用就老老实实写解析器这是底线。1.2 手写递归下降解析器的核心结构我最终选的是递归下降原因是它写起来直观、错误信息好定制、扩展新语法比如隐式乘法2x成本低。核心就三层词法分析把字符串切成 token语法分析把 token 组装成 AST求值器遍历 AST 算数值。词法分析的关键是数字和标识符的边界判断。比如2x要切成2和x两个 token 而不是一个非法标识符3.14e-2要整体识别为科学计数法。我的做法是遇到数字就贪婪吃字符直到遇到不属于数字的字符为止同时特殊处理e后面跟正负号的情况function tokenize(input) { const tokens []; let i 0; while (i input.length) { const ch input[i]; if (/\s/.test(ch)) { i; continue; } if (/[0-9.]/.test(ch)) { let num ; while (i input.length /[0-9.]/.test(input[i])) num input[i]; if (input[i] e || input[i] E) { num input[i]; if (input[i] || input[i] -) num input[i]; while (i input.length /[0-9]/.test(input[i])) num input[i]; } tokens.push({ type: number, value: parseFloat(num) }); continue; } if (/[a-zA-Z_]/.test(ch)) { let id ; while (i input.length /[a-zA-Z0-9_]/.test(input[i])) id input[i]; tokens.push({ type: identifier, value: id }); continue; } tokens.push({ type: operator, value: ch }); i; } return tokens; }语法分析用经典的表达式 → 项 → 因子三层结构处理运算符优先级。这里有个容易忽略的细节一元负号。-x^2在数学上应该解析成-(x^2)而不是(-x)^2因为幂运算优先级高于取负。我在因子层里判断如果遇到-且它出现在表达式开头或左括号之后就当作一元运算符处理递归解析后面的因子再取负。1.3 隐式乘法与函数调用的处理顺序隐式乘法是提升体验的关键——用户习惯写2x、3sin(x)、2(x1)不写乘号。处理它有个陷阱必须在语法分析阶段插入乘法节点而不是在词法阶段硬塞一个*token否则sin(x)里的sin和(之间会被误插乘号。我的策略是在解析项的时候每次解析完一个因子检查下一个 token 是否是数字、标识符或左括号如果是就当作隐式乘法继续解析下一个因子并组合成乘法节点。函数调用则优先匹配标识符后面紧跟左括号且标识符在已知函数表里就按函数调用处理否则按变量或常量处理。这个判断顺序不能反反了sin(x)会被拆成sin * (x)。输入正确解析常见错误解析2x2 * x标识符2x非法sin(x)函数调用sin * (x)-x^2-(x^2)(-x)^22(x1)2 * (x1)语法错误x^2^3x^(2^3)右结合(x^2)^3左结合最后一行值得单独说幂运算是右结合的x^2^3等于x^8而不是x^6。递归下降里实现右结合就是在解析幂的右操作数时递归调用自身而不是循环。这个细节错了画出来的曲线在特定区间会完全跑偏而且很难通过肉眼发现。2. 采样策略为什么等距取点画不出正确的图解析层搞定接下来是采样。绝大多数教程会告诉你在可视范围内均匀取 N 个点连起来我照做之后发现tan(x)在渐近线附近画出了一条竖直的假线sin(1/x)在原点附近糊成一团。问题不在渲染在采样。2.1 等距采样的三个典型失效场景高频振荡是最直观的。sin(50x)在宽度 800 像素的画布上如果只取 800 个点每个周期只有约 1 个采样点画出来是随机折线而不是正弦波。解决办法不是无脑加大采样数而是根据函数在当前区间的变化率动态调整。渐近线误连是视觉上最刺眼的。1/x在x0两侧分别趋向正负无穷等距采样会取到x-0.001和x0.001两个点它们的 y 值一个极大一个极小连起来就是一条贯穿全图的竖线。这条线在数学上根本不存在。我的处理是相邻两点的 y 值符号相反且绝对值都超过阈值时判定为跨越渐近线断开路径而不是连线。定义域空洞容易被忽略。sqrt(x)在x0时无定义log(x)在x0时无定义。等距采样如果取到无定义点求值返回NaN直接连过去会在图上留下一条从最后一个有效点到第一个有效点的诡异直线。正确做法是把NaN当作断点路径在这里断开。2.2 自适应采样按曲率加密而不是按数量堆固定采样数的本质问题是把采样预算平均分配但函数在不同区间的复杂度天差地别。我的方案是递归二分 曲率判据先在整个区间取少量种子点对每一段检查中点处的实际值与两端点线性插值的偏差偏差超过阈值就把这段一分为二继续检查直到偏差达标或达到最大递归深度。function adaptiveSample(fn, x0, x1, y0, y1, depth 0) { const MAX_DEPTH 12; const TOLERANCE 0.5; // 像素单位的偏差容忍 const xm (x0 x1) / 2; const ym fn(xm); if (!isFinite(ym)) return [{ x: x0, y: y0 }, { x: x1, y: y1 }]; const yLinear (y0 y1) / 2; const deviation Math.abs(ym - yLinear); if (depth MAX_DEPTH || deviation TOLERANCE) { return [{ x: x0, y: y0 }, { x: xm, y: ym }, { x: x1, y: y1 }]; } const left adaptiveSample(fn, x0, xm, y0, ym, depth 1); const right adaptiveSample(fn, xm, x1, ym, y1, depth 1); return left.concat(right.slice(1)); }这里TOLERANCE的单位是像素而不是数学单位这点很关键。用户感知的是屏幕上的偏差同样 0.1 的数学偏差在放大 10 倍后就变成 1 像素所以阈值要跟着缩放比例走。我一开始用固定数学阈值放大后曲线明显变折线改成像素阈值后问题消失。MAX_DEPTH设 12 意味着单段最多细分 4096 份配合初始种子点总采样量在几千到几万之间浮动实测在普通笔记本上单条曲线重绘耗时 3 到 8 毫秒拖动视图时能稳住 60 帧。2.3 采样密度与渲染性能的平衡实测自适应采样虽好但不能无节制。我做过一组对比测试同一台机器、同一条sin(x)*exp(-x/10)曲线、800×600 画布策略平均采样点数单次重绘耗时视觉质量固定 800 点8001.2ms平缓段有折角固定 4000 点40005.8ms基本平滑渐近线仍误连自适应阈值 0.5px约 18003.1ms平滑断点正确自适应阈值 0.1px约 65009.4ms几乎无差别性能浪费结论很清楚阈值 0.5 像素是性价比拐点再往下压视觉收益趋近于零耗时却线性上涨。另外采样点数不是越多越好超过画布像素宽度两倍之后多出来的点对最终图像没有贡献纯属浪费。注意自适应采样对不连续函数要额外小心。floor(x)这种阶梯函数每个整数点都是跳变递归二分会在跳变处疯狂细分直到撞上深度上限。我的处理是检测到相邻点 y 值跳变超过画布高度时直接判定为断点不再细分。3. 坐标变换数学坐标系与屏幕坐标系的对账采样算出来的是数学坐标画到屏幕上要经过一套变换。这块看起来简单——不就是乘个比例加个偏移吗——但符号方向、缩放锚点、边界裁剪三个地方各有一个坑我逐个踩过。3.1 y 轴翻转与缩放锚点的正确姿势屏幕坐标系原点在左上角、y 轴向下数学坐标系原点在中间、y 轴向上。最直觉的变换是screenY height - mathY * scale但这样写缩放时会出问题缩放锚点默认在画布左上角用户滚轮放大时图形会往右下角跑体验极差。正确做法是把变换拆成世界坐标 → 视图坐标 → 屏幕坐标三步缩放作用在视图坐标上锚点取鼠标位置。具体来说滚轮事件发生时先算出鼠标位置对应的世界坐标(wx, wy)缩放后保持这个点仍在鼠标下方反推出新的视图偏移function zoomAt(mouseX, mouseY, factor) { const wx (mouseX - offsetX) / scale; const wy (height - mouseY - offsetY) / scale; scale * factor; offsetX mouseX - wx * scale; offsetY height - mouseY - wy * scale; }这段代码里height - mouseY就是 y 轴翻转的体现。我最初漏了这个翻转缩放时图形上下颠倒着跑调了半小时才反应过来。3.2 网格与刻度的自适应步长算法网格线画多密是个体验问题。固定步长在缩小时糊成一片、放大时稀疏得没法读数。我的方案是按 1-2-5 序列选步长先算出当前缩放下每像素代表多少数学单位乘以目标像素间距我取 80 像素得到一个理想步长然后向上取到最近的 1、2、5 乘以 10 的幂。function niceStep(rawStep) { const exp Math.floor(Math.log10(rawStep)); const base Math.pow(10, exp); const norm rawStep / base; let nice; if (norm 1) nice 1; else if (norm 2) nice 2; else if (norm 5) nice 5; else nice 10; return nice * base; }为什么是 1-2-5 而不是 1-2-3-4-5因为人脑对 1、2、5 的倍数最敏感刻度标签0.5、1、2、5读起来顺而0.3、0.6、0.9这种序列看着别扭。这是制图领域的经验惯例不是我拍脑袋定的。刻度标签的格式化也有讲究。步长小于 1 时要显示足够的小数位比如步长 0.2 时标签应该是0.2、0.4而不是0、0。我的做法是根据步长的数量级动态决定小数位数decimals Math.max(0, -Math.floor(Math.log10(step)))再对-0这种浮点误差产物做归零处理。3.3 高 DPI 屏幕下的模糊问题与解决在 Retina 屏上第一次跑所有线条都是糊的。原因是 canvas 的 CSS 尺寸和实际像素尺寸不一致浏览器做了插值放大。解决办法是把 canvas 的width/height属性设成 CSS 尺寸乘以devicePixelRatio再用ctx.scale(dpr, dpr)把绘图坐标系缩回来。function setupCanvas(canvas) { const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); canvas.width rect.width * dpr; canvas.height rect.height * dpr; const ctx canvas.getContext(2d); ctx.scale(dpr, dpr); return ctx; }这里有个连带影响前面算的采样阈值TOLERANCE 0.5像素在ctx.scale之后指的是 CSS 像素而实际物理像素是它的 dpr 倍。所以阈值应该按 CSS 像素来定这样在不同 dpr 的屏幕上视觉平滑度一致。我一开始按物理像素定阈值结果高分屏上采样过密、低分屏上又不够统一到 CSS 像素后才稳定。另外线条宽度也要注意lineWidth 1在 dpr2 的屏幕上实际是 2 个物理像素看起来偏粗。想要视觉上 1 像素的细线应该设lineWidth 1 / dpr或者干脆接受 2 物理像素的观感——后者其实更清晰我最后选了后者。4. 交互与重绘让拖动缩放不卡顿的几个关键决策工具能不能用最后一公里在交互手感。函数绘图的重绘成本不低如果每次鼠标移动都全量重算拖动时必然掉帧。我在这块做了三个决策每个都对应一个具体的性能瓶颈。4.1 分层渲染静态层与动态层分离最有效的优化是把不常变的东西缓存起来。网格、坐标轴、刻度标签这些只在视图变换时变化函数曲线只在函数或视图变化时变化而鼠标悬停的十字线、坐标读数每帧都在变。我把它们分成三层 canvas 叠在一起只有最上层每帧重绘下面两层按需重绘。实测下来单纯拖动视图不改变缩放时网格层和曲线层都可以复用缓存只重绘十字线层帧率从 30 左右提到稳定 60。缩放时才需要重算曲线但因为自适应采样本身够快也能维持流畅。分层还有个额外好处导出图片时可以把三层合成一张或者只导出曲线层做透明背景灵活性比单 canvas 高很多。4.2 防抖与节流在重绘中的取舍鼠标拖动会触发大量mousemove事件如果每个事件都触发重绘等于把渲染压力放大好几倍。这里要区分两种场景拖动平移需要即时反馈用节流每 16ms 最多重绘一次保证跟手输入框改函数不需要即时用防抖停止输入 300ms 后重绘避免每敲一个字符就全量重算。function throttle(fn, interval) { let last 0; return function (...args) { const now Date.now(); if (now - last interval) { last now; fn.apply(this, args); } }; } function debounce(fn, delay) { let timer null; return function (...args) { clearTimeout(timer); timer setTimeout(() fn.apply(this, args), delay); }; }节流间隔取 16ms 对应 60 帧取更小没意义因为屏幕刷新率就那样。防抖延迟取 300ms 是经验值太短用户还没输完就重绘、太长显得迟钝。这两个数值我都试过调整最终定在这两个值上体感最好。4.3 悬停读数与曲线求交的精度处理鼠标悬停显示(x, y)读数是个小功能但精度处理不好会显得很业余。直接显示fn(mouseWorldX)的结果用户会看到1.9999999997这种浮点噪声。我的处理是按当前缩放比例决定显示精度缩放到能看清 0.01 的差异时显示两位小数缩放到整数级别时显示整数。更麻烦的是多曲线求交。用户画了两条曲线想知道交点在哪。数值求交我用的是二分法在两条曲线采样点的 x 区间内找f(x) - g(x)变号的区间然后二分逼近到足够精度。这里要注意变号检测必须基于采样点而不是连续函数因为采样点之间的变号可能被漏掉。我的做法是在自适应采样的结果上做变号检测采样已经足够密漏检概率很低。求交的精度我定在1e-6的 x 精度再代入求 y。显示时按缩放比例格式化避免出现(1.0000001, 2.0000003)这种读数。实测下来两条平滑曲线的交点定位误差在 1 像素以内用户感知不到。提示求交功能对不连续函数要禁用否则tan(x)和x会在每个渐近线附近报出一堆假交点。我的做法是检测到区间内有断点就跳过该区间。5. 几个只有真做过才会遇到的边角问题前面四块是主干下面这些是散落在各处的细节单独拎出来说是因为它们都属于不看不知道、一看吓一跳的类型。5.1 浮点误差导致的曲线断裂sin(x)在x很大时Math.sin的返回值会有微小误差导致相邻采样点的 y 值出现不该有的跳变画出来曲线上有细小的毛刺。这个问题在x超过1e6之后特别明显。我的处理是在采样阶段对 y 值做相对误差过滤如果相邻两点的 y 差值小于1e-10乘以当前 y 的量级就认为它们相等合并成一个点。另一个浮点坑是-0。Math.round(-0.4)返回-0格式化后显示成-0而不是0刻度标签上出现负零很扎眼。统一在格式化函数里加一句if (value 0) value 0就能把-0归一成0。5.2 极端缩放下的数值稳定性用户把视图放大到1e15倍时x的浮点精度只剩个位数采样点之间的间隔小于浮点精度所有点挤在一起曲线变成一条竖线。这不是 bug 是物理极限但工具应该优雅处理而不是画出一堆垃圾。我的做法是设一个缩放上限比如1e12超过就禁止继续放大并给个提示。缩小方向也有问题。缩到1e-12时x的绝对值极小1/x直接溢出成Infinity采样全返回Infinity曲线消失。处理方式是把Infinity和NaN一样当作断点同时限制最小缩放。5.3 函数定义域的动态检测有些函数的定义域不是全实数比如sqrt(x)只在x0有定义asin(x)只在[-1,1]有定义。如果用户不知道画出来只有半条曲线会以为工具坏了。我的做法是在采样时记录有效点的范围如果有效区间明显小于可视区间就在界面上给个轻提示当前视图内函数定义域有限。这个检测不能太激进否则1/x这种只在一点无定义的函数也会被误报。我的判据是有效采样点占比低于 30% 才提示且提示是弱提示不是弹窗不打断用户操作。5.4 表达式缓存的失效策略前面提到解析结果要缓存但缓存什么时候失效是个问题。用户改了函数表达式缓存必须失效用户只改了视图范围缓存应该保留。我的做法是把缓存 key 设成表达式的规范化字符串去空格、统一小写函数名视图变化不碰缓存只有表达式变化才重新解析。缓存本身用Map存设一个上限比如 50 条超过就淘汰最久未使用的。实测下来用户在一个会话里通常只画几条到十几条曲线50 条的上限绰绰有余内存占用可以忽略。边角问题触发条件处理方式浮点毛刺x 绝对值很大相对误差过滤合并点负零显示刻度值接近 0格式化时归零极端放大缩放超过 1e12限制缩放上限并提示极端缩小缩放低于 1e-12限制缩放下限定义域有限有效点占比低于 30%弱提示不打断缓存膨胀表达式超过 50 条LRU 淘汰这些边角问题单独看都不大但叠在一起就是这个工具用起来总觉得哪里不对劲的来源。我花在填这些坑上的时间比写主干功能还多。6. 用AI辅助开发时我实际怎么分工标题里提到用AI开发这块得说清楚不然容易误导。AI在这个项目里的角色是加速器不是替代品分工大致是这样的。6.1 AI擅长的部分样板代码与边界枚举词法分析器的骨架、坐标变换的公式推导、1-2-5 步长算法这类有标准答案的东西AI 给得又快又准。我通常是把需求描述清楚——写一个递归下降解析器支持四则运算、幂运算右结合、一元负号、隐式乘法——然后拿生成的代码改。省下的是查语法、回忆算法细节的时间。另一个好用的是边界情况枚举。我问过函数绘图工具在采样阶段可能遇到哪些边界情况它列了十几条其中定义域空洞导致 NaN 连线和渐近线误连是我原本没想到的。这种穷举式提问适合在动手前做能提前避掉一批坑。6.2 AI容易翻车的部分数值细节与性能判断但涉及具体数值和性能的地方AI 给的答案经常看起来对、跑起来错。比如它建议的采样阈值是0.01 数学单位这个值在默认缩放下勉强能用一放大就崩。再比如它写的防抖函数没有处理this绑定在类方法里用会丢上下文。我的经验是AI 给的代码必须逐行读懂再改尤其是涉及浮点比较、边界判断、异步时序的地方。读不懂就说明它可能在糊弄宁可自己写。性能相关的决策更不能信 AI 的直觉必须自己跑 benchmark因为 AI 没有你的硬件和你的用户场景。6.3 提示词的组织方式与迭代节奏我组织提示词的习惯是先给约束再给需求先说清楚运行环境浏览器、canvas、无第三方库、代码风格ES6、函数式优先、性能预算单次重绘 10ms 以内再说具体要什么。约束给足了AI 生成的代码返工率明显下降。迭代节奏上我不追求一次生成完整模块而是小步验证先生成词法分析跑通几个用例再生成语法分析接上词法最后生成求值器。每步都验证错了立刻回退重来比一次性生成一大坨再调试快得多。这个节奏和传统开发其实一样AI 只是把每步的耗时压缩了。说到底AI 让从零写一个工具的门槛降了很多但写得好用这件事还是得靠人对细节的把控。工具最终是给人用的那些让用户觉得顺手的地方——缩放跟手、刻度好读、断点正确——没有一处是 AI 能替你拍板的都得自己一遍遍试出来。我现在的习惯是每加一个功能先自己用十分钟专挑别扭的地方改改到不别扭为止。这个自己用的环节是任何工具都绕不过去的最后一关。
