这不是 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 网格叠加、以及是否启用了强制缩放或用户代理样式干预。视觉误差往往藏在渲染管线末端，而不是盒模型本身。
