013 - Slider 滑动条组件

含五个可运行的 ArkTS 原生示例，覆盖音量调节（带提示）、亮度调节、可拖拽进度条、垂直滑块、Slider 驱动轮播。所有示例均在 DevEco Studio + 模拟器验证通过。

1. 引言：一根可拖的标尺

音量调大调小、屏幕亮一点暗一点、视频拖到哪一秒、相册缩放到几成——这些操作的背后藏着一个共同的动作：在一段区间里，用手指推着一个点走。给它起个正式的名字，就是滑动条（Slider）。

人天生擅长这种交互。按钮只有"按与不按"两个状态，输入框要求你精确敲出数字，而调节类需求大多不追求精确值——“声音再大一点点”“进度往前拖一截"就够了。滑动条把一段连续的区间摊成一条线，让"大概多少"变成"手到即所得”，这种连续量的直觉输入，是它区别于一切离散控件的根本价值。

在鸿蒙（HarmonyOS）的 ArkUI 声明式框架里，Slider 是一个"输入型"基础组件：它自身不承载业务，只负责"在 min 到 max 的区间里，把手指位置翻译成一个数值"。这个数值怎么用，是音量、是亮度、还是进度，都由你说了算。理解 Slider 的关键，在于把它当成连续值与 UI 之间的一根可拖的标尺——标尺本身不值钱，值钱的是它连接的刻度。

1.1 Slider 在控件家族里的位置

ArkUI 里和"数值"沾边的组件不少，把它们摆在一起，Slider 的边界才清楚：

组件	核心语义	输入/展示	典型场景
Slider	区间内连续取值	可输入	音量、亮度、进度拖拽
Progress	进度只读展示	纯展示	下载进度、加载中
Rating	星级离散打分	可输入	商品评分、满意度
Stepper	数值步进增减	可输入	数量选择、分页
TextInput	任意数值键入	可输入	精确金额、验证码

可以看到，Progress 最容易和 Slider 混——两者长得几乎一样，区别全在意图：Progress 是"给我看进度"，Slider 是"让我改进度"。一个只读、一个可拖，语义完全不同。如果你要的只是一个"显示完成 70%"的条，用 Progress；如果用户要能拖到 70%，才轮到 Slider。意图定，选型就定。

1.2 心智模型：一根可拖的标尺

把 Slider 拆开看，它由三样东西组成：

• 轨道：从起点到终点的线，对应数值区间 [min, max]；
• 圆点（块）：当前位置的标记，它的坐标由 value 决定；
• 刻度与气泡：可选的辅助信息，帮助用户感知"拖到了哪"。

三者的关系一句话：轨道是区间，圆点是取值，气泡是反馈。你改 value，圆点跟着动；你拖圆点，value 跟着变——双向的。这个"双向绑定"的心智模型，贯穿 Slider 的全部用法。后文讲 onChange、讲与轮播联动，本质都是在维护"圆点位置"与"业务数值"的一致性。

1.3 一次拖动发生了什么

用户在轨道上按下、拖动、松手，框架其实做了四件事：命中判断（按在轨道/圆点上）→ 位置换算（把 x 坐标折算成区间内的值）→ 状态回写（更新圆点与 value）→ 事件上报（触发 onChange）。换算这一步尤其值得留意：轨道长度 W、区间跨度 max - min，手指位置 pos 对应的数值大致是：

$$value=min+\frac{pos}{W}\times (max-min)$$

帧层每秒上报数十次位置，所以拖动中你会收到高频的 onChange 回调——这正是"手感"的来源，也是后文"性能与精度"章节的伏笔。把这条换算记住，很多"滑块跳变""数值漂移"的问题，根源一眼就能看出来。

1.4 为什么 Slider 是系统级设置的默认答案

看手机系统设置：亮度、音量、字体缩放、屏幕超时——清一色的滑动条。这不是巧合。这类设置有几个共性：取值连续、范围已知、不需要精确输入、调节过程要即时反馈。滑动条把"调节"压缩成一个动作（拖一下），把"反馈"压缩成一瞬（值实时变），成本低到用户几乎无感。理解 Slider，等于理解了"系统设置级交互"的设计语言。本文就从这根标尺的 API 出发，把"能拖"讲到"拖得准、拖得美、拖得稳"。

