Jetpack Compose BOM 2026.02.01 解读与升级指南

Jetpack Compose BOM 2026.02.01 深度解析：这次升级到底更新了什么，值不值得跟？

如果你最近准备把项目里的 Compose 依赖统一升到 androidx.compose:compose-bom:2026.02.01，先说结论：这不是一波"新能力井喷"的大版本 BOM，而是一版很典型的稳定性补丁 BOM 。它的核心价值不在于一次性塞进大量新 API，而在于把 Compose 1.10 这一代已经落地的新能力，用一组更稳的 patch 版本重新打包给你。

对于线上项目来说，这种版本往往比"看起来更炫"的版本更值得重视：新功能不一定是每天都能用上的，但修掉布局回归、补齐运行时和 UI 侧补丁、把 BOM 对齐到更稳定的一组 artifact，通常直接影响的是发布风险和排障成本。

本文基于 Android 官方文档、AndroidX release notes、Android Developers Blog 等一手资料整理，重点回答 4 个问题：

2026.02.01 到底映射到了哪些 Compose 版本；
它相对上一版 2026.02.00 具体变了什么；
这些变化对实际工程能力提升在哪里；
项目升级时有哪些容易踩的适配点。

先说结论

Compose BOM 2026.02.01 的主变化，是把 Compose 核心模块族从 1.10.3 对齐到 1.10.4。
material3 在这版 BOM 里没有继续升级 ，仍然是 1.4.0。
material3-adaptive 这条线也没有变 ，仍然是 1.2.0。
从官方 release notes 来看，foundation 1.10.4 明确修了一个布局定位回归；runtime/ui/material/animation 1.10.4 没有列出新的公开 API 变化，更像一组维护性 patch。这是基于官方 changelog 颗粒度做出的工程判断，不是 Google 原文的直接表述。
如果你此前已经上了 2026.02.00，这次升级的重点是"补丁"和"稳定性"；如果你还停在更早的 2025 年末版本，那你实际上会连同 Compose 1.10、Material3 1.4 这一波能力一起吃进来。

这版 BOM 映射到了什么

Compose BOM 的职责，是帮你把一组 Compose 相关 artifact 锁到一套经过官方验证的兼容版本组合里。它不包含 Compose Compiler，这一点在官方 BOM 文档里说得很明确。

结合官方 BOM Mapping 页面，2026.02.01 可以概括为下面这张表：

模块族	`2026.02.01`	`2026.02.00`	变化判断
`animation`	`1.10.4`	`1.10.3`	升级补丁
`foundation`	`1.10.4`	`1.10.3`	升级补丁
`material`	`1.10.4`	`1.10.3`	升级补丁
`runtime`	`1.10.4`	`1.10.3`	升级补丁
`ui`	`1.10.4`	`1.10.3`	升级补丁
`material3`	`1.4.0`	`1.4.0`	无变化
`material3-adaptive`	`1.2.0`	`1.2.0`	无变化

这里说的"模块族"，不只是单个 artifact，而是一整串同代模块，例如：

ui 族通常包含 ui、ui-graphics、ui-text、ui-tooling、ui-test-junit4 等；
foundation 族通常包含 foundation、foundation-layout；
runtime 族通常包含 runtime、runtime-livedata、runtime-rxjava*；
animation 族通常包含 animation、animation-core、animation-graphics；
material 指的是经典 Compose Material（M2）线；
material3 和 material3-adaptive 维持独立节奏。

换句话说，这版 BOM 的核心动作其实很清楚：把 Compose 核心运行栈整体抬到 1.10.4，但不动 Material3 主版本。

相比 2026.02.00，具体更新了什么

1. `foundation`：修了一个真实会影响界面的定位问题

在官方 foundation release notes 里，1.10.4 明确提到修复了一个回归：

当一个对齐类 modifier 被错误地用在它不属于的 scope 中时，之前版本可能会触发错误布局位置；
1.10.4 对这个问题做了修复。

这个改动看起来不"炫技"，但对线上项目非常重要。因为这类问题往往最麻烦：

编译不报错；
页面也不是全挂；
只在特定组合布局、特定修饰链、特定设备尺寸下才出现"怎么这里偏了一点"的问题；
最后调半天才发现不是业务代码逻辑，而是底层布局行为的回归。

如果你的项目里有比较多自定义布局、复杂 slot API、嵌套 Box / Column / Row / Lazy* 布局，再加上扩展 modifier 比较多，这个修复是有实际价值的。

2. `runtime`：官方写明"和 1.10.3 没有变化"

runtime 1.10.4 的官方 release notes 很直接：There are no changes in this release.

这意味着什么？

如果你只看 runtime 模块本身，这次从 1.10.3 到 1.10.4 不会带来新的运行时语义变化；
它更多是在 BOM 层面把整个 Compose 版本集重新对齐；
对项目升级而言，runtime 不是这次最需要重点回归验证的模块。

