一、前言：为什么需要「下拉快捷访问」？在 Craft、Apple Notes、Apple Music 等现代内容型应用中，有一个非常经典的交互动效：在可滚动页面的顶部继续下拉，会打开一个临时浮层。这个浮层不是页面跳转，也不是弹窗——它是从手势中"生长"出来的一个快捷入口。用户可以用它来：快速创建新笔记 / 新任务打开搜索面板触发命令行入口捕获临时的想法对开发者来说，这个交互看似简单，实际上涉及多个关键决策：下拉手势与页面滚动如何共存？快速入口用 Dialog？Popup？还是 OverlayManager？浮层打开后，底层页面还能滚动吗？下拉过程中的预览反馈应该怎么做？本文将基于ArkUILab项目的 E005 实验，从零讲解如何在鸿蒙 ArkUI 中实现一个完整的下拉快捷访问浮层。二、整体架构设计2.1 交互结构首先明确我们要实现的交互模型：可滚动 Home 页面 → 顶部边缘下拉 → Quick Access Overlay 出现 → Overlay 内显示一个 Card 容器对应的组件层级结构：ApplicationShell → PullDownQuickAccessShell → Scroll(Home, homeScroller) → 可滚动内容 → PullPreviewOverlay (预览态，在 Page tree 中) → Scrim 预览（背景遮罩） → QuickAccessCard (editable=false) → OverlayManager (正式态) → QuickAccessOverlayLayer → Scrim（背景遮罩 + 模糊） → QuickAccessCard (editable=true) → TextInput("快速开始") → 清空按钮 → 内滚动候选列表关键设计决策点：方案是否采用原因用 Navigation 页面跳转❌ 拒绝Quick Access 不应产生路由历史，也不改变当前页面层级用 Dialog 弹窗❌ 拒绝Dialog 适合确认/阻断式输入，Quick Access 是手势触发的空间浮层用 Popup 弹出❌ 拒绝Popup 通常锚定某个控件，Quick Access 锚定的是页面顶部边界用 OverlayManager✅ 采用位于 Page 之上、Dialog 之下，生命周期由当前 Page 管理，内容可自定义2.2 为什么分两段：预览态 vs 正式态？这是一个非常关键的架构判断：拖动预览态不应直接用 OverlayManager。原因：OverlayManager适合作为打开后的 Floating Layer，但没有连续跟手反馈的能力拖动过程需要实时响应手指位置：opacity、scale、translate 都要逐帧变化预览态留在 Page tree 中，用状态驱动@State变量，更自然松手触发后，再由 OverlayManager 的正式 Overlay 接管两段共享同一个QuickAccessCardCo