设计稿还原不准，核心问题往往出在盒模型理解偏差或单位换算错误。不是像素没量准，而是浏览器如何解释“100px”和设计师眼中的“100px”存在隐性差异。
确认设计稿基准与浏览器默认行为一致
设计师通常基于content-box逻辑标注尺寸（即标的是内容区宽高），而CSS默认也是content-box——这点其实一致。但常见误操作是：看到按钮标“宽120px、高40px、内边距12px”，就直接写width: 120px; height: 40px; padding: 12px;，结果总比设计稿胖一圈。
原因：此时总宽度 = 120px（内容宽） + 左右padding（24px） + 左右border（若有）→ 实际占位远超120px。
- 若需严格按设计稿“整体外框”还原（比如卡片总宽必须等于375px），优先用
box-sizing: border-box - 全局设置更省心：
* { box-sizing: border-box; }，之后所有元素的width/height即为“包含padding和border的总尺寸” - 检查是否意外继承了其他组件的
box-sizing: content-box，可用开发者工具逐层验证computed值
处理字体、行高、内联元素带来的高度干扰
文字区域的高度常被低估。例如设计稿中一段正文标高“24px”，实际可能是font-size: 14px; line-height: 1.714（≈24px），但若只设line-height: 24px，在不同字号下会失准；若只设font-size: 14px又没控行高，浏览器按默认line-height（通常约1.2）渲染，高度就塌了。
立即学习“前端免费学习笔记（深入）”；
- 优先使用无单位的
line-height（如line-height: 1.714），它会随font-size缩放，更稳定 - 对齐文字时别只依赖
padding-top，多结合vertical-align（针对inline元素）或flex align-items（容器级居中） - 用开发者工具选中文字元素，看“Metrics”面板里的actual height和baseline位置，比肉眼判断更可靠
警惕缩放、设备像素比与设计稿标注单位混淆
UI设计师给的Sketch/Figma文件通常是@1x或@2x标注，但开发时写的CSS像素是逻辑像素（CSS px）。如果设计稿是iPhone 14 Pro的@3x切图，却按375×812直接写宽高，未考虑viewport缩放或dpr适配，就会整体偏小。
- 明确设计稿基准宽度（如375px对应iPhone SE）、是否已做rem/vw适配
- 避免在CSS里混用单位：同一模块内不要同时用px、rem、%来控制关键尺寸
- 移动端建议统一用vw（如
width: 100vw）或配合postcss-pxtorem自动转换，减少手动计算误差
用“差值定位法”快速校准微小偏差
当整体结构没问题，但某个图标低2px、按钮右边空隙多3px时，不要反复改padding/margin，先锁定“参照物”：
- 找一个绝对不动的基准线（如顶部导航栏下边、标题文字baseline、图片上边缘）
- 用开发者工具测量目标元素到该基准线的距离，和设计稿中标注值对比，差多少就补多少
- 优先调
transform: translateY(-2px)而非margin-top，避免影响文档流和其他元素布局