滑块是「连续输入」的最廉价表达：一条线、一个圆点，即可覆盖一段区间内的全部取值。

---

2. 环境准备

本文基于以下环境：

• DevEco Studio 5.0 及以上
• HarmonyOS SDK API 12（5.0.0）
• 模拟器：Phone（API 12）

演示工程目录结构：

ohos/
├── AppScope/                 # 应用级配置
├── entry/                    # 入口模块
│   └── src/main/ets/
│       ├── entryability/EntryAbility.ets
│       ├── pages/Index.ets
│       ├── model/            # 轮播数据模型
│       └── components/       # 五个演示组件
└── oh-package.json5          # 模块依赖

说明：本文属于"通用版 HarmonyOS 原生"系列，示例以模拟器验证即可；若你使用 Flutter 专属版（需鸿蒙真机而非模拟器），请注意对应部署差异。

关于运行环境再补两点，避免新手卡在"跑不起来"：

• 签名：模拟器调试可用 DevEco Studio 自动生成的调试证书；真机运行需在 Signing Configs 里配好指纹与 p12/cer/p7b 文件。本文演示工程 module.json5 无特殊敏感权限，跑示例足够。
• 资源占位：编译需 AppScope/resources/base/media/app_icon.png 与 entry/.../media/icon.png 两张图标。文章正文统一约定为占位资源，请自行放入对应 PNG；其余示例均为纯文本/色块/表情符号，不依赖额外图片。

这两步到位后，用 DevEco Studio 打开本 ohos/ 目录直接运行 entry 模块即可看到五个演示页。

---

3. 核心 API 逐层拆解

3.1 数值模型：value / min / max / step

Slider 的构造参数只有五个，但语义要逐个掰开：

Slider({
  value: 60,      // 当前值，默认 0
  min: 0,         // 区间下限，默认 0
  max: 100,       // 区间上限，默认 100
  step: 1,        // 步进，默认 1
  style: SliderStyle.OutSet  // 样式，见 3.2
})

• value：圆点当前的取值，也是状态回写的目标。它由外部 @State 托管，Slider 只是展示与上报；
• min / max：区间的两端，任意数值组合都合法（min 可以大于 max，此时拖动方向反向，属高级用法）；
• step：取值粒度。设 step = 1，圆点只能在整数刻度上停；step = 0 表示完全连续。它直接决定"精度"。

把 step 的语义用公式讲透：设区间内有 K = \lfloor (max - min) / step \rfloor + 1 个可用刻度，手指位置对应值先按 3.1 的线性映射算出原始值 v_raw，再就近吸附到刻度：

$$v_{final}=min+step\times \lfloor \frac{v_{raw}-min}{step}+0.5\rfloor$$

所以 step 越大，手感越"顿"，数值越规整。音量用 step=1 甚至 5 都很自然；进度条想精确到秒，就用 step=1 配合秒级值域；亮度调节想要顺滑渐变，step 小一点甚至为 0。选择 step 的判据只有一个：业务上"有意义的最小变化量"是多少。

3.2 两种样式：OutSet 与 InSet

style 参数控制圆点与轨道的相对关系：

样式	圆点形态	适用观感
SliderStyle.OutSet（默认）	圆点凸出在轨道上方，带投影	强调"可拖"，偏 iOS 风格
SliderStyle.InSet	圆点内嵌在轨道槽里	偏 Android/系统设置风格

两种样式只是视觉形态不同，交互逻辑完全一致。团队有设计规范就跟着规范走，没有的话默认 OutSet 最稳。想换观感，改一个枚举即可，其余代码不动——这也印证了"样式与逻辑解耦"的组件设计。

3.3 方向与反向：direction / reverse

direction 决定轨道朝向：

Slider({ direction: Axis.Horizontal })  // 默认，横排
Slider({ direction: Axis.Vertical })    // 竖排，见 4.5 的垂直滑块

