企业官网建设流程全解析

ToolBar 是 WPF 里最容易被人“小看”的控件之一。从表面上理解，它就是一行放按钮的容器，往里塞几个“保存”“打开”就完事。但实际用起来你会发现，它牵扯到 ToolBarTray 布局、溢出菜单、命令绑定、焦点样式、模板重写一大堆东西。尤其是你把工具栏放进 MVVM 项目里之后，稍不留神就会出现按钮灰着点不动、溢出箭头消失、样式跟系统皮肤冲突这类问题。我整理了这几年做 WPF 客户端项目时用 ToolBar 系列控件的经验，这段内容会从设计思路一直讲到具体 XAML 写法和踩坑记录，适合正在做桌面客户端界面、想把工具栏做规矩的开发者参考。

1. 整体设计与思路拆解

记得 2021 年 8 月我那时候接到一个维护老桌面项目的活儿，界面里跑着一个由几十个 Button 拼起来的“伪工具栏”：横向 StackPanel 放图标按钮，代码里用 Click 事件一个个订阅，窗口拉窄了按钮直接挤到屏幕外，没有任何折行或者收纳策略。这种方案在原型阶段是快的，但到后期维护就变成一场灾难。后来我决定全部换成 WPF 原生的 ToolBar 控件，连同 ToolBarTray 一起重构，才算把这块彻底理顺。

这里先讲清楚一个容易被忽略的设计事实：ToolBar 并不等于“一行按钮”，它是 WPF 为“可收纳、可定制工具栏”这种交互模式专门准备的一族容器控件。这套东西的核心其实分成两层。

ToolBarTray 是最外层的布局容器。它管的不是单个按钮，而是多个 ToolBar 之间的关系：允许用户拖拽排列、多个工具栏纵向堆叠、横向排布时自动分配空间。简单理解，它就是工具栏的“大盘子”，把几组工具栏装在一起，并且给这些工具栏提供拖拽和停靠的基础能力。

ToolBar 本身才是你放按钮的地方。它内部有一套自己的布局机制，其中最重要的一点是溢出处理：当可用宽度不够时，ToolBar 会自动把放不下的元素收纳到一个带箭头的“溢出菜单”里。这个行为很多新手不知道，结果一看工具栏空了就以为是样式崩了，其实只是默认收纳策略在起作用。

为什么要用这么一套组合，而不是直接手写 Grid 或者 StackPanel？我个人理解是，桌面应用工具栏天生要面对窗口缩放、屏幕分辨率差异、用户自定义习惯这几类需求。原生 ToolBar 把这些最常用的交互规则内置好，开发者就不用从零写拖拽排序逻辑，也不需要在按钮宽高和窗口宽度之间硬编码一堆判断。对熟悉这套机制的开发者来说，效率和稳定性都会好很多。

1.1 为什么选 ToolBar 而不是手动布局

手动组合按钮的最直接问题有三个。

第一，没有统一命令通道。纯 Click 事件很容易让业务逻辑和界面耦合。工具按钮的标准做法是让它们的启用/禁用随业务状态自动切换，这就是 WPF 命令系统擅长的领域。ToolBar 里的 Button 天然支持 Command 绑定，配合 CanExecute 就能自动更新按钮状态，不用自己写一堆 Enable/Disable 的赋值。

第二，没有溢出策略。窗口变窄的时候，StackPanel 里的按钮要么被裁掉要么被压缩变形。ToolBar 的内置溢出机制会把这些按钮移动到下拉区域，至少用户还能用功能，而不是看着图标被截断。

第三，没有用户可定制性。用 ToolBarTray 包一层之后，用户可以在运行期拖拽工具栏到不同位置（通过设置 IsLocked 来开关），这几乎零成本就实现了。自己写拖拽布局，要处理鼠标捕获、位置计算、重绘逻辑，调试起来很费精力。

1.2 ToolBarTray 与 ToolBar 的分工

我习惯把 ToolBarTray 类比成一个“总控面板”，把 ToolBar 类比成“面板上的每一个工具条”。ToolBarTray 的职责大体是三个：

• 管理子工具栏的停靠与拖拽；
• 让工具条之间共享水平/垂直布局策略；
• 通过 IsLocked 属性统一决定全部子项能否被拖动。

