绝大多数场景应选 position: fixed，因其能真正钉在视口底部且滚动始终可见；sticky 仅适用于特定区块内悬浮，且依赖父容器高度与溢出设置。
底部悬浮条用 position: fixed 还是 position: sticky？
绝大多数场景该选 position: fixed。它不依赖父容器流式位置，能真正“钉”在视口底部（bottom: 0），滚动时始终可见；而 position: sticky 的触发依赖滚动容器边界，用在底部时行为不可靠——比如父容器高度不够、或被 overflow: hidden 截断，就会直接失效。
唯一例外是「仅在某区块内悬浮」的窄需求（如表格下方工具栏），这时才考虑 sticky + bottom: 0，但必须确保父元素有明确高度且未裁剪子元素。
-
fixed元素脱离文档流，需手动预留底部空间（如给body加padding-bottom），否则内容会被遮挡 - 移动端 Safari 对
fixed底部支持良好，但老版本 Android WebView 可能出现键盘弹出后定位偏移，需监听resize或focusin事件微调 - 避免嵌套在
transform、perspective或filter容器中，否则fixed会降级为absolute
如何让悬浮条支持主题色、按钮文字、开关状态等运行时配置？
硬编码 CSS 类或内联样式会让后续改配变得脆弱。推荐用 data- 属性承载配置，再由 JS 注入样式或控制 DOM：
<div id="footer-bar"
data-theme="dark"
data-text="立即开通会员"
data-enabled="true">
</div>
JS 中读取并应用：
立即学习“前端免费学习笔记（深入）”；
const bar = document.getElementById('footer-bar');
bar.style.backgroundColor = bar.dataset.theme === 'dark' ? '#1a1a1a' : '#fff';
bar.innerHTML = bar.dataset.text;
bar.hidden = bar.dataset.enabled !== 'true';
- 所有
dataset值都是字符串，布尔判断务必用=== 'true'，而非== true - 避免直接拼接 HTML 字符串（如
innerHTML = '<button>' + text + '</button>'），存在 XSS 风险；应使用textContent或createElement - 配置项建议统一收口到一个对象里（如
window.FOOTER_CONFIG），方便调试和 SSR 渲染时注入
点击按钮后关闭悬浮条，怎么做到不刷新页面且下次访问仍生效？
关闭动作本身很简单（bar.remove() 或 bar.hidden = true），难点在于「记住用户选择」。优先用 localStorage，比 Cookie 更轻量、无网络传输开销：
document.querySelector('#footer-bar button.close').addEventListener('click', () => {
localStorage.setItem('footerBarClosed', 'true');
bar.hidden = true;
});
// 页面加载时检查
if (localStorage.getItem('footerBarClosed') === 'true') {
bar.hidden = true;
}
- 别用
sessionStorage——关掉标签页就丢了，用户会觉得「刚点完叉又弹出来」 - 加时间戳或版本号前缀（如
footerBarClosed_v2），避免旧配置长期残留导致新功能无法生效 - 如果业务要求多端同步（如手机关了，PC 也该关），就得走后端接口，前端只负责发请求和缓存本地 fallback
为什么在 iOS 微信里悬浮条会错位或抖动？
本质是微信内置浏览器对 fixed + input 聚焦/键盘弹起的兼容问题：键盘顶起视口时，fixed 元素可能被错误重定位，或触发两次 resize 事件造成跳动。
务实解法不是硬扛，而是降级：
- 检测 UA 是否含
MicroMessenger，是则改用position: absolute+ 动态计算bottom（监听scroll和resize） - 更简单的是：iOS 微信下默认不展示悬浮条，或仅在非输入态（
document.activeElement.tagName !== 'INPUT'）时显示 - 绝对不要用
transform: translateZ(0)强制硬件加速来「修复」，这反而加剧 iOS 重绘异常
这类问题没有银弹，关键是把「微信特殊处理」当成一个独立分支逻辑写清楚，而不是塞进通用样式里徒增混乱。