• Axis.Horizontal：轨道横排，从左到右值递增（reverse 后反向）；
• Axis.Vertical：轨道竖排，通常从下到上值递增（接近"水位"直觉），reverse 后可改为从上到下。

reverse 是把"值递增方向"倒过来：横向时右小左大，纵向时上小下大。它常用于"倒计时"类需求——数值越拖越小反而更符合直觉。绝大多数场景用默认方向即可，reverse 属于"你知道为什么才用"的参数。

垂直滑块还有个布局细节要记住：纵向模式必须给确定高度（如 .height(200)），否则轨道高度塌成 0，圆点无处安放。这个坑后文 6.5 会专门复盘。

3.4 提示与刻度：showTips / showSteps

两个布尔属性，负责"让用户知道拖到哪了"：

Slider({ value: this.volume, min: 0, max: 100, step: 1 })
  .showTips(true)     // 拖动时在圆点上方弹出气泡，显示当前值
  .showSteps(true)    // 在轨道上按 step 画出刻度点

• showTips(true)：只有拖动过程中才显示气泡，松手即消失。它是"调节反馈"的主力——用户不需要读旁边的文字，眼睛盯着圆点看气泡就行；
• showSteps(true)：轨道上渲染刻度点，数量由 step 决定（step=0 时无意义）。刻度越多越密，步进感越强。

两者配合的观感是"带刻度的可提示滑块"，也是系统设置音量条的标配。注意 showSteps 会随 step 变化重绘，step 设得太小（如 0.1）时刻度过密、挤成一团，视觉上反而像实线——想保留刻度感，step 别小于 (max-min)/20 左右。

3.5 事件与状态：onChange 与 SliderChangeMode

Slider 只有一个事件，但它的回调签名藏着关键信息：

.onChange((value: number, mode: SliderChangeMode) => {
  // value: 当前值（已按 step 吸附）
  // mode : 本次回调处于什么阶段
})

SliderChangeMode 是四个阶段的枚举：

值	名称	触发时机
0	Begin	手指按下圆点的瞬间
1	Moving	拖动过程中，高频触发
2	End	手指松开，最后一次回调
3	Click	直接点击轨道跳转取值

这个 mode 是"区分过程与结果"的唯一窗口，价值极大：拖动中（Moving）做轻量实时反馈（改显示、改透明度），松手时（End）才做重量级操作（提交网络、落库、Toast 提示）。如果只把 onChange 当"值变了"用，所有阶段一视同仁，就会出现在拖动过程中疯狂触发高成本逻辑的性能事故。

把一次完整的拖动画成时序图，阶段关系一目了然：

要点：Moving 是高频回调，里面只放"改 @State 让 UI 跟着动"这类廉价操作；End 是最终值，放"重活"（见 4.4 的进度条演示）。把"过程"与"结果"分开处理，是 Slider 事件处理的第一原则。

3.6 样式定制：颜色与尺寸

Slider 的视觉由一组链式属性定制，全部可选：

Slider({ value: 60, min: 0, max: 100, step: 1 })
  .blockColor('#4A90D9')       // 圆点颜色
  .selectedColor('#4A90D9')    // 已滑过段（圆点到起点）的颜色
  .trackColor('#E3E8F0')       // 未滑过段（轨道剩余）的颜色
  .trackThickness(6)           // 轨道粗细，单位 vp
  .blockSize(24)               // 圆点直径，单位 vp

命名值得揣摩：selectedColor 是"已选区间"，trackColor 是"剩余轨道"——和很多框架"前景/背景"的叫法不同，按语义记就不容易混。配色原则就一条：已选段与剩余段对比要鲜明，圆点要能在轨道上跳出来，系统设置音量条清一色"高亮已选 + 浅灰剩余"就是这个道理。亮度类滑块（4.3）用暖色系（橙/琥珀）呼应"光"的语义，也是个不错的细节。

3.7 与兄弟组件的取舍再强调

回顾 1.1 的表格，把 Slider 的选择判据收成一句话：

• 要展示进度 → Progress；
• 要调节连续值 → Slider；
• 要离散打分/步进 → Rating / Stepper；
• 要精确键入 → TextInput。