ToolBar 自己的职责则更聚焦：管理内部元素布局、处理溢出收纳、提供命令路由、维护键盘导航。简单来说，Tray 管“条”的位置，ToolBar 管“条”内部的内容。

1.3 适用场景边界

并不是所有界面都应该用 ToolBar。如果是主窗口的全局操作区，而且按钮数量固定不超过三五个、窗口也不允许缩放，直接用 StackPanel+Button 反而更省事。ToolBar 适合的典型场景是这些：

• 文档编辑器或设计工具，功能按钮多且分组明确；
• 界面宽度会动态变化，需要自动收纳；
• 希望允许用户自行调整工具栏布局的桌面应用；
• 按钮状态与 ViewModel 命令强绑定，需要自动启用/禁用。

反过来，如果你的“工具栏”其实是全局导航菜单，点击之后要切换页面，那应该考虑 TabControl、Menu、NavigationView 这类更语义化的控件，而不是硬塞 ToolBar。

2. 核心细节解析与实操要点

刚开始接触 ToolBar 的人，最容易困惑的是它里面能放什么元素、不能放什么元素。这里先给一个简单结论：ToolBar 内部直接放 UIElement 都可以，但它对部分控件有默认样式和交互的特殊处理。尤其是 Button、Separator、ToggleButton、ComboBox、Menu 这几类，在 ToolBar 内部的外观和行为与放在普通 Grid 里明显不同。这不是 WPF 随机变化，而是 ToolBar 的资源覆盖效果。

在 XAML 里，ToolBar 内部其实维护了一个自定义的 ItemsControl 行为，同时会为内部元素套上一套面向工具栏场景的默认模板和主题样式。所以你随手拖一个 Button 进来，发现它变成了扁平的、悬停高亮风格，这是正常的，它被系统主题里专门给 ToolBar 内元素准备的那套样式接管了。

2.1 关键属性与常用配置

先看我平时最常用的几个属性。

IsCollapsed 是 ToolBar 自身的属性。默认值为 False 时，ToolBar 占满可用宽度；如果设置为 True，则 ToolBar 的宽度仅够显示溢出按钮。这通常用于实现那种可以“折叠成一个小竖条”的侧边工具栏。需要注意，IsCollapsed 是指 ToolBar 在 Tray 中的显示宽度状态，不是隐藏整个工具条，不该和 Visibility 混淆。

Band 与 BandIndex 是 ToolBarTray 上的布局属性，分别指定子 ToolBar 停靠在第几行（或列）以及行内的顺序。不写这两个属性时，Tray 会按声明顺序自动排布。不过一旦某个 ToolBar 设置了 Band，显示位置就可能和 XAML 里的视觉顺序不一致，排查布局时先看这两个值。

OverflowMode 是放在 ToolBar 内部元素上的附加属性。Three 取值：Always（始终放到溢出区）、Never（始终放在主区域）、AsNeeded（空间不足才收纳）。定制工具栏行为时用得最多的是 Always 和 Never。比如打印按钮使用频率低，但又不希望它被收起来找不到，可以保持 AsNeeded 默认行为；某个业务上不允许被隐藏的核心按钮，则设置 OverflowMode="Never"。

IsOverflowOpen 是只读属性还是可写属性要分情况。ToolBar 自身有个只读逻辑判断当前是否有溢出项，即 HasOverflowItems。而 IsOverflowOpen 可通过绑定或代码设置，用来控制溢出菜单当前是否展开。我在做自动化测试时曾通过绑定它来判断弹出区域的状态，实测可用，但要注意它依赖 ToolBar 的模板内部状态，最好不要在模板替换后依赖它做复杂逻辑。

2.2 内部元素的默认样式行为

ToolBar 内部的 Button、ToggleButton、CheckBox 等都会套用主题中的对应样式。这些样式与普通窗口中的按钮样式是分开的，分离机制叫 ToolBar 主题样式覆盖。所以在 ToolBar 里的 Button 设置了 Height、Width、Margin 这些属性时，表现会与普通场景有所差别。例如系统主题里 ToolBar 按钮默认是 25x25 左右的图标按钮，这时再写 Height="40" 很容易造成内容垂直居中怪异或者图标拉伸失真。

