Flutter实现可吸边且隐藏一半的拖拽悬浮按钮

最近在做一款直播伴侣类的工具时，遇到了一个很典型的需求：页面上需要一个悬浮入口按钮，用户既希望它能随手拖到任意位置，又希望它别一直霸占屏幕中央影响观看内容。产品给的原话是“做个能吸边、还能藏一半的悬浮球”，正好就是标题里说的这个——Flutter可吸边且隐藏一半的拖拽悬浮按钮。不管你是刚把Flutter环境装好、正在找练手组件的新手，还是已经在做客服、直播、课程助手这类App的开发者，这个组件都值得自己手写一遍。市面上的第三方库不少，但版本跟进慢、参数锁得死，真正要适配自己业务时还得改源码，不如从零实现一个，还能彻底搞懂里面的手势、坐标、动画这些关键机制。

1. 先把需求掰开揉碎：这个按钮到底要干哪些事

1.1 一个悬浮按钮背后至少藏着四个诉求

很多人拿到这个需求会以为就是一个Draggable再加个Alignment就能搞定，真动手以后才发现，表面一句话背后其实有四个独立的功能点。

第一是“可拖拽”。这个好理解，手指按住、拖动、松手，按钮得跟着走。但这里的“走”不是漫无目的地乱走，而是要限制在屏幕可视范围内，不能拖到状态栏上面去，也不能整个掉出屏幕外面。第二是“吸边”，也就是松手后按钮不是停在原地，而是自动滑向离它最近的那条屏幕边缘，左边近就吸左边，右边近就吸右边。第三是“隐藏一半”，吸边完成后按钮要有大概一半（或者按设计指定的比例）藏在屏幕外面，只露出一部分来提示用户“我在这儿”。第四是“点击展开”，既然藏起来了，那用户想完整操作它的时候就得有个交互：点击露出的那部分，按钮滑出来完整显示。

这四个诉求是环环相扣的。拖拽是基础，吸边是拖拽结束后的收尾动作，隐藏一半是吸边之后的形态变化，点击展开则是从隐藏态恢复成完整态的动画过渡。任何一个环节没处理好，都会让整个按钮显得“不对劲”。

1.2 “隐藏一半”这个设计为什么合理

在实际产品里，悬浮按钮如果一直是完整显示的状态，其实挺烦人的。屏幕中间的弹幕、视频画面、直播礼物动画都可能被它挡住，用户想看清内容就得手动把它挪走，挪完它还在那儿大喇喇地占着一块地方。

隐藏一半这个设计巧妙在它同时满足了两个诉求：一是保留了便捷入口，用户不需要满屏找按钮，扫一眼屏幕边缘就能看到；二是最大限度减少了视觉遮挡，半个按钮的宽度通常只有20到30个像素，几乎不挡内容。而且这个“隐藏一半”还自带一种视觉暗示——半截按钮露在屏幕边缘，用户一看就知道这东西是可交互的、能拖出来的，不需要任何新手引导。

我这里说的“一半”其实是个形象说法，实际实现中露出的宽度不一定是严格的50%，通常会在20到24像素左右，既能看清图标轮廓，又不会太占地方。具体数值后面可以做成参数，不同业务自己调。

1.3 我最终圈定的可运行范围

在动手之前，我先明确了几个基础参数，避免写到一半陷入选择困难：

• 按钮默认直径：56（Material规范里FAB的尺寸）
• 吸边后露出宽度：20
• 吸边状态距离屏幕边缘的间距：8
• 拖拽过程中上下的安全范围：顶部避开状态栏，底部避开系统导航条，用MediaQuery拿到具体值

实现范围上，我先做的是单页面内的悬浮球，也就是把组件挂在当前页面的Stack里。如果你需要的是全App全局悬浮（切页面也不消失），原理是一样的，只是要把组件放到Overlay里，这个我后面单独讲。

2. 为什么选GestureDetector而不是Draggable

2.1 Draggable的适用场景

Flutter官方提供的Draggable组件，设计初衷是“把某个东西拖到另一个东西上面去”，典型的场景是拖拽排序、拖拽到回收站、拖拽到某个容器里。它天生绑定DragTarget（拖拽目标），拖拽过程中的回调、拖拽结束后的落点判断，全都是围绕“目标区域”来设计的。

