侧边悬浮功能条必须用 position: fixed，不能用 absolute；因为 absolute 相对于最近已定位祖先而非视口，滚动时会随内容偏移，而 fixed 始终绑定视口坐标系，确保滚动、缩放下位置稳定。
侧边悬浮功能条必须用 position: fixed，其他定位方式（比如 absolute）在滚动时会失效——它只认最近的已定位父容器，不是视口。
为什么不能用 position: absolute 做侧边悬浮
很多人写完 <aside class="sidebar-tool"> 就以为完事了，结果一滚动，功能条跟着内容一起跑。这是因为 absolute 脱离文档流后，是相对于「最近的 position 不为 static 的祖先」定位的，不是视口。如果父容器没设 position: relative，它可能直接锚定到 <body>，但一旦页面有滚动区域嵌套（比如带 overflow: auto 的模块），定位就会错乱。
-
fixed才真正绑定视口：滚动、缩放、软键盘弹出（iOS 除外）都不影响其坐标系 - 若强行用
absolute+body作为锚点，body高度变化或 margin/padding 异常会导致偏移漂移 - 某些 CMS 或框架会动态插入 wrapper 容器，
absolute的“最近祖先”可能意外变更
position: fixed 的基础写法与关键参数
核心就三行 CSS，但每行都容易漏掉细节：
-
position: fixed是起点，不是终点；必须配至少两个方向偏移（如top和right），否则默认贴左上角，大概率遮导航栏 - 推荐用
top: 50%+transform: translateY(-50%)居中对齐，比硬写top: calc(50vh - 100px)更可靠（不用算高度） - 必须设
z-index，且值要明显高于页面其他层（比如z-index: 1050），避免被模态框、广告位或第三方 SDK 覆盖 - 宽度建议用
width或max-width显式约束，fixed元素的width: auto在窄屏下可能撑满视口导致横向滚动
移动端和 iOS Safari 的典型坑
iOS Safari 对 fixed 的支持一直有历史包袱，尤其在以下场景会“粘住不动”或闪退：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 父容器设置了
overflow: hidden或-webkit-overflow-scrolling: touch，会导致子级fixed元素脱离视口锚定 - 页面有输入框（
<input>）且获得焦点时，iOS 可能临时降级为absolute行为，悬浮条跳到错误位置 - 不加
will-change: transform或transform: translateZ(0)时，滚动过程中可能出现卡顿或重绘撕裂 - 慎用
user-scalable=no的<meta viewport>来“修复”闪动——它会破坏可访问性，且不符合 WCAG 1.4.4
主内容如何避让侧边悬浮条
fixed 元素不占文档流，所以主内容会“上移”去填它原来的位置，造成首屏内容被遮挡。这不是 JS 能动态修好的问题，得靠 CSS 预留空间：
- 最稳方案：给主内容容器（比如
<main>）加padding-right，值等于悬浮条宽度（如padding-right: 200px） - 避免在
body上加margin-right：某些浏览器会把该 margin 当作视口边界，影响fixed元素的 right 计算 - 如果悬浮条宽度响应式变化（比如小屏收窄），用 CSS 变量 +
@media同步更新 padding，别依赖 JS 检测宽度再 setStyle - 绝对不要用
margin-top或padding-top来避让——那是给顶部固定导航用的，跟右侧无关
真正难的不是写出来，而是让 fixed 在各种滚动上下文、输入状态、缩放层级下都保持坐标稳定。很多 bug 不是样式写错了，而是没意识到 fixed 的锚点其实会被祖先的 transform、perspective 或 filter 暗中劫持。
