嘿，你的猜测完全正确！那行println确实间接导致了额外的重组，不过背后的原因得从Compose的重组机制说起，我给你拆解一下：

首先，先明确核心逻辑：Compose的重组是由「State变化+依赖追踪」驱动的——当一个Composable函数在它的重组阶段（也就是构建UI的代码部分）读取了某个State的值，Compose就会把这个Composable标记为依赖该State，后续这个State变化时就会触发它的重组。

回到你的代码里：

• oldCount是用remember { mutableStateOf(newCount) }声明的，这是一个可观察的State对象。
• 当你在RecompositionCounter的Column lambda里添加那行println("new count has been changed from $oldCount to $newCount")时，你在重组阶段读取了oldCount的值——这就等于告诉Compose：“这个Composable需要监听oldCount的变化哦”。

接下来看点击按钮后的完整流程：

1. 点击按钮，count变成1，触发RecompositionCounter第一次重组，此时newCount=1。
2. 第一次重组过程中：
   • 先输出newCount is 1；
   • 执行那行关键println，读取oldCount（此时还是0），输出new count has been changed from 0 to 1；
   • 进入SideEffect，把oldCount改成1——这里修改了State的值！
3. 因为RecompositionCounter已经依赖了oldCount，所以oldCount一变，Compose立刻触发第二次重组。
4. 第二次重组时：
   • oldCount已经是1了，所以先输出newCount is 1；
   • 那行println输出new count has been changed from 1 to 1（因为新旧值一样）；
   • SideEffect再次执行，把oldCount设为1（和当前值相同，无实际变化，但SideEffect每次重组后都会运行），所以log又打了一次。

那为什么去掉那行println就没额外重组？因为此时RecompositionCounter在重组阶段完全没碰oldCount——Compose没检测到这个依赖，所以修改oldCount时不会触发它的重组，自然就只有一次log。

给你两个小建议避坑：

1. 别在Composable的重组阶段（UI构建代码里）随意读取/修改State，尤其是不要在重组过程中修改State，很容易触发连锁重组；
2. 如果要追踪State变化，优先用LaunchedEffect+snapshotFlow监听，或者用Compose官方的重组调试工具（比如开启Android Studio的重组高亮），比加println靠谱多了，还不会引入意外依赖。

内容来源于stack exchange