WPF Expander与Menu控件模板改造：侧边栏折叠与顶部标签实战

1. 先把这两个控件放一起看的原因

侧边栏里塞了十几组配置项，全部展开像一张写满字的纸，用户翻半天找不到要改的那一项；全部折叠又只剩一排孤零零的标题，点开一个另一个不关，滚轮来回滚三屏。这种界面我在 WPF 里改过太多遍，最后基本都落到同一套做法上：Expander 做折叠栏，Menu 做顶部菜单标签。前者把纵向空间切成按需展开的块，后者在有限的水平空间里承担导航切换。两个控件一个管纵向收纳、一个管横向分区，组合起来就是一套很典型的“左侧折叠 + 顶部标签”的桌面端布局。

这篇文章面向的是已经能在 WPF 里拖控件、但被模板和样式卡住的人。我会从内置模板的骨架讲起，说清楚 Expander 的 Header 到底是怎么变成可点击区域的，MenuItem 的 Role 为什么决定了子菜单弹不出来，然后把改造过程拆成可以直接照着抄的 XAML 和 C#。中间穿插几个属性选择背后的取舍：动画到底该不该做、手风琴互斥能不能用绑定实现、Menu 当标签栏到底比 TabControl 强在哪。结尾部分是一张排查速查表和几段踩坑记录，都是我实际改界面时留下的笔记。

需要提前说明一点：这篇里的代码是片段式的最小可运行结构，变量名和业务字段都做了抽象，直接粘进你的项目里需要按自己的命名空间和资源字典路径调整。涉及具体数值（动画时长、内边距、字号）的地方，我会给出取值理由，但最终数值要跟着你自己的设计规范走。

2. Expander 的骨架：默认模板中究竟有什么

2.1 逐层拆开默认模板

很多人第一次改 Expander 样式，是直接右键“编辑模板副本”，然后面对一大坨 XAML 发懵。其实它的结构极简，本质就是一个 ToggleButton 加一个 ContentPresenter，剩下的全是视觉修饰。我可以把这个骨架重写成十几行的版本，功能完全等价：

<Style x:Key="FlatExpander" TargetType="Expander"> <Setter Property="Background" Value="Transparent"/> <Setter Property="Template"> <Setter.Value> <ControlTemplate TargetType="Expander"> <Border Background="{TemplateBinding Background}"> <DockPanel> <ToggleButton x:Name="HeaderSite" DockPanel.Dock="Top" Focusable="False" Content="{TemplateBinding Header}" IsChecked="{Binding IsExpanded, RelativeSource={RelativeSource TemplatedParent}, Mode=TwoWay}"/> <ContentPresenter x:Name="ExpandSite" Visibility="Collapsed" Focusable="False" HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}" VerticalAlignment="{TemplateBinding VerticalContentAlignment}"/> </DockPanel> </Border> <ControlTemplate.Triggers> <Trigger Property="IsExpanded" Value="True"> <Setter TargetName="ExpandSite" Property="Visibility" Value="Visible"/> </Trigger> </ControlTemplate.Triggers> </ControlTemplate> </Setter.Value> </Setter> </Style>

这段 XAML 里有三个地方值得单独说。

第一，IsChecked必须写成Mode=TwoWay且绑定到模板父级的IsExpanded。这是整个控件能工作的关键：ToggleButton 负责接收鼠标和键盘，Expander 负责对外暴露状态，两者靠这条绑定同步。如果你只写了{TemplateBinding IsExpanded}，单向绑定会导致点击箭头之后视觉上按下了、内容却不展开——这个坑我在早期项目里踩过，排查了半小时才反应过来是绑定方向的问题。

第二，Focusable="False"加在 ToggleButton 上。默认模板里这个按钮是可聚焦的，意味着用户按 Tab 键时会在“展开箭头”上停一站，再按一次才进内容区。对于一屏有七八个 Expander 的侧边栏，Tab 键要按十几次才能穿过侧栏，键盘用户会直接骂人。把它设成不可聚焦，键盘操作交给 AccessKey（后面会讲），Tab 顺序就干净了。

第三，ContentPresenter上必须补HorizontalAlignment和VerticalAlignment的 TemplateBinding。默认模板里这两条是有的，自己重写时最容易漏。漏了之后的表现是：你在 Expander 上设了HorizontalContentAlignment="Stretch"，里面的 Grid 依然按内容宽度缩在左边，怎么调都没反应。原因很简单，ContentPresenter 自己不认识这两个属性，它只认模板父级传下来的值。

