可缩放UI核心是用:root变量配合rem：定义--scale变量，根字号设为calc(16px * var(--scale))，所有尺寸用rem；transform:scale仅视觉拉伸，不重排布局、错位事件坐标、模糊文字。
怎么用 rem 配合 :root 变量做可缩放UI
核心就一条：把根字体大小变成可配置的变量，再让所有尺寸单位都基于它。不是靠 JS 动态改 document.documentElement.style.fontSize，而是用 CSS 自身的级联和计算能力。
常见错误是直接在 :root 里写死 font-size: 16px，然后各处用 rem，结果缩放时还得手动调多个地方。真正可缩放的关键，在于把缩放因子抽成变量，用 calc() 推导出根字号。
-
:root里定义一个缩放系数变量，比如--scale: 1 - 用
font-size: calc(16px * var(--scale))设置html根字号 - 所有组件内尺寸（
padding、border-radius、font-size等）统一用rem，不写px或em - 需要局部微调时，只改该组件的
--scale值，或加一层 wrapper 元素覆盖变量
为什么不能只靠 transform: scale() 实现缩放
它只是视觉拉伸，不改变布局流、事件坐标、媒体查询断点，还会模糊文字、错位 position: fixed 元素。用户缩放页面时滚动条位置异常、点击区域偏移，基本都源于此。
而 rem + 变量方案是真实重排：字体变大、行高变大、间距变大，整个盒模型按比例响应。媒体查询依然有效，vh/vw 也保持同步，打印样式不会崩。
立即学习“前端免费学习笔记（深入）”；
-
transform: scale(1.2)后，click事件的clientX/Y还是原始坐标，容易误触 - 设了
transform的元素，getBoundingClientRect()返回值不变，JS 测量失效 - 缩放后文字边缘发虚，尤其在 Windows + Chrome 下明显
- 无法与系统缩放（Windows 缩放设置、macOS 显示器分辨率缩放）自然对齐
rem 在不同设备上的兼容性陷阱
老版本 iOS Safari（calc() 中嵌套 var() 支持不稳定，比如 font-size: calc(16px * var(--scale)) 可能被忽略，回退到浏览器默认字号。
安全做法是提供降级：用 @supports 包裹变量方案，不支持时 fallback 到固定 rem 基准（如 16px），同时确保所有尺寸仍可用 rem 表达，不混用 px。
- 别在
calc()里写var(--scale) * 16px，顺序颠倒某些 Android 4.x WebView 会解析失败 - 避免在
@keyframes内使用含变量的calc()，iOS 12–13 有渲染卡顿 - 如果项目需支持 IE，
rem本身就得配pxfallback，但变量方案本身 IE 完全不支持，得彻底换路
如何让缩放不影响特定元素（比如图标、边框线）
缩放是全局的，但有些东西不该跟着变粗或变大——比如 1px 边框、SVG 图标、阴影扩散值。解决思路不是“禁止缩放”，而是“用相对单位反向抵消”。
例如边框：根字号放大 2 倍后，border: 1px solid 会变粗一倍。此时改用 border-width: calc(1px / var(--scale))，就能维持视觉粗细不变。
- SVG 图标建议用
width/height设为1em，再通过font-size控制大小，而不是固定px - 阴影如
box-shadow: 0 2px 4px rgba(0,0,0,0.1)，其中2px和4px也要用calc()按比例缩小 - 绝对定位的提示框（tooltip）若用
top: -10px往上偏移，得改成top: calc(-10px / var(--scale))，否则缩放后偏移量失真
缩放逻辑越往 CSS 层下沉，越要小心那些“看起来没动但其实被连带影响”的地方——比如 line-height 的数值类型、letter-spacing 的单位、甚至 outline-offset。它们不像 font-size 那样显眼，却会在缩放后悄悄破坏对齐。
