注塑车间的质检程序里，有一段判断产品是否合格的逻辑。

你写了一遍，能用。

然后领导说："冲压线也要加这个判断。"你又复制了一遍。

焊接线要加？再复制。

三条线改完，参数阈值调整，你要找三处去改……

改漏了一处，生产线报了假警，被领导点名。

这不是你粗心，是你还没用上"方法"这把利器。

学完今天这节，这种情况彻底消失。

---

📌 上节回顾

「上一节我们学了 Dictionary<K,V> 字典集合，掌握了用"键值对"快速存取设备数据的方法。

今天在这个基础上，我们进一步学习如何把重复逻辑封装成方法，让代码可以反复调用、灵活传参。」

---

💡 核心知识讲解

方法是什么？用工厂类比秒懂

你可以把**方法（Method）**想象成车间里的一台专用设备。

你把原材料（参数）送进去，设备加工完，把成品（返回值）送出来。

每次需要加工，你不用重新造一台设备，直接调用就行。

这就是方法的核心价值：定义一次，调用多次，逻辑集中，易于维护。

---

方法的基本结构，拆开看就这几块

一个完整的方法长这样：

访问修饰符  返回类型  方法名(参数列表)
{
    // 方法体：具体逻辑
    return 返回值;
}

部分	作用	工厂类比
访问修饰符	控制谁能调用	车间门禁权限
返回类型	告诉调用者结果是什么类型	成品规格说明
参数列表	调用时传入的数据	投料口
方法体	实际执行的逻辑	加工工序
return	把结果送出去	出料口

「记住：如果方法不需要返回任何结果，返回类型写 void（空的意思），就像有些设备只做动作、不出料。」

---

参数：向方法"投料"的方式

参数分两种你最常用的：

① 普通参数（值传递）——把数值的"副本"传进去，原始数据不受影响。就像你给设备一份加工单的复印件，原件还在你手里。

② 默认参数——调用时可以不传，方法里有预设值。就像设备有默认转速，不特别指定就按默认跑。

csharp
// 有默认参数的方法示例
static bool CheckTemperature(double deviceTemp, double alarmThreshold = 85.0)
{
    return deviceTemp >= alarmThreshold;
}

调用时可以这样写：

• CheckTemperature(92.5) — 用默认阈值 85°C 判断
• CheckTemperature(92.5, 90.0) — 自定义阈值 90°C

「默认参数必须放在参数列表的最后面，不能放在普通参数前面，否则编译器会报错。」

---

🤔 一个被忽视已久的组合问题

做 Python 桌面工具的开发者，在数据持久化这件事上大多经历过类似的轨迹：最开始直接用 sqlite3 标准库，手写 SQL，能跑就行；后来项目复杂了，表多了，关联查询多了，开始觉得手写 SQL 维护起来很费劲；于是换了 SQLAlchemy，但 SQLAlchemy 的 ORM 学习曲线不低，配置也繁琐；再后来听说 Tortoise-ORM 写法简洁，异步原生支持，想试试，结果发现它是为 FastAPI、Sanic 这类异步 Web 框架设计的，和 Tkinter 这种同步事件循环的框架放在一起，asyncio 的事件循环怎么跑起来，是个让很多人卡住的问题。

这个组合其实非常有价值——Tortoise-ORM 的模型定义简洁，迁移机制清晰，查询语法直观；SQLite 零配置、单文件、无需服务器；Tkinter 轻量、无依赖、跨平台。三者结合，非常适合工控上位机、数据采集工具、本地管理系统这类场景。

本文直接解决"Tkinter + Tortoise-ORM 怎么在一起跑"这个核心问题，给出三个渐进式方案：从最简单的异步桥接跑通基础 CRUD，到带连接池管理的完整应用架构，最后到一个可直接复用的设备数据记录系统完整示例。所有代码在 Windows 11 + Python 3.11 + tortoise-orm 0.21.x + customtkinter 5.2.2 下实测通过。

---

🔍 问题深度剖析：两个事件循环的冲突

要理解这个问题的根源，得先搞清楚 Tkinter 和 Tortoise-ORM 各自的运行机制。

Tkinter 的 mainloop() 是一个同步的事件循环，它在主线程里不断轮询 GUI 事件队列，处理用户操作和界面刷新。这个循环是阻塞的，只要它在跑，主线程就被它占着。

