position: sticky 在 uni-app 中跨端兼容性差——小程序不支持，H5 需严格满足父容器无 transform/filter/overflow:hidden、自身非 stretch flex 项、显式 top: 0，App 端内核差异导致失效；推荐 scroll-view + bindscroll 手动控制 fixed 定位。
直接写 position: sticky 在 uni-app 里基本无效——不是你代码错了，是微信/支付宝小程序压根没实现，h5 端又极易因父容器样式失效。
为什么 position: sticky 在真机上“掉下来”
常见错误现象：sticky 在 H5 浏览器里看着正常，一换到微信小程序真机就完全不吸顶；iOS 微信里偶尔卡顿跳动；App 端（尤其 iOS）直接忽略样式。
- 微信/支付宝/百度小程序：底层 WebView 不支持
position: sticky，加-webkit-sticky也白搭 - H5 环境必须同时满足三个条件才可能生效：父容器不能有
transform、filter或overflow: hidden；元素自身不能是 flex 子项且align-self: stretch；必须显式写top: 0（top: auto或不写等于放弃） - App 端依赖 Webview 内核：iOS 用 UIWebView（已弃用）或旧版 WKWebView，Android 各厂商内核版本混乱，
sticky兼容性极差
scroll-view + bindscroll 手动控制 fixed 是唯一稳解
这是目前全平台（小程序/H5/App）兼容性最高、可控性最强的做法，核心是监听滚动位置，动态切换 class 控制定位状态。
- 必须给
scroll-view设置固定高度（如height: calc(100vh - var(--status-bar-height))），否则bindscroll不触发 -
offsetTop要在onReady或nextTick后获取，Vue 3 的onMounted中 DOM 可能还没渲染完，直接取会是0 - 吸顶后内容会上跳，必须加占位节点（比如一个空
view高度等于吸顶元素height）或用padding-top补高；但不要用padding-top给父容器补高——滚动区域高度变化会导致滚动条跳动 - 避免在
bindscroll回调里调用uni.createSelectorQuery()或getComputedStyle()——它们是同步阻塞操作，一帧内多次执行会卡顿甚至丢帧 - 用
requestAnimationFrame节流，防止高频滚动反复触发重排
使用 u-sticky 或 list-view 的 sticky-header 要注意什么
封装组件省事，但参数稍有偏差就会静默失效。
-
u-sticky的offsetTop单位是rpx，若传0且页面有状态栏，吸顶会遮挡内容；建议根据uni.getSystemInfoSync().statusBarHeight动态计算 -
customNavHeight必须显式传入，否则在自定义导航栏下吸顶位置偏移 - 在
scroll-view内部使用时，u-sticky依赖父容器可滚动，若父容器没设scroll-y或高度不足，它会静默失效 -
list-view场景下不能用普通sticky，必须用一级子组件sticky-header；配合sticky-section才能实现分段吸顶（如通讯录字母索引）
最易被忽略的点是：吸顶元素脱离文档流后，下方内容“上跳”不是 bug，而是必然结果；不加占位或不补高，视觉错位会立刻暴露。跨端开发中，别赌平台实现了什么，只信自己亲手控制的逻辑。