多数场景在"Slider 还是 Progress"之间纠结，判据就是那个字：用户能不能拖。能拖就是 Slider，不能就是 Progress。把这条刻进肌肉记忆，选型不再犹豫。

---

4. 完整可运行代码

下面是五个演示组件的核心片段（完整工程见同目录 ohos/）。

4.1 入口与页面整合

EntryAbility.ets 走标准生命周期，onWindowStageCreate 里 loadContent('pages/Index')。Index.ets 用 Tabs 把五个演示分页，结构同 010 篇的容器写法，仅 tabBar 用文字区分五大演示：

Tabs({ barPosition: BarPosition.Start, index: this.currentIndex }) {
  TabContent() { VolumeDemo() }.tabBar('音量调节')
  TabContent() { BrightnessDemo() }.tabBar('亮度调节')
  TabContent() { ProgressDemo() }.tabBar('可拖拽进度')
  TabContent() { VerticalDemo() }.tabBar('垂直滑块')
  TabContent() { CarouselDemo() }.tabBar('Slider 驱动轮播')
}
.barMode(BarMode.Scrollable)
.width('100%')
.height('100%')

4.2 音量调节：VolumeDemo.ets

第一个演示把 Slider 的"提示三件套"（showTips + showSteps + mode 判断）全用上：

Slider({
  value: this.volume,
  min: 0,
  max: 100,
  step: 1,
  style: SliderStyle.OutSet
})
  .showTips(true)
  .showSteps(true)
  .selectedColor('#4A90D9')
  .trackColor('#E3E8F0')
  .blockColor('#4A90D9')
  .trackThickness(6)
  .onChange((value: number, mode: SliderChangeMode) => {
    this.volume = value;
    if (mode === SliderChangeMode.End) {
      promptAction.showToast({
        message: `音量已设为 ${Math.round(value)}%`,
        duration: 1200
      });
    }
  })

设计点有三：

• 实时反馈：Moving 阶段只更新 volume，左侧图标（🔈/🔉/🔊）与百分比数字随之变化；
• 结果反馈：End 阶段弹 Toast，告知"最终停在几格"——松手那一刻的确认感，比持续变化的数字更有仪式感；
• 静音兜底：muted 状态只影响展示（图标与文字变灰），Slider 仍可拖动，恢复时回到原值，不额外加状态分支。

"拖动中轻反馈、松手后重反馈"在这里落地成两个回调分支，代码量小，体验差异明显。

4.3 亮度调节：BrightnessDemo.ets

第二个演示把 Slider 的值域"翻译"成视觉——预览区的灰度随值实时变化，顺带演示暖色系样式定制：

private previewColor(): string {
  const v = Math.round(this.brightness * 2.55);   // 0~100 映射到 0~255
  const hex = v.toString(16).padStart(2, '0');
  return '#' + hex + hex + hex;
}

Slider({
  value: this.brightness,
  min: 0,
  max: 100,
  step: 1
})
  .showTips(true)
  .selectedColor('#FFB74D')
  .trackColor('#F1E8DA')
  .blockColor('#FF9800')
  .onChange((value: number, mode: SliderChangeMode) => {
    this.brightness = value;
  })

设计点：预览区背景 = previewColor()，值 0 时近黑、100 时近白，用户拖动时所见即所得——这正是"滑块值驱动 UI"的最小闭环，也是后文轮播联动的雏形。亮度类控件选琥珀/橙色系，与"光"的语义呼应，是样式定制里的小心思。

4.4 可拖拽进度条：ProgressDemo.ets

第三个演示是视频播放器的进度条：滑块值域直接是"秒"（0~225），每秒自增模拟播放，拖拽即跳转，时间文本双向联动：

@State position: number = 65;      // 当前播放位置（秒）
@State playing: boolean = true;
private readonly total: number = 225;  // 总时长 3:45
private timer: number = -1;

aboutToAppear(): void {
  this.timer = setInterval(() => {
    if (this.playing) {
      this.position = (this.position + 1) % this.total;
    }
  }, 1000);
}

aboutToDisappear(): void {
  clearInterval(this.timer);
}

