双指缩放时fixed头部“变大变形”是因DPR变化导致渲染层拉伸而定位锚点未更新；需配全viewport、禁用transform父级、改用vh/vw/inset单位或sticky替代。
双指缩放时 fixed 头部“变大变形”，根本不是 CSS 问题，而是浏览器把整个渲染层按比例放大了——position: fixed 元素被强制重绘在更高 DPR 的画布上，但它的 top/left 值仍按原始视口像素解析，视觉上就出现错位、拉伸、边缘模糊甚至文字锯齿。
fixed 元素在缩放中实际发生了什么
缩放不是“改样式”，是浏览器底层重设渲染管线：CSS 像素映射到设备像素的比例（DPR）变了，比如从 2x 变成 2.5x。此时：fixed 元素的尺寸、边框、字体大小都会被 GPU 拉伸；但它的定位锚点（如 top: 0）仍锁定在初始视口坐标系里，导致它“卡”在旧位置，而页面内容已按新比例重排——看起来就像头部被放大后偏移、变形、边缘发虚。
为什么用 rem 或 em 也救不了
rem 和 em 只影响字体、内边距、外边距等流内属性，不参与 fixed 的视口锚定计算。哪怕你写 font-size: 1.5rem; top: 1.5rem，后者也会在计算时立刻转成 px（比如 top: 24px），缩放后照样跳。真正起作用的只有能随视口实时重算的单位：vh、vw、inset、transform。
移动端双指缩放下 fixed 头部的实操修复路径
别指望纯 CSS 一劳永逸。必须分层应对：
立即学习“前端免费学习笔记（深入）”；
- 先堵住缩放源头：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">—— 缺任意一项，iOS Safari 都可能悄悄缩放 - 禁用祖先干扰：检查
header所有父级是否含transform、overflow: hidden、filter，任一存在都会让fixed降级为 relative 定位 - 改用现代定位语法：
inset: 0 0 auto 0替代top: 0; right: 0; bottom: auto; left: 0，避免传统属性混用冲突 - 单位必须纯净：
left: 5vw✅，left: calc(5vw + 8px)❌ —— 混入 px 就会有一部分值“冻住”不缩放 - 真要支持缩放交互？放弃
fixed，监听visualViewport动态调整：el.style.top = visualViewport.offsetTop + 'px'（仅 Chrome / Edge 支持稳定）
最常被忽略的一点：双指缩放后，fixed 元素的 border 和 box-shadow 会因亚像素渲染失真，看起来“变形”。这不是 bug，是缩放本身带来的绘制副作用——此时唯一干净解法，是彻底不用 fixed，改用 position: sticky 或 JS 控制的 absolute + relative 根容器。