2.2 几个关键属性与它们的实际行为

Expander 的公开属性不多，但每一个都有容易误解的地方。我整理成一张表，改模板之前先过一遍：

ExpandDirection这一条值得展开说。默认模板里有多套触发器，会根据ExpandDirection是 Up/Down/Left/Right 调整 ToggleButton 停靠在哪一侧、箭头用哪个方向的图形。你自己重写模板时，这些触发器就全部消失了，属性还在、界面不动。所以如果你的界面需要“向上展开”或“向右展开”的折叠栏，要么在自定义模板里自己写四组触发器，要么老老实实用默认模板只改颜色和字体。我的建议是后者——为了一个方向属性写四套触发器，维护成本远高于收益，不如换个布局思路。

Header能放任意内容是很多人没意识到的能力。比如侧边栏的折叠标题经常需要“图标 + 标题文字 + 右侧数量角标”，直接这么写就行：

<Expander IsExpanded="True"> <Expander.Header> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto"/> <ColumnDefinition Width="*"/> <ColumnDefinition Width="Auto"/> </Grid.ColumnDefinitions> <Path Grid.Column="0" Data="{StaticResource IconFolder}" Fill="{DynamicResource TextSecondary}" Width="16" Height="16"/> <TextBlock Grid.Column="1" Text="消息通知" Margin="8,0,0,0"/> <Border Grid.Column="2" CornerRadius="8" Padding="6,1" Background="{DynamicResource BadgeBg}"> <TextBlock Text="{Binding UnreadCount}" FontSize="11"/> </Border> </Grid> </Expander.Header> <!-- 内容 --> </Expander>

这种写法有个副作用要提前知道：Header 里的元素会继承 ToggleButton 内容区的样式，字体、前景色、行高都按按钮模板走，不会自动继承外部 TextBlock 的样式。所以上面那段我必须显式给 Border 和 TextBlock 设颜色，否则在深色主题下会变成看不清的深灰。

2.3 折叠动画：值得做，但不要动画高度

原生 Expander 展开是瞬间的，没有任何过渡。要不要加动画，我的判断标准是：内容块高度超过一屏的一半，就加；低于这个值，别加。理由在于视觉锚点——短内容瞬间出现，用户的视线几乎不会丢失；长内容突然把下方所有东西推走，会产生明显的“页面跳了一下”的错觉，尤其是有 ScrollViewer 的时候。

真要做，别去动画Height。Height是布局属性，每帧都会触发 Measure 和 Arrange，一个折叠栏里如果嵌了 DataGrid 或图表，60fps 根本跑不动，掉帧肉眼可见。我通常用两种替代方案：

一是动画内容区的Opacity加一个小的TranslateTransform，配合Visibility的延迟切换。实现方式是在模板触发器里用Storyboard，展开时先把Visibility设为 Visible，再跑 150ms 的透明度 0→1 和 Y 偏移 -8→0。这种方案的成本几乎为零，因为 Opacity 和 RenderTransform 都不触发布局。缺点是内容区的高度是“瞬间撑开”的，下方内容依然会跳。

二是用MaxHeight动画，从一个够用的固定值动画到 0。MaxHeight也会触发布局，但它比Height温和，因为内容本身的高度不受影响。取值套路是给一个远大于实际内容的值，比如 800，动画时长 200ms。超过这个高度的内容会被裁掉，所以只适合内容高度可控的场景——配置面板、筛选条件区这类都合适，聊天记录列表就不合适。

我个人在绝大多数项目里选的是第一种，只在少数“折叠栏本身就是主角”的界面（比如设置页）用第二种。过度动画是种病，我见过一个后台系统给每个 Expander 都加了 400ms 的弹簧缓动，展开五个折叠栏要两秒，用户点开之后手指还得悬在鼠标上等，体验反而更差。

3. 实战：把 Expander 改成可用的侧边栏手风琴

3.1 重写样式：先解决视觉，再谈交互

默认 Expander 的那个灰色圆角边框和实心三角箭头，放在现代风格的界面里非常突兀。改造顺序建议从外到内：先去掉边框背景，再换指示器，最后调内边距。