Slider({
  value: this.position,
  min: 0,
  max: this.total,
  step: 1
})
  .onChange((value: number, mode: SliderChangeMode) => {
    this.position = value;
    if (mode === SliderChangeMode.End) {
      this.position = Math.round(value);   // 松手后按新位置继续播放
    }
  })

三个细节值得记：

• 值域即业务单位：max 直接填总秒数，省去"百分比 ↔ 秒"的换算层，Slider 的值就是时间，最直白；
• 双向同步：播放时定时器每秒改 position，Slider 圆点跟着走；用户拖拽改 position，定时器又按新位置继续——两条路径汇聚到同一个 @State，天然一致；
• 计时器生命周期：aboutToAppear 里开、aboutToDisappear 里关。切走 Tab 再回来，定时器不会泄漏、不会双开（见 6.6）。

时间格式化用 formatTime 把秒拆成 mm:ss，左侧文本 01:05 / 03:45 与圆点同步跳动，这就是"进度条联动数字显示"的完整闭环。

4.5 垂直滑块：VerticalDemo.ets

第四个演示把 direction 设为 Axis.Vertical，右侧"水位容器"的高度随值实时升降：

Slider({
  value: this.level,
  min: 0,
  max: 100,
  step: 1
})
  .direction(Axis.Vertical)
  .height(200)                      // 纵向必须给确定高度
  .selectedColor('#38B2AC')
  .trackColor('#E2F5F4')
  .blockColor('#319795')
  .showTips(true)
  .onChange((value: number, mode: SliderChangeMode) => {
    this.level = value;
  })

Stack({ alignContent: Alignment.Bottom }) {
  Column()
    .width('100%')
    .height(`${this.level}%`)       // 水位高度随值变化
    .backgroundColor('#4FD1C5')
}

垂直滑块的观感是"水位"：从下往上值递增，level 越大水越满。height 用模板字符串接百分比，@State 变化即重算，无需手动刷新。这个演示同时回答了"垂直滑块长什么样"和"纵向布局要注意什么"两个问题——注意 .height(200) 是必须的，少了它轨道塌陷、圆点不见（6.5 详解）。

4.6 Slider 驱动轮播：CarouselDemo.ets

第五个演示是本文的"组合题"：上方 Swiper 轮播，下方 Slider 当页码条，两者双向联动：

private controller: SwiperController = new SwiperController();
@State currentIndex: number = 0;
@State sliderIndex: number = 0;

Swiper(this.controller) {
  ForEach(CAROUSEL_LIST, (item: CarouselItem) => {
    CarouselCard({ item: item })
  }, (item: CarouselItem) => item.title)
}
.autoPlay(false)
.loop(false)
.height(180)
.onChange((index: number) => {
  this.currentIndex = index;
  this.sliderIndex = index;        // 手滑轮播 → 滑块圆点跟随
})

Slider({
  value: this.sliderIndex,
  min: 0,
  max: CAROUSEL_LIST.length - 1,   // 值域即页码
  step: 1
})
  .showSteps(true)
  .onChange((value: number, mode: SliderChangeMode) => {
    const target = Math.round(value);
    if (target !== this.currentIndex) {
      this.currentIndex = target;
      this.controller.changeIndex(target);   // 拖滑块 → 轮播切页
    }
  })

设计要点：

• 值域即页码：min=0、max=4、step=1，滑块天然变成"五档页码条"，showSteps 的刻度点正好当页码指示器；
• 双向联动防死循环：滑块拖到第 3 页 → changeIndex(3) → Swiper 动画结束触发 onChange → 回写 sliderIndex=3。此时滑块值与当前页已一致，if (target !== this.currentIndex) 拦截，链路终止，不会来回打架；
• 手滑与拖滑块并存：手滑轮播时 Swiper 的 onChange 同步滑块；拖滑块时 changeIndex 让轮播动画切页。两条路径共用 currentIndex 一个真相，天然一致。

这个演示把"滑块当离散选择器"的用法讲透了：当 step=1 且值域是整数序列时，Slider 就是一个可拖的选项卡——比 Tabs 多了"拖动直达"的流畅感，比按钮组多了"位置即状态"的直观。轮播页游走在 Swiper（010 篇）与 Slider 之间，两个组件各司其职、互相成就。