但悬浮按钮的需求恰恰不是这样。它不需要知道自己落在了哪个目标上，它只需要知道自己最后停在了屏幕的哪个坐标，然后根据坐标决定往左吸还是往右吸。Draggable在这里反而成了累赘，因为它的feedback、childWhenDragging这些机制，以及它内部对手势竞技场的处理，都会让“自由移动+吸边”这种逻辑变得绕。

2.2 GestureDetector + Positioned的组合才是正道

我最终用的是GestureDetector的onPanUpdate系列回调，配合Stack + Positioned来定位。核心逻辑就一句话：手指移动多少，按钮的left和top就跟着加多少，松手之后做吸边计算。

这套组合的逻辑非常直观，没有任何中间层。onPanUpdate回调里会给一个details.delta，这个值就是本次回调相对于上次回调的位移增量，直接用这个增量去更新坐标就行。之所以不用onHorizontalDragUpdate和onVerticalDragUpdate分开监听，是因为悬浮按钮的拖拽是自由方向的，onPanUpdate能同时拿到水平和垂直两个方向的增量。

这里还有一个细节值得注意：GestureDetector只负责手势识别，不负责布局。把GestureDetector放进Positioned里，Positioned负责按钮在Stack中的位置，GestrueDetector负责把手势回调转换成位置变化，两者各司其职。

2.3 方案对比：为什么不用第三方库

我也看过几个Flutter悬浮按钮的第三方库，比如flutter_draggable_fab这类，功能确实开箱即用，但问题也不少。

最现实的痛点就是第三方库的更新速度。Flutter本身一年要发好几个大版本，有些库半年不更新，你升级一下Flutter版本就编译不过，最后还是要自己改源码。与其改别人的还看不明白，不如自己写一个，总共就是几个回调加几行坐标计算，算上动画半小时搞定。

3. 核心逻辑实现：从零手写一个能用的悬浮球

3.1 先搭一个最简可运行的骨架

组件类我命名为SnapDockButton，它的最外层结构是这样的：

dart复制class SnapDockButton extends StatefulWidget {
  final double size;            // 按钮直径
  final double hiddenWidth;     // 吸边后露出的宽度
  final Widget child;           // 按钮内部的内容，比如Icon
  final VoidCallback? onTap;    // 完全展开状态下点击时的业务回调
  final bool autoHideOnSnap;    // 吸边后是否自动收起

  const SnapDockButton({
    Key? key,
    this.size = 56,
    this.hiddenWidth = 20,
    required this.child,
    this.onTap,
    this.autoHideOnSnap = true,
  }) : super(key: key);

  @override
  State<SnapDockButton> createState() => _SnapDockButtonState();
}

State类里我维护了几个关键变量：

dart复制class _SnapDockButtonState extends State<SnapDockButton> {
  double _left = 0;          // 当前left
  double _top = 0;           // 当前top
  bool _isDragging = false;  // 是否正在拖拽
  bool _expanded = false;    // 是否完全展开
  bool _hitLeft = true;      // 当前吸附在哪一边
  double _screenWidth = 0;
  double _screenHeight = 0;
  double _safeTop = 0;
  double _safeBottom = 0;
}

initState里拿到屏幕尺寸和安全区的高度，把按钮初始位置设在屏幕右侧边缘、垂直方向约三分之一处：

dart复制@override
void initState() {
  super.initState();
  WidgetsBinding.instance.addPostFrameCallback((_) {
    final size = MediaQuery.of(context).size;
    final padding = MediaQuery.of(context).padding;
    setState(() {
      _screenWidth = size.width;
      _screenHeight = size.height;
      _safeTop = padding.top;
      _safeBottom = padding.bottom;
      _left = size.width - widget.size - 8;
      _top = size.height / 3;
    });
  });
}

使用PostFrameCallback是因为在initState阶段MediaQuery可能还没准备好，等第一帧渲染完再拿数据更稳妥。

然后是build方法：

dart复制@override
Widget build(BuildContext context) {
  return Stack(
    clipBehavior: Clip.none,
    children: [
      AnimatedPositioned(
        duration: _isDragging
            ? Duration.zero
            : const Duration(milliseconds: 300),
        curve: Curves.easeOutBack,
        left: _left,
        top: _top,
        child: GestureDetector(
          behavior: HitTestBehavior.opaque,
          onPanDown: _handlePanDown,
          onPanUpdate: _handlePanUpdate,
          onPanEnd: _handlePanEnd,
          onTap: _handleTap,
          child: Container(
            width: widget.size,
            height: widget.size,
            decoration: BoxDecoration(
              shape: BoxShape.circle,
              color: Colors.deepPurple,
              boxShadow: [
                BoxShadow(
                  color: Colors.black26,
                  blurRadius: 8,
                  offset: Offset(0, 4),
                ),
              ],
            ),
            child: widget.child,
          ),
        ),
      ),
    ],
  );
}

