小数点偏差是浏览器按DPR进行亚像素渲染的必然结果，getBoundingClientRect()返回的是含DPR缩放的实际渲染尺寸，如100.345px；应接受小数存在，用flex/grid等布局机制兜底而非强行取整。
小数点偏差不是渲染错误，而是浏览器把逻辑像素按物理像素密度（DPR）做亚像素映射时的必然结果——width: 100px 在 DPR=2 的设备上要铺满 200 物理像素，中间某几个像素只能用半透明或插值填充，最终合成出带小数的渲染尺寸。
亚像素渲染导致 getBoundingClientRect() 返回小数值
Chrome/Firefox/Safari 都会把 CSS 声明的整数像素，结合当前 DPR 和缩放比例，映射到物理像素网格上。这个过程不是简单乘法，而是带抗锯齿和子像素定位的合成计算。
-
getBoundingClientRect().width返回的是渲染后实际占位（含 DPR 缩放），所以常见100.345、199.998这类值，不是 JS 计算误差 - 当容器宽度为
33.333%× 父宽 = 333.333...px，而 DPR=2 时，浏览器可能分配 666.666 物理像素 → 渲染引擎四舍五入或插值得到 333.33px - 不要用
Math.round()强行取整：它掩盖了真实渲染状态，可能导致 layout shift 或滚动条闪现
box-sizing + flex/gap 组合放大微小偏差
即使你写了 box-sizing: border-box，flex 子项在分配剩余空间时仍会基于浮点运算做均分，而每个子项的 border、gap 又各自引入独立的亚像素误差，多列叠加后视觉错位就明显了。
- 三列
flex: 1容器宽 1000px，DPR=1.25 → 实际物理宽度 1250px；均分后每列得 416.666...px，但浏览器给第一列 416.67px、第二列 416.66px、第三列 416.67px，加起来仍是 1250px，视觉上却出现 0.01px 累积差 -
gap: 12px在 DPR=1.5 下实际占 18 物理像素，但若父容器宽是 1000px（DPR=1.5 → 1500 物理像素），gap 占比就不是精确的 12/1000 - 解决方案：用
flex-basis: calc((100% - 2 * 12px) / 3)显式减去 gap，再配合box-sizing: border-box，让所有尺寸锚定在同一计算链上
字体度量与 line-height 插入不可见小数高度
中文字体的 ascent/descent、OpenType 的 line gap、以及浏览器对 line-height 的内部实现，都会让行框高度不是整数——哪怕你设了 height: 44px，真实 getBoundingClientRect().height 可能是 44.23px。
- Chrome 对
font-family: "PingFang SC"的默认 line gap 是 1.123 倍font-size，16px 字号下这行高就是 17.968px，不是 18px -
vertical-align: middle实际对齐的是元素中线与父行框中线，而父行框高度本身就有小数，导致图片或图标底部浮动 0.3px - 调试建议：打开 DevTools → Elements → Computed → 拉到最底下看
line-height和height的实测值，别信“应该”是多少
真正麻烦的不是小数本身，而是它常藏在 getBoundingClientRect()、offsetHeight、甚至 transform: translateY() 的像素对齐判断里，一旦你拿它做条件判断或动画起点，偏差就会被放大。处理原则只有一条：接受小数存在，用相对单位（如 em、ch）或布局机制（flex、grid）兜底，而不是硬用 parseInt() 截断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