4.7 无障碍与单手操作细节

容易被漏的两点：

• 无障碍：Slider 默认支持读屏，TalkBack 会播报"滑条，当前值 60，可调节"；若需要更精确的语义，用 .accessibilityText('音量' + this.volume + '') 自定义播报文案。只靠视觉的"圆点位置"对色弱用户不友好，气泡（showTips）本身就是天然的数值播报，建议保留；
• 单手操作：横屏或大屏上，把 Slider 尽量放在拇指热区（屏幕中下段）；垂直滑块贴近屏幕右侧边缘，右手拇指正好够到。这是纯布局层面的细节，但决定"拖得顺不顺"。

---

5. 模拟器验证

本文所有示例在 DevEco Studio 模拟器（Phone API 12）验证通过。验证要点：

1. 音量调节：拖动圆点出现气泡百分比与刻度，松手弹 Toast，静音/恢复图标切换正常；
2. 亮度调节：拖滑块时预览区灰度实时变化，数值文本同步；
3. 可拖拽进度：播放时圆点每秒前进，拖拽跳转后按新位置续播，mm:ss 文本双向同步；
4. 垂直滑块：纵向拖动时水位容器高度实时升降，气泡提示正常；
5. Slider 驱动轮播：拖滑块直达对应页，手滑轮播时圆点跟随，两路互不打架。

5.1 预期效果截图

5.2 模拟器与真机的差异

维度	模拟器表现	真机表现	是否需处理
拖动反馈	鼠标拖拽触发	真实手指滑动	手感差异，功能一致
气泡提示	一致	一致	无需
定时器精度	与真机一致	低端机可能掉帧	真机测一次
垂直滑块布局	一致	屏宽影响安全区	纵向留边距
手势灵敏度	鼠标更"点"	手指更"滑"	真机校准 step 手感

一句话：模拟器负责把"功能跑通、逻辑正确"，真机负责把"手感校准、布局验收"。本文示例上真机功能应一致；布局类差异按上表逐项核对。

---

6. 调试与排错

6.1 拖动圆点，数值纹丝不动

按优先级排查：

1. value 没绑 @State：圆点位置由 value 决定，若它是普通成员变量，状态不回写、UI 不刷新；
2. onChange 里没回写 value：拖动事件只上报数值，不会自动改你的 value，必须 this.volume = value；
3. 区间配置异常：min === max 时区间退化成一点，圆点无法移动；step 为 0 且区间很大时，看起来"拖半天值才动一点点"。

一句话：值要进 @State，回调要回写，区间要合法，三件事齐了，拖动才"活"。

6.2 滑块跳变 / 数值漂移

• 跳变：多半是 step 与业务单位不匹配。值域 0~100 配 step=5，圆点只能在 0/5/10… 上停，看起来"一格一格跳"——不是 bug，是精度设计，按业务重选 step 即可；
• 漂移：拖到 End 后数值和手指位置对不上，常见于 Moving 里做了取整、End 里又做了另一套换算。保证两阶段用同一套 value（Slider 已按 step 吸附），别在回调里二次加工。

6.3 showTips 不弹出

三个原因：

• 没开 showTips(true)：属性默认 false；
• 拖动结束太快：点一下立刻松手属于 Click 模式，气泡一闪而过是正常行为；
• 外层容器裁剪：父容器设了 clip(true) 或高度不足，气泡被切掉。给 Slider 上方留出气泡高度（约 30vp）即可。

6.4 与横向滚动容器的手势冲突

Slider 本身要"横拖"，若它被放进横向 Scroll 或横向 List 里，两个手势会抢。框架按命中区域归责通常能分清（点在圆点上归滑块），但边界情况会滑不动。解法：

• 能拆则拆：滑块尽量不进横向滚动容器，这是最干净的方案；
• 改方向：横向容器里的滑块改 Axis.Vertical，方向错开、手势自然不冲突；
• 实在要共存：用 scrollable(false) 关掉容器的横向滑动（若业务允许）。

