Design intuitive search experiences
Design 进阶 16m

设计直观的搜索体验

Design intuitive search experiences

2026年6月10日

在 Apple 官方观看视频

一句话判断

✅ iOS 搜索框官方终于“妥协”推荐放底部工具栏了，配合全新的 Liquid Glass（液态玻璃）材质，大屏手机的单手搜索体验迎来史诗级救赎。

这场 Session 讲了什么

过去几年 iOS 搜索框死磕顶部导航栏，大屏手机单手够不着的痛点被开发者吐槽了无数遍。这次 HIG（人机界面指南）明确转向，强烈推荐将搜索入口放在底部工具栏（Bottom Toolbar），并在激活时让搜索栏优雅地上移至键盘上方。对于标签式应用（Tabbed Apps），Apple 提出了“搜索标签（Search Tab）”范式，分为带落地页的标准标签和直接弹键盘的突出按钮标签。

在 iPad 和 Mac 端，搜索体验与 iOS 进行了对齐，主要收拢在工具栏后置位置（Toolbar trailing）或侧边栏顶部（Sidebar top）。系统会自动根据所在容器应用 Liquid Glass 材质或标准内容样式，开发者不需要再手动去调那些半透明模糊背景的参数。

这对做内容消费、邮件、文档和媒体类 App 的团队影响最大。你需要重新审视现有的 .searchable 放置逻辑，特别是那些还在用自定义顶部搜索栏、且没有适配大屏人体工程学的老项目，现在有了官方的“尚方宝剑”去推动 UI 重构。

值得深挖的点

底部搜索与 Liquid Glass 的人体工程学博弈

把搜索框从顶部挪到底部，听起来只是改个 Y 轴坐标，背后的交互重构却相当繁琐。Apple 这次推荐底部工具栏搜索，是为了解决 6.7 英寸设备上“拇指够不到顶部”的物理限制。当搜索框在底部时，点击后它不会原地弹键盘，而是向上动画到键盘上方，这个过渡动画是系统级接管的，保证了视觉连贯性。

配合 WWDC26 引入的 Liquid Glass 材质，底部工具栏不再像以前那样显得笨重。玻璃效果让底部的搜索框在视觉上“透气”，不会遮挡下方列表内容的滑动。这里的 trade-off 在于，底部空间寸土寸金，如果你的工具栏已经有 3 个以上的按钮，搜索框就必须折叠成一个放大镜按钮（Button），点击后再展开成输入框（Field）。这种“先按钮后输入框”的二级交互会增加一次点击成本，但在空间受限时的确是保全体面做法。相比以前开发者自己用 UIViewPropertyAnimator 硬写底部搜索上移动画，现在系统原生的 .searchable 配合底部放置，省去了处理键盘遮挡和手势冲突的无数个通宵。

Search Tokens（搜索标记）让过滤条件“自然语言化”

传统的搜索过滤通常依赖 Scope Bar（范围栏）或者隐藏的 Filter 菜单。Scope Bar 只能做单选（比如“全部/发件箱/草稿”），而 Filter 菜单层级太深。这次 Session 重点推了 Search Tokens，也就是在搜索框里以“药丸”形态存在的过滤标签。

以照片 App 为例，你可以输入“2021”，系统生成一个年份 Token，再输入“约书亚树”，生成一个地点 Token。这种设计把结构化的数据库查询，伪装成了自然语言对话。它的优势在于极高的灵活性，用户可以随意组合、删除条件，而不需要在多层级的菜单里来回跳转。

但坑也很明显：Token 的可发现性（Discoverability）极低。普通用户看着一个空搜索框，根本不知道可以输入特定关键词来触发 Token。Apple 在 Session 里也承认了这一点，并明确建议“不要用 Token 替代 App 中更可见的过滤界面”。正确的做法是，在搜索建议列表（Suggestions）或者专门的过滤面板中，提供显式的按钮，用户点击这些按钮后，系统再将其转化为搜索框里的 Token。

代码片段

1. 底部工具栏搜索 (iOS)

场景：将搜索框放置在底部工具栏，利用系统原生的上移动画和 Liquid Glass 材质。

struct MailListView: View {
    @State private var searchText = ""
    
    var body: some View {
        NavigationStack {
            List { /* 邮件列表内容 */ }
                // 将搜索框绑定到视图
                .searchable(text: $searchText, prompt: "搜索邮件")
                .toolbar {
                    // 确保工具栏在底部，系统会自动处理搜索框的动画和材质
                    ToolbarItemGroup(placement: .bottomBar) {
                        Button(action: {}) { Image(systemName: "tray") }
                        Spacer()
                        // 搜索框会自动适配这里的空间
                        Spacer()
                        Button(action: {}) { Image(systemName: "square.and.pencil") }
                    }
                }
        }
    }
}

