几年前我刚从 View 体系转到 Jetpack Compose 时，最不适应的不是布局写法，而是“点击反馈”这件事。在 XML 里一个?attr/selectableItemBackground就能搞定按压波纹，到了 Compose 里却发现一切要重新学。Indication就是 Compose 处理交互反馈的核心抽象，它决定了组件被点击、长按、拖动时，视觉上如何“回应”用户。这篇文章我会把 Indication 是什么、默认实现怎么工作、自定义一套反馈效果要踩哪些坑，一次性讲透。
Indication并不是一个高频词，但它藏在每一个Modifier.clickable背后。无论你是刚开始写 Compose 的新手，还是已经在项目里全面铺开 Compose 的开发者，理解这层机制都很有价值。它能帮你解释很多“为什么这里没有波纹”“为什么自定义反馈这么绕”的问题，也能让你在面对设计稿里那些花哨的按压动效时，不再只能靠graphicsLayer硬凑。
全文会从机制原理、默认行为拆解、自定义实现、坑点排查、性能优化五个角度展开。你可以把它当成一篇实战总结，也可以当成排错手册，按需翻阅。
1. 机制拆解：Indication 在 Compose 交互链路里的位置
1.1 从一次点击开始，事件经历了什么
要理解 Indication，得先看 Compose 的交互事件流。用户在屏幕上点一下，系统会把这个触摸事件交给 Compose 的PointerInputService，经过命中测试确定当前触摸位置对应哪些组件，然后按层级分发。Modifier.clickable内部会注册一个ClickableNode，它监听按压、抬起、取消等一系列指针事件，最终对外回调onClick。
事件链路很长，但 Indication 挂在哪个环节，很多人没有仔细想过。它在Modifier.clickable内部处于“反馈层”，当ClickableNode感知到指针状态变化时，会调用MutableInteractionSource发射交互事件。常见的交互状态有三种：
PressInteraction.Press：手指按下，携带按压位置。PressInteraction.Release：手指抬起，不再按压。PressInteraction.Cancel：按压被取消，比如滑动到组件外面。
MutableInteractionSource是连接事件源和反馈效果的桥梁。clickable、combinedClickable、toggleable、selectable这些修饰符内部都有它的引用，并通过它向外发射交互状态。而Indication接收这些状态，负责把状态变化转化成视觉反馈。
一句话总结交互链路：手势事件 → InteractionSource 发射状态 → Indication 消费状态 → UI 更新。这个链路是理解所有自定义反馈效果的基础，不管你把 Indication 的 API 用得再怎么花哨，底层都是这么流转的。
1.2 InteractionSource 与 Indication 各自的分工
有不少人会把InteractionSource和Indication混为一谈，其实它们职责完全不同。
InteractionSource是“交互状态的通知器”。它是一个接口，定义了tryEmit(interaction: Interaction)和collect(interaction: Interactions: Interaction, collector: FlowCollector<Interaction>)两个方法。组件通过它告知外界“我正处于什么状态”。它不关心状态如何表现，只负责数据的产生。
Indication则是“交互状态的渲染器”。它接收InteractionSource，返回一个Modifier。这个 Modifier 会通过侧效应（Side Effect）订阅 interaction 流，每次状态变化时更新对应的绘图层级，最终改变视觉表现。它不关心手势具体怎么产生，只负责“状态进来之后怎么画”。
所以标准的分工是：InteractionSource管“发生了什么”，Indication管“看起来怎样”。如果你需要监听长按、聚焦、拖拽等状态来做非视觉逻辑（比如上报埋点、联动其他组件），直接用InteractionSource.collect就够了，不需要经过 Indication。反过来，你要是只想要一个视觉反馈，而不想处理原始手势，只处理 Indication 即可。
1.3 为什么说 Indication 是一个“依赖注入”的机制
很多开发者第一次接触Modifier.clickable的重载时会困惑，为什么一个点击修饰符要带上interactionSource和indication这两个看起来不相关的参数。其实这里藏着 Compose 一个重要的设计思想：把交互行为和视觉反馈解耦，通过参数注入实现灵活替换。
clickable的核心实现接收两个参数：
fun Modifier.clickable( interactionSource: MutableInteractionSource?, indication: Indication?, ... )interactionSource为 null 时，内部会创建一个新的实例；indication为 null 时，会从LocalIndication中读取当前环境默认值。这意味着同一套点击逻辑，可以完全不用修改内部代码，只替换Indication对象，就能实现波纹、发光、缩放、阴影等完全不同的反馈风格。
这跟后端开发里的依赖注入思路一致：点击行为是核心逻辑，反馈是外挂效果。你把反馈抽象成接口，具体实现由调用方决定。这样设计的好处是 Compose 自带的基础组件（Button、Card、ListItem 等）都能共用一套反馈逻辑，而 Material 主题的更新也只需要切换LocalIndication的值，不需要重写所有组件。
2. 默认行为：Material 的 RippleIndication 是怎么工作的
2.1 Ripple 的两个阶段：按下与扩散
Material 主题下的默认 Indication 是RippleIndication，它实现的反馈效果是水波纹。这个效果分两个阶段：
第一阶段是按下瞬间。手指接触屏幕，波纹以按下的位置为圆心，以初始半径渲染一个带透明度的圆形。这个阶段视觉上通常看起来像是“颜色变深”，因为初始波纹半径很小，颜色叠加在组件表面。
第二阶段是扩散阶段。手指保持按住时，波纹不断向外扩散，直到覆盖整个组件的边界。Material 规范中，这个扩散过程通常是 300ms 左右到完整尺寸，但 Compose 会根据按压力度和持续时间做一定动态调整。如果用户在扩散完成前就松手，波纹会在松开位置以淡出方式收尾，而不是强行扩散完。
这个两阶段设计不是凭空拍脑袋的：它兼顾了“即时反馈”（按下瞬间屏幕必须有响应）和“状态表达”（按住期间持续显示高亮区域）。如果只有按下瞬间的颜色变化而没有扩散，界面会显得僵硬；如果只有扩散而没有按下瞬间的响应，用户会产生“卡了一下”的感知。
2.2 波纹状态机：从 Idle 到 Press 到 Release
Ripple 内部是一个状态机。从InteractionSource流中收集到的事件，会被映射成波纹的状态：
- 收到
PressInteraction.Press，如果当前没有其他按压点，波纹进入 Pressed 状态。 - 收到
PressInteraction.Release，如果这是最后一个按压点，波纹进入 Released 状态，开始淡出。 - 收到
PressInteraction.Cancel，波纹直接进入 Released 状态，但不会有扩散到完成的过程，而是迅速透明化。
对多点触控，Ripple 会维护多个按压点的映射关系。手指 A 按住时开始扩散，手指 B 再按下去，波纹不会重新从中心开始，而是保持当前的扩散进度，同时维护 B 点的按压状态。等其中一个手指抬起，只结束对应的按压状态，另一个手指的状态不受影响。
这个状态机虽然看起来复杂，但好处是确保反馈的连续性。如果每次按压事件都从零开始播放动画，用户快速连点时会看到波纹不断“重置”，视觉上会非常闪。Ripple 的设计保证了多次快速点击下反馈平滑连续，这也是 Material 规范能落地为代码的关键细节。
2.3 LocalIndication：主题如何把默认反馈注入到每个组件
在 Compose 里不需要每个组件手动传入indication参数，是因为主题层提供了LocalIndication。这是一个CompositionLocal，它持有当前主题下的默认Indication实例。当clickable的indication参数为 null 时，框架会从这里读取。
MaterialTheme在组合时会把LocalIndication设置为RippleIndication。如果你使用的是自定义主题或者没有包裹 MaterialTheme，这个默认值会是DebugIndication，它会绘制一个矩形边框并在按压时改变透明度，视觉上简陋得多。
理解了LocalIndication的机制，你就能做一件很实用的事：全局替换默认反馈。如果你所在团队的产品不想用 Material 默认波纹，可以用自定义 Indication 包裹整个应用：
CompositionLocalProvider( LocalIndication provides CustomIndication ) { MyApp() }这样所有使用clickable且没有显式传indication的组件都会自动使用新的反馈效果。但要特别注意，显式传入indication的组件不会受影响。排查“为什么我全局替换了但某个按钮还是老效果”时，第一件事就是去代码里找显式传入indication的地方，八成是这里出了问题。
3. 自定义 Indication：从规范入手到核心实现
3.1 先想清楚：你要的反馈是什么
在写任何代码之前，先定义清楚你要的反馈类型。常见自定义反馈有三类：
第一类是颜色覆盖型，类似旧的Ripple平铺效果。按压时组件整体颜色加深，松手后恢复。实现最简单，百分之八十的自定义反馈其实都是这种。
第二类是形状变化型，按压时组件略有缩放，或者背景圆角变化。这是很多非 Material 风格应用的首选，比如游戏化界面、儿童产品、拟物风格设计。
第三类是组合型，颜色、阴影、缩放同时变化。这种效果看起来最“高级”，但实现复杂度高，且需要特别注意不要严重影响性能。
不要一上来就做组合型。先从最简单的颜色覆盖开始验证思路，确认你的InteractionSource能正确收到事件后，再去叠加复杂效果。否则事件流都没通，动画写得再炫也白搭。
3.2 实现一个简单的颜色指示器
自定义 Indication 的核心是实现IndicationNodeFactory接口。这里直接给出一个可运行的最小实现，做一个按压时颜色加深的效果。
class ColorIndication( private val pressedColor: Color ) : IndicationNodeFactory { override fun create(interactionSource: InteractionSource): DelegatableNode { return ColorIndicationNode(interactionSource, pressedColor) } override fun hashCode(): Int = pressedColor.hashCode() override fun equals(other: Any?): Boolean { return other is ColorIndication && other.pressedColor == pressedColor } } private class ColorIndicationNode( private val interactionSource: InteractionSource, private val pressedColor: Color ) : Modifier.Node(), DelegatableNode { var interaction: PressInteraction.Press? = null override fun onAttach() { coroutineScope.launch { interactionSource.interactions.collect { interaction -> when (interaction) { is PressInteraction.Press -> { this@ColorIndicationNode.interaction = interaction updateBackgroundColor() } is PressInteraction.Release -> { if (interaction.press == this@ColorIndicationNode.interaction) { this@ColorIndicationNode.interaction = null updateBackgroundColor() } } is PressInteraction.Cancel -> { if (interaction.press == this@ColorIndicationNode.interaction) { this@ColorIndicationNode.interaction = null updateBackgroundColor() } } } } } } private fun updateBackgroundColor() { val target = if (interaction != null) pressedColor else Color.Unspecified // 这里通过 drawBehind 或 graphicsLayer 更新绘制内容 } }核心逻辑很清晰：订阅交互流，维护当前按压状态，状态变化时触发重绘。但这个实现有个关键问题：它没有使用动画，颜色变化是跳变的。真实产品中跳变的按压反馈会很生硬，所以你需要引入Animatable来做过渡，这点下面小节展开。
3.3 深入 Modifier.Node：不只是 IndicationNode，还有 DrawModifierNode
上面的简单实现里，Modifier.Node只负责收集事件，真正把颜色画出来还需要一个绘制节点。DelegatableNode接口允许一个Modifier.Node同时实现多个接口，因此我们可以让同一个节点实现DrawModifierNode。
private class ColorIndicationNode( private val interactionSource: InteractionSource, private val pressedColor: Color ) : Modifier.Node(), DelegatableNode, DrawModifierNode { var press: PressInteraction.Press? = null override fun onAttach() { coroutineScope.launch { interactionSource.interactions.collect { interaction -> when (interaction) { is PressInteraction.Press -> { press = interaction animateColorChange() } is PressInteraction.Release -> { if (interaction.press == press) { press = null animateColorChange() } } is PressInteraction.Cancel -> { if (interaction.press == press) { press = null animateColorChange() } } } } } } private suspend fun animateColorChange() { val target = if (press != null) pressedColor else Color.Unspecified colorAnimatable.animateTo(target, tween(150)) } private val colorAnimatable = Animatable(Color.Unspecified) override fun draw(content: DrawScope) { drawRect(colorAnimatable.value) content.draw() } }这里的精髓在于DrawModifierNode.draw方法。它在外层先绘制反馈色，再绘制内容。因此反馈色是显示在内容“下方”的，如果组件本身是不透明的，颜色覆盖型反馈会被完全遮挡。
那怎么显示在内容上方？把顺序反过来：
override fun draw(content: DrawScope) { content.draw() drawRect(colorAnimatable.value, blendMode = BlendMode.SourceAtop) }先绘制内容，再用BlendMode.SourceAtop把颜色叠加上去。但SourceAtop在某些硬件加速组合下表现诡异，可能需要设备实测。更稳的方案是用graphicsLayer设置 alpha 或者用drawWithContent配合drawRect来调整。
别小看这个绘制的顺序问题，它坑过不少人。你按照文档写了一个颜色指示器，结果发现按钮被完全盖住或者完全看不见反馈色，多半就是绘制层级搞反了。
3.4 理解 RippleIndication 源码：官方是怎么写动画的
与其自己摸索动画的细节，不如直接读RippleIndication的官方源码，理解标准实现是怎么处理按压和扩散两个阶段动画的。
官方实现中关键类是RippleAnimation。它内部持有Animatable的radius和alpha两个属性，分别控制波纹半径和透明度。当交互状态变化时，这两个属性通过animateTo设置目标值并启动动画。
按压开始时，半径从 0 动画到目标半径，alpha 从 1 逐渐降低到目标透明度；按压结束或被取消时，半径保持不变，alpha 动画到 0，实现淡出收尾。整个过程中没有使用LaunchedEffect来启动动画，而是通过Animatable的挂起函数在协程中顺序执行，确保动画连续不中断。
一个值得注意的实现细节是：官方通过calculateRippleRadius计算目标半径。跟手区域的测量尺寸不同，如果目标半径是固定值，大按钮上波纹只覆盖一部分，小按钮上波纹可能溢出直接裁剪，效果都会不对。所以任何自定义反馈都应该根据DrawScope.size来动态计算动画目标值，别写死。
4. 实战过程：完整实现一个按压缩放 + 颜色反馈的按钮
4.1 先搭框架：定义 Indication 和 Node
我把上面几节的理论落到一个完整案例里。目标效果：按压时按钮整体轻微缩小（scale 0.96），同时背景颜色加深；松手时恢复原状，整个过程用 120ms 的动画过渡。
首先定义ScaleIndication，它实现了IndicationNodeFactory：
class ScaleAndColorIndication( private val pressedColor: Color ) : IndicationNodeFactory { override fun create(interactionSource: InteractionSource): DelegatableNode { return ScaleAndColorNode(interactionSource, pressedColor) } override fun equals(other: Any?): Boolean { return other is ScaleAndColorIndication && other.pressedColor == pressedColor } override fun hashCode(): Int = pressedColor.hashCode() }注意实现equals和hashCode。Indication对象会被 Compose 作为 key 参与比较，如果你在重组时创建了新的 Indication 实例，会因为 equals 不相等导致节点重建，进而中断动画。
4.2 动画控制：用 Animatable 保证连续性和取消能力
ScaleAndColorNode需要同时驱动 scale 和 color 两个动画。这里我有两种选择：开两个协程分别动画，或者只用一个协程串行动画。推荐后者，原因在于两个动画的目标值相同，串行可以保证状态一致，不会有视觉撕裂。
private class ScaleAndColorNode( private val interactionSource: InteractionSource, private val pressedColor: Color ) : Modifier.Node(), DelegatableNode, DrawModifierNode { private var press: PressInteraction.Press? = null private val scaleAnimatable = Animatable(1f) private val colorAnimatable = Animatable(Color.Unspecified) override fun onAttach() { coroutineScope.launch { interactionSource.interactions.collect { interaction -> when (interaction) { is PressInteraction.Press -> { press = interaction animateFeedback() } is PressInteraction.Release -> { if (interaction.press == press) { press = null animateFeedback() } } is PressInteraction.Cancel -> { if (interaction.press == press) { press = null animateFeedback() } } } } } } private suspend fun animateFeedback() { val isPressed = press != null launch { scaleAnimatable.animateTo( if (isPressed) 0.96f else 1f, tween(120, easing = FastOutSlowInEasing) ) } launch { colorAnimatable.animateTo( if (isPressed) pressedColor else Color.Unspecified, tween(120, easing = LinearEasing) ) } } }这里用了launch同时启动两个动画，但这会破坏串行保证。其实更好的做法是分别维护状态，如果两次按压状态快速切换，动画目标会被覆盖，这不会产生冲突。不过确实可能出现 scale 和 color 不同步到达终值的情况，视觉上只是细微差异，整体可接受。
实际项目中更稳妥的做法是使用Animatable.snapTo在动画前先停掉旧的动画协程。你可以保存上一次动画的 Job，每次状态变化时 cancel 旧 Job 再启动新 Job，这样能保证动画绝对不重叠。这是官方 Ripple 没有做的，但对自定义效果很有用。
private var animationJob: Job? = null private fun animateFeedback() { animationJob?.cancel() animationJob = coroutineScope.launch { val isPressed = press != null launch { scaleAnimatable.animateTo(if (isPressed) 0.96f else 1f, tween(120)) } launch { colorAnimatable.animateTo(if (isPressed) pressedColor else Color.Unspecified, tween(120)) } } }4.3 绘制与缩放：协调 DrawModifierNode 与 graphicsLayer
Scale 动画不能直接在draw里做，因为draw里的scale变换会影响绘制裁剪，而且每次 draw 都做矩阵运算不划算。标准做法是使用Modifier.graphicsLayer或直接在绘制时用scale参数。
这里我不引入额外的graphicsLayer，而是通过DrawModifierNode配合drawContext.transform来实现缩放。drawContext.transform可以对绘制的内容做矩阵变换，但要注意它同样会变换反馈色，导致反馈色也跟着缩放。合理做法是先画反馈色不缩放，再对内容做缩放。
override fun draw(content: DrawScope) { // 先画反馈色，不缩放 drawRect(colorAnimatable.value) // 再对内容做缩放绘制 val scale = scaleAnimatable.value val center = center withTransform({ translate(center.x, center.y) scale(scale, scale, pivot = Offset.Zero) translate(-center.x, -center.y) }) { content.draw() } }这段代码把内容以中心为锚点缩放，反馈色保持满幅绘制。按钮大小如果本身就很小，缩放锚点在中心没问题；如果按钮形状不规则、锚点需要贴近按压位置，就得根据press!!.pressPosition计算锚点。
循环引用问题也值得一说：content.draw()在withTransform内部被调用时，如果 content 内部还包含一个同样使用了ScaleAndColorIndication的子组件，它的 draw 也会尝试做变换，导致嵌套缩放叠加，视觉上会抖动。这个问题在嵌套点击组件（比如 Button 内嵌 IconButton）时非常常见，你需要设计好缩放只作用到当前组件的直接内容，不要把子节点的变换也算进来。
4.4 无状态使用方式：通过 Modifier.composed 包装
上面的ScaleAndColorIndication是要配合clickable使用的。使用方式有两种。
第一种是显式传入：
val interactionSource = remember { MutableInteractionSource() } val indication = remember { ScaleAndColorIndication(Color.Gray) } Box( Modifier .size(100.dp) .background(Color.White) .clickable( interactionSource = interactionSource, indication = indication ) { /* onClick */ } )第二种是把整个反馈包装成Modifier.composed，让外部使用更简洁：
fun Modifier.scaleAndColorClickable( interactionSource: MutableInteractionSource? = null, pressedColor: Color = Color.Gray, onClick: () -> Unit ): Modifier = composed { val source = interactionSource ?: remember { MutableInteractionSource() } val indication = remember(pressedColor) { ScaleAndColorIndication(pressedColor) } clickable( interactionSource = source, indication = indication, onClick = onClick ) }两种方式我都建议写成扩展函数，方便复用。团队里统一反馈风格时，把ScaleAndColorIndication封装成一个自定义组件中途替换默认LocalIndication也行，但要记住Modifier.clickable内部的 null 判断时机问题，下节细说。
5. 常见问题与排查技巧实录
5.1 反馈不显示：检查 LocalIndication 的作用层
第一种常见问题是：自定义了 Indication，但按钮上完全看不到反馈。最先要查的是你传入的indication是否真的被使用。如果代码里写的是：
Modifier.clickable( interactionSource = interactionSource, indication = null, onClick = { } )indication为 null，框架会从LocalIndication读取。如果你没在CompositionLocalProvider里设置自定义值，那么默认就是 Material 的 Ripple。你的自定义 Indication 根本没被注入。
排查思路：在 Indication 的create方法里加日志，确认它有没有被调用。如果create被调用了但 UI 没反应，问题就出在绘制层，多半是绘制顺序或者动画链路的问题。
5.2 快速点击时动画错乱：善用 Job 取消
第二种常见问题是快速连点时，动画出现跳变或卡在中间状态。原因是多个动画协程重叠执行，Animatable的终值被后来的动画覆盖，前一个动画还没结束就被打断，光影出现毛刺。
解决方法是维护一个 Job 引用，每次状态变化先 cancel 旧动画。这是我在实际项目里踩过最深的坑，快速点按两次后，反馈色直接停在半透明状态，用户界面看起来像是“卡住了”。
如果你已经在animateFeedback里用了 cancel 机制，但问题还在，检查Animatable的作用域。Animatable被创建在Modifier.Node内部时，它默认使用rememberCoroutineScope的作用域。如果作用域被外部取消（比如节点 detach），动画也会停止，导致 UI 状态残留。这个时候不要依赖onDetach里的清空操作，而是确保动画结束时把 Animatable 的终值显式设置回来。
5.3 反馈与手势事件不同步：不要手动发射 Interaction
第三个高频坑是开发者试图自己发射 Interaction，比如在pointerInput里调用interactionSource.tryEmit(PressInteraction.Press(...))，用来实现自定义手势反馈。这种做法看上去很高端，但极易出问题。
原因有两个：一是MutableInteractionSource.tryEmit会把事件发给所有订阅者，如果组件内部也订阅了同一份 source，事件会重复；二是手势的取消和抬起事件非常复杂，比如父容器抢走触摸事件时系统会发Cancel，这些成对的事件如果由你自行发射，成对逻辑很容易错，导致按压状态永远得不到复位。
正确做法是让clickable或combinedClickable管理交互事件的发射，你只负责通过Indication订阅处理结果。如果确实需要自定义手势，使用detectTapGestures或者awaitPointerEventScope处理用户事件，再通过你自己的回调去驱动一个独立的动画状态，而不是去发 Interaction。
5.4 实际项目中的性能优化建议
Indication 的实现很容易写出卡顿。最常见的性能问题是：动画过程中持续触发 compose 重组。
在我的ColorIndicationNode中，如果直接在 draw 里读取一个State<Color>，组合阶段只会在颜色变化时重新绘制，这个没问题。但如果你把 interactive状态读到了一个普通的Modifier.background里，就会导致组件整体重组，布局和绘制全部重来一遍，性能就差了。
优化方向是尽可能在DrawModifierNode里完成反馈绘制，而不是用Modifier.background或Modifier.graphicsLayer去绑定状态。后者虽然代码更短，但把状态读取放到了组合阶段，不触发重组也会触发布局阶段，比在 draw 阶段做多一层开销。
如果反馈效果只需要 alpha 或 scale 变化，直接用graphicsLayer设置动态属性其实是最优解，因为graphicsLayer的 lambda 块只在绘制阶段运行，不会触发组合。
5.5 无障碍与低电量模式：不要只顾视觉
Indication是一个纯视觉反馈，它不需要处理无障碍语义，但自定义反馈可能会影响无障碍体验。如果你用Indication替换了波纹，视觉上按压反馈不明显，屏幕朗读用户可能无法感知点击状态变化。官方推荐的做法是在无障碍描述里增加“可点击”状态，但很多项目忽略了这个细节。
还有低电量模式。波纹的 radius 动画是比较重的绘制操作，在系统低电量模式下可以关闭部分反馈。用LocalDensity判断当前是否是低电量，或者用Build.VERSION判断 API 级别，在低电量时返回一个空 Indication：
fun Modifier.adaptiveIndication( indication: Indication ): Modifier { return if (isLowBattery()) Modifier else composed { clickable(indication = indication) } }这个方案不只是省电，对系统资源的占用也有明显下降。我实测在高刷屏上，一个页面 30 个可点击组件，开启组合型反馈后帧率降到 50 帧左右，关闭动画后回到满帧。反馈动画要做到轻量，控制好绘制范围，别把波纹半径动画做太大。
5.6 与主题动态切换的配合
如果你的应用支持深色模式或者动态主题，自定义Indication的颜色不能写死。最好让 Indication 在创建时从LocalColorScheme中读取颜色，而不是直接传一个常量。最简单的方式是让工厂方法持有 lambda，在create时通过CompositionLocal读取当前值：
class ThemeAwareColorIndication( private val colorProvider: @Composable (ColorScheme) -> Color ) : IndicationNodeFactory { override fun create(interactionSource: InteractionSource): DelegatableNode { val color = colorProvider(MaterialTheme.colorScheme) return ColorIndicationNode(interactionSource, color) } }这样主题切换时，节点重建会重新计算颜色。但注意：主题切换本身会触发重组，Indication对象也需要重新创建，否则节点不会知道颜色变了。把 Indication 的创建放到remember里，以主题作为 key 之一，这样最保险。
结尾的小体会
关于 Indication 想说的基本到此为止。做自定义反馈这一路，我最深的感触是：Compose 并不是简化了交互反馈，而是把反馈机制从一个“系统默认行为”提升成了“可插拔的抽象层”。刚开始你可能不适应，但掌握机制之后，反而比 View 时代自由得多。团队里有设计想改按压效果时，我通常不急着写代码，而是先问清楚：反馈的触发阶段是按下瞬间还是松手时？抑制阶段有没有退出动画？不同点击频率下动画要怎么取舍？这几个问题想明白，实现也就是几十分钟的事。最后再留一个建议：不管你的效果多漂亮，记得用慢动作录屏检查一次，很多动画的瑕疵在正常速度下看不清，在 0.5 倍速下会暴露无遗。
