17370845950

这不是 bug，是 CSS 盒模型中 border、padding、box-sizing 和渲染像素对齐共同作用的结果；视觉尺寸与 offsetWidth 不一致源于 subpixel 渲染、DPR、outline 等非布局属性及字体渲染差异。

元素看起来变大但 offsetWidth 没变？先看盒模型计算逻辑

这不是 bug，是 CSS 盒模型中 border、padding、box-sizing 和渲染像素对齐共同作用的结果。浏览器渲染时，元素的视觉尺寸（人眼感知的“大小”）可能和 offsetWidth / getBoundingClientRect().width 返回值不一致——尤其在缩放、字体变化或 subpixel 渲染场景下。

box-sizing: border-box 下 padding/border 不影响 width，但影响视觉密度

当设置 width: 200px; padding: 10px; border: 2px solid #000; 且 box-sizing: border-box 时，offsetWidth 仍是 200，但内容区被压缩到 176px（200 − 2×10 − 2×2），文字/子元素实际可用空间变小，导致视觉上“更挤”“显得更大”。这种错觉常被误认为“元素变大了”。

• 用 getComputedStyle(el).width 查的是 CSS 宽度声明值（如 "200px"），不是渲染后像素
• 用 el.getBoundingClientRect().width 才是真实渲染宽度（含 subpixel，可能为 200.34）
• 开启 Chrome DevTools 的 “Rendering > Paint flashing” 可直观看到重绘区域是否超出预期

字体缩放、DPR 和 subpixel 渲染让视觉尺寸“浮动”

高 DPR 屏幕（如 macOS Retina、Windows 缩放 125%）下，CSS 像素 ≠ 物理像素。1px 边框可能被渲染为 1.25 个物理像素，浏览器会做抗锯齿或模糊处理，造成边缘发虚、块状感增强，主观觉得“变厚了”“变大了”，而 offsetWidth 仍返回整数 CSS 像素值。

• 检查当前设备像素比：window.devicePixelRatio
• 禁用 subpixel 渲染可验证：给元素加 transform: translateZ(0) 或 will-change: transform，有时会让渲染强制走整像素对齐（但副作用是触发新层）
• 避免用 px 控制字体大小时依赖视觉“刚好填满”，改用 em 或 rem + line-height 组合控制垂直节奏

伪元素、outline、box-shadow 也会“偷走”视觉注意力

::before/::after 即使 display: none 但未移除，或 outline（不占布局空间）、box-shadow（不参与盒模型计算）都可能让元素在视觉上“膨胀”。比如 outline: 2px solid blue 会让焦点态明显变厚，但 offsetWidth 完全不变。

button {
  width: 100px;
  outline: 3px solid rgba(0, 100, 255, 0.5);
  /* 点击后视觉宽度明显超过 100px，但 getBoundingClientRect().width 还是 ~100 */
}

• 排查时优先在 DevTools 中关闭 outline、box-shadow、filter 等非布局属性
• 用 “Computed” 面板对比 border-box 和 content-box 视图，确认 padding/border 是否被意外撑开
• 某些字体（如 system-ui）在不同系统下字形高度差异大，配合 line-height: 1 易导致容器被文字顶高，看似“变高”，实为 inline 元素基线对齐问题

真正要盯住的不是“看起来大不大”，而是 getBoundingClientRect() 返回的数值、DevTools 的 Layout 网格叠加、以及是否启用了强制缩放或用户代理样式干预。视觉误差往往藏在渲染管线末端，而不是盒模型本身。