position: fixed 图标错位因父元素触发新包含块；应将浮窗dom靠近body、避免transform/filter；ios需确保body overflow: visible；图标用inline-flex+gap+rem+touch-action: manipulation；遮罩层需touch-action: none+body.no-scroll+preventdefault；微信分享须config成功后绑定事件，避开iframe/shadow dom。
为什么 position: fixed 的图标组在滚动时错位或消失？
常见错误是把浮窗容器套在某个有 transform、perspective 或 filter 的父元素里——这些属性会触发新的层叠上下文和包含块，导致 fixed 实际相对于该父容器定位，而非视口。
- 检查浮窗最近的祖先是否用了
transform: translateZ(0)、filter: blur(1px)等隐式创建包含块的样式 - 浮窗 DOM 应尽量靠近
根部，避免嵌套在section、app或带动画的 wrapper 里 - iOS Safari 下，如果页面有
overflow: hidden在html或body上，fixed元素可能被裁剪，需确保body { overflow: visible }
.share-float {
position: fixed;
right: 24px;
bottom: 120px; /* 留出底部操作栏空间 */
z-index: 1000;
}如何让微信/微博/QQ 分享图标在不同设备上对齐且不重叠？
图标尺寸、间距、点击热区在移动端极易出问题：小屏下图标挤在一起，或者 font-size 缩放后图标失真；iOS 上 touch-action: manipulation 缺失会导致点击延迟。
- 所有图标统一用
inline-flex容器 +gap控制间距，避免依赖margin带来的累积误差 - 图标使用
rem或em单位（如font-size: 1.25rem），配合html { font-size: 16px }基准，禁用viewport中的user-scalable=no（否则缩放失效） - 为每个图标链接添加
touch-action: manipulation，减少 iOS 300ms 点击延迟 - 微信分享需调用 JS-SDK，但图标本身只是触发按钮，不要在
click里直接写 SDK 初始化逻辑——应提前完成config，只留share调用
点击分享图标后，弹窗遮罩层为什么挡不住底层滚动？
典型表现是弹出浮层后，用户还能滚动背景内容，甚至触发页面下拉刷新。根源在于遮罩层未阻止 touchmove，且 body 的 overflow 未及时锁定。
- 遮罩层必须设
touch-action: none，并在show时给body加class="no-scroll"，对应 CSS：.no-scroll { overflow: hidden; height: 100vh; width: 100vw; } - 不要只靠
overflow: hidden，iOS Safari 对body的滚动锁定支持不稳定，建议同时在遮罩层上监听touchmove并preventDefault() - 弹窗关闭后，记得移除
.no-scroll并恢复scrollTop（尤其当用户曾滚动过页面）
微信分享图标在 iOS 微信内打开时显示异常或点击无响应？
这不是 CSS 问题，而是微信内置浏览器对 iframe、shadow DOM 和某些事件监听的限制所致。很多团队误以为“样式能显示=功能正常”，结果分享调用始终失败。
立即学习“前端免费学习笔记（深入）”；
- 微信 JS-SDK 的
ready回调必须等config成功后再绑定图标click事件，不能写在 DOM ready 后立即绑定 - 图标不能放在
iframe内，也不能用Web Components封装后丢失事件冒泡路径 - 检查控制台是否报错
invalid signature或config:fail—— 这类错误不会影响图标渲染，但会让点击彻底静默 - 最小验证方式：在图标
click回调里先console.log('clicked')，再调WXJSSDK.onMenuShareTimeline，确认是逻辑未执行，还是 SDK 报错
侧边浮窗看着简单，真正卡住人的永远不是“怎么固定”，而是“固定之后谁还在动”——父容器、滚动上下文、JS 生命周期、微信环境兼容性，全得挨个对齐。