注意这里的Stack一定要设置clipBehavior: Clip.none，否则吸边后按钮藏在屏幕外面的那部分会被裁剪掉，露出来的部分就不是“半个按钮”，而是“缺了一角的按钮”，视觉效果差很多。这个坑我后面详细说。

3.2 拖拽过程与边界约束

拖拽的逻辑用三个回调构成一个完整的生命周期：按下、移动、松手。

dart复制void _handlePanDown(DragDownDetails details) {
  setState(() => _isDragging = true);
}

void _handlePanUpdate(DragUpdateDetails details) {
  setState(() {
    _left = (_left + details.delta.dx)
        .clamp(_minLeft(), _maxLeft());
    _top = (_top + details.delta.dy)
        .clamp(_minTop(), _maxTop());
  });
}

void _handlePanEnd(DragEndDetails details) {
  setState(() => _isDragging = false);
  _snapToEdge();
}

边界约束的计算是这里的一个关键点：

dart复制double _minLeft() {
  // 吸到左边时，按钮左边部分藏在屏幕外
  return widget.hiddenWidth - widget.size;
}

double _maxLeft() {
  // 吸到右边时，按钮左边在屏幕右侧露出位置
  return _screenWidth - widget.hiddenWidth;
}

double _minTop() => _safeTop;

double _maxTop() => _screenHeight - widget.size - _safeBottom;

left的最小值可以取到负数，表示按钮有一部分在屏幕外，这是符合预期的。top的控制范围则是从状态栏底部到屏幕底部减去按钮高度再减去底部安全区，这样按钮不会拖到状态栏上，也不会被系统手势条挡住。

这里有个容易忽略的点：在拖拽过程中，left的clamp范围和吸边状态下是相同的。想想看，拖拽时用户可能把按钮往屏幕外拖一点，但clamp会阻止它跑出这个范围，松手后无论它在哪，都还处于“藏一半”的状态范围内，吸边动画的起点和终点不会出现跳变。

3.3 吸边计算：拿中心点到左右边缘的距离比大小

吸边逻辑的核心非常简单：判断按钮中心点离屏幕左边缘更近还是离右边缘更近，离哪边近就吸哪边。

dart复制void _snapToEdge() {
  final centerX = _left + widget.size / 2;
  final half = _screenWidth / 2;
  final bool shouldHitLeft = centerX < half;

  setState(() {
    _hitLeft = shouldHitLeft;
    if (shouldHitLeft) {
      _left = widget.hiddenWidth - widget.size;
    } else {
      _left = _screenWidth - widget.hiddenWidth;
    }
    _top = _top.clamp(_minTop(), _maxTop());

    if (widget.autoHideOnSnap) {
      _expanded = false;
    }
  });
}

这个计算为什么用中心点而不是按钮边缘？你可以试想一个场景：按钮四分之三都在屏幕右侧，只有左边一小部分超过了中线。如果按按钮的左边缘来判断，它离左边缘还挺远，但实际上用户松手时按钮的重心已经在右边了，强行吸回左边会让用户体验很分裂。用中心点来判决，整个按钮视觉上的“归属感”更强，吸边方向也符合用户直觉。

吸边完成后，如果autoHideOnSnap为true，就把_expanded置为false，让按钮进入隐藏一半的形态。

3.4 展开与收起的动画状态切换

吸边状态下按钮露出一截，用户点击这截露出的部分，按钮需要滑出来完全展开。这个动画我直接交给了AnimatedPositioned，它会在left、top这些属性变化时自动插值过渡。

展开和收起的核心方法是_toggleExpand：

dart复制void _toggleExpand() {
  setState(() {
    _expanded = !_expanded;
    if (_expanded) {
      // 完全展开：恢复到正常边距位置
      if (_hitLeft) {
        _left = 8;
      } else {
        _left = _screenWidth - widget.size - 8;
      }
    } else {
      // 收起：回到吸边隐藏位置
      if (_hitLeft) {
        _left = widget.hiddenWidth - widget.size;
      } else {
        _left = _screenWidth - widget.hiddenWidth;
      }
    }
  });
}

展开状态下，如果是吸在左边，left恢复到8（正常margin），按钮完整显示在屏幕内；吸在右边则同理。收起时left又回到那个“藏一半”的值。