去掉边框很简单，把模板外层 Border 的BorderThickness和Background都设为 0 或透明。但注意不要顺手把Padding也清零，默认模板的内边距是给内容留的呼吸空间，清零之后内容会顶到边缘，视觉上更挤。我的习惯是外层 Border 用Padding="0"，内容区单独包一层 Border 设内边距，这样标题和内容的左右边距可以分别控制。

指示器是重点。默认是Path画的小三角，通过RenderTransform的RotateTransform在展开时旋转 90 度。这套逻辑可以保留，但三角的视觉太老旧。换成 chevron（就是那种>形状的折线）更符合现在的审美，实现方式还是 Path，只是Data换成两段线：

<Path x:Name="Arrow" Data="M 1,1 L 6,6 L 1,11" Stroke="{DynamicResource TextSecondary}" StrokeThickness="1.6" StrokeStartLineCap="Round" StrokeEndLineCap="Round" Width="8" Height="12" VerticalAlignment="Center" RenderTransformOrigin="0.5,0.5"> <Path.RenderTransform> <RotateTransform x:Name="ArrowRotate" Angle="0"/> </Path.RenderTransform> </Path>

然后在模板触发器里，IsExpanded=True时把ArrowRotate.Angle设为 90。这里有个细节：RotateTransform需要给x:Name才能在 Trigger 的 Setter 里用TargetName定位，但 Setter 的TargetName只能指向模板里的具名元素，不能指向元素内部的具名对象。所以正确写法是把旋转角度动画写成Storyboard，用Storyboard.TargetName="Arrow"加Storyboard.TargetProperty="(UIElement.RenderTransform).(RotateTransform.Angle)"。这个路径写法一开始很别扭，但它是模板动画的标准姿势，记住就行。

RenderTransformOrigin="0.5,0.5"别忘。漏了它旋转轴心是左上角，箭头会绕着角转，看起来像在甩尾。

3.2 手风琴互斥：三种做法的取舍

手风琴效果（展开一个自动收起其他的）需求极高频，实现方式我看到过三种，各自适用的场景不太一样。

第一种，父容器的路由事件里统一处理。Expander.Expanded是冒泡的路由事件，可以在外层 Panel 上一次监听：

private void OnAnyExpanderExpanded(object sender, RoutedEventArgs e) { if (!(sender is Panel host)) return; if (!(e.OriginalSource is Expander current) || !current.IsExpanded) return; foreach (var child in host.Children.OfType<Expander>()) { if (!ReferenceEquals(child, current) && child.IsExpanded) { child.IsExpanded = false; } } }

这段代码有个隐蔽的风险要提醒：如果外层 Panel 里有嵌套的 Expander（折叠栏里再套折叠栏），host.Children.OfType<Expander>()只处理直接子级，内层的事件依然会冒泡上来，e.OriginalSource是内层那个，于是你会把外层的兄弟全部收起来——用户点开内层的小折叠栏，外层的大折叠栏跟着关了。解决方法是加个e.Handled = true或者判断current.Parent是不是host。我倾向于判断父级，因为e.Handled会挡住其他可能监听这个事件的逻辑。

第二种，附加属性做“组名”语义。给 Expander 加一个AccordionHelper.GroupName附加属性，同一个组名内互斥。这种方式的好处是声明式、不依赖代码后置，适合 MVVM 做得比较干净的界面。实现上需要一个静态字典记录“组名 → 当前展开的 Expander 弱引用”，在属性变更回调里注册Expanded事件。写起来大约四十行，比第一种复杂，但复用性好，一旦封装完整个项目都能用。

第三种，纯绑定到 ViewModel。每个分组对应一个SelectedGroupId，每个 Expander 的IsExpanded绑到一个转换器，判断自己的 Id 是否等于选中项。这种方式最“MVVM”，但我实测下来最不推荐：IsExpanded是双向绑定，用户在界面上点击会回写 ViewModel，而 ViewModel 又要把其他的设为 false，容易产生“点开 A 之后 A 又自动关掉”的抖动。要修就得把绑定改成单向到 ViewModel、ViewModel 里手动通知集合，代码量翻倍。

我的选择顺序是：界面里 Expander 是静态写的（XAML 里手写几个），用第一种；是数据驱动的（ItemsControl 生成），用第二种或者直接在 ViewModel 里管；别用第三种。

