Jetpack Compose：@Stable与@Immutable能否混用？使用疑问

问题1：“更强的承诺”是向谁作出的？ #

这个承诺同时面向协作开发者和Compose编译器：

• 对开发者：是一种代码契约，明确告知其他维护者这个类的实例完全不可变——一旦创建，内部所有属性的值都不会被修改，开发者无需担心实例在任何地方被意外篡改。
• 对编译器：是更严格的约束，编译器可以基于这个承诺执行更激进的底层优化，比如缓存计算结果、减少状态追踪的额外开销，虽然表面上重组跳过行为和@Stable一致，但优化逻辑的效率更高。

问题2：若仅告知编译器，为何二者的重组跳过行为一致？ #

二者重组跳过表现一致，核心原因是Compose的重组触发逻辑基于状态的相等性判断：

• @Stable的承诺是：如果实例的equals判断为true（语义上无变化），那么它的所有公开属性、方法的返回值也不会改变。编译器会基于这个规则，通过equals比较决定是否跳过重组。
• @Immutable是@Stable的超集，它要求实例完全不可变，equals判断逻辑更简单（直接对比所有属性），编译器同样会通过equals比较来跳过重组。所以从开发者视角看重组行为一致，但编译器内部的优化路径是不同的。

问题3：可以随意选用二者吗？ #

绝对不能随意选用，即便某些可变类用@Immutable暂时能正常运行，也是违反契约的危险操作：

• 比如BookmarkUiState如果内部状态可变，用@Immutable注解相当于向编译器和开发者传递错误信息——声称这个类不可变。一旦后续代码修改了实例的内部状态，编译器因信任@Immutable的承诺，不会追踪这些变化，会导致UI无法正确更新，出现难以排查的隐性bug。
• 必须严格区分使用场景：只有当类的所有属性都是不可变的（且属性类型也为@Immutable或@Stable），才能用@Immutable；如果类的实例允许内部状态变化，但能保证状态变化时通知编译器（比如使用MutableState），则用@Stable。

问题4：从性能优化角度，有区分的必要吗？ #

从性能优化和代码维护的角度，区分二者都是必要的：

• 性能层面：虽然常规场景下重组表现一致，但@Immutable给了编译器更强的保证，它可以执行一些@Stable无法做到的深层优化——比如将不可变实例的属性直接内联到Compose节点中，避免重复的相等性检查；在复杂组合场景中，减少状态追踪的额外开销。
• 维护层面：区分二者能清晰传递类的设计意图，@Immutable明确标记不可变数据类，@Stable标记可变但状态可追踪的类，让协作开发者快速理解类的使用规则，避免误用。

内容的提问来源于stack exchange，提问作者송규빈