JavaScript实现计算器听起来像是一门课程的第一课作业可这个作业的坑有多深只有亲自动手写过的人才知道。我最早写这个项目的时候以为难点在界面布局后来发现界面半天就能做完真正的难点全藏在“用户乱按一通”之后的逻辑处理里。这篇文章我打算从拆需求、写界面、绑事件、设计运算核心、处理浮点精度、收拾边界条件这几个方面把一笔一笔的实操经验都翻出来适合刚开始接触原生JavaScript、想做点能跑的东西的新人也适合那些已经能写出页面但一碰交互逻辑就心虚的开发者。1. 计算器项目的真实难点不是算出99而是把用户操作变成可靠状态1.1 一个看似简单的问题背后藏着三类麻烦很多人拿到这个题目第一反应是界面上放一堆按钮监听点击把数字和运算符拼成一个字符串塞进一个函数里算一下完事。如果你只是交一个静态Demo这个思路确实够用。但只要你把计算器当成一个给别人用的工具问题马上冒出来用户不按你的逻辑出牌。比如用户输入“1 2 3”然后按等号。这时候你是每按一次加号就立刻算一次还是等按等号时再一次性结算这两种策略得到的结果可能一样但中间状态完全不同。再比如用户连续按两次加号第二次加号是覆盖第一次还是忽略又比如用户按了等号之后不按清空直接输数字计算器该接着上一次结果继续算还是开启一个新的算式这三个问题只要有一个没想清楚写出来的代码就会在某个角落留下奇怪的行为。我把这些麻烦大致分成三类。第一类是操作顺序不可控用户的点击顺序千变万化你没办法假设常量第二类是数值精度问题JavaScript里的浮点数计算会给出各种看起来离谱的尾巴第三类是显示与内部状态的一致性屏幕上显示什么、内部拿什么值参与计算这两者一旦脱节计算器就会变成“看起来对用起来错”的玩具。这三类问题才是这个项目真正的骨架界面反而是最不费脑子的部分。1.2 先把需求写成行为清单再开始动代码我后来养成了一个习惯写代码之前先把需求列成一张表。计算器项目不用整得跟软件需求文档一样复杂但至少要把用户能做什么操作、每种操作对应什么预期结果写清楚否则写到一半很容易自己推翻自己。我做的这版标准型计算器功能范围是0到9的数字输入、小数点、四则运算、等号、清空键、退格键、正负号切换。百分比和括号一开始不做因为百分比在不同计算器上的行为差异很大括号则需要一套真正的表达式解析器作为第一版来说容易把状态机搅浑。功能范围明确之后行为清单大概是这样的。用户操作预期行为数字键追加到当前显示数字若刚按过等号则清空旧状态并开启新算式小数点若当前数字已包含小数点则忽略否则追加运算符加、减、乘、除保存当前数字为操作数若之前已有未执行的运算符则先结算再记录新运算符等号若存在未执行的运算符则执行运算并显示结果保留重复计算所需的信息清空键重置所有内部状态显示归零退格键仅删除当前输入数字的最后一个字符正负号翻转当前显示数字的符号这张表现在看起来平平无奇但当时它帮我避免了很多反复改代码的尴尬。比如我原本没写“等号后按数字开启新算式”这条结果做了一个加号得到了结果结果再按数字时数字直接拼到了结果后面屏幕变成了“58这样”。把行为清单补上之后所有支线逻辑都有了依据代码写起来心里踏实很多。2. 界面和事件层按键如何被解析成一次有效输入2.1 布局用flex或grid都行但真正决定成败的是每个按钮的标签设计界面这块我不打算花太多篇幅但有一个点值得单独说按钮上的数据标签。很多人做计算器会把“”、“-”这些符号直接写在按钮文字里然后通过判断按钮的文本内容来区分功能。这样做的缺点是一旦你要做多语言切换或者按钮文案调整事件代码也要跟着改。我习惯在按钮上额外挂两个自定义数据属性一个是动作类型一个是动作参数。比如数字键的数据类型是digit参数就是对应的数字运算符键的数据类型是operator参数就是对应的运算符。这样一个结构既清晰也为后面的统一事件处理打好基础。div classcalculator idcalculator div classscreen idscreen0/div div classkeypad idkeypad button>const keypad document.getElementById(keypad); keypad.addEventListener(click, (event) { const button event.target.closest(button); if (!button) return; const action button.dataset.action; const value button.dataset.value; handleAction(action, value); });这里有一个细节用event.target.closest(button)而不是直接判断event.target。因为如果按钮内部以后加了图标元素点击图标时event.target指向的是图标而不是按钮closest能自动向上找最近的按钮元素避免这种边界问题。这个习惯在其他需要事件委托的场景里也很有用。事件委托把“点击到哪个按钮”这件事统一收集起来后续所有的逻辑分发都在handleAction里做。这样界面层只负责提供动作类型和参数不接触任何计算细节。2.3 键盘支持别让用户只能用鼠标映射表要稳定统一一个像样的计算器不该只能点鼠标。桌面场景下用户很自然地会去按键盘上的数字键和小键盘区域。我在做键盘支持的时候踩过一个教训一开始用keypress事件后来发现某些浏览器对这个事件的支持已经变了而且回车键、退格键行为也不太统一。切换成keydown事件之后一切就稳定了。键盘映射的核心是判断event.key。数字键直接对应0到9运算符对应、-、*、/回车键或等号键触发等号逻辑退格键触发退格Escape键触发清空。需要特别注意的是键盘上的Enter和都可能被当成触发等号的键而小键盘上的Enter在有些浏览器里返回的也是Enter所以两者都要判断。document.addEventListener(keydown, (event) { const key event.key; if (key 0 key 9) { handleAction(digit, key); } else if (key ) { handleAction(operator, ); } else if (key -) { handleAction(operator, -); } else if (key *) { handleAction(operator, *); } else if (key /) { event.preventDefault(); handleAction(operator, /); } else if (key Enter || key ) { handleAction(equals); } else if (key Backspace) { handleAction(backspace); } else if (key Escape) { handleAction(clear); } else if (key .) { handleAction(decimal); } });这里有一个单独要提的细节键盘上的/键在某些浏览器里会触发快速查找功能所以要加event.preventDefault()拦住默认行为。同理回车键在表单环境下可能触发提交不过这个场景下没有表单风险不大但了解这一点以后在更复杂的页面里很有用。3. 运算核心从eval冲动到状态机我对连续运算的取舍过程3.1 eval 只适合拿来画演示图一旦出现在真实项目里就是在引雷说句实话我最早写计算器的时候也干过用eval的蠢事维护一个字符串用户按什么就往上拼什么按等号时eval一下。页面确实能跑但它把所有问题都掩盖了包括运算符优先级、连续运算、显示值和真实值不一致等等。直到某次我输入了一个带小数点的算式屏幕上的数字和我心里想的结果差了一截我才开始意识到这条路走不通。eval的问题在于它接收的是字符串不是结构化数据。你很难在按等号之前知道用户到底输入了什么也很难判断某个数字到底是正在输入的数字还是已经参与过运算的中间结果。更别提如果你哪天想让计算器支持自定义表达式或者接入更多输入来源字符串拼接的思路很快就会变成一团乱麻。所以我后来把所有逻辑推翻重写改成状态机模型这一步回头看是值得的。3.2 状态机模型五六个变量就能撑起一台标准计算器状态机这个词听起来很高端其实就是把“当前计算器处在什么状态”用几个变量明确表达出来再定义清楚每种用户操作会让状态发生什么变化。我用到的核心状态变量有这些。currentInput当前正在输入的数字初始是“0”accumulator已经累计的运算结果pendingOperator已经保存、但还没有执行的运算符waitingForOperand是否正在等待用户输入新的操作数justEvaluated是否刚执行过等号计算用于处理连续按等号lastOperand最近一次等号计算时的右侧操作数用于连续按等号时重复运算核心运算函数只做一件事给定左侧数字、运算符、右侧数字返回计算结果。除数为零时返回一个特殊值让上层去处理错误提示。function applyOperation(left, operator, right) { switch (operator) { case : return left right; case -: return left - right; case *: return left * right; case /: return right 0 ? null : left / right; default: return right; } }状态流转规则用一段伪代码说明可能更清楚。每当用户按下一个数字如果waitingForOperand为真说明上一个操作数已经结束当前输入应该替换而不是追加如果justEvaluated为真说明等号刚算完此时应该清空旧的累计状态开始一个全新算式。用户按下运算符时如果之前已经保存了待执行的运算符并且当前确实有新输入的操作数就先结算一次如果用户连着按运算符只需要更新pendingOperator不能重复结算。用户按等号时如果存在待执行的运算符就用当前输入作为右侧操作数执行运算如果刚按过等号则用上次保存的lastOperand作为右侧操作数实现“2 3 5再按一次 得到 8”的效果。这个模型当时我调试了很久最后发现它其实可以整理成一张状态表每次用户操作都按表来代码分支非常清晰。这也是为什么我说计算器项目练的不是DOM操作而是状态管理把这张表画清楚代码怎么写都顺。3.3 用手推演一遍“12 7 - 5 ”你就什么都明白了光说变量定义还不够直观我拿一个具体算式走一遍。初始状态是currentInput为“0”accumulator为0pendingOperator为空waitingForOperand为假。按“1”再按“2”currentInput变成“12”。按“”因为pendingOperator为空所以把当前输入数字12存入accumulator然后记录pendingOperator为“”同时把waitingForOperand设为真。按“7”读数字时发现waitingForOperand为真就把currentInput从“12”替换为“7”并关掉该标志。按“-”此时pendingOperator不为空且用户输入了新的操作数7所以先执行一次结算12 7 1919存入accumulator屏幕也显示19。然后把pendingOperator更新为“-”再次把waitingForOperand设为真。按“5”currentInput变成“5”。按“”执行 19 - 5 14显示14accumulator变成14最后记录lastOperand为5justEvaluated设为真。这个推演过程看起来繁琐但当你写代码写不下去时用纸笔这样走一遍比看十篇教程都管用。我当时甚至把每一步的状态变化画成表格贴在显示器旁边调试时对着表一眼就知道哪个分支写错了。4. 精度、显示与格式化0.10.2这个坎和它身后的显示哲学4.1 0.30000000000000004 是怎么冒出来的只要你写过JavaScript就一定见过0.1 0.2的结果不是0.3而是0.30000000000000004。我第一次看到这个结果时也愣了半天因为数学直觉告诉我这就是0.3。后来才明白计算机内部存储小数用的是二进制浮点数用二进制去表示十进制的0.1就像用十进制去表示1/3一样永远只能近似无法精确。具体来说JavaScript里的数字类型遵循IEEE 754双精度标准底层用64位二进制来存储一个数其中分数位有53位精度。0.1在二进制里是一个无限循环小数存储时必然被截断于是计算时产生的微小误差就积累到了显示结果里。这不是JavaScript独有的问题Python、Java、C都会遇到只是JavaScript的默认小数显示策略让它暴露得特别明显。4.2 我采用的方案内部保持原始浮点数显示时做一次“收尾”明白了原理之后我的第一反应是能不能让计算永远不产生误差答案是不能除非你全程用整数或字符串模拟十进制运算。对一台标准计算器来说追求这种绝对精确没有意义用户能接受的底线是显示结果看起来干净。所以我采用了一套折中方案内部计算时直接使用浮点数显示值统一经过一个格式化函数把那些多余的尾巴清掉。function cleanNumber(value) { if (!isFinite(value)) { return value; } const fixed value.toFixed(12); const cleaned parseFloat(fixed); if (Math.abs(cleaned) 1e16) { return cleaned.toExponential(10); } return String(cleaned); }这段代码的思路是先保留12位小数再用parseFloat把末尾多余的0去掉。比如0.1 0.2内部算出来是0.30000000000000004经过toFixed(12)变成0.300000000000再parseFloat就得到了0.3。如果数字大到一定程度就转成科学计数法保住高位信息。这里有一个坑必须提醒格式化只应该发生在显示层不该反过来污染内部计算结果。原因是如果你每次都把内部值四舍五入到固定小数位再参与下一步运算连续运算时误差会累积得很快。比如0.1 0.2 0.3如果每步都截断到两位小数还好但一旦你截断到更少的位数结果会越来越离谱。正确的做法是内部永远存原始浮点结果只在最终显示时做清理。4.3 显示值不等于内部值这个概念越早建立越好显示层和内部值分离这个理念在做计算器的时候体现得特别明显但它其实是前端开发里放之四海皆准的原则。界面上看到的永远是一个“被格式化过”的、方便阅读的版本而真正参与运算、存储的是未经展示处理的原始数据。举一个实际案例。用户输入0.1 0.2界面显示0.3。如果用户不按任何键继续按“ 0.4”那么参与运算的应该是0.3这个显示值还是内部那个0.30000000000000004答案应该是显示值0.3。因为在我们的格式化策略里内部值已经通过parseFloat转变成了干净的0.3后续运算自然基于这个值。但如果你在某个版本里写的是直接toFixed(2)却不转回数字那参与运算的就会变成一个带有额外误差的二进制表示长时间使用之后误差会被逐渐放大。我在项目里做了一个约定内部所有状态变量里存的都是数字类型只有在screen元素上显示的才是字符串。每次运算结果在存入状态变量之前必须经过cleanNumber里的数值清理逻辑确保后续运算拿到的都是干净数字。这个约定执行之后很多隐蔽的小误差问题自然消失了。5. 边界条件汇总连按等号、连按运算符、除以0、超大数字这些我全踩过5.1 连按等号的行为最容易被新手漏掉如果用户输入2 3按一次等号得到5再按一次等号他期望得到什么我测试过身边不少人大部分人的预期是得到8也就是继续用上一次的运算符和右侧数重复计算。少数人觉得应该是5因为他们认为第二次等号是重复“上一次完整的运算”。主流计算器用的是前者我刚写第一版时完全没想到这个需求导致用户再按一次等号时毫无反应。实现连等逻辑的关键是等号运算时把右侧操作数保存下来并在justEvaluated为真时继续使用它。比如2 3 5保存lastOperand为3再按一次等号因为justEvaluated为真执行5 3 8再按一次就是8 3 11。这个逻辑一旦加上计算器的“手感”一下子就对了。5.2 连按运算符和先按运算符我的处理策略是“覆盖”另一种高频边界场景是连按运算符比如输入1 2 。我的处理策略是如果当前正处于等待操作数状态也就是用户刚按过运算符那么再次按键直接覆盖之前记录的运算符。这样1 2等价于1 2。还有人会设计成忽略第二次运算符直接不响应。两种方案各有道理我选择覆盖是因为它更符合大多数人使用实物的习惯不会让你觉得按键“失灵”。还有一个我一开始没处理的场景算式一开始就按运算符比如用户直接按“”再按“5”再按“”。合理的行为是把它当作0 5 5来处理。状态机里当pendingOperator为空且accumulator为初始状态时按运算符就把当前显示值存入accumulator显示值在没有输入数字时就是0所以自动变成0 5 5。这个行为不需要额外写代码但设计时要想明白否则你可能会在初始化上写出多余的分支。5.3 除以0不崩溃错误提示要温和行为要干脆除数为零在JavaScript里不会抛错会得到Infinity或-Infinity。如果你直接把Infinity显示出来普通用户会一头雾水而且继续用这个值运算会产生更诡异的结果。我的做法是在applyOperation里对除数为零的情况返回null上层拿到null时把屏幕显示为“不能除以0”然后重置内部状态让用户从干净状态重新开始。这里千万不要用alert弹窗因为弹窗会打断操作节奏在真实输入环境里非常烦人。5.4 前导0、连续小数点、退格键这些操作都需要输入过滤输入细节上也有不少要收拾的地方。比如用户先按了好几个0显示应该是“0”而不是“000”用户输入“0.5”时数字前面可以有0但不能再追加0用户按小数点时如果当前数字已经包含小数点应该忽略这次点击退格键删到只剩一个字符时应该把显示重置为“0”而不是显示空字符串。这些过滤逻辑通常集中在处理数字输入的函数里用一个简单的字符串判断就能完成。我习惯在这个函数里同时处理“刚按过等号后按数字”的重置逻辑保证所有进入状态机的输入都是经过净化的避免脏数据流入运算部分。如果你偷懒不做这些过滤用户操作速度一快屏幕上就会出现“00.5.3”这类完全不可解析的内容。5.5 屏幕装不下时怎么办显示截断与科学计数法的取舍数字无限增长是有可能的比如用户连续按“999999999”屏幕装不下或者算出一个天文数字。我的处理策略是分两步第一步限制输入当显示字符串长度达到上限时数字键不再追加但退格键仍然有效第二步是格式化输出数值超过一定量级时自动切换成科学计数法保证信息不丢。这里有一个容易被忽略的平衡问题如果一味压缩字号来塞更多数字计算结果会显得拥挤而且用户根本读不清如果直接截断数字又会造成精度损失。科学计数法是更可靠的选择因为它在不丢高位信息的前提下把数字压到最短。我在cleanNumber里设置了一个阈值超过1e16时使用指数表示实测下来兼顾了可读性和准确性。5.6 这些边界条件不是靠聪明绕开的而是靠一张测试清单边界条件太多了靠脑子记不现实更靠谱的做法是维护一张验证清单。我每改完一个分支就会按清单把典型场景跑一遍。下表是我实际用过的一组用例。输入操作期望显示备注0.1 0.2 0.3浮点精度收尾2 3 5再按得到8连续等号1 2 3连续运算符覆盖9 ÷ 0 不能除以0除零保护000123123前导0消除1.2.3停留在1.2连续小数点忽略5 10运算符前默认01 ÷ 3 0.333333333333小数位数截断后收尾这张清单里的每一项都是我实际遇到过的真实问题。写完这版计算器后我意识到这类边界测试单的价值不比代码本身低因为计算器的逻辑分支很多任何一次改动都可能引入回归有一张能反复执行的用例清单心里才有底。6. 做完这版计算器后我对“从零手写”这件事的看法6.1 同类库和组件那么多为什么这一版仍值得自己写如果你和我说现在前端界有各种成熟的组件库拖一个按钮进来就有现成的计算器何必从零手写我只能说用手写代码换来的理解是直接拿组件换不来的。这个项目最值钱的部分不是最后那几百行代码而是你从“想清楚一件小事”到“把它变成代码”的整个过程。我记得有一次给组里新人讲代码他看了半天状态机的实现问我为什么不直接把表达式存成字符串再解析。我说你也试一下纯手工实现把用户操作变成可靠的状态迁移写完你就明白了。他果然去写了一天第二天回来跟我说以前从来不知道自己在DOM操作上没什么问题也不会想到一个计算器里居然藏着这么多逻辑分支。这个项目的价值就在这里它可以让你在一百行代码的范围内完整体验到状态管理、边界思考、模块分离这些大项目里才能碰到的问题。6.2 如果你要在这个基础上继续加功能建议按这个顺序来第一版做完之后你可以在这个稳定骨架上逐步加功能。我建议的顺序是先加百分比键和平方根键它们不触及表达式结构只是新增两类运算然后让计算器支持记忆键M、M-、MR、MC这会在状态变量里多一块独立存储再往后如果你想要括号和真正的四则运算优先级那就需要升级成递归下降解析器或调度场算法状态机就撑不住了要换思路。我一直觉得普通计算器做到状态机这层就够了但如果你还想继续往里钻可以把计算器当成一个小型编译原理项目来做把输入按键解析成“词法单元”再按优先级生成“语法树”最后求值。这个方向很有意思做完之后你再去看那些支持括号的计算器脑内的建模方式会完全不一样。6.3 最后分享一个我写计算器时一直用的习惯说了这么多技术细节最后聊点个人的小习惯。我每写一个带交互状态的项目都会先把“用户操作与状态变化”的对应关系写在一张纸上或者记在文档里写完代码后再对照着把分支逻辑逐条过一遍。计算器是这个习惯的绝佳练习场因为它的状态数量不多但每种状态之间的迁移路径几乎全被覆盖过。每过一遍我对“代码就是状态迁移”这句话的理解都会更深一点。另外一个建议是别急着把按钮排版和炫酷样式放到前面做。先把一个功能完整、逻辑可靠的标准型计算器做出来再考虑换肤、音效、键盘布局这些锦上添花的东西。功能内核不结实界面再漂亮也是空壳内核结实了后面你想怎么加都很从容。这个道理我在写程序这些年里反反复复验证过计算器是体会它最划算的一次实践。