3.3 数据驱动：ItemsControl 生成的折叠栏

当侧边栏的分组数量不固定、来自配置或接口时，就得让 ItemsControl 生成 Expander。最朴素的写法是这样：

<ItemsControl ItemsSource="{Binding Groups}"> <ItemsControl.ItemTemplate> <DataTemplate> <Expander Header="{Binding Title}" IsExpanded="{Binding IsExpanded, Mode=TwoWay}"> <ItemsControl ItemsSource="{Binding Items}"/> </Expander> </DataTemplate> </ItemsControl.ItemTemplate> </ItemsControl>

能跑，但有几个坑必须提前处理。

第一个坑：IsExpanded必须绑到 ViewModel 属性且是 TwoWay。如果绑定了却没在 ViewModel 里实现通知，用户展开的状态会在滚动或刷新后莫名其妙丢失。原因是 ItemsControl 默认的ItemsPanel是StackPanel，本身不做虚拟化，容器不会被回收，看起来没问题；但一旦你换成VirtualizingStackPanel或者外面套了ListBox，容器复用就会把展开状态带回新数据项，出现“我明明没展开这个，它自己开了”的灵异现象。根治办法只有一个：状态放 ViewModel，容器永远只做呈现。

第二个坑：想要虚拟化，光换 ItemsPanel 不够。ItemsControl 的默认模板里没有 ScrollViewer，虚拟化根本没有容器去触发。必须同时替换ItemsControl.Template：

<ItemsControl.Template> <ControlTemplate TargetType="ItemsControl"> <ScrollViewer CanContentScroll="True" VerticalScrollBarVisibility="Auto" HorizontalScrollBarVisibility="Disabled"> <ItemsPresenter/> </ScrollViewer> </ControlTemplate> </ItemsControl.Template> <ItemsControl.ItemsPanel> <ItemsPanelTemplate> <VirtualizingStackPanel/> </ItemsPanelTemplate> </ItemsControl.ItemsPanel>

CanContentScroll="True"是关键，它让 ScrollViewer 按“项”滚动而不是按像素，虚拟化才有意义。漏了这一条，虚拟化容器虽然创建了但不会真正回收，等于白改。

第三个坑：分组内容多的时候，Expander每次展开都要重新 Measure 全部子项。如果内容里有一个几百行的 DataGrid，第一次展开会有明显的卡顿。缓解办法是把内容区包在一个ContentControl里，用ContentTemplate延迟实例化，或者干脆给内容区加个IsExpanded的条件——只有展开时才创建真实内容，折叠时用占位。后者会牺牲一点动画流畅度，但在大表格场景下是值得的。

4. Menu：别只把它当顶部菜单栏

4.1 Menu 的层级模型与 Role 属性

MenuItem 的Role是只读属性，由 WPF 自动计算，取值有四个：TopLevelItem、TopLevelHeader、SubmenuItem、SubmenuHeader。计算规则很简单——有子项的是 Header，没子项的是 Item，在 Menu 直接下面的是 TopLevel，在子菜单里的是 Submenu。这个属性看着无关紧要，但它直接决定了样式触发器能不能命中。

举个例子，你想给顶部菜单的项加个选中下划线，写法是：

<Style TargetType="MenuItem"> <Style.Triggers> <Trigger Property="Role" Value="TopLevelHeader"> <Setter Property="Template" Value="{StaticResource NavTopHeaderTemplate}"/> </Trigger> <Trigger Property="Role" Value="TopLevelItem"> <Setter Property="Template" Value="{StaticResource NavTopItemTemplate}"/> </Trigger> <Trigger Property="Role" Value="SubmenuItem"> <Setter Property="Template" Value="{StaticResource NavSubItemTemplate}"/> </Trigger> </Style.Triggers> </Style>

如果你只写了一个Set模板直接设在 Style 上，没做 Role 判断，那所有层级的 MenuItem 会共用一个模板——顶部项和下拉项长得一模一样，下拉里的项会带上顶部项的下划线，视觉全乱。我见过有人为了省事，直接给 MenuItem 设Template而不管 Role，然后抱怨“下拉菜单的子项右边多了一块空白”，其实那块空白是顶部模板留给 Popup 的位置。

4.2 用 Menu 做标签导航：Menu 具备的优势

