Chrome缩放（<100%）时非预期显示滚动条的原因与解决办法

我之前也踩过这个坑！当Chrome把页面或控件缩放到100%以下，再加上元素设置了overflow: auto，哪怕元素里完全没内容，也会莫名出现滚动条，确实挺闹心的。结合你给出的示例和Chrome版本，我来拆解下原因和可行的解决办法：

问题产生的原因 #

• Chrome在处理非100%的缩放时，会对元素的实际渲染尺寸进行浮点运算，但滚动条的显示判断逻辑存在精度偏差。浏览器会检查内容是否超出容器，可缩放后的尺寸计算误差会让它误判“内容超出了容器”，哪怕实际是空的。比如你示例里的textarea，缩放90%后，容器的渲染尺寸可能出现了像素级的小数偏差，直接触发了滚动条的显示逻辑。
• 另外，textarea这类元素本身带有默认的内边距、边框，缩放后这些默认样式的尺寸计算也会加剧偏差，进一步让浏览器误以为有内容需要滚动。

解决方法 #

给你几个实用的方案，按需选择：

• 方案一：用overflow: hidden替代auto（适合确定不需要滚动的场景）
  如果你的元素肯定不会有超出容器的内容，直接把overflow: auto改成overflow: hidden，从根源上避免滚动条触发。示例代码：

  <textarea style="overflow: hidden; height: 100px; width: 500px; zoom: 90%;"> </textarea>
  

• 方案二：重置textarea的默认样式并配合box-sizing
  textarea默认的内边距和边框是误差的重灾区，重置这些样式能大幅减少计算偏差。要是需要保留边框，记得用box-sizing: border-box确保边框尺寸不会影响容器的尺寸计算：

  <textarea style="overflow: auto; height: 100px; width: 500px; zoom: 90%; box-sizing: border-box; padding: 0; border: 1px solid #ccc;"> </textarea>
  

• 方案三：使用标准的transform: scale()替代非标准zoom
zoom是Chrome的非标准属性，渲染逻辑和标准的transform: scale()差异很大。用transform缩放能有效减少尺寸计算的精度问题，记得配合transform-origin调整缩放原点，避免元素位置偏移：

  <textarea style="overflow: auto; height: 100px; width: 500px; transform: scale(0.9); transform-origin: top left;"> </textarea>
  

• 方案四：通过JS动态微调元素尺寸
  如果你必须保留zoom和overflow: auto，可以用JS动态获取元素的实际渲染尺寸，微调容器大小来抵消计算误差：

  const targetTextarea = document.querySelector('textarea');
  // 微调高度，比如减去1px来修正偏差
  targetTextarea.style.height = `${parseInt(getComputedStyle(targetTextarea).height) - 1}px`;
  

内容的提问来源于stack exchange，提问作者Caramiriel