下拉菜单的宽度我算了五年，现在浏览器自己会算了——`select` 的 `field-sizing: content` 把这个场景也包了

写过下拉菜单的同学都知道，不管 option 里文字多长，select 盒子就那么宽。要么提前固定个 max-width，要么用 JS 去量最长的那条有多宽，然后动态设置。代码写得多了，每次还要处理截断和省略号，体验一言难尽。

这个问题，field-sizing: content 这次也顺手给你解决了。

先说是什么

field-sizing 是一个 CSS 属性，最初设计是用来让表单输入框自己调整大小的。你可能见过这个用法：

input, textarea {
  field-sizing: content;
}

设置了之后，输入框会自动根据内容撑开，不再需要手动设置宽度。这个能力在 2024 年进入 Baseline，MDN 上已经有完整的文档记录。

但这次要说的，是它顺带覆盖到的另一个元素：select。

select 的 field-sizing: content

给 select 加上这行试试：

select {
  field-sizing: content;
}

然后你就能看到——下拉菜单的宽度会自动适配最长的那个 option，不用写任何 JS。

这个行为其实不是浏览器”特意”为 select 加的，而是 field-sizing: content 本身的规则：它会让元素的尺寸跟随内容变化，而 select 内部的 option 内容变化会被视为内容变化，触发重算。所以无论是 <select> 还是 <input type="select">，只要你设置了这行，它就会去找最宽的 option，然后把自己撑到那个宽度。

几个需要注意的细节

placeholder 的影响。 如果你的 select 第一个 option 是空值作为 placeholder，比如 <option value="">请选择</option>，这个空白 option 的宽度在计算时可能不会被计入。实际表现以最长的可见 option 文字为准。

宽度有上限。 select 不会无限制撑开，如果它的父容器有宽度约束，它会在达到父容器宽度后停止，然后内容溢出时显示滚动条。这个行为和普通 block 元素一致。

多选 select 的情况。 multiple 类型的 select 行为略有不同，它主要控制高度而不是宽度，内容变化时的高度调整是主要的。

渐进增强。 目前主流浏览器基本都支持了，但如果你的项目需要兼容老版本浏览器，可以加一个 @supports 检测：

select {
  /* 老浏览器兜底 */
  min-width: 200px;
  width: 200px;
}

@supports (field-sizing: content) {
  select {
    field-sizing: content;
    width: auto;
  }
}

和 JS 方案的对比

过去实现”自动宽度 select”的常见方式：

1. JS 动态计算：创建一个隐藏的 span，用 getComputedTextLength() 量最长的 option 文字，再设置 select 的宽度。每次 options 变化都要重新计算。
2. 固定 max-width + 省略号：简单，但用户看不到完整文字，体验差。
3. 自定义下拉组件：体验好，但引入第三方依赖，而且 accessibility 要自己处理。

field-sizing: content 的优势在于：零 JS、浏览器原生行为、继承 CSS 的所有能力（媒体查询、容器查询、主题变量等），以及天然的 accessibility 支持——因为它还是原生 select，屏幕阅读器和键盘操作完全不受影响。

什么时候用它，什么时候换组件

field-sizing: content 适合：选项文字长度差异不大、但不想手写宽度的下拉菜单；移动端表单；需要响应容器宽度变化的场景。

不适合：选项极多、文字超长（比如国家列表带完整地址）；需要图标、图片等富内容 option；UI 设计要求特定的下拉样式。后两种情况建议直接上自定义下拉组件，比如用 listbox 模式配合 ARIA。

下一步

找个表单页面试一下，把原来的固定宽度 select 改成：

select {
  field-sizing: content;
  max-width: 100%; /* 防溢出 */
}

看看效果。如果在某个浏览器上有问题，加 @supports 兜底即可。这个改动成本几乎为零，但能省掉以后维护 JS 宽度计算逻辑的麻烦。