今天打开 shadcn/ui 的组件文档，会发现每个页面默认打开的不再是 Radix 标签，而是 Base UI。shadcn/ui 在 7 月的更新记录里正式宣布，Base UI 成为新项目的默认无头组件库，Radix 退到"点一下才能看到"的位置。
这不是一次普通的默认值切换。Base UI 出自 Radix 原班人马之手，相当于同一批人把自己三年前的作品，亲手挪出了 C 位。官方给出的理由很克制：Base UI 已经到 1.6.0，周下载量超过 6M，用 shadcn/create 建新项目的人选它对 Radix 的比例是 2 比 1，"社区已经做了选择，我们只是追认"。但一款被三年生产环境验证过、写进无数教程和企业组件库的默认项被换掉，从来不只是技术决定。
三年翻篇：同一批人做了第二次同样的事
shadcn/ui 2023 年 1 月诞生时，唯一的底座是 Radix——无样式、无障碍语义扎实、久经生产环境考验，几乎没有对手。做出 Radix 的那批人后来另起炉灶，做了 Base UI，相当于带着第一代产品攒下的经验，重新做了一遍。
去年 12 月，npx shadcn create 开始同时支持两个库；今年 1 月，Base UI 文档补齐。中间没有强推，官方只说过一句话："贸然换组件库，对生产项目是最糟糕的事"。三个月后拿到的数据是：新建项目里选 Base UI 的人是选 Radix 的两倍。7 月这次官宣，更像是把这三个月观察盖章，而不是临时拍板。
文档更新之前，用户已经先"倒戈"了
档案里一个细节值得留意：Base UI 的支持是被 Reddit 上的开发者先发现的，早于官方文档公开更新。同一批讨论里，一名自称 Base UI 维护者的用户说 Radix 的开发已经放缓、Base UI 才是活跃的那条线——这句话没有第二个信源佐证，shadcn 官方 changelog 也从没提过 Radix 维护降速，只字未提这个说法。
这正是这次公告留白的地方。官方叙事是"社区选了，我们跟上"；另一种解读是决策更早就定了，官宣只是补一张文档。两种说法目前都拿不出实锤，但"用户先于文档发现变化"本身，已经说明这次切换不是突然袭击，更像是拖了大半年才补的手续。
- 结论.新老用户认知已先出现割裂，大量教程、模板、Stack Overflow 答案还停在 Radix 的写法上，官宣不会让这个滞后立刻消失。
asChild 换成 render，不只是改个名字
changelog 把 asChild 到 render 的变化轻描淡写成"机械重命名，到处自动修好"。实际上这是两种不同的组合哲学。asChild（Radix 的做法）是克隆子元素、合并 props；render（Base UI 的做法）是直接把渲染函数交给开发者，由你决定最终渲染成什么元素。前者的无障碍语义、焦点管理由库内部包办；后者把这部分责任往你的代码里推了一层。
编译能通过，不代表交互行为没变。这类差异不会报错，只会在无障碍测试或键盘导航时冒出来——迁移报告里单独列成"行为变化"，官方原话是"标记出来，不静默打补丁，你自己决定"。工具不替你兜底，这句话说得很清楚。
用 AI agent 的 skill 而不是传统 codemod 来做迁移，是同一个逻辑的延伸。项目里大概率已经改过组件的 class、加过 variant，codemod 碰到没动过的代码能改对，碰到动过的代码容易改坏。shadcn 选择让 agent 先读懂"你改了什么"，再决定怎么迁移，一个组件一次 commit，能停能续。这跟 shadcn 一贯"给代码不给决定"的做法是一回事——它不想替你做选择，只想让你做选择时更省心。
谁该现在动，谁该按兵不动
官方话说得明白：Radix 不会被弃用，两个库的更新都会跟上，已经在生产里跑着的 Radix 项目不用换。真正要留意的是两类人：CI 里非交互式跑 shadcn init 的团队，默认值变了，不加 -b radix 参数，新流水线会悄悄换库；维护开源 registry 或内部组件库的人，得自己决定要不要锁定 registry:base，否则新装组件默认就是 Base UI。
官方给出的迁移基准——60 多个组件里 36 个基于 Radix，整个流程约 25 分钟、每个组件约 1 万 token——听起来轻巧，但这是官方自己挑的测试项目，复杂度和手头那个改得面目全非的生产项目未必是一回事。真要迁移，先拿一两个用得最杂的组件试一次迁移报告，再决定要不要推全量。
Radix 没被抛弃，只是不再是唯一答案。