真正可维护的做法是将像素值变量化的 CSS 自定义属性方案：通过 :root 定义 --unit 等基础变量，用 calc() 动态计算尺寸，实现集中控制、安全缩放与实时调试。
用 CSS 自定义属性 + calc() 实时微调像素值
设计稿里按钮高 42px，开发出来是 41.8px，差的不是 bug，是设计师盯着屏幕缩放 300% 后的执念。硬改 height: 42px 不行——下次改稿可能变成 42.5px，或者所有圆角统一加 0.3px。真正可维护的做法，是把像素值“变量化”。
把频繁变动的数值抽成 --unit、--gap-sm 这类自定义属性，在根元素或组件作用域内集中管理：
:root {
--unit: 1px;
--gap-sm: calc(4 * var(--unit));
--radius-md: calc(6.5 * var(--unit));
}这样后续只需改一行 --unit，整个系统就按比例缩放；或者单独调 --radius-md，不影响其他尺寸。比全局搜 6px 替换安全得多。
- 别在 JS 里动态写内联样式去覆盖，会破坏 CSS 优先级和可追溯性
- 避免用
em或rem做微调——它们依赖字体大小，容易被意外继承干扰 - 设计标注若带小数（如
12.3px），直接写进calc()，浏览器支持良好，Chrome/Firefox/Edge 均无兼容问题
PostCSS 插件自动注入设计标注值
当设计稿由 Zeplin/Figma Sync 输出 JSON 标注，人工抄数值既慢又易错。PostCSS 插件如 postcss-design-tokens 或自研解析器，能把标注里的 spacing.sm: 8.4 直接转成 CSS 变量。
立即学习“前端免费学习笔记（深入）”；
关键不是“自动化”，而是建立设计→代码的单向映射链：设计改了 → JSON 更新 → 构建时重生成 CSS 变量 → 开发无需手动同步。
- JSON 中的单位必须明确（如
"8.4px"而非8.4），否则插件可能误判为倍数 - 插件输出的变量名要带命名空间（如
--ds-spacing-sm），避免和业务变量冲突 - 不建议让插件直接生成具体组件样式（如
.btn { padding: ... }）——那会剥夺开发对语义和响应式的控制权
浏览器 DevTools 里实时拖拽调整 CSS 变量
设计师现场提需求：“这个边距再收 0.7px”，不用切编辑器、改文件、等热更新。打开 DevTools 的 :root 节点，找到 --gap-xs，鼠标悬停后出现小箭头，直接拖拽微调——值实时生效，且支持小数精度。
这招只适用于调试阶段，但能极大缩短反馈闭环。前提是变量已正确定义并被使用，否则拖了也看不见效果。
- 确保变量定义在
:root或父级作用域，子元素用var(--gap-xs)引用，不要用inherit或initial干扰链路 - 拖拽时注意单位——DevTools 默认按 px 拖，但如果变量定义是
calc(3.2 * 1px)，拖动的是乘数部分，实际变化是非线性的 - 拖完记得复制新值，粘贴回源码，否则刷新即丢
慎用 transform: scale() 修复像素对齐
遇到 Canvas 渲染模糊、border-width 在 Retina 屏显示为 1.5px 这类底层对齐问题，有人会想到 transform: scale(0.99) 强行“挤”出整像素。这不是微调，是掩耳盗铃。
scale() 会让文字发虚、阴影变形、点击区域偏移，且无法响应式适配不同 DPR。它解决的不是设计一致性，而是渲染缺陷的表象。
- 真要处理 DPR 对齐，优先用
window.devicePixelRatio动态设置border-width或 canvasbackingStorePixelRatio - 如果只是按钮高度差 0.2px，检查是否用了
box-sizing: border-box却漏算了border或padding的累积误差 - 设计标注本身若没声明 DPR 适配规则（比如“所有尺寸按 2x 出图”），那先和设计师对齐基准，而不是在代码里打补丁
像素级差异背后，往往不是 CSS 写得不够细，而是变量边界没划清、设计交付物缺少机器可读性、或者团队对“1px”到底指物理像素还是逻辑像素缺乏共识。这些地方一模糊，再多的 calc() 也救不回来。
