使用 disabled 输入框作显示区、addeventlistener 绑定按钮事件、eval() 白名单校验求值、css grid 布局是实现轻量计算器的核心方案：disabled input 保障可访问性与文本操作，事件委托避免内联脚本，受限 eval 安全高效，grid 解决响应式布局问题。
直接用 <input type="text"> 做显示区、<button></button> 做按键，配合原生 JavaScript 就能跑起来——不需要框架，也不用预编译工具，浏览器里开个 .html 文件就能调试。
HTML 结构必须用 disabled 输入框做显示区
很多人一开始用 <div> 或 <code><p></p> 显示结果，结果发现无法聚焦、无法选中文本、键盘输入会意外触发，还容易被用户误改。真实场景下，显示区本质是“只读输出”，但又需要支持复制、全选等操作——<input type="text" disabled> 是唯一兼顾语义、可访问性和交互行为的方案。
-
disabled阻止用户编辑，但保留文本可选、可复制能力 - 别用
readonly：它允许聚焦，焦点进入后按 Backspace 可能清空内容（尤其在 Safari 中） - 别用
contenteditable="false"：语义不明确，屏幕阅读器支持差，且 DOM 更新时易触发光标跳动 - 记得加
id="display"，后续 JS 通过document.getElementById("display")拿到引用最稳
按钮事件绑定优先用 addEventListener，不是 onclick 属性
写 <button onclick="append('1')">1</button> 看似简单，但会导致函数名硬编码、无法复用、调试困难，而且一旦 JS 文件加载失败或函数未定义，整个按钮就静默失效——连控制台报错都看不到。
- 所有按钮统一用 class 区分类型，比如
class="digit"、class="operator"、class="equals" - JS 里用
document.querySelectorAll("button")批量绑定，再根据event.target.textContent或event.target.dataset.value分发逻辑 - 键盘支持必须靠
addEventListener("keydown", ...)监听，onclick属性完全无能为力 - 避免内联事件，否则压缩工具（如 Terser）可能把字符串字面量误判为死代码删掉
eval() 不是洪水猛兽，但必须加白名单校验
计算器表达式求值，90% 的新手会卡在“怎么把 "1+2*3" 算出结果”。用正则拆解再手动运算太重；用第三方库又引入依赖。其实 eval() 在受控环境下是合理选择——前提是输入来源可信且格式受限。
- 只对来自按钮点击或键盘输入的字符做拼接，绝不用
eval()处理location.search或localStorage里的任意字符串 - 拼接前用正则过滤：允许数字、
+、-、*、/、.、(、)，其余一概丢弃 - 执行前检查是否含字母、
;、function、return等敏感词，有则直接清空显示并提示“非法输入” - Chrome 和 Firefox 对
eval()的性能优化已很成熟，比手写解析器快得多；真正慢的是 DOM 更新和重排，不是求值本身
CSS 布局别碰 float 和 inline-block，用 grid 最省心
计算器按钮网格看着简单，但用传统方式容易出现间隙、换行错位、响应式断裂等问题。现代浏览器对 display: grid 支持已全覆盖（IE11 除外，但 2026 年基本可忽略），它是目前最干净的解法。
- 给容器设
display: grid; grid-template-columns: repeat(4, 1fr); gap: 8px; - 数字键默认占一格，
=键加grid-row: span 2占两行，0键加grid-column: span 2占两列 - 避免用
width: 25%+float：小数像素导致累计误差，按钮宽度参差不齐 - 别依赖
font-size控制按钮大小——应统一用min-height和padding，确保触控区域 ≥ 44px（移动端友好）
最常被跳过的细节是键盘输入的防抖和连续点 = 的状态同步——比如用户狂按 =，上一次计算还没结束，下一次就覆盖了中间状态。这不会报错，但结果不可预测，且难以复现调试。