如果你不想让某个按钮使用 ToolBar 默认样式，有两个办法。一是设置该按钮的样式为独立样式，覆盖 TargetType；二是完全不使用 ToolBar 容器，改用普通容器。

2.3 分组与分隔

工具栏按钮通常需要按功能分组，“另存为”和“打开”放一起，“撤销”“重做”放一起。在 ToolBar 中分隔元素最自然的就是 Separator。它放在 ToolBar 内部时会显示为一条竖线，不需要额外样式。我用的时候一般直接在 XAML 里连续写几个 Separator，但想对分隔间距再收紧时，往往会重写 Separator 的样式，核心是设置 Template 为一个固定宽度的 Border，并用 Margin 控制与两边按钮的间距。

2.4 命令绑定与 MVVM

MVVM 模式下，ToolBar 内部的按钮应当使用 Command 属性绑定 ViewModel 中的命令对象。这可让 CanExecute 自动控制按钮启用状态。这里有个细节：ToolBar 在 Focus 管理上有点“特殊体质”，它自带焦点定位逻辑，即 Tab 键可以在工具栏按钮之间移动焦点，而且首次点击时会让按钮获得焦点并显示焦点矩形样式。这其实是 WPF 的 ToolBar 键盘交互模型，需要保留，不要为了好看强行去掉所有焦点样式，否则键盘用户会很难操作。

我在命令绑定时常用的示例是这样的：

<ToolBar Band="0" BandIndex="0"> <Button Command="{Binding OpenCommand}" ToolTip="打开文件"> <Image Source="/Assets/Icons/open.png" Width="16" Height="16"/> </Button> <Separator/> <Button Command="{Binding UndoCommand}" ToolTip="撤销"/> <Button Command="{Binding RedoCommand}" ToolTip="重做"/> </ToolBar>

这里 Command="{Binding OpenCommand}" 要求 DataContext 已经设置为对应的 ViewModel。我曾经见过把按钮 Image 放在 Content 里、把 Command 写在 Image 上的写法，那样命令永远绑定不到，按钮自然一直是灰色的。这个错误很常见，尤其从普通 Button 转到工具栏封装时容易犯。

2.5 溢出菜单里还能不能自定义样式

有经验的开发者通常会问：溢出菜单里的项长成什么样？

是的，它并非直接复用主区域按钮的样式，而是由 ToolBar 模板里那个 Overflow 区域的 ItemsControl 决定。默认情况下，溢出菜单中的每项像普通菜单项那样呈现，带图标和文字。如果你想自定义，可以在模板中替换 Overflow 区域的 Panel 和 ItemTemplate。但是直接改默认模板代价比较大，一般我建议优先使用 ToolBar 允许的内置方式：把溢出项设为 OverflowMode="Always"，然后在它们外面包一层 Menu 或者干脆自定义样式。这个方案在实践中更容易维护。

3. 实操过程与核心环节实现

理论说完，接下来重点复盘一次完整实践。模拟一个文档编辑器主界面的工具栏，上面要包含文件操作组、编辑操作组、视图切换组，还要支持运行期拖动工具栏和窗口窄化时的溢出收纳。顺带会演示 XAML 结构和对应的 ViewModel 绑定，很容易改成自己的项目。

3.1 搭建基础界面

先定义窗口布局。通常我把 ToolBarTray 放在窗口最上方，下面放内容区。以 Grid 为例：

