纯HTML+JS计算器应使用type="text"输入框配合正则校验，用parseFloat()转数字并isNaN()检查，统一监听keydown处理键盘与按钮事件，结果用textContent显示于contenteditable="false"的div中，除零等错误需重置缓冲区。
用 <form></form> 和原生 JavaScript 实现基础四则运算
不需要框架，纯 HTML + JS 就能跑起来的计算器，核心是把表单控件当作输入出口、用 event.preventDefault() 阻止默认提交、再手动取值计算。关键不是“怎么画按钮”，而是“怎么安全读取并执行运算”。
常见错误：直接用 eval() 解析用户输入的表达式（比如 "2+3*4"），这等于给 XSS 开后门；或者没处理空输入、除零、非数字字符，一算就报 NaN 或崩溃。
- 只允许输入数字、小数点、
+-*/和等号，其他字符一律过滤或忽略 - 运算符最多连续出现一个（如
2++3应截断为2+3） - 除零必须显式提示，不能让结果变成
Infinity还继续参与后续计算 -
<input type="number">看似省事，但它会阻止用户输入小数点和负号，反而更难控制，建议统一用type="text"+ 正则校验
parseFloat() 和 Number() 选哪个？
两者都能转数字，但行为差异直接影响计算器健壮性。比如用户输 " 12.5 "（带空格）、"12.5.6"（非法小数）、"12abc"，它们的返回值完全不同。
-
parseFloat(" 12.5 ")→12.5（自动去首尾空格，停在第一个非法字符） -
Number(" 12.5 ")→12.5（同样去空格） -
parseFloat("12.5.6")→12.5（只取前半段合法部分） -
Number("12.5.6")→NaN（整个字符串不合法就直接失败） -
parseFloat("abc12")→NaN（开头就不合法）
推荐用 parseFloat()，它更宽容，适合表单场景；但必须配合 isNaN() 检查结果是否有效，不能假设一定成功。
立即学习“前端免费学习笔记（深入）”；
为什么不要用 onclick 写死每个按钮逻辑？
写 10 个数字按钮 + 4 个运算符 + 等号，如果每个都绑 onclick="append('5')"，代码冗余、难维护、无法响应键盘输入。真实项目里，用户肯定要用键盘敲数字和回车计算。
- 统一监听
input元素的keydown事件，捕获event.key - 用
switch(event.key)匹配"0"–"9"、"+"、"-"、"*"、"/"、"Enter"、"Backspace" - 按钮点击也触发同一套处理函数，避免逻辑分裂
- 特别注意：
event.key在不同键盘布局下可能返回"="或"+"（比如 Mac 小键盘），需兼容判断
计算结果该显示在 <input> 还是 <div>？
<p>显示区域本质是只读输出，但很多人习惯用 <code><input type="text" readonly>。问题在于：iOS Safari 对 readonly 输入框仍允许光标聚焦，用户可能误触清空；而且语义上它不是“输入”，是“结果”。
- 用
<div contenteditable="false"> 更干净，无聚焦、无光标、样式可控
<li>若坚持用 <code><input>，务必加 tabindex="-1" 并监听 focus 后立即 blur()，防止意外激活
- 更新显示时别直接改
innerHTML，用 textContent 避免 HTML 注入（比如用户输 "<script>alert(1)</script>"）
- 结果为小数时，用
result.toFixed(6).replace(/\.?0+$/, "") 去掉末尾冗余零，但注意 toFixed 会四舍五入，金融类场景慎用
最易被忽略的是错误状态的恢复逻辑：比如用户输 "5/0" 显示 "Error" 后，接下来按任何键都不该继续在错误基础上计算，必须重置输入缓冲区——这个 reset 时机和条件，比实现加减乘除本身还容易出错。
<div contenteditable="false"> 更干净，无聚焦、无光标、样式可控
<li>若坚持用 <code><input>，务必加 tabindex="-1" 并监听 focus 后立即 blur()，防止意外激活innerHTML，用 textContent 避免 HTML 注入（比如用户输 "<script>alert(1)</script>"）result.toFixed(6).replace(/\.?0+$/, "") 去掉末尾冗余零，但注意 toFixed 会四舍五入，金融类场景慎用最易被忽略的是错误状态的恢复逻辑：比如用户输 "5/0" 显示 "Error" 后，接下来按任何键都不该继续在错误基础上计算，必须重置输入缓冲区——这个 reset 时机和条件，比实现加减乘除本身还容易出错。