Tortoise-ORM 是基于 asyncio 的异步 ORM，所有数据库操作都是协程，必须在 asyncio 事件循环里执行。标准用法是 asyncio.run(main()) 或者在 FastAPI 的异步上下文里自然运行。

问题来了：Tkinter 的同步事件循环和 asyncio 的异步事件循环，本质上都是"独占主线程的死循环"，两个死循环没办法直接共存在同一个线程里。

很多人第一反应是在按钮回调里直接 asyncio.run(some_query())，这会每次都创建一个新的事件循环，Tortoise-ORM 的连接池状态无法在多次调用间共享，而且频繁创建销毁事件循环有明显性能开销。在实测中，这种写法每次数据库操作的开销比正确方案高 5~15 倍（Windows 11, Python 3.11, SSD 环境，1000 次单条查询对比）。

正确的解法是：把 asyncio 事件循环放在一个独立的后台线程里持续运行，Tkinter 的回调通过 asyncio.run_coroutine_threadsafe() 把协程提交给这个后台循环执行，结果通过 Future 或队列同步回主线程。

---

💡 核心要点提炼

后台事件循环的生命周期管理是关键。 asyncio 循环需要在应用启动时初始化，在应用退出时优雅关闭（包括关闭 Tortoise-ORM 的连接）。如果退出时不做清理，SQLite 文件可能留下未提交的事务或锁。

run_coroutine_threadsafe 返回的是 concurrent.futures.Future，不是 asyncio 的 Future。 这两个东西虽然名字像，但用法不同。concurrent.futures.Future 可以在任意线程里调用 .result() 阻塞等待，也可以通过 .add_done_callback() 注册回调——后者是推荐做法，因为阻塞等待会卡住 Tkinter 主线程。

Tortoise-ORM 的模型定义和初始化要分离。 模型类的定义是纯 Python 类，不依赖事件循环；Tortoise.init() 和 generate_schemas() 才需要在异步上下文里执行。把这两件事混在一起，初始化逻辑会变得很难测试。

数据库操作结果回到 Tkinter 主线程要用 after(0, callback)。 add_done_callback 的回调是在 asyncio 线程里执行的，不能直接操作 Tkinter 组件。正确做法是在回调里调用 root.after(0, lambda: update_ui(result))，把 UI 更新调度回主线程。

---

🛠️ 方案一：最小可运行的异步桥接方案

先把核心机制跑通，不追求完整功能，只验证"Tkinter 按钮触发 Tortoise-ORM 查询"这条链路。

python
import asyncio  
import threading  
import random  
import time  
import customtkinter as ctk  
from tortoise import Tortoise, fields  
from tortoise.models import Model  
from tortoise.context import TortoiseContext  
  
ctk.set_appearance_mode("dark")  
ctk.set_default_color_theme("blue")  
  
  
class Record(Model):  
    id = fields.IntField(pk=True)  
    name = fields.CharField(max_length=100)  
    value = fields.FloatField(default=0.0)  
    created_at = fields.DatetimeField(auto_now_add=True)  
  
    class Meta:  
        table = "records"  
  
  