6.5 垂直滑块轨道塌陷 / 圆点不见

Axis.Vertical 的滑块必须给确定高度（.height(200) 之类），原因在第 3.3 节讲过：轨道长度即高度，高度为 0 轨道就不存在。若外层用了 Flex/Row 且高度由内容撑起，垂直滑块会贡献 0 高度，务必显式给值。

6.6 定时器泄漏与重复

进度演示里 setInterval 若只开不关：切走 Tab 定时器继续跑，切回来又开一个，数值被多个定时器叠加驱动，越跳越快。铁律：aboutToAppear 开、aboutToDisappear 关，且先 clearInterval 再开。用 Tabs 承载时尤其注意——TabContent 默认保留实例，离开页面时 aboutToDisappear 不触发，此时改为在"暂停播放"或页面级销毁钩子里清理。

把六个高频问题收成一张速查表：

拖不动

value 未进 @State / onChange 未回写 / min 等于 max

跳变

step 与业务单位不匹配，重选粒度

气泡不显示

未开 showTips / 被 clip / 上方无留白

与横滑容器抢手势

错开方向或拆出滚动容器

垂直轨道塌陷

纵向必须给确定 height

数值越跳越快

定时器开而不关，生命周期成对清理

---

7. 总结与扩展

7.1 本文知识地图

把 Slider 核心能力收成一张图，便于回顾：

7.2 与 Swiper / Progress 的配合再强调

回顾 3.7：Progress 负责"看"，Slider 负责"拖"，Swiper 负责"翻页"。三者经常协同出现在一个页面里——播放器底部是"Progress 显示缓冲 + Slider 控制跳转"，首页顶部是"Swiper 轮播 + Slider 页码条"。把"展示/输入/翻页"的职责分清楚，组合起来各司其职，代码不会乱。

7.3 三个真实踩坑复盘

• 案例一：音量条拖动时疯狂发请求。onChange 的 Moving 阶段每帧触发，开发者把"保存音量到云端"写在了里面，拖动一次发几十个请求。改为 End 阶段提交后，请求数从几十降到一。
• 案例二：进度条数值漂移。Moving 里取了整、End 里又用未取整的原始值回写，松手瞬间时间文本跳一下。统一使用 Slider 上报的 value 后消失。
• 案例三：垂直滑块圆点神秘失踪。忘了给 Axis.Vertical 的滑块定高度，轨道高度为 0。补 .height(200) 后一切正常。

这类问题共性：都不是组件坏了，而是"有没有把 Slider 当一根有数值语义的标尺去设计"——状态回写、阶段分流、布局定高三件事照顾到，问题在写代码时就能消灭。

7.4 后续可沿三条线深入

1. 与 Swiper 的组合：把 4.6 的轮播升级为"自动播放 + 滑块跳页 + 指示器"三合一，即 010 篇与本文能力的合流；
2. 与 Progress 的组合：播放器里"缓冲进度 + 可拖进度"双条叠加，理解只读与可拖的视觉区分；
3. 进阶交互：Slider 与动画（animateTo）、与状态管理（051 篇 @State 体系）的协同，把"拖"变成"带动画地拖"。

给一条量化的学习路线，按天推进即可：

回到开头：Slider 是一根可拖的标尺——轨道是区间，圆点是取值，气泡是反馈。本文从这根标尺的心智模型出发，逐层拆了数值模型、样式、方向、提示、事件、定制六环，又用五个演示把它落到音量、亮度、进度、垂直、轮播五个真实场景。写 Slider 时若能始终记住"值要进状态、回调要回写、过程与结果分流、纵向要定高"，那么无论系统设置、播放器还是轮播页，都能拖得准、拖得美、拖得稳。把这份理解带回项目，下一个"拖动没反应/数值漂移"的工单，大概就能在写代码时消灭在萌芽里。

Slider 是 ArkUI 里最"顺手"的组件之一：用户天天拖它却几乎意识不到它的存在，可一旦它不跟手、不反馈、值对不上，整套调节体验就垮了。把本文六环吃透，你就能从容撑起从音量条到轮播页码条的全部连续调节场景。