项目标题“A6：编写计算器界面程序”，看起来像是课程作业或者新手入门时的第一个图形界面项目。但别因为它叫“计算器”就小看它——一个像样的计算器界面程序，几乎能覆盖图形界面开发的全部核心知识点：布局管理、事件绑定、状态维护、逻辑解耦、异常处理。语言也好，框架也好，换到任何一个平台，这套思路都通用。这篇就按我自己的实践经验，把从零做一个计算器界面程序的完整路径拆开讲，能直接照着做的那种。
写之前先说清楚：这不是一篇教你怎么“抄代码”的文章，我也不会贴一大段让读者直接复制的完美源码。我更想把“为什么这样设计”“哪些地方容易翻车”“怎么一步步把脑子里的界面变成能跑的程序”讲透。适合正在学 GUI 编程的初学者，也适合那些已经能写简单窗口程序、但总感觉界面和逻辑纠缠不清的人。看完之后，你会对界面程序的结构、事件驱动的运行方式、还有各种边界情况有更实在的理解。
1. 写计算器之前，先想清楚这几件事
1.1 这不是一个“简单”项目：从需求拆解说起
很多初学者拿到“计算器”三个字，第一反应就是拖几个按钮、接一个文本显示框，然后给每个按钮绑定事件。真动手之后才发现，光是一个“连续计算”就能把脑子绕晕。比如用户按下1 + 2 =，结果是 3；再按+ 5 =，结果应该是 8；如果按的是3 =呢？不同计算器的行为还不一样。所以第一步不是写代码，而是把需求钉死。
我先给自己的计算器定了这么几条边界：只做加减乘除四则运算，支持小数、负数、括号（可选），支持连续运算，支持退格和清零，键盘和鼠标都能输入。再往外扩展，比如历史记录、进制转换、百分号，这些属于锦上添花，但不该在第一版就塞进来。一个项目如果需求不清晰，写出来的代码一定会反复推翻。把范围缩小，反而能让你集中精力把最核心的交互打磨好。
这里要特别提醒：计算器界面的“界面”和“逻辑”是两个独立的东西。界面负责好看、好按、能显示，逻辑负责算得对、状态不乱。如果你一开始就把计算结果直接写进按钮的回调函数里，后面想换控件样式、想改计算规则，就会牵一发动全身。这也是很多自称“会写计算器”的人，代码看起来却一团糟的根本原因。
1.2 界面程序的核心套路：模型-视图-控制分离
做界面程序，绕不开一个老生常谈的概念——MVC（Model-View-Controller），中文叫模型-视图-控制器。听起来很高大上，其实落到计算器上特别直观。
模型（Model）负责数据与规则：当前输入的表达式、当前值、上一个操作符、计算逻辑。视图（View）负责展示：窗口、按钮、文本框、样式。控制器（Controller）负责响应事件：你按了“+”，控制器告诉模型“记下这个操作符”，然后让视图刷新显示。
这样分离之后，你会得到一个非常舒服的体验：你想改按钮颜色，只改视图；你想增加一个开根号功能，只改模型和控制器；你写单元测试，可以直接测模型，不需要启动图形界面。我见过太多新手把计算逻辑写在按钮点击事件里，最后想去掉某个按钮，还得小心翼翼把逻辑摘出来，很痛苦。
哪怕你用最轻量的 Tkinter 或者 Swing，也别嫌这个套路麻烦。先建一个CalculatorModel类管状态和计算，再建一个CalculatorUI类负责画界面，最后用事件回调把两者桥接起来。代码量不会增加多少，但清晰程度是另一个量级。
1.3 你该选哪套技术栈？聊聊 Tkinter / Swing / PyQt 的取舍
计算器界面程序可以用几乎任何带 GUI 能力的语言来写，但不同技术栈的侧重点差异很大。我平时用得比较多的是 Python，因为封装快、调试方便，适合把精力放在逻辑上。具体到 Python 生态，最主流的是 Tkinter、PyQt/PySide、还有 Kivy，各自适用不同场景。
Tkinter 是 Python 标准库自带的工具包，最大的优势就是不需要额外安装，换到哪台机器都能跑，适合快速做原型、写小工具，也适合新手第一次接触事件驱动。缺点是控件的原生感比较“朴素”，样式偏旧，复杂布局时要跟grid、pack的参数较劲。
PyQt/PySide 的出现则更像“正规军”，控件丰富、样式现代化、文档齐全，还自带 Qt Designer 可视化设计工具。用它做计算器有点“杀鸡用牛刀”，但如果你想深入了解信号槽机制、多线程、自定义控件，PyQt 是特别好的学习材料。注意 PyQt 和 PySide 的授权协议不同，商用前要确认清楚。
Java Swing 是另一种经典选项，大学课程里很常见。Swing 的优势是跨平台稳定，布局管理器经过多年打磨，后续可以参考 JavaFX 做更现代的界面。选哪套不是关键，关键是别换着玩，认准一个把前面说的 MVC 套路走通。我今天后面的例子里以 Tkinter 为主，因为最不挑环境，读者复现成本最低。
2. 界面布局：从零把计算器画出来
2.1 按钮布局怎么排最好按？参照真实计算器
界面设计不是随心所欲。计算器作为成熟产品，按钮排列早就形成了肌肉记忆：数字键在右边区域，0 在下方中间，加减乘除在右侧一列，等号在右下角。你做成 iOS 计算器那样的竖排，还是 Windows 计算器的标准布局，都可以，但一定要“像那么回事”。
标准的四行五列布局大概是这样的：第一行放C（清空）、±、%、÷；第二行7 8 9 ×；第三行4 5 6 -；第四行1 2 3 +；最后一行0、.、=。这样用户不需要看说明书就知道该按哪里。有些新手喜欢把所有按钮横着排一行，或者按自己的喜好乱放，那只能算“会显示控件”，不是“会设计界面”。
按钮的大小也值得讲究。手指点击的最小舒适区大概在 30 到 50 像素之间，电脑上鼠标点还好，但如果你考虑触摸屏，按钮就得做得大一点。Tkinter 里按钮的宽度按字符数算，一个数字键设成width=5, height=2左右表现不错；稍大一点也行，但窗口会跟着变大，要考虑在常见分辨率下不超出屏幕。
2.2 显示区、字体、配色：细节决定手感
显示区是整个计算器的“脸”，用户所有反馈都靠它。显示区的设计有三个关键点：对齐方式、字体、以及状态反馈。
文本对齐通常选右对齐，因为数字是从低位到高位读的，右对齐更符合视觉习惯。真实的计算器还会在输入到一定长度时自动缩小字号，让长数字不被截断。Tkinter 的Label或Entry默认不支持自动缩放字体，但你可以监听文本长度，超过阈值就把字体调小一档。这个功能很便宜，但能明显提升“专业感”。
配色方面，数字键和运算键最好不要同色。比如数字键用浅色底、深色文字，运算键用深色底、浅色文字，等于号再用一个醒目色。这种颜色分区不是单纯的审美问题，它让用户手不用看屏幕，就能凭颜色定位到要按的键。我见过很多计算器程序在配色上“五彩斑斓”，结果看起来像玩具，操作起来反而更累。
还有一个细节：按下去要有视觉反馈。Tkinter 的按钮默认有按下效果，但如果你用了flat样式，建议换成raised或groove，这样用户能明确知道“我按到了”。如果你嫌默认效果不够，可以在Button上绑定<ButtonPress-1>和<ButtonRelease-1>分别改背景色，实现自定义按压高亮。
2.3 用网格布局还是绝对定位？手把手画一个面板
拿 Tkinter 来说，布局管理器有三种：pack、place、grid。对计算器这种规则表格，最合适的是grid，因为每一个键都能对号入座到行列里。
我建议创建一个专门的方法，例如_create_display和_create_keypad，把界面拆成两个区域。顶部用一个Frame作为显示区，底部用一个Frame放按钮网格。下面是一个常规的网格初始化写法：
display = ttk.Entry(root, justify="right", font=("Arial", 18)) display.grid(row=0, column=0, columnspan=4, sticky="nsew", padx=5, pady=5) buttons = [ ["C", "±", "%", "÷"], ["7", "8", "9", "×"], ["4", "5", "6", "-"], ["1", "2", "3", "+"], ["0", ".", "=", None], ] for r, row in enumerate(buttons, start=1): for c, text in enumerate(row): if text is None: continue btn = ttk.Button(root, text=text, command=lambda t=text: self.on_key(t)) btn.grid(row=r, column=c, sticky="nsew", padx=2, pady=2)这里有个很重要的技巧：用lambda t=text来捕获当前按钮的文本。如果你直接写command=lambda: self.on_key(text)，等按钮被点击时，循环里的text已经变成了最后一轮的值，所有按钮都会触发同一个操作。这是新手必踩的经典坑，记住了。
为了让按钮随窗口伸缩，可以给root.grid_rowconfigure和root.grid_columnconfigure设置权重，比如每行每列的weight=1，再把按钮的sticky设为"nsew"。如果不做这一步，窗口拉伸时按钮会保持原来的大小，界面中部会出现难看的空白。想让窗口不可拉伸也可以，直接固定root.resizable(False, False)，更省事。
3. 核心逻辑：别让按钮只是摆设
3.1 表达式解析：从“按下等于”到计算结果的完整流程
计算器的核心在于怎么处理你输入的算式。网上最常见的方案是“表达式求值”，也就是每次按等号时，把当前输入框里的字符串拿去做解析，调用eval之类的函数算出结果。用 Python 写，三行代码就能跑：
result = eval(expression)但eval是一把危险的钥匙，它会把任意代码当表达式执行。你在自己的电脑上练习无所谓，但如果想发布给别人用，用eval等于给恶意输入开了后门。更稳妥的方式是自己写一个解析器，把数字、小数点、运算符、括号拆成记号（token），然后基于调度场算法或递归下降解析来求值。
不过，对于只有加减乘除和括号的计算器，我推荐另一种思路：不要维护一个“字符串表达式”，而是直接让程序记住“当前值、待处理的操作符、刚输入的数字”。这样你根本不需要在最后去解析一个长表达式，而是边输入边计算。这种模式叫“立即执行计算器”，和真实计算器的行为更接近。
举个例子：输入12 + 34，当你按下+时，程序立刻把12存成“当前值”，把+存成“待处理操作符”，然后清空输入区让用户输入第二个数。按下等号时，把当前输入框里的34拿出来，和之前的当前值做一次加法，得到46。如果用户再按×，程序不做运算，而是把46当作新的当前值，把×存起来。这样做的好处是，每次运算都是两个数的事，逻辑简单，不容易被乱七八糟的表达式搞晕。
3.2 一次性输入与逐步计算：两种模式的实现差异
刚才提到的其实对应两种主流模式。第一种叫“表达式模式”，用户输入12+34*5=，按下等号才统一计算结果，符合数学上“先乘除后加减”的规则。第二种叫“即时计算模式”，按一次运算符就算一次，没有真正的优先级，更像普通手持计算器。
如果你做表达式模式，就需要一个像样的解析器。一个简化版的递归下降求值器大概是这样的：解析数字、处理+-时先递归到下一层乘除，然后返回结果。或者用两个栈，一个存数字，一个存运算符，遇到右括号或优先级高的运算符就弹出计算。这个做法能力更强，可以处理复杂的算式，但代码量也大不少。
即时计算模式则不用管优先级，因为每次只算两个数。它更适合初学者，而且在连续运算时反馈很直接——按一次运算符就能看到中间结果，不用等最后等号。我建议第一次做计算器时先选即时模式，把主流程跑通之后，再去挑战表达式模式。千万别贪心，一上来就想做支持百分号、括号、正负号的花哨计算器，结果最后哪一步都调不稳。
3.3 连续运算、清空、退格：这些状态怎么管
计算器程序里最考验状态管理的三个操作是：连续运算、清空、退格。先说连续运算，在即时模式下，状态至少有三个：当前值（accumulator）、待处理操作符（pending_op）、是否刚完成一次运算（just_equal）。每按一个数字，你要更新显示；每按一个操作符，你要决定是“先算前一步”还是“只存操作符”。这块设计得不好，会出现1 + 2 + 3，第二次按+时结果却变成 0 的诡异情况。
我个人的写法是：数字键只负责把数字追加到输入缓冲区；操作符键按下时，如果输入缓冲区有数字，就先把缓冲区的数字和当前值按上一次操作符计算，更新当前值；如果缓冲区空，就只更新待处理操作符。等号键则强制做一次计算，然后设置just_equal=True，这样下一次按键就重置输入缓冲区，而不是继续追加。
清空也要分清两种：“AC”是全清，把所有状态归零；“C”通常只清当前输入。退格则是从输入缓冲区去掉最后一个字符，如果缓冲区只有一个字符，退格后应该显示 0 而不是空。这些细节看起来小，但正是它们决定了程序到底好不好用。
还有个极易出错的地方：用户按了1 + 2 + =，这该得到什么？不同计算器有不同答案，有的是 3，有的是 5（再算一次）。为了减少歧义，我一般把等号设计成“重复上一次操作符”的效果，或者直接忽略多余的操作符。不管选择哪种，都要保持一致，并在文档里写清楚。
4. 事件绑定与交互细节：让程序“活”起来
4.1 绑定键盘输入和鼠标点击
一个好用的计算器不能只靠鼠标点。用户常常会习惯用实体键盘输入数字和运算符，所以你要把键位映射到对应的逻辑函数。在 Tkinter 里，可以给窗口绑定<Key>事件，然后根据event.keysym或event.char分发。
我习惯这样分发：数字和小数点直接走on_digit，运算符走on_operator，Return（回车）当等号，BackSpace当退格，Escape当清空。注意event.char在某些按键上可能是一个空字符串，这时得靠event.keysym判断。例如小键盘上的回车键，keysym会是KP_Enter，你要同时处理。
绑定键盘时最需要注意的是输入焦点。如果界面上有一个 Entry 控件，它可能始终占据焦点，导致全局按键绑定失效。解决办法是把绑定放在计算器的根窗口上，并设置focus_set()，或者用bind_all绑定到全局。我在做计算器时习惯把显示区 Entry 设置为只读或不可获得焦点，这样数字都进我们自己定义的输入缓冲区，不容易发生“在输入框里打出了两个 1，显示区却只剩一个 1”的错乱。
4.2 防止连点、防止除零：边界情况处理清单
写计算器界面程序，最大量的代码其实不是正常流程，而是边界情况。我把我的清单贴在下面，做的时候可以一条条对照。
- 除数为 0 时，不能直接让程序崩掉，应该显示中文提示“错误”或英文
Error，并清空待处理操作符。 - 输入多个小数点：
1.2.3这种状态必须禁止。你可以设置一个标志，在按下小数点时检查输入缓冲区里有没有.，有就不处理。 - 负数输入：比如要输入
-5。即时模式下，我建议提供“正负号”按钮，而不是让用户先按减号再按数字。因为-会被当成运算符，导致状态错误。 - 连续除以零或连点等号：等号不能让程序重复执行上次的操作导致数值爆炸。必须明确每次等号后的状态。
- 整数除法和浮点误差：
10 / 3在二进制浮点里会得到3.3333333333333335这种尾部误差。显示时最好保留一定小数位，或者做一个“结果化整”的判断，例如(result * 10**12).is_integer()时直接取整。
除零是其中最不能妥协的点。我见过很多“看起来能跑”的计算器程序，一按1/0就抛异常退出。哪怕你只用eval的懒人方案，也应该在调用后加一个try/except，把异常捕获成显示值，而不是让整个程序崩掉。这种细节不需要多高深的技术，但特别影响用户对你程序的信任。
4.3 多线程还是不碰？计算器界面卡顿问题
计算器本身计算量小，基本不会卡。但如果你在按钮回调里做了什么阻塞操作，比如弹窗、读写文件、网络请求，界面就会“假死”，因为 GUI 程序的主线程通常被事件循环占着，阻塞操作会让窗口无法重绘。
给你一个判断标准：任何耗时超过 50 毫秒的操作，都不应该直接放在按钮回调里。计算器的“耗时”主要体现在显示大量数据或复杂逻辑时，普通四则运算完全不用担心。如果你未来想给计算器加历史记录、云端同步、语音识别等扩展功能，那才需要把耗时任务丢到子线程，再用队列或事件通知线程安全地更新界面。
Tkinter 本身不是线程安全的，子线程直接操作控件会导致各种诡异问题。如果需要并行任务，请用queue.Queue或root.after来把结果传给主线程。不过就第一版计算器而言，请保持简单，别为了“支持大数计算”就去搞多线程，逐渐增加复杂度才是正路。
5. 实战记录：一个可运行的完整案例
5.1 用 Python Tkinter 快速搭一个最小可用版本
现在把前面的思路落到实际代码。下面的例子是一个可运行的最小即时计算器，代码我会逐段说明。你不需要第一遍就完全看懂，跑起来再对照着改才有效。
先导入模块和定义程序类：
import tkinter as tk from tkinter import ttk class Calculator: def __init__(self, root): self.root = root self.root.title("计算器界面程序") self.root.resizable(False, False) self.display_var = tk.StringVar() self.display_var.set("0") self.buffer = "" # 当前输入的数字缓冲 self.accumulator = 0.0 # 当前值 self.pending_op = None # 待处理操作符 self.just_equal = False # 刚按过等号 self._build_ui() self._bind_keys()这样，初始状态就清楚了：缓冲为空，当前值为 0，没有待处理操作符。
接着搭 UI。_build_ui里创建显示区和一个 5 行 4 列按钮网格，代码和前面布局小节类似。为了简洁，我把所有按钮文本放进一个二维列表，然后循环创建。
5.2 关键代码逐段说明
显示区我用ttk.Entry，设置state="readonly"防止用户直接在里面打字。但你注意，只读 Entry 的textvariable值还是能通过程序更新的，所以显示不受影响。
def _build_ui(self): display = ttk.Entry( self.root, textvariable=self.display_var, justify="right", font=("Helvetica", 20), state="readonly" ) display.grid(row=0, column=0, columnspan=4, sticky="nsew", padx=8, pady=8) key_rows = [ ["AC", "±", "%", "÷"], ["7", "8", "9", "×"], ["4", "5", "6", "-"], ["1", "2", "3", "+"], ["0", ".", "=", None], ] for r, row in enumerate(key_rows, start=1): for c, text in enumerate(row): if text is None: continue btn = ttk.Button( self.root, text=text, command=lambda t=text: self.handle_key(t) ) btn.grid(row=r, column=c, sticky="nsew", padx=2, pady=2, ipadx=12, ipady=6)这里的handle_key是总入口。它根据按键文本决定走_handle_digit、_handle_operator、_handle_equal、AC还是±和%。下面这段是数字键的处理：
def _handle_digit(self, digit): if self.just_equal: self.buffer = "" self.just_equal = False if digit == "." and "." in self.buffer: return if len(self.buffer) < 15: # 限制输入长度 self.buffer += digit self.display_var.set(self.buffer)当用户刚按完等号，紧接着按数字，我希望开始一个新数，而不是在上一个结果后面追加数字，所以清空 buffer。长度限制是为了防止显示溢出。
运算符处理是最核心的：
def _handle_operator(self, op): if self.buffer: self._push_buffer() else: # buffer 为空：比如用户按了 1 + = +，此时可能已有 accumulator if self.accumulator is None: self.accumulator = 0.0 self.pending_op = op self.just_equal = False self.display_var.set(str(self._format_number(self.accumulator)))_push_buffer把当前 buffer 解析成浮点数，如果 pending_op 存在，就按它和 accumulator 做运算；如果 pending_op 为空，就直接把 buffer 值赋给 accumulator。它还会设置show_temp之类的状态。
def _push_buffer(self): num = float(self.buffer) if self.pending_op is None: self.accumulator = num else: self.accumulator = self._apply_op( self.accumulator, num, self.pending_op ) self.buffer = ""_apply_op简单做四则运算，并在除零时返回字符串"错误"。注意如果 accumulator 一旦变成错误，后续运算全部要短路，避免 TypeError。
等号的处理：
def _handle_equal(self): if self.buffer: self._push_buffer() self.buffer = "" elif self.accumulator is not None: # 支持连续按等号做重复运算，需要保存上次操作 num = self.accumulator if self.pending_op: self.accumulator = self._apply_op( self.accumulator, num, self.pending_op ) self.just_equal = True self.display_var.set(self._format_number(self.accumulator))这里“连续按等号”的逻辑是可选的，你可以把它简化成“没有 buffer 就什么也不做”，也能正常使用。我的做法是记录上一次操作符，等号连按就重复算一次，模拟手持计算器的体验。这需要额外保存last_operation和last_value，为了篇幅我就不贴全了，但思路就是“把刚才的操作再执行一遍”。
最后，显示格式化函数要处理浮点数尾数问题：
def _format_number(self, value): if isinstance(value, str): return value if abs(value - round(value)) < 1e-12: return str(int(round(value))) return format(value, ".10f").rstrip("0").rstrip(".")这样，3.0会显示成3，0.1 + 0.2的浮点尾数0.30000000000000004也会被简化成0.3。别小看这段代码，没有它，你的计算器会时不时冒出0.30000000000000004这种让外行觉得“程序坏了”的结果。
5.3 测试用例：从 2+3=5 到 连续运算
写完代码别急着炫，先拿一组用例过一遍。我通常按从简到繁的顺序测试：
- 基础四则：
2+3=得 5；9-4=得 5；3×7=得 21；15÷3=得 5。 - 连续运算：
2+3+4=得 9；2+3×4=在即时计算模式下是(2+3)×4=20，如果你是表达式模式才该得 14。先确认自己属于哪种模式，再决定期望值。 - 清除与退格：输入
123，退格两次显示1；按 AC 后显示0。 - 小数：
0.1+0.2=应显示0.3；1.2×3=得3.6。 - 边界：
1÷0=显示“错误”，按 AC 后继续输数字能恢复正常；连点等号不崩溃；空 buffer 按运算符不崩溃。 - 键盘：用键盘数字键、回车、退格、Esc 分别触发等价操作。
这套测试用例不仅是验收标准，也是你后面改代码时的回归检查清单。每改一个功能，跑一遍，安全很多。
6. 常见问题与排查技巧实录
6.1 按钮显示不出来 / 布局错乱
如果你创建了按钮但窗口里看不到，大概率是grid没有执行到位。检查三件事：按钮是否真的被grid过；父容器是否也被放入另一个容器中；窗口是否设置了size而不是直接 resize。还有一种常见情况是按钮被创建但被后续创建的控件遮挡，或者columnspan设置错误导致按钮被挤到窗口外。
另一个容易忽略的问题是 Tkinter 的默认样式。有些 Linux 环境下ttk.Button没有可用的主题，按钮会显示成一条细线。解决办法是显式设置一个主题：style.theme_use("clam")，或者退回用tk.Button代替。Windows 和 macOS 一般没这问题，但跨平台时建议用ttk加主题，免得在别人机器上莫名其妙变丑。
布局错乱的另一个原因是grid的行列权重没设置。如果你某一行按钮没有设置sticky="nsew"，窗口拉大后按钮会停留在左上角，看起来很“飘”。给每个按钮都设sticky，再给根窗口的每个行列设weight=1，这样按钮就会均匀拉伸。
6.2 连续运算结果不对 / 精度丢失
连续运算出错，十有八九是状态没有在正确时机清空。比如按完等号后没有把buffer清干净，下一个数字就会拼接到旧结果后面。我建议你在_handle_equal的最后打印一下所有状态（buffer、accumulator、pending_op、just_equal），看看每一步的状态是否符合预期。这种“调试输出法”虽然原始，但对 GUI 事件逻辑特别有效。
精度丢失则是浮点数的天性问题。普通二进制浮点表示不了所有十进制小数，比如0.1其实是一个近似值。所以显示前我一律过_format_number做舍入处理。但要注意：舍入只影响显示，运算时仍然用浮点，所以多次运算后误差会累积。如果做金融计算或高精度需求，应该用decimal.Decimal。计算器这个场景，误差到小数点后 10 位再清理足够用了。
还有一种“看起来不对”的迷之情况：用户输入1 + 2 * 3，因为你在即时模式下，按*时会把前面的2和当前的 accumulator1相加，得到3，然后乘 3 得 9。用户以为该先乘后加得 7，于是说你程序算错了。解决办法是界面上明确显示中间结果，或者干脆在帮助文档里写明这是“实时计算”模式。很多人其实不清楚什么“100 分段函数”之类的，但他们知道普通计算器是什么样。
6.3 窗口卡死 / 无法退出
窗口点了没反应，先看主线程是否被某个循环或等待阻塞。最常见的阻塞点是你在回调里用了time.sleep()或while死循环。哪怕循环本身只要 0.1 秒，都会让界面感觉卡一下。如果你发现卡死，按 Ctrl+C 通常在命令行也未必能中断，得用任务管理器关掉进程。排查方法是把可疑的阻塞代码注释掉，逐步二分定位。
另一种“无法退出”是窗口关闭事件被拦截了。Tkinter 默认关闭窗口会销毁所有控件并退出，但如果你给WM_DELETE_WINDOW绑定了一个没有destroy的函数，窗口点关闭却不会退出。这时候建议绑定一个统一的关闭函数，在里面保存必要状态并调用self.root.destroy()。
计算器本身没多少资源可保存，但以后扩展复杂功能时，这个习惯很重要。
6.4 老手也会踩的 5 个坑
- 坑一：用
lambda在循环里绑定按钮命令，不小心捕获了循环变量。记住lambda t=text的固定写法。 - 坑二：忘记处理“负号”与“减号”的差异，导致
-3-2计算错误。提供正负号键，并区分pending_op == "-"。 - 坑三：按完等号后直接按数字，却把数字追加到结果后。需要
just_equal标志。 - 坑四：除零异常只在运算函数里 try，但状态没有重置，导致后面所有操作都报错。错误后应将
accumulator设为None，并强制用户按 AC。 - 坑五：想当然地用
eval解析表达式，然后发现10**或1;2这种输入行为诡异。哪怕你自己写，也别用 eval。
这些坑我第一版代码里全踩过。所以现在写计算器，我会花一半时间列边界情况，而不是急着画窗口。
写到最后，我想分享一个自己常用的调试技巧：给计算器加一个隐藏的“状态面板”控件，在界面下方实时显示buffer、accumulator、pending_op、just_equal这四个变量。运行程序时你一眼就能看到状态是怎么流转的，很多逻辑问题瞬间就懂了。等调试完再把这个面板删掉。这个技巧对任何状态机风格的界面程序都适用，比我当年对着代码猜状态高效得多。
要是你想继续进阶，可以尝试给这个计算器加上历史表达式记录、使用Decimal做高精度计算、或者把界面换成 PyQt 并用 QSS 美化。但那些都是后话了。先把上面这套流程走通，任何一个图形界面项目你都能披荆斩棘。
与GROUP BY的本质区别及实战应用)
