zoom 修改渲染尺寸并触发重排，影响布局计算和字体最小限制；transform: scale() 仅改变绘制坐标，不触发重排，但导致事件区域与视觉位置错位。
因为 zoom 直接修改元素的「渲染尺寸」，而 transform: scale() 仅改变其「绘制坐标」，不参与 layout 阶段计算。
zoom 会重算盒模型尺寸，触发重排
zoom 是非标准属性，但 Chrome/Safari/Edge（除 Firefox）实际将其当作一种“伪 layout 缩放”：它会让浏览器在 layout 阶段就按缩放比重新计算 width、height、font-size 等值。这意味着：
- 父容器会根据缩放后尺寸重新分配空间（比如
zoom: 0.8的div原本占 200px 宽，现在只占 160px） - 子元素的百分比宽高、
em字体等都会基于缩放后的新基准计算 - 整个页面可能触发 layout dirty，尤其套在
body上时，性能开销明显 - 文字缩放受最小字号限制（Chrome 强制 ≥12px），即使
zoom: 0.5也不会让font-size: 10px变成 5px
transform: scale() 不影响 layout，只改绘制位置
transform: scale() 在合成层（compositor layer）执行，属于 post-layout 操作。浏览器先按原始尺寸完成 layout，再用矩阵把像素块拉伸/压缩并偏移。所以：
- 元素的 margin box、content box 尺寸完全不变，兄弟元素布局不受干扰
-
transform-origin控制缩放中心，默认是50% 50%（居中），不是左上角 - 文字、图片、边框全部按数学比例缩放，无最小字号限制（
font-size: 10px+scale(0.5)就是视觉上 5px） - 事件坐标仍基于原始 layout box —— 点击区域和视觉位置错位，必须手动换算或避免用于可交互区域
两者对 width/height 和 font-size 的影响逻辑完全不同
假设一个 div 原始样式为 width: 200px; height: 100px; font-size: 16px;：
立即学习“前端免费学习笔记（深入）”；
- 加
zoom: 0.75后，layout 阶段它变成width: 150px; height: 75px; font-size: 12px（若未低于 12px） - 加
transform: scale(0.75)后，layout 阶段仍是200px × 100px，只是最终绘制时被压成 150×75 的像素块，文字也按比例变小 - 如果同时设
width: 200px和transform: scale(0.75)，视觉宽度 ≈150px，但点击热区仍是 200px 宽（从左边缘起算）
实际选型时最易忽略的坑
真正麻烦的从来不是“能不能缩”，而是缩完之后谁还信得过这个尺寸：
- 不要在需要精确响应式布局的容器上混用
zoom和transform，它们的坐标系不兼容，transform-origin和zoom左上角锚点无法对齐 -
zoom在 Firefox 中完全无效，且无法通过@supports检测（它不进 CSSOM） - 用
transform: scale()做全局缩放时，position: fixed元素会脱离 viewport 锚定逻辑，需额外加transform: scale(1.33)反向补偿（如缩放 0.75 倍，fixed 元素要scale(1/0.75)） - 任何依赖
getBoundingClientRect()或offsetWidth的 JS 逻辑，在transform: scale()下拿到的仍是原始值，不是视觉值
