正如 Matt 所指出的，这完全与堆叠顺序有关.堆叠顺序只是应用程序中小部件的z 坐标"—你可以把它想象成除了屏幕上的自然 x 和 y 坐标之外，还有另一个垂直于屏幕平面的轴.所有的小部件都沿着这个轴位于某个地方.您在屏幕上实际看到的图像是沿该轴将所有小部件展平"在一起的结果.小部件在 x 和 y 平面中重叠的任何地方，堆叠顺序中较高的小部件就是您在该位置看到的.

It's all to do with stacking order, as Matt noted. Stacking order is just the "z-coordinate" for widgets in your app — you can think of it as if in addition to the natural x and y coordinates you have on the screen, there is another axis that is perpendicular to the plane of the screen. All the widgets lay somewhere along this axis. The image you actually see on screen is the result of "flattening" all the widgets together along that axis. Anywhere that widgets overlap in the x and y plane, the widget that is higher in the stacking order is what you see at that location.

小部件在 Tk 中的默认堆叠顺序由它们的创建顺序决定.它创建的小部件越早，它在堆叠顺序中的位置就越低 —想想屏幕本身在 z 坐标零处，随着越来越多的值从屏幕向您传来.创建的第一个小部件的堆叠顺序为零，第二个为一个，依此类推

The default stacking order of widgets in Tk is determined by their creation order. The earlier the widget it created, the lower it is in the stacking order — think of the screen itself being at z-coordinate zero, with increasing values coming towards you from the screen. The first widget created has stacking order zero, the second has one, etc.

解决您的问题最简单的方法就是按正确的顺序创建小部件，但是如果您对按照显示的顺序创建小部件一无所知，您可以稍后手动更改堆叠顺序，以确保小部件按您想要的顺序堆叠.例如，要将您的蓝框再次置于顶部，您可以添加:

The easiest solution to your problem is just to create the widgets in the right order, but if you are dead set on creating the widgets in the order you've shown, you can manually change the stacking order later, to ensure the widgets are stacked in the order you want. For example, to bring your blue frame to the top again, you could add:

raise .top .root

这告诉 Tk 更改 .top 的堆叠顺序，使其位于 .root 的上方".

This tells Tk to change the stacking order of .top so that it is "above" .root.

当我使用窗格窗口小部件时，我倾向于让它管理子小部件—对我来说，它在概念上只是一个具有额外行为的框架，并且由于我使用框架将相关的小部件组合在一起，因此我以相同的方式使用窗格窗口.此策略还巧妙地回避了堆叠顺序的问题，因为它要求您首先创建窗格窗口 —您必须这样做，因为在创建小部件本身之前，您无法创建小部件的子部件.因此，我会像这样修改您的示例:

When I use the paned window widget, I tend to have it manage child widgets — to me, it is conceptually just a frame with extra behaviors, and since I use frames to group related widgets together, I use the paned window the same way. This policy also neatly sidesteps the question of stacking order since it requires that you have created the paned window first — you must, because you can't create children of a widget until the widget itself is created. Thus I would modify your example like this:

panedwindow .root -orient vertical -showhandle true -background red
frame .root.top -background blue -width 100 -height 100
frame .root.bot -background green -width 100 -height 100
.root add .root.top .root.bot

对我来说，这使得 .root 和 .root.top 和 .root.bot 之间的关系变得清晰:两个框架是内部"窗格窗口.自然的堆叠顺序恰好是正确的，每个人都很高兴.

To me, this makes the relationship between .root and .root.top and .root.bot clear: the two frame are "inside" the paned window. The natural stacking order happens to be the correct one, and everybody is happy.