顶部导航用 TabControl 也行，我为什么还要用 Menu？我列一下实际对比：

倒数第二行是个取舍点，得说清楚。语义上，如果这块区域确实是“页面切换”，TabControl 对辅助技术的表述更准确；如果这块区域是“功能入口”，Menu 更准确。所以我不建议无脑用 Menu 做标签，而是看这块区域是不是真的在切换页面。上面那个后台管理系统里，“概览 / 订单 / 客户 / 设置”这四个确实是页面切换，我最后还是用了 Menu，理由是它同时要挂“设置”下面的二级弹层——TabControl 做不了这个，硬做要写一堆 Popup 定位代码。

4.3 标签栏样式的完整改法

顶部标签的关键需求有三个：选中项要有指示条、悬停要有背景反馈、点击要能触发命令。指示条我用一个底部 Border 实现，选中态靠一个附加属性NavHelper.IsActive来驱动：

public static class NavHelper { public static readonly DependencyProperty IsActiveProperty = DependencyProperty.RegisterAttached( "IsActive", typeof(bool), typeof(NavHelper), new FrameworkPropertyMetadata(false)); public static void SetIsActive(DependencyObject d, bool value) => d.SetValue(IsActiveProperty, value); public static bool GetIsActive(DependencyObject d) => (bool)d.GetValue(IsActiveProperty); }

XAML 那边，模板里放一条底部横线，触发器读这个附加属性：

<ControlTemplate x:Key="NavTopItemTemplate" TargetType="MenuItem"> <Grid> <Border x:Name="Bg" Background="Transparent" Padding="16,9"> <ContentPresenter ContentSource="Header" RecognizesAccessKey="True" VerticalAlignment="Center"/> </Border> <Border x:Name="Indicator" Height="2" VerticalAlignment="Bottom" Background="{DynamicResource AccentBrush}" Visibility="Collapsed"/> </Grid> <ControlTemplate.Triggers> <Trigger Property="IsMouseOver" Value="True"> <Setter TargetName="Bg" Property="Background" Value="{DynamicResource HoverBrush}"/> </Trigger> <Trigger Property="IsEnabled" Value="False"> <Setter Property="Opacity" Value="0.45"/> </Trigger> <DataTrigger Binding="{Binding (local:NavHelper.IsActive), RelativeSource={RelativeSource Self}}" Value="True"> <Setter TargetName="Indicator" Property="Visibility" Value="Visible"/> </DataTrigger> </ControlTemplate.Triggers> </ControlTemplate>

RecognizesAccessKey="True"这一条不起眼但很值钱。设了它，Header 写成_Orders里的下划线会被解析成访问键，用户按Alt+O就能跳到这一项。桌面端用户里有一部分是重度键盘操作者，这个小功能能明显提升他们的效率。代价是标题里出现下划线字符时会被吃掉，需要写成双下划线转义。

DataTrigger里的绑定路径写法(local:NavHelper.IsActive)要注意括号和命名空间前缀，漏了括号会当成属性路径解析失败，界面上不会报错，只是触发器永远不生效——这种静默失败是最难查的，因为 XAML 里那条绑定看起来完全正常。

上面这个模板是只有导航、没有子菜单的版本。如果你还需要下拉，必须补上 Popup 和 ItemsPresenter，否则二级菜单直接消失，一点痕迹都不留：

<Popup x:Name="PART_Popup" Placement="Bottom" IsOpen="{Binding IsSubmenuOpen, RelativeSource={RelativeSource TemplatedParent}}" AllowsTransparency="True" Focusable="False" PopupAnimation="Fade"> <Border Background="{DynamicResource SurfaceBrush}" CornerRadius="6" Padding="4" Margin="0,4,0,0"> <Border.Effect> <DropShadowEffect BlurRadius="16" ShadowDepth="2" Opacity="0.12"/> </Border.Effect> <ItemsPresenter x:Name="ItemsPresenter"/> </Border> </Popup>

PART_Popup这个名字是硬约定，不能被改成别的。MenuItem 内部会按这个名字去找 Popup 并把IsSubmenuOpen绑上去，名字不对就是“点开没反应”。同理ItemsPresenter不带x:Name其实也能工作，但加上便于调试模板。

4.4 命令绑定与 CanExecute 的刷新时机

MenuItem 最常绑的就是Command。写法没什么花样：