class AsyncBridge:  
    """  
    所有协程在同一个 TortoiseContext 内的 worker 协程中串行执行，  
    彻底避免跨 Context 的配置丢失问题。  
    """  
    def __init__(self):  
        self._loop = asyncio.new_event_loop()  
        self._queue: asyncio.Queue | None = None  
        self._started = threading.Event()  
  
        self._thread = threading.Thread(  
            target=self._run_loop, daemon=True, name="AsyncLoop"  
        )  
        self._thread.start()  
        self._started.wait()  # 等待事件循环就绪  
  
    def _run_loop(self):  
        asyncio.set_event_loop(self._loop)  
        # 启动常驻 worker        self._loop.run_until_complete(self._bootstrap())  
  
    async def _bootstrap(self):  
        self._queue = asyncio.Queue()  
        self._started.set()           # 通知主线程可以开始提交任务  
        await self._worker()          # 永久阻塞在此，直到收到 None 哨兵  
  
    async def _worker(self):  
        """在 TortoiseContext 内永久运行，消费任务队列"""  
        async with TortoiseContext():  
            while True:  
                item = await self._queue.get()  
                if item is None:      # 关闭哨兵  
                    break  
                coro, future = item  
                try:  
                    result = await coro  
                    future.set_result(result)  
                except Exception as e:  
                    future.set_exception(e)  
  
    def submit(self, coro) -> asyncio.Future:  
        """把协程投入队列，返回 asyncio.Future"""        future = self._loop.create_future()  
        self._loop.call_soon_threadsafe(  
            self._queue.put_nowait, (coro, future)  
        )  
        return asyncio.futures.wrap_future(future)  
  
    def submit_sync(self, coro):  
        """阻塞等待结果，仅用于初始化阶段"""  
        future = self._loop.create_future()  
        self._loop.call_soon_threadsafe(  
            self._queue.put_nowait, (coro, future)  
        )  
        # 用 concurrent.futures 包装以便在普通线程中 .result()        import concurrent.futures  
        cf = concurrent.futures.Future()  
  
        def _transfer(f):  
            if f.cancelled():  
                cf.cancel()  
            elif f.exception():  
                cf.set_exception(f.exception())  
            else:  
                cf.set_result(f.result())  
  
        self._loop.call_soon_threadsafe(future.add_done_callback, _transfer)  
        return cf.result()  
  
    def shutdown(self):  
        """发送哨兵让 worker 退出，然后停止事件循环"""  
        self._loop.call_soon_threadsafe(self._queue.put_nowait, None)  
        self._thread.join(timeout=5)  
  
  
#  数据库初始化（在 worker 的 TortoiseContext 内执行）  
async def init_db():  
    await Tortoise.init(  
        db_url="sqlite://./demo.db",  
        modules={"models": ["__main__"]},  
    )  
    await Tortoise.generate_schemas(safe=True)  
    if await Record.all().count() == 0:  
        await Record.create(name="温度传感器A", value=25.6)  
        await Record.create(name="压力传感器B", value=101.3)  
        await Record.create(name="流量计C", value=3.7)  
  
  
#  主应用 class App(ctk.CTk):  
    def __init__(self, bridge: AsyncBridge):  
        super().__init__()  
        self.bridge = bridge  
        self.title("Tortoise-ORM + Tkinter 演示")  
        self.geometry("520x380")  
        self._build_ui()  
        self._load_records()  
  
    def _build_ui(self):  
        ctk.CTkLabel(  
            self, text="设备记录列表",  
            font=("Microsoft YaHei", 15, "bold")  
        ).pack(pady=(16, 8))  
  
        self.textbox = ctk.CTkTextbox(self, font=("Consolas", 12), state="disabled")  
        self.textbox.pack(fill="both", expand=True, padx=20, pady=(0, 8))  
  
        btn_frame = ctk.CTkFrame(self, fg_color="transparent")  
        btn_frame.pack(pady=8)  
  
        ctk.CTkButton(btn_frame, text="刷新列表",  
                      command=self._load_records).pack(side="left", padx=8)  
        ctk.CTkButton(btn_frame, text="新增记录",  
                      command=self._add_record).pack(side="left", padx=8)  
  
        self.status = ctk.CTkLabel(  
            self, text="就绪",  
            font=("Microsoft YaHei", 11), text_color="#95A5A6"  
        )  
        self.status.pack(pady=4)  
  
    def _load_records(self):  
        self.status.configure(text="查询中...", text_color="#3498DB")  
  
        async def do_query():  
            return await Record.all().order_by("-id")  
  
        future = self.bridge.submit(do_query())  
  
        def on_done(f):  
            try:  
                records = f.result()  
                self.after(0, lambda: self._update_list(records))  
            except Exception as e:  
                msg = str(e)  
                self.after(0, lambda: self.status.configure(  
                    text=f"查询失败：{msg}", text_color="#E74C3C"  
                ))  
  
        future.add_done_callback(on_done)  
  
    def _update_list(self, records):  
        self.textbox.configure(state="normal")  
        self.textbox.delete("1.0", "end")  
        for r in records:  
            self.textbox.insert(  
                "end", f"[{r.id:>3}] {r.name:<20} {r.value:>8.2f}\n"  
            )  
        self.textbox.configure(state="disabled")  
        self.status.configure(  
            text=f"共 {len(records)} 条记录", text_color="#2ECC71"  
        )  
  
    def _add_record(self):  
        async def do_add():  
            names = ["加速度计", "陀螺仪", "磁力计", "超声波传感器", "红外测距"]  
            name = random.choice(names) + f"_{int(time.time()) % 1000}"  
            value = round(random.uniform(0.1, 999.9), 2)  
            return await Record.create(name=name, value=value)  
  
        future = self.bridge.submit(do_add())  
  
        def on_done(f):  
            try:  
                record = f.result()  
                rec_name = record.name  
                self.after(0, lambda: (  
                    self.status.configure(  
                        text=f"已新增：{rec_name}", text_color="#2ECC71"  
                    ),  
                    self._load_records()  
                ))  
            except Exception as e:  
                msg = str(e)  
                self.after(0, lambda: self.status.configure(  
                    text=f"新增失败：{msg}", text_color="#E74C3C"  
                ))  
  
        future.add_done_callback(on_done)  
  
    def on_close(self):  
        self.bridge.shutdown()  
        self.destroy()  
  
  