<Grid> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> <ToolBarTray Grid.Row="0" IsLocked="False"> <ToolBar Band="0" BandIndex="0" Header="文件"> <Button Command="{Binding NewCommand}" ToolTip="新建"> <Image Source="pack://application:,,,/Assets/new.png" Width="16" Height="16"/> </Button> <Button Command="{Binding OpenCommand}" ToolTip="打开"> <Image Source="pack://application:,,,/Assets/open.png" Width="16" Height="16"/> </Button> <Button Command="{Binding SaveCommand}" ToolTip="保存" OverflowMode="Never"> <Image Source="pack://application:,,,/Assets/save.png" Width="16" Height="16"/> </Button> <Separator/> <Button Command="{Binding PrintCommand}" ToolTip="打印" OverflowMode="AsNeeded"> <Image Source="pack://application:,,,/Assets/print.png" Width="16" Height="16"/> </Button> </ToolBar> <ToolBar Band="1" BandIndex="0" Header="编辑"> <Button Command="{Binding UndoCommand}" ToolTip="撤销"> <Image Source="pack://application:,,,/Assets/undo.png" Width="16" Height="16"/> </Button> <Button Command="{Binding RedoCommand}" ToolTip="重做"> <Image Source="pack://application:,,,/Assets/redo.png" Width="16" Height="16"/> </Button> <Separator/> <Button Command="{Binding CutCommand}" ToolTip="剪切">剪切</Button> <Button Command="{Binding CopyCommand}" ToolTip="复制">复制</Button> <Button Command="{Binding PasteCommand}" ToolTip="粘贴">粘贴</Button> </ToolBar> <ToolBar Band="1" BandIndex="1" Header="视图"> <ToggleButton IsChecked="{Binding ShowGridLines}" ToolTip="显示网格线"> <Image Source="pack://application:,,,/Assets/grid.png" Width="16" Height="16"/> </ToggleButton> <Separator/> <CheckBox IsChecked="{Binding IsReadOnly}" Content="只读"/> </ToolBar> </ToolBarTray> <Border Grid.Row="1" Background="#FFF8F8F8"> <ContentControl Content="{Binding CurrentView}"/> </Border> </Grid>

这里有一个我后来觉得很重要的小技巧：为了让按钮同时显示图标和文字，可以在 Content 里放一个水平方向的 StackPanel，里面放 Image 和 TextBlock。ToolBar 的默认样式并不限制 Content 的形态，只是会把按钮整体压成紧凑模式。想要文字按钮和图标按钮混排，内容放什么决定了最终呈现，核心是控制好 StackPanel 的间距。

3.2 让工具栏支持拖拽

上面代码里 ToolBarTray 的 IsLocked 设置为 False，这正是允许拖拽的关键。运行后，用户可以把“文件”工具栏拖到另一行，或者把“视图”工具栏拖动到“文件”旁边。默认 ToolBarTray 允许多个 ToolBar 在同一 Band 内水平排列，Band 数值差决定上下布局。

拖拽时经常遇到两个小问题。一是拖拽后工具栏位置不理想，下次启动没有保存。ToolBarTray 本身不提供布局持久化，需要自己记录 Band、BandIndex，并做序列化保存。通常做法是监听 ToolBarTray 的 LayoutChanged 事件（这个事件存在，但触发条件是子 ToolBar 位置发生变化），把每个 ToolBar 的 Band 和 BandIndex 存入配置文件。我没有为它写过复杂的执行逻辑，因为大多数项目只需要保存字符串数组即可，但如果你要做，建议在窗口 Closing 时读取这些值并保存。

第二个问题是运行时拖拽和固定并存。有些工具栏应该固定，比如“文件”工具栏不允许移动。这时不能直接设置 ToolBarTray.IsLocked=True，因为那会锁住所有子工具栏。替代方案是把需要固定的那个 ToolBar 从 ToolBarTray 中拿走，放在 DockPanel 或 Grid 里。ToolBar 不是必须放在 Tray 里才能用，它能单独放，只是没有拖拽和排列能力。可以接受的情况下，这是最简单的固定方案。

3.3 命令对象与 CanExecute 控制

上面的 XAML 用了一堆命令绑定，背后 ViewModel 里的命令对象自然要定义好。我这里用常见的 ViewModel 结构举个例子，关键是把 CanExecute 做扎实。

