--scale变量统一驱动所有尺寸计算更可控易维护，因transform:scale()仅缩放渲染层不改DOM尺寸，导致交互错位、坐标失准及字体糊化；而--scale配合calc()实现真布局缩放，需覆盖font-size、padding、border-width、line-height、letter-spacing、stroke-width、box-shadow等所有物理尺寸属性，并按视口宽高比动态计算以保比例，同时注意局部反向缩放隔离与Canvas/SVG坐标系同步。
直接用 --scale 变量统一驱动所有尺寸计算，比写一堆媒体查询或硬编码 px 值更可控、更易维护。
为什么不能只靠 transform: scale()
它只缩放渲染层，不改 DOM 尺寸：getBoundingClientRect() 返回的宽高还是原始值，导致鼠标 hover 区域错位、position: absolute 偏移失效、Canvas/SVG 内部坐标系失准。字体在 scale(1.2)～scale(1.4) 区间容易糊化，第三方图表库（如 ECharts）也不响应 transform 变化，不会触发重绘。
而 --scale 配合 calc() 是真布局缩放——每个 font-size、padding、width 都随比例重算，点击区域、z-index、文字清晰度全在线。
--scale 要绑定哪些 CSS 属性？
常见遗漏项远不止 font-size 和 padding，必须检查所有带物理尺寸含义的属性是否参与 calc() 计算链：
立即学习“前端免费学习笔记（深入）”；
-
border-width：高分屏下1px会细得看不见，得写成calc(1px * var(--scale)) -
line-height：别写1.4em，要写calc(1.4 * var(--scale))，否则嵌套时变成指数放大 -
letter-spacing、stroke-width（SVG 中）、box-shadow的blur和offset值也常被漏掉 -
vw/vh是视口单位，和--scale正交；若设计稿以1920px宽为基准，100vw应换算为calc(100vw / 1920 * var(--scale))
如何动态计算 --scale 值？
别简单用 window.innerWidth / 1920，真实场景要保设计稿宽高比（如 1920×1080 → 16:9），防止窄屏下内容被压扁或拉长：
- 先算当前视口宽高比：
const currentRatio = window.innerWidth / window.innerHeight - 对比设计稿比值
1920 / 1080 ≈ 1.77778 - 若
currentRatio > 1.77778（屏幕更宽），说明高度是瓶颈 → 按高度缩放：scale = window.innerHeight / 1080 - 否则按宽度缩放：
scale = window.innerWidth / 1920 - 最终设为：
document.documentElement.style.setProperty('--scale', scale.toFixed(4)) - 加防抖（300ms），但别引入 Lodash —— 大屏首屏性能敏感，手写一个即可
容易被忽略的复杂点
最隐蔽的问题不是计算逻辑，而是“局部反向缩放”：比如弹窗需要固定大小，有人会在子元素里覆盖 --scale，结果父子缩放叠加，font-size: calc(14px * var(--scale)) 在子元素里又乘一遍，字体爆炸式变大。真要用局部反向，必须显式重置并隔离作用域，比如用 [data-no-scale] 类配合 :not([data-no-scale]) 选择器排除，而不是无差别覆盖变量。另外，Canvas 和 SVG 元素内部坐标系不自动响应 --scale，需在 JS 中同步调整 canvas.width/height 或 viewBox。这些细节不处理，大屏上线后第一眼看不出问题，但交互一多就露馅。
