CSS interpolate-size 让 height:auto 可过渡：旧写法、迁移边界与降级验证

折叠面板里的说明文字只有3行时展示正常，换成12行的长内容后，height: auto 往往还是瞬间展开。以前常用的处理方案，要么是把高度上限设成一个远大于预期值的 max-height，要么用 JavaScript 先测量内容的实际高度再手动写回像素值。现在可以先在局部容器开启 interpolate-size: allow-keywords，让普通长度值和 auto、max-content 这类 intrinsic size 参与过渡运算；但它本身属于渐进增强特性，不适合跳过兼容性检查直接全站替换。

从 max-height 迁移到 intrinsic size 过渡

先看一个大家都写过的旧方案。它不需要提前测量内容，靠一个“足够大”的上限值来模拟流畅的展开效果：

.panel {
  max-height: 0;
  overflow: hidden;
  transition: max-height 240ms ease;
}

.panel.is-open {
  max-height: 800px;
}

这个方案的问题不是没法用，而是过渡时长的曲线被你预设的800px这个估算值绑死了：如果实际内容只有160px高，视觉上过渡动画会提前结束，剩下的时间都是静止画面；如果内容高度超过你预设的上限，内容又会被直接裁切掉。把 max-height 换成真正的 height，让浏览器原生参与 intrinsic size 的插值计算，迁移的边界就能清晰很多。

最小改造：allow-keywords 与 height:auto

下面这组样式可以直接放到普通折叠面板的示例里测试。核心改动只有两处：折叠关闭状态给出明确的固定长度，打开状态直接使用 auto，再在合适的上层祖先节点上开启插值权限。

.faq-panel {
  interpolate-size: allow-keywords;
  height: 0;
  overflow: hidden;
  transition: height 240ms ease;
}

.faq-panel.is-open {
  height: auto;
}

@media (prefers-reduced-motion: reduce) {
  .faq-panel {
    transition-duration: 1ms;
  }
}

interpolate-size 是支持继承的 CSS 属性，所以你也可以把它放在 :root 或者某个页面全局区域。不过更推荐先把它放在实际用到的组件上，这样新特性的影响面会非常小，页面里其他没适配的组件依然可以保持原本的布局逻辑，不会出现意料之外的异常。

有个很容易被忽略的限制：过渡的两端不能全是 intrinsic size。height: auto 到固定长度可以正常插值，auto 到 max-content 就没法靠这一条声明直接实现。碰到这类设计需求，可以先调整状态逻辑改成“固定长度 ↔ 内容原生高度”的两端模式，不需要堆叠多余的过渡属性强行实现效果。

继承范围、支持检测和旧浏览器结果

这项能力在 MDN 上目前还标注为 Limited availability，上线前先确认自己产品要覆盖的目标浏览器兼容矩阵。好消息是，不认识 interpolate-size 的浏览器会直接忽略这条陌生声明，折叠面板依然能按普通CSS规则正常展示，只是不会出现从0平滑过渡到内容原生高度的动画效果。

如果页面需要明确区分“有动效”和“无动效”两种表现，可以把增强样式放到特性检测的分支里：

.faq-panel {
  height: auto;
}

@supports (interpolate-size: allow-keywords) {
  .faq-panel {
    height: 0;
    overflow: hidden;
    interpolate-size: allow-keywords;
    transition: height 240ms ease;
  }

  .faq-panel.is-open {
    height: auto;
  }
}

这里写的默认规则不是多余的装饰，而是必须保证的降级基线：不支持新属性的环境下，内容要始终保持可见，用户至少能正常读到完整信息。如果产品逻辑里默认就是折叠状态，就要额外设计适配键盘操作的按钮状态和无脚本体验，不能完全依赖高度过渡效果来做交互。

calc-size() 什么时候值得引入

如果你只需要实现从0展开到内容自然高度的效果，interpolate-size 通常已经完全够用。需要在 intrinsic size 的基础上做额外数值计算的时候，再考虑引入 calc-size()，比如给算出来的内容高度额外再加一段预留的留白空间：

.card {
  interpolate-size: allow-keywords;
  height: calc-size(auto, size + 16px);
  transition: height 240ms ease;
}

要注意，calc-size() 本身就进一步拉高了浏览器兼容门槛，不能把它和普通的 calc() 特性当成同一个兼容层级的属性直接混用。生产环境代码建议用 @supports (height: calc-size(auto, size + 1px)) 包住所有增强分支，同时保留不带额外计算逻辑的兜底高度规则。

上线前的四个核对点

测试的时候别只放一段短文本凑数。至少准备空内容、单行内容、长段落和动态插入内容四组测试样本，再分别用鼠标、键盘操作，配合不同的窄屏宽度验证。这套测试流程能帮你提前暴露出“动画看起来跑通了，但最后一行内容始终不可见”这类边缘问题。

相关问题

为什么 height:auto 以前很难直接 transition？

传统的 CSS 插值逻辑只支持在两个预先可计算的长度或者百分比之间运算，auto 需要等到完整布局阶段才能算出最终的实际尺寸。新属性提供的是显式的选择加入通道，不是直接改动所有旧样式的默认语义逻辑。

能不能把两个 auto 状态做动画？

不能把两个 intrinsic size 直接当成这个属性的通用动画端点。可以把其中一端调整成明确的固定长度，或者改用适配内容动态变化的其他布局方案。

不支持 interpolate-size 的浏览器会白屏吗？

不会因为这一条浏览器不认识的声明白屏，但用户不会得到平滑的高度过渡效果。只要提前写好的默认规则保证内容始终可见，降级结果就是“功能完全可用，只是少了过渡动画”。

JavaScript 测量方案需要马上删除吗？

完全不必。碰到需要精确控制过渡中间高度、兼容更低版本浏览器或者配合复杂虚拟列表的场景，手写测量方案依然有不可替代的价值。可以先根据自己产品的浏览器分布数据和组件复杂度做灰度替换。

把迁移控制在组件边界内

interpolate-size 的核心价值是减少开发者为了拿到内容高度专门写的冗余测量代码，但它不会替你解决交互语义校验、内容裁剪、全量兼容所有旧版本浏览器这些问题。先给单个折叠组件加上局部增强，确认键盘操作状态、长内容展示和降级路径都完全稳定，再考虑逐步扩大属性的继承范围。这样哪怕某个浏览器暂时还没支持这项能力，页面也只是少了一个过渡效果，不会丢失任何实际展示的内容。