if __name__ == "__main__":  
    bridge = AsyncBridge()  
    bridge.submit_sync(init_db())   
  
    app = App(bridge)  
    app.protocol("WM_DELETE_WINDOW", app.on_close)  
    app.mainloop()

这个方案把核心机制展示得很清楚：AsyncBridge 是整个方案的枢纽，submit() 负责跨线程提交协程，add_done_callback + after(0, ...) 负责把结果安全地送回 Tkinter 主线程。

踩坑预警： on_done 回调里的 lambda 要特别注意闭包捕获问题。lambda: self._update_list(records) 里的 records 是立即绑定的，没问题；但如果在循环里生成多个回调，要用默认参数 lambda r=records: ... 的方式固定绑定，否则所有回调会共享同一个变量的最终值。

🤔 你有没有遇到过这种情况？

做一个动态展示标签的面板，手动计算每个控件的 Left、Top，写了一堆坐标赋值代码。结果需求一改，控件数量变了，整个布局全乱套，又得重新算一遍。

这不是个例。在 Winform 开发里，手动管理控件坐标是一个长期存在的痛点。稍微复杂一点的动态界面，维护成本会以指数级上升。

实际上，Winform 早就内置了一个专门解决这类问题的容器控件：FlowLayoutPanel。它能让控件像水流一样自动排列，无需手动计算位置。遗憾的是，很多开发者要么不知道它，要么只是浅尝即止，没有真正用好它。

读完这篇文章，你将掌握：

• FlowLayoutPanel 的核心机制与布局原理
• 3 个从简单到复杂的渐进式实战方案
• 动态增删控件、响应式换行、自定义间距等关键技巧
• 性能优化手段，避免大量控件时的界面卡顿

---

🔍 问题深度剖析：手动布局的真实代价

先来看一段典型的"传统写法"：

csharp
int x = 10, y = 10;
foreach (var tag in tagList)
{
    var btn = new Button();
    btn.Text = tag;
    btn.Location = new Point(x, y);
    btn.Size = new Size(80, 30);
    panel.Controls.Add(btn);
    x += 90;
    if (x > panel.Width - 90)
    {
        x = 10;
        y += 40;
    }
}

这段代码看起来没什么问题，但实际项目中会暴露出几个隐患：

换行逻辑与业务逻辑耦合。一旦 panel.Width 变化（比如窗口可以拉伸），换行计算就会出错，需要额外监听 Resize 事件重新排列，代码量翻倍。

控件尺寸不一致时直接崩溃。标签文字长短不同，按钮宽度各异，固定步长 x += 90 会导致重叠或间距不均。

动态增删极其麻烦。删除中间某个控件后，后续所有控件的坐标都要重新计算，几乎等于重写。

这些问题的根源在于：手动布局把"控件排列逻辑"和"业务数据逻辑"混在了一起，职责不清，维护困难。

---

💡 核心原理：FlowLayoutPanel 是怎么工作的

FlowLayoutPanel 继承自 Panel，它的核心能力是自动流式排列子控件。你只需要往里面 Add 控件，它会按照设定的方向自动排列，空间不足时自动换行（或换列）。

几个关键属性需要理解透彻：

FlowDirection：控制流向，有四个选项——LeftToRight（默认，从左到右）、RightToLeft、TopDown、BottomUp。日常用得最多的是 LeftToRight。

WrapContents：是否自动换行。默认为 true，空间不够时自动折行。设为 false 则所有控件排成一行，超出部分被裁剪。

AutoScroll：当内容超出容器大小时是否显示滚动条。动态内容较多时通常开启。

