fixed元素宽度异常根本原因在于脱离文档流后浏览器按视口计算尺寸，但iOS Safari中100vw包含滚动条宽度约15px，box-sizing默认为content-box导致padding/border额外叠加，且祖先transform等属性会改变其包含块。
fixed 元素在移动端盒模型宽度异常，根本不是 width 属性写错了，而是它脱离文档流后，浏览器仍按视口计算尺寸，但不同浏览器对 100vw、box-sizing 和祖先干扰属性的处理不一致，导致视觉上“宽了”或“溢出”。
为什么 width: 100vw 在 iOS 上会右边溢出？
iOS Safari 的 100vw 等于屏幕物理宽度（含约 15px 滚动条），不是可用视口宽度。哪怕页面没滚动条，这个值也固定包含那部分“隐藏空间”，所以 width: 100vw + padding: 16px 就必然超宽。
- 别用
width: 100vw做 fixed 导航栏或横幅，尤其当有 padding/border 时 - 改用
left: 0; right: 0;，等价于width: auto，浏览器自动按视口减去左右偏移算宽，更稳 - 如果必须留边距，用
left: 16px; width: calc(100% - 32px);，百分比基于视口，且不受滚动条影响
为什么加了 padding 和 border 还是撑出屏幕？
默认 box-sizing: content-box 下，width: 100% 只管内容区，padding 和 border 是额外叠加的。比如 width: 100%; padding: 16px; border: 1px solid，总宽 ≈ 100% + 34px，必溢出。
- 所有 fixed 元素必须显式设
box-sizing: border-box - 全局重置更省心：
* { box-sizing: border-box; } - 避免在 fixed 容器上直接写
width: 100% + padding，改用inset: 0+ 内部子容器处理内边距
为什么祖先元素一加 transform，fixed 就变窄或错位？
Safari/iOS 和旧版 Firefox 遇到祖先有 transform、filter 或 perspective 时，会把那个祖先当作新的包含块（containing block），fixed 不再锚定视口，而是锚定这个父容器——它的宽度很可能小于视口，于是 width: 100% 就变成“父宽”，看起来突然变窄。
立即学习“前端免费学习笔记（深入）”；
- 用开发者工具「Computed」面板看该元素的 «Fixed position containing block»，Safari 会明确标出
- 临时删掉疑似父级的
transform: translateZ(0)或filter: opacity(0.99)，确认是否恢复 - 修复优先级：移除无意义的 transform > 把 fixed 元素提到
<body>直接子级（需 JS 动态挂载） > 改用position: sticky
真正容易被忽略的是：fixed 元素的宽度问题从来不是单个 CSS 属性能解决的，它总是同时牵扯 viewport 元标签是否配全、祖先是否意外创建新包含块、以及你是否混淆了“内容宽”和“盒子总宽”。