动画的时长和曲线我在AnimatedPositioned里已经配好了：拖拽过程中duration为0，按钮跟手移动不会有延迟感；松手吸边或者点击展开收起时，切换到300毫秒加easeOutBack曲线，会有轻微的反向回弹，吸边动作看起来很灵动，而不是生硬地平移过去。

3.5 点击与拖拽的边界：用位移阈值区分“想点”和“想挪”

悬浮按钮上同时存在点击和拖拽两种手势，这里有个平台差异值得注意。Flutter的GestureDetector在同时注册onTap和onPan时，会根据手势竞技场机制自动裁决：如果手指在按下后产生了超过touch slop（默认约18像素）的位移，就判定为拖拽，onTap不会触发；如果手指按下后基本没动就松开了，则判定为点击。

所以理论上我不需要额外写阈值判断。但实际测试时我发现一个体验问题：用户快速滑动时，即使位移没到18像素，系统可能在onPanEnd的时候已经做了吸边判断，随后onTap又触发了展开，导致按钮刚吸完边又弹出来，看起来很诡异。

我后来在_handlePanEnd里加了一个总位移量判断，用onPanDown时记录的起始坐标和onPanEnd时的结束坐标做差：

dart复制Offset _downPosition = Offset.zero;

void _handlePanDown(DragDownDetails details) {
  _downPosition = details.globalPosition;
  setState(() => _isDragging = true);
}

void _handlePanEnd(DragEndDetails details) {
  final distance = (details.globalPosition - _downPosition).distance;
  setState(() => _isDragging = false);
  if (distance < 8) {
    return; // 位移太小，交给onTap处理
  }
  _snapToEdge();
}

这里我用了8像素作为阈值，比系统touch slop更严格一些。如果位移小于8像素，就判定为点击，不执行吸边逻辑，把事件完全交给onTap去处理，这样就不会出现“吸边后又展开”的冲突。

4. 让这个组件能真正上线用的细节

4.1 屏幕旋转、安全区和路由切换后的位置校正

在真机上跑一段时间你就会发现，光把按钮放到页面里还不够，还得处理各种环境变化。

首先是安全区。不同手机的底部home条高度不一样，刘海屏的顶部高度也不一样。如果left和top用的是硬编码数值，iPhone 14 Pro和一台千元安卓机上的表现会差很多。我建议在组件内部统一用MediaQuery的padding来获取安全区，而不是自己写死状态栏高度。

其次是屏幕旋转。竖屏状态下用户把按钮拖到了右下角，横屏后屏幕尺寸变了，按钮可能跑到屏幕外面去。这个问题我一般用WidgetsBindingObserver来监听尺寸变化：

dart复制@override
void didChangeMetrics() {
  final size = MediaQuery.of(context).size;
  final padding = MediaQuery.of(context).padding;
  setState(() {
    _screenWidth = size.width;
    _screenHeight = size.height;
    _safeTop = padding.top;
    _safeBottom = padding.bottom;
    // 重新校正位置
    _left = _left.clamp(_minLeft(), _maxLeft());
    _top = _top.clamp(_minTop(), _maxTop());
  });
}

注意didChangeMetrics是在系统metrics变化后调用的，包括屏幕旋转、键盘弹出、分屏等。这里面最常出问题的其实是键盘弹出。比如用户在评论框里输入文字，键盘弹出来后整个布局被压缩，如果你的页面不是用Scaffold的resizeToAvoidBottomInset默认行为（默认是true），悬浮按钮的位置就会跟着乱跳。至少要在didChangeMetrics里对top重新clamp，保证键盘弹起来时按钮不会被推到屏幕外面。

4.2 位置记忆：下次启动还停在老地方

用户把悬浮球拖到了一个自己习惯的位置，结果App重启后它又回到了初始位置，这个体验挺糟的。实现位置记忆并不难，用shared_preferences存两个值就够了。

我推荐存比例而不是绝对坐标，因为不同屏幕宽度下绝对坐标没有意义。比如用户把按钮放在屏幕高度30%的位置，那存的就是0.3这个比值，下次启动时用新的屏幕高度乘以0.3还原出top值。

dart复制Future<void> _savePosition() async {
  final prefs = await SharedPreferences.getInstance();
  await prefs.setBool('ball_hit_left', _hitLeft);
  await prefs.setDouble('ball_vertical_ratio', _top / (_screenHeight - widget.size - _safeBottom));
}