子控件的 Margin 属性：这是很多人忽略的关键点。FlowLayoutPanel 里控件之间的间距不是由容器控制的，而是由每个子控件自身的 Margin 决定的。想调整间距，要改子控件的 Margin，而不是找容器属性。

---

跨平台 UI 的"最后一块拼图"，很多人还没搞清楚它的底层

在 .NET 生态里，跨平台桌面开发这条路走了很多年，WinForms 太老，WPF 绑死 Windows，MAUI 在桌面端又差点意思。直到 Avalonia 出现，很多 C# 开发者才真正松了口气。但用了一段时间之后，不少人开始遇到一些让人头疼的问题：自定义控件渲染出现撕裂、动画在某些平台卡顿、样式系统行为和预期不符……

这些问题的根源，几乎都指向同一个地方——对 Avalonia 底层架构和渲染引擎的理解不够深。

本文不打算重复官方文档里那些入门级的介绍，而是从架构分层、渲染管线、合成器机制三个维度，把 Avalonia 的"内脏"拆开来看清楚。读完之后，你会掌握：

• Avalonia 的分层架构设计思路，以及为什么它能真正做到跨平台
• 渲染管线的完整流程，从 Visual Tree 到像素输出
• 合成器（Compositor）的工作原理，以及如何利用它做性能优化

---

🏗️ 一、架构分层：不是"套壳"，是真正的平台抽象

很多人第一次看 Avalonia 的架构图，会觉得它和 WPF 很像——毕竟连 XAML 语法都差不多。但这两者在架构理念上有一个本质区别：WPF 的渲染依赖 DirectX，是 Windows 专属的；而 Avalonia 从设计之初就把平台相关的部分彻底隔离出去了。

Avalonia 的整体架构可以分为四层：

第一层：平台抽象层（Platform Abstraction Layer）

这一层负责和操作系统打交道，包括窗口创建、输入事件、文件系统访问等。不同平台有不同的实现：Windows 用 Win32 API，macOS 用 Cocoa，Linux 用 X11 或 Wayland，还有 iOS、Android 和 WebAssembly 的实现。这一层对上层完全透明，上层代码感知不到自己跑在哪个平台上。

第二层：渲染后端层（Rendering Backend）

这是 Avalonia 架构里最有意思的一层。它支持多种渲染后端：Skia（默认，基于 Google 的 Skia 图形库）、Direct2D（Windows 专属优化）、以及实验性的 Vulkan/Metal 后端。渲染后端只负责"把图形指令转化为像素"，不参与任何 UI 逻辑。

第三层：合成器层（Compositor）

这是 Avalonia 11 之后引入的重大架构升级，后面会重点讲。简单说，它负责管理渲染树（Render Tree）和 UI 树（Visual Tree）的同步，以及处理动画、变换、透明度等合成操作。

第四层：UI 框架层

这才是开发者日常打交道的部分：控件系统、布局引擎、样式系统、数据绑定、XAML 解析等。

┌─────────────────────────────────────┐
│         UI Framework Layer          │  ← 控件、布局、样式、绑定
├─────────────────────────────────────┤
│          Compositor Layer           │  ← 合成、动画、变换
├─────────────────────────────────────┤
│       Rendering Backend Layer       │  ← Skia / Direct2D / Vulkan
├─────────────────────────────────────┤
│    Platform Abstraction Layer       │  ← Win32 / Cocoa / X11 / Wayland
└─────────────────────────────────────┘

这种分层设计的好处是显而易见的：每一层只依赖下一层的抽象接口，而不依赖具体实现。这意味着你可以在不改动任何 UI 代码的情况下，切换渲染后端，或者把整个应用移植到新平台。

---

🌳 二、Visual Tree 与 Logical Tree：两棵树，各司其职

理解 Avalonia 的渲染机制，绕不开两个核心概念：Visual Tree（视觉树） 和 Logical Tree（逻辑树）。

逻辑树描述的是控件之间的父子关系，是开发者在 XAML 里定义的那个结构。视觉树则是控件展开模板之后的完整结构，包含了所有用于渲染的视觉元素。

举个例子，一个 Button 在逻辑树里就是一个节点，但在视觉树里，它会展开成 Border + ContentPresenter + 内部文本等多个节点。

