上个月帮朋友重构一个管理后台的导航栏，碰到一个特别经典的边界场景：鼠标从“产品”按钮往下拉，刚跨过按钮和下拉面板之间那条几像素的缝隙，菜单瞬间收回。这个问题我反复见过很多次，也见过各种补救手段，加transition-delay、在中间补一层透明“桥”、甚至改成JS去监听mouseenter和mouseleave再配合一堆状态判断，效果都很别扭。把问题拆开看，其实是两个独立的技术痛点叠在了一起：height从0到auto的过渡在CSS里一直没有一个优雅的解法；以及:hover这种状态在跨区域交互里天生就“保不住”。后来我把展开逻辑全部改成:focus加:focus-within驱动，高度动画改用grid-template-rows的0fr到1fr过渡，两个痛点一次解决。这篇文章不打算讲一堆概念，就把从原理到代码、从正常流程到暗坑的完整过程写出来，给正在做下拉菜单、搜索联想、折叠面板，或者想深入理解CSS动画机制的前端同学做个参考。
1. 为什么 height: auto 从来就不是一个“可过渡的值”
1.1 transition 的插值前提：起点和终点必须是可计算的数值
想理解这个问题的根源，得先看浏览器做动画的底层机制。CSS transition要做过渡，必须拿到两个可以“插值”的数值。什么叫插值？就是浏览器知道起点是0px、终点是100px之后，才能在动画进行到25%、50%、75%的时候，分别算出25px、50px、75px这些中间帧。整个过程本质上就是在做数学运算。
问题来了：auto不是一个数值，它是一个让浏览器自己去现场布局、根据内容计算出具体高度的指令。起点height: 0明确，终点height: auto却是个“打开箱子才知道重量”的值，浏览器没办法预先知道动画进行到一半时，那个“中间高度”应该是多少。所以规范直接禁止了这种过渡——这不是浏览器实现偷懒，插值函数对关键字根本无从下手。
可以打个比方：一个动画师需要给角色画关键姿势，才能补出中间过渡帧。你告诉他“起始姿势是蹲下，结束姿势是‘一个你觉得合适的姿势’”，他没法画。height: auto就是那个“你觉得合适的姿势”，CSS规范不会给这种不确定性买单。
1.2 那些看似能用的“绕路方案”都有物理限制
这个问题存在这么多年，市面上自然积累了一批解决方案，但每一种都是在“绕路”。
最常用的是max-height法：给目标元素设置一个足够大的max-height，比如max-height: 400px，然后把过渡属性从height换成max-height，让它在0和400px之间动画。这个方案简单可靠，兼容性好，代价是物理上的时间扭曲：如果内容实际高度只有100px，浏览器实际在对0 → 400px做插值，视觉上内容在前四分之一动画时长内就被推完了，后面四分之三完全在空转。如果配合ease-in-out曲线，那种“先快后慢再空转”的违和感会更明显，像是动画在抢跑。
另一个方案是用transform: scaleY()配合overflow: hidden。它的问题是不会撑开文档流里的布局，内容可能被压缩变形，文字在低端设备上还会有渲染模糊问题，通常只适合绝对定位的小浮层，想用它做展开后挤压下方内容的面板基本不现实。
再就是JS方案，通过scrollHeight测量内容真实高度，再手动把height设置成具体像素值。这个方案准确，但强依赖JS执行时机，如果JS还没加载完就触发展开，动画会直接失效。在服务端渲染或者弱网环境里，还可能出现“首屏没动画、交互后才有动画”的割裂感。
1.3 新特性已经在松绑，但生产环境仍要看兼容矩阵
最近两年CSS规范其实开始正视这个问题了。Chrome 129开始支持calc-size()函数，配合interpolate-size: allow-keywords声明，可以让height真正从0过渡到auto；Firefox的新版本也跟进支持了interpolate-size。我实测过，效果非常顺滑，代码也干净，不需要任何中间层容器，就是一个朴素的height过渡。
但问题在于Safari的完整支持一直滞后，如果你做的是跨端H5、线上电商这类对兼容性要求较高的页面，这套新特性目前还不敢直接上生产。所以下面要重点讲的grid-template-rows方案，在“不需要具体像素值”这个核心目标上，是目前兼容性最广、原理上也最干净的一条路。
2. 真正的边界场景：hover 状态链一断，整个交互就崩了
2.1 一个复现率百分之百的翻车现场
先把边界场景具象化。一个导航按钮加一个下拉面板，鼠标hover到按钮上，面板展开。这个时候用户想点面板里的“定价方案”，鼠标必须从按钮移动到面板上。听起来很简单，但注意：鼠标离开按钮的那一瞬间，按钮就不再匹配:hover了，展开状态立刻消失。
你可能觉得，鼠标移动很快，也就几十毫秒，菜单应该来不及收回吧？实际测试恰恰相反，越是想快速跨过去，越容易在离开按钮、还没进入面板的那几毫秒里触发收起。如果过渡时长设了0.2s甚至更多，视觉效果就是“菜单刚弹出来就开始往回缩”，你还没来得及把鼠标送进去，菜单已经缩没了。这种翻车现场每次都能复现，几乎不用碰运气。
2.2 为什么 :hover 在原理上就不成立
:hover是一个典型的“位置瞬态”状态，它只描述“鼠标此刻正好在这个元素上”。只要位置一变，状态立刻归零。这在下拉菜单这个交互里是一个致命弱点：用户的操作路径是从触发器A移动到面板B，A和B在DOM上通常还是兄弟节点，中间没有任何一个元素能维持:hover的连续性。CSS也没有提供“你从A滑向B，这个路径上的状态我帮你保持”的能力。
传统的补救思路是在触发器和面板中间加一个透明的“桥”，或者把transition-delay设得足够长，让鼠标有充足时间跨过缝隙。这些trick都是经验补丁，并没有修复状态模型本身的问题——这个状态基于位置，而位置恰恰是交互中最不可控的变量。
2.3 搜索联想、折叠面板、移动端菜单是同一种问题的变体
想通了这个模型，你会发现很多边界场景其实是同一个问题换了身衣服。
搜索框的联想列表：input获得焦点弹出列表，但如果列表项是普通的div，你点一下，input失焦，列表瞬间收回，点击行为根本没机会在视觉上被确认。还有导航面板里如果放了SVG图标或者自定义封装的组件，组件内部没有可聚焦元素，点击它一样会引起焦点漂移。触摸设备上更直接，根本没有:hover这个概念，所有基于hover的展开交互全部失效。
这些场景共同揭示了问题的核心：“展开”这个状态依赖了一个随时会消失的信号。想要根治，就要换一个更持久、更可靠的信号。下面要说的焦点，就是这样一个信号。
3. :focus 与 :focus-within 的“状态保活”能力
3.1 焦点和悬停的本质区别：位置记忆 vs 位置瞬态
焦点（focus）是键盘和屏幕阅读器交互的基础概念。一个元素一旦获得焦点，焦点就会一直留在它身上，直到用户Tab到下一个元素、点击了其他可聚焦元素、或者按下ESC。鼠标的移动本身不会导致焦点变化。这是核心差异：焦点是“状态保持型”信号，:hover是“位置瞬态”信号。
举个例子你立刻明白：在输入框里打字，鼠标中途移到页面的其他位置再移回来，输入框的焦点不会丢，你的光标还在原地。但如果你用:hover做联想面板的展开，鼠标一挪走，面板就缩了。对输入框而言，我们从来不会因为鼠标移开就认为用户“不想输入了”；那为什么下拉菜单要因为鼠标跨过了一条缝隙，就认为用户“不想点菜单了”呢？这种思维惯性本身就是问题。
3.2 :focus-within 把焦点状态提升到容器边界
:focus-within解决的是“后代获得焦点时，父容器也能被选中”的问题。这一个特性非常关键，因为下拉面板本身并不是一个天然可聚焦的元素，用户点击面板里的a标签时，:focus匹配的是那个链接，不是面板。如果用.menu:focus去写展开逻辑，根本不管用——焦点不在.menu自己身上。
但:focus-within会检查整个后代树，只要后代里有任何一个元素持有焦点，菜单容器就匹配。这意味着用户点击按钮获得焦点后，菜单展开；再把焦点从按钮移到面板里的链接，链接仍然是菜单容器的后代，容器继续匹配:focus-within，菜单保持展开。这个特性在2017年前后所有主流浏览器就都已经支持了，不需要担心兼容性。
3.3 展开逻辑重写：鼠标能否成功“跨栏”不再决定生死
在:focus-within的模型下，整个展开逻辑可以重写成下面这样：
如果用户点击或者Tab到按钮，按钮获得焦点，菜单容器匹配:focus-within，面板展开；用户从按钮移动到面板链接，焦点从按钮跳到链接，链接仍然是容器的后代，容器继续匹配:focus-within，面板保持展开；用户点击面板之外的任意区域，焦点转移到body或者其他新元素，容器不再匹配，面板收起。
整个流程里，鼠标不需要走什么“桥”、不需要依赖transition-delay的卡点，因为展开状态的维持完全不依赖鼠标路径。这是从状态模型层面解决问题，而不是打补丁。
3.4 交互模型辨析：:focus 到底适合哪种开关，不适合哪种
这里必须泼一盆冷水：:focus不是万能的。它适合“焦点在就开，失焦就关”的即时型展开收起，比如下拉菜单、搜索联想、工具提示。它不适合“点击一次展开、再点击一次收起”的持久切换型交互，比如经典的手风琴折叠面板。
原因很简单：在点击切换模型里，按钮自己一直是焦点持有者，你再点一次它，焦点并不会消失，状态就无法翻转。强行用:focus做手风琴，结果就是“展开后收不回去”。这种交互想要纯CSS解决，应该用:checked配合隐藏checkbox，或者踏实加JS配合aria-expanded。选错模型，工具再好用也白搭。
| 交互类型 | 推荐机制 | 典型场景 |
|---|---|---|
| 焦点在开、失焦即关 | :focus/:focus-within | 下拉菜单、搜索联想、轻提示 |
| 点击切换、再次点击收回 | :checked+ 隐藏checkbox | 手风琴折叠面板、Drawer |
| 需要复杂状态逻辑 | JS +aria-expanded | 多级联动菜单、受控组件 |
4. grid-template-rows 的 0fr → 1fr：唯一不需要具体像素值的优雅解
4.1 fr 轨道是“可以参与插值的 auto”
把高度过渡的问题拆开，本质就是我们想要一个既能自动适配内容高度、又能参与动画插值的数值单位。height: auto能适配内容但不能参与插值，height: 320px能参与插值但不能适配内容。那Grid布局里的fr轨道，恰好站在了两者的交叉点上。
fr单位本身是一个可计算的数值单位。0fr到1fr，中间的插值浏览器可以正常算出来。更妙的是，当Grid容器没有固定高度、只有一行轨道时，1fr轨道最终计算出来的高度，恰恰等于内容高度。也就是说，fr单位给了我们一个“既能动画、又能自动适配内容”的表达式，本质上就是auto的数值化替身。
为什么不用Flexbox？因为flex的交叉轴尺寸不参与类似的轨道插值，flex-grow控制的是主轴空间分配，和高度过渡的诉求对不上。Grid的轨道尺寸是一个显式可动画的属性，这才是它的过人之处。
4.2 三层结构：grid 容器、inner、content 缺一不可
用Grid方案做展开动画，HTML需要保持一个清晰的三层结构：最外层是Grid容器，中间是负责裁剪的inner层，最里面才是真实内容。为什么必须有中间层？因为轨道缩到0fr的时候，如果内容没有裁剪边界，实际渲染还是会溢出；内容只会被“隐藏”而不是“收缩”。必须给inner加上overflow: hidden和min-height: 0，才能强制轨道收缩时把内容藏住。
下面是最小可运行的结构：
<div class="expand"> <div class="expand__inner"> <div class="expand__content"> 这块内容可以随意变高，比如商品列表、菜单列表、搜索候选项 </div> </div> </div>.expand { display: grid; grid-template-rows: 0fr; transition: grid-template-rows 0.25s ease; } .expand.is-open { grid-template-rows: 1fr; } .expand__inner { overflow: hidden; min-height: 0; }min-height: 0是Grid子项特有的坑。Grid项的默认最小高度是auto，如果你的内容里有一张很宽的图片或者一行很长的文本，auto会让子项强制保持最小内容高度，导致轨道缩不到0。overflow: hidden和min-height: 0建议都写上，双保险。
4.3 为什么这里能表示“从0到内容高度”
展开一下原理。容器设置grid-template-rows: 0fr，同时声明transition: grid-template-rows 0.25s ease；展开态改成grid-template-rows: 1fr。动画过程中，浏览器在每一帧为轨道插值出一个fr系数，比如动画到50%时轨道系数是0.5fr。因为容器只有一个轨道且高度不固定，轨道实际高度就会按比例逼近内容高度。
一个重要的加分项是，如果内容高度是动态变化的——比如异步加载的图片导致栈高——1fr轨道会自动跟随内容高度重新计算，动画结束后的最终高度始终正确。这一点是max-height方案做不到的：你设小了内容会被裁掉，设大了又会有时间扭曲。用Grid方案，内容有多高，轨道就长到多高，不需要开发者事先预估。
4.4 和 max-height 的时间扭曲效应对比
我实测对比过一个内容实际高度100px的菜单。max-height设成400px，过渡时长0.25s，视觉上内容在动画刚启动没多久就被推完了，后面的时间几乎全在“空转”。更准确地说，浏览器是在对0 → 400px这个区间做插值，内容只是其中0 → 100px的一截画面，所以动画完成度看起来是被拉伸的。
Grid方案直接对0fr → 1fr做插值，1fr就是内容的真实高度，视觉速度和时间曲线完全对应。这个差异带来的体验提升是实打实的：用max-height方案，缓动曲线作用在了一个错误的区间上，你会感觉内容“冲出去”又“顿住”；用Grid方案，缓动曲线才真正作用于内容本身的位移。
| 对比项 | max-height 方案 | grid-template-rows 方案 |
|---|---|---|
| 是否需要具体上限值 | 需要，内容高了会被裁 | 不需要，1fr自动等于内容高度 |
| 实际内容速度和动画时长 | 不一致，存在空转 | 完全一致 |
| 动态内容适配 | 差，内容变高可能溢出 | 好，自动跟随 |
| 兼容性 | 极好 | 现代浏览器普遍支持，Safari 16+ |
5. 真实场景完整落地：导航下拉、搜索联想与可访问折叠面板
5.1 导航下拉：点击项不“断链”，点外部自动收回
先看导航下拉菜单的完整实现。HTML结构里，按钮、面板、裁剪层按三层嵌套，整个导航容器作为:focus-within的观察对象：
<nav class="menu"> <button class="menu__trigger" type="button">产品</button> <div class="menu__panel"> <div class="menu__panel-inner"> <a href="/features">核心功能</a> <a href="/pricing">定价方案</a> <a href="/docs">开发文档</a> </div> </div> </nav>.menu { position: relative; display: inline-block; } .menu__panel { position: absolute; top: calc(100% + 4px); left: 0; min-width: 200px; display: grid; grid-template-rows: 0fr; transition: grid-template-rows 0.25s ease; } .menu__panel-inner { overflow: hidden; min-height: 0; } .menu:focus-within .menu__panel { grid-template-rows: 1fr; }这个实现的关键点在于，点击面板里的链接时，焦点从按钮跳到了链接上，而链接仍然在.menu__panel-inner里，所以.menu:focus-within持续成立，菜单不会收回。用户点完链接触发页面跳转，或者执行完操作之后再点外部区域，焦点移走，菜单自然收起。
5.2 搜索词联想面板：解决点击选项瞬间面板闪烁
搜索联想是另一个高频场景。交互模式是输入框聚焦时弹出联想列表，用户能点选某个候选词，面板在点击候选词时不能闪掉，在点击外部时收起。
<div class="search-wrap"> <input type="search" class="search-input" placeholder="输入关键词" /> <div class="search-panel"> <div class="search-panel-inner"> <a class="suggestion" href="/result?q=css" tabindex="-1">css 高度过渡</a> <a class="suggestion" href="/result?q=grid" tabindex="-1">grid 0fr 1fr</a> </div> </div> </div>.search-wrap:focus-within .search-panel { grid-template-rows: 1fr; } .search-panel { display: grid; grid-template-rows: 0fr; transition: grid-template-rows 0.2s ease; } .search-panel-inner { overflow: hidden; min-height: 0; }这里有一个非常值得记录的坑：如果联想项是普通的div，没有加tabindex，用户点击它时，mousedown会先触发焦点转移，input失焦，焦点跳到body，:focus-within立刻失效，面板开始收起。紧接着click回调执行，数据虽然填回输入框，但输入框已经失去焦点，不会自动重新聚焦，最终表现就是面板“闪了一下”然后缩掉。
解决办法就是让每个可点击的联想项都成为“可聚焦元素”。我用加tabindex="-1"的方式，保证点击选项时它能接收焦点，容器:focus-within不丢；同时-1又不会让选项进入Tab的导航序列，不会干扰键盘用户的正常顺序。这个细节看起来小，实际体验差别很大，不做处理整个组件就会有“手感很脆”的感觉。
5.3 折叠面板的模型边界：:focus 不适用，:checked 才是正解
导航下拉和搜索联想都属于“焦点在开、失焦即关”模型，但如果你把手风琴折叠面板也套进:focus，就会踩中3.4里说的坑：展开后再点按钮，焦点不会消失，面板收不回去。
折叠面板的正确纯CSS做法是用:checked配合隐藏checkbox，动画部分还是可以用同一套Grid轨道思路：
<div class="collapsible"> <input type="checkbox" id="terms" class="collapsible__input" /> <label for="terms" class="collapsible__trigger">服务条款</label> <div class="collapsible__body"> <div class="collapsible__body-inner"> <p>这里放很长很长的内容，自动撑开，不需要知道具体高度。</p> </div> </div> </div>.collapsible__body { display: grid; grid-template-rows: 0fr; transition: grid-template-rows 0.3s ease; } .collapsible__body-inner { overflow: hidden; min-height: 0; } .collapsible__input:checked ~ .collapsible__body { grid-template-rows: 1fr; } .collapsible__input { position: absolute; opacity: 0; pointer-events: none; }把:focus-within和:checked放在一起对比，可以更清楚地看出状态来源决定交互模型：:focus是外部作用力决定的开关，:checked是用户主动记住的开关。选哪个不取决于哪个更“新潮”，而是取决于产品要什么行为。
5.4 Tab 键划过时，所有的键盘用户都会感谢你
这套方案还有一个容易被忽视的巨大优势：它的交互路径天然兼容键盘。桌面端键盘用户按Tab，焦点依次经过导航按钮，按钮聚焦时菜单展开；再按Tab，焦点进入面板里的链接；选择完成后按Shift+Tab倒着回退，或者继续往下Tab离开菜单，焦点移出容器，菜单收起。整个过程不需要额外写任何JavaScript，也不需要用focus事件去手动维护菜单状态。
我测试下来，唯一需要提防的是给触发器按钮加了outline: none又没做替代方案，把键盘用户的导航线索给抹了。这个后面第6章会专门说。
6. 填坑与兼容性处理：我在生产环境里踩过的四个暗坑
6.1 Safari 的 grid-template-rows 过渡经常“跳变”而非渐变
第一个坑来自Safari。grid-template-rows的过渡支持，Safari到16版本之后才算基本可用，16之前大概率是直接跳变，没有动画过程。这种“能显示、不渐变”的失败方式隐蔽性很强，你只看一眼截图根本发现不了，必须真机上手试才会察觉。
如果产品对旧版Safari有硬性要求，我的建议是准备好降级方案。Grid结构和:focus-within还都可以用，只是高度动画要用max-height或者干脆不做动画。降级用@supports检测的时候要注意：@supports能检测grid-template-rows: 0fr这种属性解析，但没法直接检测“该属性是否支持过渡动画”，所以需要靠版本判断或者把过渡做成渐进增强。最稳妥的做法是动画做得短一点，然后接受旧Safari上“瞬间展开”这种视觉结果，这总比动画扭曲或者内容被裁掉好。
6.2 失焦会先于点击回调触发，闪烁问题怎么防
这个坑我在做搜索联想组件时踩得很深。现象是输入框聚焦后弹出联想列表，用户点击候选词，面板闪了一下马上收回，哪怕click回调里已经正确填充了输入框的值。
排查过程很有代表性。我在mousedown、mouseup、click三个事件上分别打了日志，发现mousedown触发时焦点已经从input转移到了body，:focus-within在这个时刻就失效了，收起动画立即启动。之后click回调就算把值填回输入框，输入框也已经失焦，不会自动恢复焦点，面板自然就缩了。
解决方案是让被点击的选项自己成为焦点接收者。具体做法就是5.2里展示的：给选项加tabindex="-1"，点击时焦点落在选项上而不是跳到body，:focus-within从输入框到选项无缝交接，面板绝不会闪断。这个思路也可以扩展到其他场景：只要发现“点击面板内的区域导致面板关闭”，优先检查点击目标是否可聚焦。
6.3 焦点环样式的取舍：不要为了视觉牺牲键盘可定位性
:focus生效时，浏览器默认会给聚焦元素画一个焦点环。很多人嫌焦点环丑，直接写一句outline: none把它干掉。这个做法在鼠标场景下问题不大，但在键盘用户的视角里，这等于把导航灯全关了。
正确姿势是用:focus-visible区分输入方式：鼠标点击时隐藏焦点环，键盘Tab时保留明显环。浏览器在检测到键盘交互时会让:focus-visible匹配，鼠标点击时通常不匹配。写法很简单：
:focus-visible { outline: 2px solid #2f6fed; outline-offset: 2px; }注意这里只是控制了“视觉焦点环”的显示与否，元素的:focus状态本身不会消失，所以展开逻辑完全不受影响。视觉上干净了，键盘可达性也保住了。
6.4 多菜单互斥是 :focus 白送的礼物，但容器层级别放错
最后一个坑关于多菜单场景下的互斥。焦点机制有一个天然特性：同一时刻整个页面只能有一个元素持有焦点。这意味着如果你的每个下拉菜单都是独立的:focus-within观察容器，那么多个菜单同时展开的事件从原理上就被排除了——不可能有两个焦点同时存在于两个容器里。
但容器层级一旦放错，这个“白送的礼物”就会变成麻烦。我第一次重构多级导航时，把展开样式挂在整个nav根容器上，结果任意一个子菜单获得焦点，整个导航区域都匹配:focus-within，所有菜单同时展开，页面瞬间变成一个“多级烟花秀”。排查后发现根因就是观察粒度太大。正确做法是给每个菜单一个独立的.menu容器，把:focus-within观察范围限制在组件内部，互斥自然成立，逻辑也更好维护。
如果确实需要“焦点在菜单A时，菜单B也收起”这种跨组件联动，那就要引入JS了。但在绝大多数导航场景下，组件级的:focus-within已经足够干净可靠。
最后分享一个我自己的判断标准：如果一个展开交互是“打开后马上自动关闭”的即时型，优先考虑:focus或者:focus-within配合Grid轨道动画；如果是“打开后需要用户手动关闭”的持久型，才考虑:checked或者JS方案。想清楚交互模型再动手，比任何姿势都重要。