Future<void> _loadPosition() async {
  final prefs = await SharedPreferences.getInstance();
  final hitLeft = prefs.getBool('ball_hit_left') ?? false;
  final ratio = prefs.getDouble('ball_vertical_ratio') ?? 1 / 3;
  setState(() {
    _hitLeft = hitLeft;
    _top = ratio * (_screenHeight - widget.size - _safeBottom);
    _left = hitLeft
        ? widget.hiddenWidth - widget.size
        : _screenWidth - widget.hiddenWidth;
  });
}

调用时机上，_savePosition在每次吸边完成后调用即可，_loadPosition在initState里异步调用。

4.3 如果按钮内容很复杂，拖拽卡顿怎么办

默认实现里，拖拽时每次onPanUpdate都会调setState触发整个按钮子树重建，包括Container的装饰、阴影、子组件。如果按钮里只是放一个Icon，完全没压力；但如果哪一天产品要求在悬浮球里塞一个实时变化的头像、几行文字甚至一个小动画，那每次setState都会带来不必要的性能损耗。

一个简单的优化思路是拖拽时不用setState改left和top，而是改用Transform.translate。做法是：Positioned的left和top保持在一个相对稳定的基准值，拖拽时通过Transform.translate做视觉位移，松手后再把基准值和位移量合并计算最终位置，用setState落到Positioned上。

实现上会复杂一些，但原理不复杂：

dart复制// 拖拽中
Transform.translate(
  offset: Offset(_dragOffsetX, _dragOffsetY),
  child: Positioned(
    left: _baseLeft,
    top: _baseTop,
    child: yourChild,
  ),
)

这样拖拽过程中只有Transform层在变化，不触发按钮子树的rebuild。不过说实话，如果你的按钮内容真的很重，更彻底的方案是用RepaintBoundary把按钮包一层，或者干脆把内容部分复杂度降下来。我实际项目中大部分场景按钮就一个Icon，setState方案完全够用，这个优化了解思路就行。

4.4 全局悬浮：从单页面扩展成Overlay形式

前面实现的是单页面内悬浮，切页面按钮就没了。如果产品要求全局悬浮，就需要把组件挂到App根部的Overlay上。

Overlay方案的核心是OverlayEntry，它可以把任意Widget插入到Overlay里。关键代码是：

dart复制class GlobalBallManager {
  static OverlayEntry? _entry;
  static void show() {
    _entry = OverlayEntry(builder: (_) => SnapDockButton(...));
    Overlay.of(navigatorKey.currentContext!)!.insert(_entry!);
  }
  static void remove() {
    _entry?.remove();
    _entry = null;
  }
}

这里有一个前提条件：项目里需要有一个全局的navigatorKey，否则在非页面上下文中拿不到Overlay。我在项目里通常是先在MaterialApp里配置好navigatorKey：

dart复制MaterialApp(
  navigatorKey: globalNavigatorKey,
  ...
)

然后用globalNavigatorKey.currentContext去取Overlay。注意Overlay的层级非常高，它盖在所有页面之上，所以悬浮按钮不会因为页面切换而消失。

Overlay方案还有一个好处：页面的所有路由切换、弹窗展示都不会影响它，因为它和Navigator是同一层级的。坏处则是，吸边位置的记忆和恢复逻辑要自己维护全局状态，不能像页面内组件那样随State销毁。

5. 我实际踩过的几个坑

5.1 吸边后按钮点不出展开效果

这是我调试时遇到的第一个诡异问题。吸边功能做完后，按钮也正常藏了一半，但点击露出的那半截，onTap怎么都不触发。

排查后发现原因在Stack的clipBehavior。如果不设置Clip.none，Stack默认会把超出布局范围的子Widget裁剪掉。按钮吸到左边时，left是负数，按钮左边部分确实在屏幕外，但它右边露出的20像素应该还在屏幕内。按理说露出部分可点击才对，但由于裁剪默认开启，整个按钮被裁成了一个不规则的形状，GestureDetector的点击区域计算也受到了影响，导致点击事件命中不到。

解决方式就是在Stack上显式设置clipBehavior: Clip.none。这个设置让按钮可以绘制到Stack边界之外，但同时也要注意，如果外面再套一层其他容器，那层容器的clipBehavior也可能影响，需要逐层排查。

