AndroidX Compose UI 页面把两个版本放在同一张表里，稳定线是 1.11.4，beta 线是 1.12.0-beta02。移动端团队看到这种节奏，最容易犯的错是只看能不能编译通过。
Compose 升级真正麻烦的地方，经常藏在输入、滚动、焦点、无障碍语义和截图差异里。编译器没报错，不代表用户不会看到抖动。
稳定线和 beta 线要分仓库策略
业务 App 建议把稳定线放进常规依赖升级流程。设计系统、组件库、基础壳工程可以开一条 beta 观察分支，用来提前看 API 变化和手势行为。两条线别混在一个合并请求里。
我见过不少团队把依赖升级做成一串版本号替换，跑一下单测就合。Compose 不太适合这么干。一个 TextField 的语义变化，一个 pointer event 的行为调整，都可能让自动化测试和真实输入表现不一致。
BOM 只能管版本，管不了行为
Compose 由多个 Maven group 组成，UI、Foundation、Runtime、Material 各有发布说明。使用 BOM 能减少版本错配，但它不会替团队判断行为风险。尤其是组件库项目，经常同时依赖 foundation、ui-test、material3，升级时要一起看。
更稳的方式是给升级单加一个小矩阵。页面截图、深色模式、大字号、横竖屏、软键盘、TalkBack、列表快速滚动、返回手势。矩阵不用大，关键是覆盖自己产品最容易出问题的路径。
模拟器内存变化会影响 CI 成本
Android Emulator 36.6.11 的说明里提到，API 37 起 Phone AVD 的最小 RAM 提到 4GB，低于这个值会被自动改写。这个信息看起来像工具细节，但对移动端 CI 很实际。
如果一个 Windows 或 Linux 构建机并发跑 4 个模拟器，内存预算马上变得紧张。原来靠低配 AVD 撑出来的并发数，升级系统镜像后可能直接掉下来。CI 管理员要提前拆分任务，或者把截图测试和端到端测试分到不同池子。
截图回归要盯住输入和焦点
Compose 页面最怕只测静态布局。真实用户会点输入框，会切键盘，会从系统返回手势回到上一页，会用辅助功能读控件。发布说明里涉及内部 flag、pointer event、测试函数这些内容时，组件库维护者都该多跑几组交互用例。
建议把截图基线分成两类。一类是稳定页面，用来拦截样式漂移。一类是交互状态，比如输入框聚焦、错误提示、底部弹层、列表滚动到中段。后一类更容易抓到升级带来的小裂缝。
升级记录要写给下一个维护者看
依赖升级单里别只写版本号。写清楚升级原因、影响模块、跑过哪些设备、保留了哪些风险。组件库项目还要标出是否需要业务方重新生成截图基线。
优易云做移动端工程化时，会把 Compose 升级拆成依赖锁定、组件库验证、业务页面抽样、CI 资源评估这几步。听起来慢一点，但比线上发现输入框错位要便宜。
Compose 的迭代速度很快，团队没必要追每一个 beta。该追的是自己的升级纪律。版本号会变，纪律不能漂。
