继承AppBar自定义组件异常：汉堡菜单不显示问题排查

核心问题 #

Flutter原生AppBar内部对抽屉汉堡图标的显示有一套内置逻辑——当页面存在Scaffold.drawer时，它会自动根据屏幕宽度判断是否展示leading区域的菜单图标。但你直接继承AppBar时，很可能破坏了这套内置逻辑：

• 要么是自定义组件中手动设置了leading: null，覆盖了默认的抽屉图标逻辑；
• 要么是没有在build过程中实时读取屏幕宽度，而是用了固定值或缓存值，导致尺寸变化时判断逻辑不更新；
• 还有可能是继承AppBar时没有正确传递上下文，让它无法感知到Scaffold的存在，从而不触发默认的leading显示逻辑。

修复步骤 #

1. 改用组合而非继承（更推荐） #

直接继承AppBar容易踩内部逻辑的坑，换成组合方式把AppBar作为子组件实现自定义，更灵活且不易出错：

class AppBarResponsive extends StatelessWidget implements PreferredSizeWidget {
  @override
  Size get preferredSize => const Size.fromHeight(kToolbarHeight);

  @override
  Widget build(BuildContext context) {
    final screenWidth = MediaQuery.of(context).size.width;
    // 判断是否显示汉堡菜单，同时保留AppBar对Scaffold.drawer的感知
    final showMenu = screenWidth < 600;
    
    return AppBar(
      // 如果showMenu为true，让AppBar自动处理抽屉图标；否则隐藏leading
      leading: showMenu ? null : const SizedBox.shrink(),
      // 你的其他自定义配置，比如title、actions等
      title: const Text("Responsive AppBar"),
    );
  }
}

这里注意：当leading设为null时，AppBar会自动检查是否有Scaffold.drawer，如果有就显示默认的菜单图标；设为SizedBox.shrink()则强制隐藏leading区域。

2. 若坚持继承AppBar，需复用默认逻辑 #

如果一定要继承，要确保复用AppBar的默认leading逻辑，而不是完全覆盖：

class AppBarResponsive extends AppBar {
  AppBarResponsive({super.key}) : super();

  @override
  Widget build(BuildContext context) {
    final screenWidth = MediaQuery.of(context).size.width;
    // 先获取AppBar原本的leading（也就是默认的抽屉图标）
    final originalLeading = super.build(context).leading;
    
    return super.build(context).copyWith(
      leading: screenWidth < 600 ? originalLeading : const SizedBox.shrink(),
    );
  }
}

3. 确保屏幕尺寸变化时组件重建 #

不管用哪种方式，都要确保在build方法中实时通过MediaQuery.of(context)获取屏幕宽度，这样当屏幕尺寸变化（比如平板横竖屏切换）时，组件会自动重建并更新显示状态。

4. 检查Stacked框架的状态影响 #

如果用了Stacked的ViewModel，别在ViewModel中缓存屏幕宽度值，要每次在UI的build方法中直接读取；或者在ViewModel中添加屏幕尺寸监听，当尺寸变化时通知UI刷新。

为什么原生AppBar正常？ #

原生AppBar内部已经和Scaffold做了联动，会自动根据屏幕宽度和是否存在抽屉来控制leading图标的显示。而自定义继承时，很容易因为覆盖参数、上下文传递问题，打断了这套联动逻辑。

内容的提问来源于stack exchange，提问作者ChD Computers