3. `ui` / `material` / `animation`：更像同步补丁与维护性发布

从对应的 AndroidX release notes 页面来看：

ui 1.10.4 没有列出额外的显性 API 变更摘要；
material 1.10.4 也没有单独列出显著变更说明；
animation 1.10.4 在 release 页面上同样没有像大版本那样给出新的能力条目。

因此比较稳妥的工程判断是：这几个 1.10.4 更像一组维护性 patch / 同步发布，而不是新的功能迭代节点。

这里还是强调一下：这句话是基于官方 release notes 未列出新增 API / 新特性摘要的推断。如果你需要逐 commit 追踪，可以继续顺着各 release notes 页里的 change list 链接深挖，但就日常升级决策来说，这个粒度已经足够判断风险级别。

4. `material3`：这版 BOM 不动，仍然停在 1.4.0

这点很关键。很多同学看到 BOM 版本号继续往 2026.02.01 走，会下意识以为 Material3 也一起升了。实际上没有。

按官方映射页，这一版里：

androidx.compose.material3:material3 仍然是 1.4.0；
androidx.compose.material3.adaptive:* 仍然是 1.2.0。

所以，如果你这次升级之后感觉 Material3 API 没有新增，那不是你姿势不对，而是 BOM 本身就没有把 Material3 再往前推。

那"能力提升"体现在哪？

如果只盯着 2026.02.01 对 2026.02.00 的 diff，你会觉得"这不就是个 patch 吗"。这判断没错，但不完整。

更准确地说，这版 BOM 的价值分成两层：

短期价值 ：把核心 Compose 族对齐到更稳的 1.10.4；
平台价值 ：把 Compose 1.10 和 Material3 1.4 这一代的能力，打包到一个更适合生产落地的组合上。

下面这部分，才是程序员真正关心的"升了以后我能干嘛"。

1. Lazy 布局和滚动链路更成熟了

根据 Android Developers Blog 对 Compose 1.10 的总结，Google 在这一代继续强化了性能路线，几个点很值得关注：

Pausable Composition 已默认用于 Lazy 布局的预取；
官方给出的内部 benchmark 显示，某些滚动场景下 Compose 已能达到和传统 View 非常接近的性能水平；
这意味着在复杂列表、卡片流、瀑布式 feed、首页混排场景里，Compose 的"流畅度心理门槛"又往前迈了一步。

对于业务开发来说，这种能力提升不是"我今天多了一个 API"，而是：

你更敢把复杂首页从 RecyclerView 迁到 Compose；
你在做首屏预取、异步图片、嵌套列表时，调优空间更大；
同样一套 UI 结构，达到稳定 60fps / 120fps 的难度在下降。

2. 状态保存模型更细了：`retain` 填上了中间层

Compose 1.10 里新增了 retain API。官方的定位很明确：它位于 remember 和 rememberSaveable 之间。

这对大型页面尤其有意义。过去很多场景都很尴尬：

remember 生命周期太短，离开组合就没了；
rememberSaveable 又偏"跨配置变化/进程恢复"的重量级持久化路径；
中间缺一个"离开当前组合树但暂时还想留住"的状态层。

retain 的意义就在这里。你可以把它理解为：为复杂导航栈、可回收页面、短时脱离组合的内容，提供一个更合理的状态存活层级。

如果你的项目里有这些模式，这项能力很实用：

多 Tab 页面切换；
底部导航多 back stack；
局部内容被回收后重新挂载；
大表单 / 编辑页中间状态不想轻易丢。

3. Shared Element / Lookahead 这一套更能上生产了

Compose 1.10 在动画侧最像"能力升级"的部分，是共享元素与 Lookahead 相关 API 的继续完善。官方博客提到的点包括：

可以在运行时启用或禁用共享元素；
Modifier.skipToLookaheadPosition 让空间位置同步更灵活；
过渡动画支持初始速度；
支持 veiled shared bounds 这类更接近真实产品需求的过渡模式。

如果你做的是下面这些页面，这一代动画 API 的成熟度提升会比较明显：

列表到详情页的跨屏转场；
卡片展开 / 收起；
Hero image、视频封面、头像转场；
大屏多面板布局里跨容器的视觉连贯动画。

而从 animation 1.10.4 只是跟进 patch 这一点也能看出，Google 这一阶段更像是在把 1.10 这一代能力往稳定期推进，而不是继续大开大合地扩 API。

4. Material3 `1.4.0` 的价值，很多人低估了

虽然 2026.02.01 没有继续升级 material3，但只要你项目还没吃上 1.4.0，这一版 BOM 仍然值得关注。

根据官方 material3 release notes 和 Android Developers Blog，1.4.0 这代比较有感的能力包括：