csharp
using Avalonia;
using Avalonia.Controls;
using Avalonia.VisualTree;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace AppFirstAvalonia.Views
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            // 更好的做法是在窗口加载完成后再遍历
            this.Loaded += OnWindowLoaded;
        }

        private void OnWindowLoaded(object? sender, Avalonia.Interactivity.RoutedEventArgs e)
        {
            // 现在视觉树已经完全构建，可以安全地遍历
            DebugVisualTree(this);

            // 如果需要获取所有后代，可以这样做
            var descendants = GetVisualDescendants(this).ToList();
            Debug.WriteLine($"Total descendants found: {descendants.Count}");
        }

        // 遍历 Visual Tree 的示例
        public static IEnumerable<Visual> GetVisualDescendants(Visual root)
        {
            foreach (var child in root.GetVisualChildren())
            {
                yield return child;
                Debug.WriteLine($"Found descendant: {child.GetType().Name}");

                // 递归获取所有后代
                foreach (var descendant in GetVisualDescendants(child))
                {
                    yield return descendant;
                }
            }
        }

        // 调试视觉树的方法
        public void DebugVisualTree(Visual? root, int depth = 0)
        {
            if (root == null) return;

            var indent = new string(' ', depth * 2);
            Debug.WriteLine($"{indent}{root.GetType().Name} " +
                          $"Bounds: {root.Bounds}, " +
                          $"IsVisible: {root.IsVisible}");

            foreach (var child in root.GetVisualChildren())
            {
                DebugVisualTree(child, depth + 1);
            }
        }
    }
}

为什么要区分这两棵树？ 因为它们服务于不同的目的。逻辑树用于数据绑定的上下文传播、样式继承、事件路由；视觉树用于布局计算和渲染。把这两个关注点分开，让框架在处理复杂控件模板时更加灵活。

🤔 你的桌面应用，用起来顺手吗？

做了好几年 Python 桌面开发，我发现一个很有意思的现象——很多开发者花了大量时间把核心功能做得漂漂亮亮，却在"菜单"这种基础交互上敷衍了事。要么就是一个光秃秃的窗口，要么菜单做了但快捷键一个没有，用户每次都得拿鼠标去点点点。

说实话，这挺影响体验的。

一个专业的桌面应用，菜单栏、工具条、快捷键这三件套缺一不可。它们不只是"好看"的问题，而是直接决定用户操作效率的核心要素。今天咱们就用 CustomTkinter，把这三件事一次性讲透——从基础搭建到实战技巧，附完整可运行代码。

---

🧱 先把基础搞清楚：CTk 的菜单到底怎么回事

CustomTkinter（以下简称 CTk）本身并没有内置一套独立的菜单组件。它的菜单栏实际上是借用了 tkinter 原生的 Menu 组件，然后通过 configure(menu=...) 挂载到 CTk 窗口上。

这一点很多人踩过坑——以为 CTk 有自己的菜单，结果找半天找不到，最后才发现要用 tk.Menu。

别担心，这不是缺陷，而是设计取舍。 CTk 的强项在于现代化的控件风格，菜单这种系统级 UI 元素，交给原生 tkinter 处理反而更稳定，跨平台兼容性也更好。

先来一个最简单的菜单骨架：

python
import customtkinter as ctk
import tkinter as tk

ctk.set_appearance_mode("dark")
ctk.set_default_color_theme("blue")

class App(ctk.CTk):
    def __init__(self):
        super().__init__()
        self.title("菜单演示")
        self.geometry("800x600")
        
        # 创建菜单栏
        self._build_menubar()
    
    def _build_menubar(self):
        menubar = tk.Menu(self)
        
        # 文件菜单
        file_menu = tk.Menu(menubar, tearoff=0)
        file_menu.add_command(label="新建", command=self.on_new)
        file_menu.add_command(label="打开", command=self.on_open)
        file_menu.add_separator()
        file_menu.add_command(label="退出", command=self.quit)
        menubar.add_cascade(label="文件", menu=file_menu)
        
        self.configure(menu=menubar)
    
    def on_new(self):
        print("新建文件")
    
    def on_open(self):
        print("打开文件")

if __name__ == "__main__":
    app = App()
    app.mainloop()

运行起来就能看到一个带"文件"菜单的窗口。tearoff=0 这个参数记得加上，不然菜单顶部会有一条虚线，点了之后菜单会"撕下来"变成独立窗口——这个行为在现代应用里基本上是不需要的。