public class MainViewModel : INotifyPropertyChanged { public DelegateCommand OpenCommand { get; } public DelegateCommand SaveCommand { get; } public DelegateCommand UndoCommand { get; } private bool _isDirty; public bool IsDirty { get => _isDirty; set { _isDirty = value; SaveCommand.RaiseCanExecuteChanged(); } } public MainViewModel() { OpenCommand = new DelegateCommand(OpenFile, CanOpenFile); SaveCommand = new DelegateCommand(SaveFile, () => IsDirty); // ... } private bool CanOpenFile() => true; private void OpenFile() { // 打开文件逻辑 } }

这种 DelegateCommand 的 RaiseCanExecuteChanged 在属性变更时调用，按钮就会自动更新为可用/不可用状态。这个机制里最容易被忽略的是：并非直接给 Command 的 CanExecute 写死布尔值就完了，CanExecute 必须在相关业务状态变化后主动抛出改变通知。我用过几个第三方 MVVM 框架，但核心原理都是同一个：命令改变执行条件时，要让 WPF 重新查询 CanExecute。

如果想进一步优化性能，可以在按钮很密集时用 CommandManager。RequerySuggested 事件会让 WPF 在键盘焦点切换等时机自动重新查询所有命令，但它查得很频繁，有时会带来无谓开销。我的习惯是少量命令直接用框架自带的 RaiseCanExecuteChanged，大量命令时才考虑手动封装。

3.4 强调一点：ToolBar 内的按钮焦点样式

第一次把普通 Button 放进 ToolBar 后，通常会被它那个淡淡的焦点外框吓到。这不是 bug，这是 WPF 默认导航样式的一部分。键盘用户通过 Tab 进入工具栏时，需要知道当前焦点在哪，所以它会显示一圈焦点视觉。如果产品经理要求完全去掉这些，也不是不行，但代价是键盘可访问性下降。我的建议是保留，或者按照自己产品的焦点风格做一个更美观的 FocusVisualStyle。而且这个也能通过全局定义统一：

<Style TargetType="Button"> <Setter Property="FocusVisualStyle" Value="{StaticResource NewFocusVisual}"/> </Style>

注意这里的全局样式会覆盖 ToolBar 内 Button 的默认样式吗？要看资源作用域。如果定义为窗口级资源，则优先影响窗口内部所有 Button；ToolBar 主题样式优先级更高，它的默认样式里面定义了 Template 和部分属性，FocusVisualStyle 是独立属性，所以可以正常覆盖。只是要确认新样式同样能被模板应用，否则样式可能不生效。实践中可以先验证 ToolBar 对外观的实际影响，再针对性地写样式。

3.5 样式与资源定制

ToolBar 默认外观在 Windows 不同主题下表现不太一样。如果你需要统一深色主题，最简单的做法是直接在 Application 资源里重写 ToolBar 和 ToolBarTray 的默认样式。千万不要在每一个窗口里重复写一大段相同的样式，那样后期改起来会非常痛苦。

一段比较精简的自定义样式可以这样写：

<Style TargetType="ToolBar"> <Setter Property="Background" Value="#FF2D2D30"/> <Setter Property="Foreground" Value="#FFF0F0F0"/> <Setter Property="BorderThickness" Value="0"/> <Setter Property="Template"> <Setter.Value> <ControlTemplate TargetType="ToolBar"> <Border Background="{TemplateBinding Background}" Padding="2"> <DockPanel> <ToggleButton x:Name="OverflowButton" DockPanel.Dock="Right" Visibility="{TemplateBinding HasOverflowItems, Converter={StaticResource BoolToVisibilityConverter}}" ClickMode="Press"/> <ItemsPresenter/> </DockPanel> </Border> </ControlTemplate> </Setter.Value> </Setter> </Style>

直接手写 ControlTemplate 时，有几个坑需要注意：

• 必须保留名为 OverflowButton 的 ToggleButton，即使视觉上不显示，因为 ToolBar 通过它来控制溢出菜单的开关；
• ItemsPresenter 不能少，否则 ToolBar 内容不渲染；
• 一旦替换 Template，系统内置的溢出容器以及 ToolBar 的键盘导航可能变得不一致，需要多测 Tab 键和箭头键。

如果你不想手写这么长的样式，也可以基于默认样式复制出来改。在 Visual Studio 或 Blend 中可以右键控件选择“编辑模板”，把默认模板拷贝到 XAML 里慢慢改。这个方式适合想快速做出自定义外观却不想从零摸索按钮状态样式的场景。

3.6 动态生成 ToolBar 按钮

某些项目的数据来自后台权限配置，需要在运行期动态生成工具栏。这种情况下我一般不在 XAML 里写死按钮，而是把 ToolBar 的 ItemsSource 绑定到一个模型集合：

public class ToolItemViewModel { public string Title { get; set; } public string IconPath { get; set; } public ICommand Command { get; set; } }

然后设置 ToolBar 的 ItemTemplate：

<ToolBar ItemsSource="{Binding ToolItems}"> <ToolBar.ItemTemplate> <DataTemplate> <Button Command="{Binding Command}" ToolTip="{Binding Title}"> <StackPanel Orientation="Horizontal"> <Image Source="{Binding IconPath}" Width="16" Height="16"/> <TextBlock Text="{Binding Title}" Margin="4,0,0,0" VerticalAlignment="Center"/> </StackPanel> </Button> </DataTemplate> </ToolBar.ItemTemplate> </ToolBar>

数据驱动模式下，分组逻辑也建议数据化。根据后台返回的分组标识，动态创建多个 ToolBar，并分别设置 Band 和 BandIndex。

这里有一个最常见的坑：直接把整个 ToolItemViewModel 集合给一个 ToolBar 的 ItemsSource，结果按钮之间的分隔线不见了。因为 Separator 也是 UI 层面的事物，数据里没有专门表示分组的项，模板里也不知道哪一段该输出 Separator。我的处理办法是给数据模型加一个 ItemType 字段，或者在 ViewModel 层把集合拆成多个分组：一个分组生成一个 ToolBar，分组内若干个按钮。比在模板里做智能分隔更简单清晰。

4. 常见问题与排查技巧实录

我把实际项目中遇到的高频 ToolBar 问题整理成一个速查表，很多问题是搜索时容易绕弯的，直接对照处理效率更高。

这里挑两个实际排查过程讲细一点。

4.1 问题一：为什么 ToolBar 按钮绑不上命令

有一次我给一个窗口加了一排“复制”“粘贴”按钮，绑定的是当前文档视图的 ViewModel 命令。界面运行后按钮一直禁用，从绑定错误日志看，ToolBar 的 DataContext 确实是窗口的 DataContext，但按钮的 Command 没绑上。后来发现是时间线问题：窗口构造期间先设了 DataContext 又立刻被其他地方重置了，导致命令目标改变，CanExecute 没有重新触发。解决方式是在视图加载完成后统一刷新命令状态。

还有一种常见情况出现在 ToolBar 内部嵌套了控件。比如你给 ToolBar 的 Button 的 Content 写了一个 UserControl，这个 UserControl 的 DataContext 如果被局部设置，那么 Button 自身的 Command 绑定仍然正常，但 UserControl 内部再去绑定同一个 ViewModel 里的属性，就可能拿到局部 DataContext 导致绑定失败。遇到这种嵌套时，建议让 UserControl 继承或显式绑定到按钮的 DataContext。

4.2 问题二：溢出区域的内容突然显示异常

如果你的 ToolBar 元素包含复杂 UserControl，比如 ChartControl 或者包含 ScrollViewer 的 QuickPanel，一旦窗口变窄，这些元素被收纳到溢出区时，尺寸可能不正常。原因在于溢出区的容器是 StackPanel 或类似面板，不会给子元素无限空间；UserControl 自身高度宽度又依赖外部尺寸，于是出现错位。

我后来给这种复杂元素专门设置了 OverflowMode="Never"，用显式按钮代替复杂控件。因为当一个控件复杂到需要大量空间时，它其实并不适合塞进溢出菜单，用户体验也差。宁可把它单独放到弹出的右侧 Window，也不要试图让它在溢出区妥协。

4.3 问题三：工具栏按钮想要“控件组”效果

有些工具按钮并不是单击型，而是一个小下拉菜单，显示多种模式。比如一个“对齐方式”按钮，点击之后弹出三种对齐模式。此时可以直接放 Menu 控件：

<ToolBar> <Menu> <MenuItem Header="对齐"> <MenuItem Header="左对齐" Command="{Binding AlignLeftCommand}"/> <MenuItem Header="居中" Command="{Binding AlignCenterCommand}"/> <MenuItem Header="右对齐" Command="{Binding AlignRightCommand}"/> </MenuItem> </Menu> </ToolBar>

放在 ToolBar 里的 Menu 会展示为紧凑的顶部菜单样式，Natural 地适配工具栏外观。不过注意，这种菜单项默认也会占据一定高度，和普通 Button 不一样，要额外调整模板让高度对齐。还有一个更简的方法：用 SplitButton 风格的第三方控件，但原生 WPF 没有 SplitButton，需要自定义模板或者引入扩展库。这个要看团队偏好。

4.4 问题四：固定高度下图标按钮的对齐问题

ToolBar 按钮内部同时放 Image 和 TextBlock 时，经常出现文字和图标无法垂直居中的问题。Image 默认 Stretch 会拉伸图片，如果你给了固定 Width/Height 却没有给工具条容器设置合适高度，Image 会和文字错位。我一般这样处理：

<Button Command="{Binding SaveCommand}" Padding="6,2"> <StackPanel Orientation="Horizontal"> <Image Source="/Assets/save.png" Width="16" Height="16" Stretch="Uniform"/> <TextBlock Text="保存" Margin="4,0,0,0" VerticalAlignment="Center"/> </StackPanel> </Button>

这里关键在于给 Button 设置 Padding，然后把 Image 和 TextBlock 放在一个 StackPanel 中。Button 的默认对齐逻辑会把 Content 整体摆放，只要 StackPanel 尺寸合理，Center 对齐就不会有问题。

5. 从踩坑到形成自己的封装习惯

ToolBar 用了一段时间之后，我把它做成了一个自定义控件类，统一处理几个常见需求：固定某些按钮不收纳、记录工具栏拖拽布局、统一按钮样式资源。具体实现不复杂，就是把上述 XAML 中的 ToolBar 提取成用户控件或继承 ToolBar 的控件，把可配置属性通过依赖属性暴露出来。这样每加入一个新模块，只要把工具模型列表填好，UI 部分几乎不用重新写。

封装过程中遇到最值得注意的一点，是依赖属性的默认值设计。比如 OverflowMode 的默认值应该是 AsNeeded，而不是 Always。因为如果默认全部 Always，所有按钮都会跑进出溢出区，主区域反而空了，第一次集成时很容易误判成绑定错误。设置默认值时，要反复模拟几个典型窗口宽度来验证。

另一个经验心得是资源字典的组织。建议把 ToolBar 相关的样式单独放进一个 ResourceDictionary（比如 ToolBarStyles.xaml），由 Application 统一引用。这样多个窗口共享一套工具栏外观。不要在窗口级复制粘贴样式，因为后续调整主题颜色时需要改无数个副本。

还有一点，我在项目里为了全局统一占位，通常会给 ToolBarTray 设置 Key 类似的样式控制整体高度，而不是直接改每个 ToolBar 的 Height。原因是 ToolBar 在 Tray 内高度是由行内最高子元素撑起来的，你把单个 ToolBar 的高度写死，但内部按钮如果更高，工具栏整体还是会被撑开，视觉效果反而不整齐。所以在设置高度时，重点要控制 ToolBar 内部模板里的 MaxHeight、MinHeight 以及按钮的 Margin 值，让它们形成一致节奏。

6. 最后分享两个细节技巧

一个是切换文档的时候刷新整个工具栏。你可能会把 ViewModel 整体替换，这时候旧的命令和新的命令都实现了相同接口，但按钮绑定没变，容易出现旧状态残留。更稳妥的做法是在 ViewModel 中实现 IDisposable 或者定义统一的刷新接口，当内容切换完成后调用命令状态刷新。习惯上我会在根 ViewModel 暴露 RefreshAllCommands 方法，给所有按钮的命令 CanExecute 重新校验。

另一个是 ToolBar 的键盘访问。想要工具栏在 Tab 导航中跳过，可以设置 KeyboardNavigation.TabNavigation="Once"；这样用户 Ctrl+Tab 或 Tab 时会优先整体聚焦到 ToolBar，再通过方向键在按钮之间移动。这种交互对密集工具栏很有用，桌面端老用户通常很吃这一套。如果你的产品主打鼠标点击，不做也不会有太大问题，但做了之后产品的完成度和专业度都会明显提高。

再说说我自己最认可的做法：别把 ToolBar 当成一个单纯的“按钮容器”去用。把它当成一个完整交互组件，一个由 Tray、ToolBar、内部元素、默认模板、溢出机制、命令通道组合出来的复合体系。理清这个体系之后，无论做深色主题、动态权限、拖拽布局还是复杂工具集，你都不会陷入“一个个按钮调样式”的泥潭。希望这次内容能帮你把 WPF 工具栏做扎实。