基于 state-based TextField 的新文本输入体系；
SecureTextField / OutlinedSecureTextField，更适合密码、敏感信息输入；
Text 的 autoSize 能力；
HorizontalCenteredHeroCarousel；
TimePicker 在 picker / input 模式之间切换；
新的纵向拖拽手柄（vertical drag handle）；
一批曾经实验性的 Material3 API 进入稳定状态；
一些性能优化已经进入正式版。

这组能力对真实业务非常有价值：

输入组件 更接近现代应用的复杂表单需求；
安全输入 不再需要大量自定义封装；
自适应排版 在标题、卡片、横幅类组件里更好落地；
内容型首页 可以更方便地做 Hero Carousel 一类强运营模块；
时间选择器 的可用性更好。

对工程侧的实际收益，可以怎么理解

如果只用一句话总结：2026.02.01 不是"让我今天马上能写出完全不同 UI"的版本，而是"让 Compose 这条生产链更稳、更敢大规模用"的版本。

把收益拆开看，会更清楚：

收益 1：列表、复杂布局和动画的生产风险更低

foundation 1.10.4 修正布局回归，直接降低界面错位风险；
1.10 代的性能和动画能力已经明显更适合生产；
对复杂首页、商城、内容流、社交 feed 这类页面更友好。

收益 2：状态管理更贴近大型应用架构

retain 提供了比 remember 更长、比 rememberSaveable 更轻的状态层级；
对 Navigation、多 back stack、复杂编辑流尤其有帮助；
可以减少很多"到底是存在 ViewModel 里还是存在 rememberSaveable 里"的别扭设计。

收益 3：输入与 Material3 组件更可用

新 TextField 能力和 SecureTextField 让表单页收益明显；
autoSize 和 Carousel 等能力，让内容型设计更容易实现；
如果你在推进 design system 的 Compose 化，1.4.0 是个比 1.3.x 更成熟的落点。

升级方式：依赖应该怎么写

最标准的写法还是直接上 BOM：

kotlin 复制代码

dependencies {
    val composeBom = platform("androidx.compose:compose-bom:2026.02.01")

    implementation(composeBom)
    androidTestImplementation(composeBom)

    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.foundation:foundation")
    implementation("androidx.compose.material3:material3")

    debugImplementation("androidx.compose.ui:ui-tooling")
    androidTestImplementation("androidx.compose.ui:ui-test-junit4")
}

如果你用 Version Catalog，也建议只在 catalog 里声明 BOM 版本，把具体 Compose artifact 写成无版本号依赖，避免手滑把单个模块拉出对齐范围。

升级适配要点：这些地方一定要看

1. 先记住：BOM 不管 Compose Compiler

这是很多项目升级时最容易搞混的点。

官方文档明确说明：Compose Compiler 不包含在 Compose BOM 里。

同时，官方 Compose Compiler 文档又补了一条很关键的信息：从 Kotlin 2.0 开始，Compose Compiler 由 Kotlin 仓库统一管理，推荐直接使用 Compose Compiler Gradle plugin，并让它和 Kotlin 版本保持一致。

也就是说：

升 compose-bom，不等于 compiler 自动一起升；
如果你已经在 Kotlin 2.0+，优先走官方推荐的 org.jetbrains.kotlin.plugin.compose；
如果你还停在旧 Kotlin 版本，升级前要核对 compiler compatibility map，不要只盯着 BOM。

一个典型配置如下：

kotlin 复制代码

plugins {
    id("org.jetbrains.kotlin.android") version "<your-kotlin-version>"
    id("org.jetbrains.kotlin.plugin.compose") version "<your-kotlin-version>"
}

2. 如果你手动覆盖过单个 Compose 依赖，先清理一遍

BOM 的前提是"版本统一受控"。

如果你的项目历史上做过下面这些事：

手写过 ui:1.x.x；
单独把 material3 钉在别的版本；
因为临时修 bug 覆盖过 foundation-layout；
引入过 alpha / beta 版 Compose artifact；

那升级到 2026.02.01 前，最好先把这些 override 摸一遍。否则你以为自己在用 BOM，实际依赖图已经部分失控了。

建议直接跑一遍依赖树确认：

bash 复制代码

./gradlew :app:dependencies --configuration debugRuntimeClasspath

重点看有没有：

同一模块族里混入多个小版本；
稳定版和 alpha / beta 混用；
material3 被外部组件库偷偷带成别的版本。

3. 如果你从更早版本跨上来，要补测布局和滚动，不要只测编译通过

这次官方明确提到的补丁在 foundation，说明布局链路是本轮升级里最值得回归的地方。

建议重点回归这几类页面：

大量自定义 modifier 的页面；
LazyColumn / LazyVerticalGrid / Pager 混合页面；
有粘性头部、吸顶、嵌套滚动的页面；
依赖对齐、权重、offset、padding 叠加的复杂布局；
平板、折叠屏、横屏等大尺寸场景。