坑：如果底部工具栏元素过多，系统会将搜索框折叠为按钮。别试图在 .bottomBar 里强行塞入 5 个以上的图标，会导致搜索按钮被挤出屏幕或触发奇怪的布局截断。

2. 使用 Search Tokens 实现自然语言过滤

场景：在搜索框中支持“标签化”的过滤条件，如按发件人或日期过滤。

struct TokenSearchView: View {
    @State private var searchText = ""
    @State private var tokens: [SearchToken] = []
    
    var body: some View {
        NavigationStack {
            List { /* 搜索结果 */ }
                .searchable(
                    text: $searchText,
                    tokens: $tokens,
                    prompt: "搜索信息"
                ) { token in
                    // 渲染 Token 的 UI
                    Label(token.name, systemImage: token.icon)
                }
                // 提供搜索建议，用户点击后转化为 Token
                .searchSuggestions {
                    ForEach(suggestedFilters) { filter in
                        Button {
                            tokens.append(SearchToken(name: filter.name, icon: filter.icon))
                        } label: {
                            Label(filter.name, systemImage: filter.icon)
                        }
                    }
                }
        }
    }
}

struct SearchToken: Identifiable, Hashable {
    let id = UUID()
    let name: String
    let icon: String
}

坑：Token 的删除逻辑是系统接管的（用户点击 Token 上的 ‘x’ 或按退格键），你不需要手动写删除手势。但如果你绑定的 tokens 数组没有正确实现 Hashable，UI 会出现闪烁或无法删除的 Bug。

3. 优雅处理搜索空状态

场景：当搜索没有返回结果时，展示系统标准的“内容不可用”视图，避免留白让用户困惑。

struct SearchResultsView: View {
    let searchText: String
    let results: [Item]
    
    var body: some View {
        if results.isEmpty && !searchText.isEmpty {
            // 使用系统预设的搜索空状态视图
            ContentUnavailableView.search(text: searchText)
        } else {
            List(results) { item in
                Text(item.title)
            }
        }
    }
}

坑：ContentUnavailableView.search 会自动提取 searchText 并高亮显示，帮用户检查拼写错误。千万别自己手写一个“未找到结果”的 Text，不仅丑，还丢失了系统自动适配深色模式和动态字体（Dynamic Type）的能力。

最佳实践

  • 已有项目的迁移策略：别急着把全局搜索全挪到底部。先评估你的导航结构，如果是重度依赖底部 Tab Bar 的应用，把搜索放在 Tab Bar 上方容易引发误触。对于这类应用，优先考虑新增一个独立的 Search Tab（搜索标签），并在里面提供全局搜索的 Landing Page。
  • 新项目的采用建议：无脑使用 SwiftUI 的 .searchable 修饰符，并让系统决定它的外观。在 iOS 上尽量利用底部工具栏，在 iPad/Mac 上放在侧边栏顶部或工具栏右侧。把精力花在完善 Search Suggestions（搜索建议）和 Recent Searches（最近搜索）的数据源上，这才是提升转化率的关键。
  • 实战中容易踩的坑：最近搜索（Recent Searches）在 iOS 上必须在输入框获得焦点时内联显示，而在 iPad/Mac 上如果搜索框在侧边栏，应该放在下拉菜单里。很多开发者用同一套 UI 逻辑跑全平台，导致 Mac 端侧边栏弹出一个巨大的全屏搜索建议列表，极其违和。

还有什么值得关注

  • 取消按钮的回归：在 iOS 上，当搜索框获得焦点时，系统会自动在右侧显示“取消”按钮，点击可同时退出搜索并收起键盘，省去了开发者自己监听键盘事件的麻烦。
  • 侧边栏搜索的边界划定：在 iPad/Mac 的侧边栏放搜索框时，HIG 明确建议仅用于过滤侧边栏本身的内容（如设置 App），不要用它去搜索右侧详情视图里的内容，以免造成用户认知混乱。
  • 预测建议的视觉区分：在展示 Predictive suggestions（预测建议）时，系统要求必须在视觉上区分“用户已输入的文本”和“系统补全的灰色预测文本”，保持搜索自然延伸的语感。
Search Human Interface Guidelines SwiftUI Liquid Glass ContentUnavailableView