<MenuItem Header="导出报表" Command="{Binding ExportCommand}" CommandParameter="{Binding SelectedRange}"/>

坑在CanExecute。WPF 的ICommand实现里，CanExecute的重新求值依赖CommandManager.RequerySuggested事件，而这个事件由输入系统在鼠标键盘操作时触发，不是实时的。也就是说，如果你的“导出”按钮是否可用取决于某个后台任务是否完成，任务完成了但用户没动鼠标，按钮会一直保持灰色，直到他随便点一下界面。

三种解法，按侵入性从低到高：

第一种，手动调CommandManager.InvalidateRequerySuggested()。在后台任务完成的地方加一行，够用，缺点是得记住在哪儿加，漏一处就是一个“按钮卡死”的 bug。

第二种，用RelayCommand的RaiseCanExecuteChanged精确通知。如果你用的是自己封装的命令类，通常会实现一个只通知自己订阅者的方法，比全局刷新更精准，代价是每个依赖条件变化的地方都要显式调用。

第三种，用CommandBinding配合Executed和CanExecute的路由事件。这种方式在自定义控件里更自然，但在普通 ViewModel 场景下反而绕。

我一般用第二种，因为项目里通常已经有现成的RelayCommand基类，加一行调用不费事。另外还要注意CommandParameter的时机：如果CanExecute依赖参数，参数为空时框架不会调用CanExecute，按钮直接呈现禁用态，看起来像逻辑写错了，其实是参数没绑上。这个现象我在一个多选列表的批量操作菜单上遇到过，排查了半天才发现是SelectedItems不支持直接绑定，得走附加行为。

5. 焦点、键盘与可达性：容易被忽略但会被用户批评的部分

5.1 Expander 的键盘行为

前面提到把 ToggleButton 设成不可聚焦，那键盘用户怎么展开折叠栏？答案是用 AccessKey。在 Header 里放一个TextBlock并给Text写成带下划线的形式，同时确保模板里的 ToggleButton 设置了RecognizesAccessKey="True"，用户按Alt + 那个字母就能切换。多个折叠栏的访问键必须唯一，这一点在设计文案时就要定好。

如果界面里折叠栏数量多到字母不够用，可以退一步：给 Expander 本身设Focusable="True"，然后在PreviewKeyDown里处理空格和左右方向键。实现成附加属性更好复用，但代码量会上去。我的判断是——如果你的用户以鼠标操作为主，AccessKey 就够了；如果面向的是效率工具类用户，值得把方向键支持加上，因为“按住方向键连续展开收起”比“Alt + 字母”顺手得多。

还需要注意一个小细节：Expander折叠时，内容区里的控件会从 Tab 序列中消失（因为Visibility是Collapsed），但焦点如果正好在内容区里，会被移到父级——这个过程没有视觉提示，用户会感觉“焦点突然丢了”。稳妥做法是在Collapsed事件里把焦点显式移到 Header 上：

private void OnExpanderCollapsed(object sender, RoutedEventArgs e) { if (sender is Expander ex && ex.IsKeyboardFocusWithin) { ex.MoveFocus(new TraversalRequest(FocusNavigationDirection.First)); } }

5.2 Menu 的键盘导航路线

Menu 的键盘支持是内置的，但有开关。Menu.IsMainMenu默认是true，含义是这个菜单会响应Alt或F10键进入“菜单模式”——按下之后焦点跳到第一个菜单项，方向键在项之间移动。如果你的界面里有多个 Menu（比如顶部主菜单、工具栏里的一个小 Menu），只有一个应该设IsMainMenu="True"，否则按 Alt 时焦点跳到哪个是不确定的，用户会觉得键盘失灵。

菜单模式里的移动逻辑也得知道：左右键在顶层项之间移动，上下键打开下拉并在子项间移动，Esc逐层退回。这套是框架做好的，不需要额外代码，但前提是 MenuItem 的IsEnabled和可见性正常。如果某个顶级项设了Visibility="Collapsed"，方向键会跳过它，这是符合预期的；但如果设成Hidden，它仍然占位并且能被键盘选中——这是个容易忽略的差异。

还有一个跨界的坑：如果菜单项里有 TextBox 之类的输入控件（很少见但确实有人这么干，比如搜索框塞在菜单里），方向键会被文本框吃掉，菜单导航就断了。这种情况不要硬塞，改用 Popup 自己做。