原因很简单：布局回归类问题最容易"编译通过、代码 review 也看不出来，但线上截图才暴露"。

4. 如果你准备用 Material3 新输入体系，优先从局部页面试点

material3 1.4.0 的 TextField 体系更新是很有价值的，但也意味着：

你的 design system 可能要同步抽象；
表单状态管理方式可能要调整；
输入过滤、校验、错误态展示、焦点切换等逻辑可能要重新梳理。

我的建议不是"全量一把梭"，而是：

先在登录、注册、个人资料编辑、收货地址这类表单集中页面试点；
把状态模型、错误态规范、密码输入策略跑顺；
再向更复杂的业务域扩散。

5. 如果你还在用 Material Icons 扩展库，顺手评估迁移到 Material Symbols

在 material3 官方 release notes 里，Google 已经不再推荐继续使用 Material Icons Library，而是建议使用 Material Symbols 的自动镜像 Vector Drawable 方案。

这不是一个"必须今天改"的阻塞项，但如果你刚好在做 design token、图标系统、资源瘦身或者国际化适配，这次升级很适合顺手把这件事纳入技术债清单。

6. 关注大版本背景：新发布 AndroidX 库的默认 minSdk 已经提高到 23

Google 在 Compose 1.10 相关说明里已经提到，AndroidX 的新发布库默认 minSdk 正在从 21 往 23 提升。

对大多数今天仍在活跃开发的项目来说，这通常不是大问题；但如果你的投放范围、ROM 适配或者企业客户环境还覆盖 API 21/22，那升级前最好把下面几件事再确认一遍：

App 的实际 minSdk；
业务模块是否有单独的发布目标；
第三方 SDK 是否还卡着低版本系统；
CI / 测试矩阵里是否保留了低版本设备。

这版值不值得升？我会怎么建议

适合尽快跟进的情况

你已经在 Compose 1.10.x，想吃掉最新 patch；
你最近碰到过列表、布局、定位错位类问题；
你准备把更多复杂页面迁到 Compose；
你想把 Material3 1.4.0 作为新的稳定落点。

这种场景下，2026.02.01 基本属于"可以排进近期升级计划"的版本。

可以稍微观察一下的情况

你线上项目非常稳定，最近没有 Compose 相关问题；
你已经在 2026.02.00 且没有布局异常；
你对 material3 新能力没有迫切需求；
你当前迭代窗口不允许 UI 侧做大量回归。

这种情况下，也不是不能升，而是可以把它当成"下一个常规基础设施升级窗口顺手做"的版本。

一个更实用的判断：这版 BOM 的真实定位是什么

如果让我用一句程序员视角的话来概括：

Jetpack Compose BOM 2026.02.01 本质上是 Compose 1.10 时代的一次稳定性收口版 BOM。

它没有把 Material3 再推到新的主版本，也没有甩出一串高调新 API；但它做了更重要的事：

把核心 Compose 族统一补到 1.10.4；
修复了明确的布局定位回归；
继续站在 1.10 的性能、状态、动画能力之上；
让 material3 1.4.0 这代组件能力，处在一个更适合生产项目接入的 BOM 组合里。

如果你问"要不要升"，我的答案会是：

从 2026.02.00 升上来：更像一次低风险、偏稳健的补丁升级；
从更老版本直接升上来：收益会明显大得多，但记得按 compiler + BOM + 布局回归 + 输入组件 四条线一起看。

参考资料

Android Developers: Compose BOM 文档
developer.android.com/develop/ui/...
Android Developers: Compose to Kotlin Compatibility / Compose Compiler 文档
developer.android.com/develop/ui/...
Android Developers: Compose BOM Mapping
developer.android.com/develop/ui/...
AndroidX Release Notes: Compose Foundation
developer.android.com/jetpack/and...
AndroidX Release Notes: Compose Runtime
developer.android.com/jetpack/and...
AndroidX Release Notes: Compose UI
developer.android.com/jetpack/and...
AndroidX Release Notes: Compose Material
developer.android.com/jetpack/and...
AndroidX Release Notes: Compose Animation
developer.android.com/jetpack/and...
AndroidX Release Notes: Compose Material3
developer.android.com/jetpack/and...
Android Developers Blog: What's new in Jetpack Compose 1.10
android-developers.googleblog.com/2025/12/wha...

如果你后面还要继续升级，我建议下一步别只盯着 BOM 版本号，而是把三件事绑在一起看：

Kotlin / Compose Compiler 是否同步；
Material3 新输入体系是否准备接入；
复杂布局页是否有足够的回归覆盖。

这三件事，往往比"我是不是已经升到最新 BOM"更影响真实项目的收益。