另外还有一个点击区域的问题：GestureDetector的behavior默认是deferToChild，也就是只有child实际绘制的区域才能响应点击。吸边状态下，按钮的实际可视区域只有20像素宽的一小条，用户要精准点中它其实不太容易。所以我把它调整成了HitTestBehavior.opaque，让整个矩形区域（包括屏外部分在屏内的投影区域）都能参与点击判定，加大命中范围。

5.2 拖拽后松手，按钮“弹”到奇怪的位置

还有一次测试发现，按钮拖到屏幕底部松手，它会突然弹到状态栏附近，位置完全不在预期范围内。

后来定位到问题是top的clamp范围算错了。我一开始写的是：

dart复制_top = _top.clamp(0.0, _screenHeight - widget.size);

这个0.0的意思是“顶部可以从屏幕最顶端开始”。但屏幕最顶端其实是状态栏，系统状态栏区域的触摸事件是不归App管的，而且按钮如果拖到状态栏上，视觉上也会被状态栏时间、电量这类信息干扰。

正确做法是把顶部边界设置成安全区的top，把底部边界设置成屏幕高度减按钮高度减底部安全区。修正后按钮拖到最上边就贴着状态栏底部停住，拖到最下边也不会挡住系统导航条。

5.3 AnimatedPositioned拖拽时总觉得慢半拍

吸边动画我用easeOutBack曲线做了回弹，效果很灵动。但问题是，这个动画同样作用在了拖拽过程中。手指拖动按钮时，AnimatedPositioned会对每次left变化都走一遍300毫秒的动画，表现出来就是按钮永远比手指慢半拍，有一种黏糊糊的滞后感。

解决方式就是前面代码里写的：拖拽期间把duration设为Duration.zero，松手后才切回300毫秒。这里的关键是_isDragging这个状态要维护准确，特别是onPanEnd之后，要先把_isDragging置为false再执行吸边计算，动画才能从当前位置平滑过渡到目标位置。

5.4 与系统边缘返回手势的冲突

如果你的App在Android上启用了预测性返回手势（Android 10以上的手势导航），屏幕左右边缘从外向里滑是系统返回手势。悬浮按钮吸在左边边缘时，用户从屏幕边缘往右滑想要拖拽按钮，很容易被系统识别成返回手势。

这个问题没有完全完美的解法，我只能分享几个缓解思路。一是把默认吸边位置设在右侧，因为大部分人右手操作，右侧吸边更顺手，也避开了左侧的返回手势热区。二是吸边状态下，把按钮可拖拽的起始区域稍微向屏幕内侧偏移一点，比如露出宽度从20调到24，让用户的手指更容易按到露出的部分，减少误触系统手势的概率。

还有一个思路是，按钮吸边后检测到快速滑动（velocity大于某个阈值），优先触发吸边动画而不是进入拖拽状态，但这个实现起来复杂，而且会牺牲拖拽的跟手性，我最终没采用。

5.5 底部弹窗里的TextField把按钮顶飞

这个坑比较隐蔽，是热搜词里也出现的“flutter底部弹窗内有text field”相关场景。当页面底部弹出一个带输入框的弹窗时，Scaffold会为了给TextField腾出键盘空间而缩小body区域，如果你把悬浮按钮放在body的Stack里，它就会被键盘顶上来说不准跑到哪里去。

解决方式一般有两种：一是把悬浮按钮放到Scaffold的floatingActionButton位置，因为FAB是Scaffold层的组件，不受body区域缩放影响；二是监听键盘的显示和隐藏事件，在键盘弹出时隐藏悬浮按钮。考虑到悬浮按钮通常要被用户随时操作，键盘弹出时直接隐藏是最干净的处理，键盘收起后再恢复。

最后再分享一点实战心得

这个组件整套写完以后，我在两个项目里复用过了，每次都是复制源码微调参数就能用。最让我觉得值得的，是把“吸边”和“隐藏”这两个细节真正想透了的那几分钟——中心点判决、clamp边界、动画时长的区分，这些看起来不起眼的细节，决定了这个按钮用起来是“顺手”还是“难受”。

如果你要把这个组件放到自己的项目里，我建议拿到代码后先改三个东西：按钮颜色改成和App主题匹配、吸边露出宽度按实际图标复杂度调一调（我试过16像素太窄，22到24像素最舒适）、把onTap回调接成你自己的业务逻辑。改完这三个地方，这个悬浮球就真正属于你的项目了。另外，如果你的Flutter版本比较新（3.16以上），注意把项目SDK约束拉高，这个组件里用到的API都很基础，兼容性完全没问题。