6. 常见问题与排查实录

6.1 排查速查表

下面这张表是我这几年改这两个控件时攒下来的，按“现象 → 根因 → 处理”组织，遇到问题可以直接对号：

6.2 我实际踩过的几个坑

第一个：模板里的x:Key重名，导致整块样式静默失效。资源字典里给 Expander 模板起了个通用的名字，比如ExpanderTemplate，然后在另一个字典里又起了同名。WPF 的资源查找是就近优先，不会报错，只会默默用上先找到的那个。表现是“我明明改了模板，界面一点没变”。排查方法是给所有模板加项目前缀，比如App.Expander.Flat，或者干脆用{DynamicResource}并打开实时可视化树去查实际命中的是哪个。后者更直接，我现在的习惯是遇到样式不生效，第一件事就是开可视化树看属性来源。

第二个：Header 里放 Button，结果整个折叠栏点不开。ToggleButton 是内容控件，Header 里嵌套的 Button 会截获点击事件，e.Handled在按钮内部就被置为 true，ToggleButton 收不到。表现是点标题文字能展开，点文字旁边那个小图标按钮不展开——如果那个图标本来就是个“更多”按钮，这其实是期望行为；但如果是装饰性的图标，就得把它设成IsHitTestVisible="False"。判断标准很简单：这个元素需要被点击吗？不需要就给IsHitTestVisible="False"。

第三个：Menu 放在 ScrollViewer 里，下拉菜单错位。Popup 的定位坐标相对于屏幕，而 ScrollViewer 滚动之后元素位置变了，Popup 的位置计算如果发生在滚动前，就会漂移。这个问题的根子在PlacementTarget的坐标变换，比较麻烦。我的规避方案是：菜单不要放进可滚动容器，或者给 Popup 显式设Placement="Bottom"并加HorizontalOffset修正。更好的做法是把菜单提出来做成独立区域，滚动区只放内容。

第四个：手风琴的事件处理里忘记排除自己，导致死循环。早期版本的代码里我写的是遍历所有 Expander 并把非当前的设为IsExpanded = false，但如果某个 Expander 本身已经是 false，赋值不会触发事件，看起来没问题；一旦有一处写成IsExpanded = !child.IsExpanded，就会形成 Expanded → Collapsed → Expanded 的循环，界面直接卡死。原因很明确：设置IsExpanded会同步触发事件，而事件处理里又去设置它。修法是加个守卫标志，或者严格只在“目标值不同”时才赋值。

第五个：深色主题切换后折叠栏标题看不清。因为模板里直接写死了Foreground="#333"。这类问题看似低级，但在自己重写模板时发生率极高，因为手写模板很容易顺手写具体颜色。规矩只有一条：模板里除透明色外，一律用DynamicResource引用主题画刷，连Stroke也别写死。

7. 我从这些改造中固化下来的几个习惯

写模板的时候，我现在的固定动作是先写一个“最小骨架”——就是第 2.1 节那种十几行的版本，把功能跑通、把绑定方向确认无误，再往里加视觉元素。一上来就复制官方模板然后删改，往往删掉某个 Trigger 之后不知道自己破坏了什么，回头排查花的钱比一开始多写十行还贵。

尺寸和间距我会在样式里统一走一套变量，比如HeaderPadding、IndicatorHeight、HoverRadius，用Thickness类型的资源定义，DynamicResource引用。好处是后续调视觉的时候改一处、全界面同步，而且给设计同学看的时候能直接说“这个数值是 16”，不用去 XAML 里翻三层模板找那个硬编码的Padding="16,9"。

最后一个是关于IsExpanded的默认值。侧边栏的折叠栏，我默认只展开第一个，其余全收。理由很朴素：全展开等于没有折叠，全收起等于让用户先做十次点击。只开一个既暗示了“这里可以展开”，又给了用户一个明确的起点。配合首项展开还能让界面在初次加载时呈现一点内容，不至于看起来像一片空白。

这套东西搭完之后，日常再遇到折叠面板和顶部导航的需求，基本就是复制样式、改改文案和图标、接上命令，两三个小时能出一版能看的界面。真正花时间的从来不是写模板，而是想清楚“用户在这一屏最想看到什么、最不想看到什么”，这件事没有现成控件能替你决定。