卡片里的标题写了 position: sticky; top: 0，页面往下滚时它却和卡片一起消失。把 top 改成更大的数没有用，换 z-index 也没动静。更常见的原因是标题盯错了滚动容器，层叠顺序与这类偏移无关。
原样布局先给出一个反常结果
验证页在页面顶部放了 500 像素空白，卡片本身设为 overflow: hidden，标题是 sticky，卡片内容高于容器。脚本先把页面滚到卡片上缘，再往下滚 120 像素，最后比较标题和卡片的视口坐标。Chrome 本机输出如下，浏览器窗口是隔离的临时配置，页面没有访问网络：
scrollY: 620
sticky top after page scroll: -119px
card top after page scroll: -120px
sticky moved with card: true
assertion: PASS
标题和卡片上缘几乎同步移动，top: 0 并没有把标题钉在视口上。测试脚本是 tools/verify-frontend-sticky-overflow.mjs，页面内容在同目录下的 verify-frontend-sticky-overflow.html。日志里的坐标只说明这个布局中的行为，不代表所有 sticky 元素都会以同样方式失败。
我第一次看这种布局也会先怀疑层叠顺序。读坐标反而更快：如果标题与卡片一起离开视口，优先查它的祖先是否建立了另一个滚动容器；只有标题被别的元素盖住时，才值得先调 z-index。
overflow 祖先改变了参照边界
position: sticky 需要一个滚动祖先作为约束。overflow: auto 或 scroll 的祖先通常很直观，因为它确实能滚动；overflow: hidden 也会建立滚动容器，只是用户没有滚动条可拖。页面滚动时，卡片内部并没有滚动，标题因此没有机会在这个容器里保持顶部位置，最终看起来像普通内容一样跟着页面离开。
这个差别藏在组件边界里时尤其难找。标题所在组件可能只设置了 sticky，外层弹窗、横向裁切容器或布局包装器却已经带着 overflow。沿 DOM 向上检查计算样式，比在标题上反复改 top、z-index 更直接。若祖先原本就是可滚动区域，sticky 应相对它工作；若祖先只为裁切溢出而设置 hidden，就要问它是否真需要承担滚动容器的角色。
修复要保住的到底是哪种行为
若只需要裁掉绘制溢出，而不希望该祖先成为 sticky 的滚动容器，可以在支持目标浏览器的前提下测试 overflow: clip。它会裁切内容，却不建立滚动容器。最小差异是：
.card {
height: 240px;
overflow: clip;
}
这不是对所有 overflow: hidden 的机械替换。代码可能依赖程序化滚动、焦点自动滚动，或祖先内部的滚动位置；clip 不提供这些滚动行为。改之前应检查组件是否调用 scrollTop、是否要让焦点元素滚进可见区域，以及旧浏览器兼容范围。若卡片本来就应该内部滚动，应保留 overflow: auto，再让 sticky 标题属于那个真正滚动的区域。
另一个常见修法是把 sticky 标题移出裁切祖先，让它与内容各自处在正确的容器里。结构调整比一条 CSS 更重，却能把滚动边界写清楚。修复后再用同一套几何检查：让预期的滚动容器滚动，标题应贴住该容器顶部；继续滚动外层页面时，它应随整个组件一起移动。要贴住谁，测试就该滚谁。
一个坐标测试能证明什么
这个复现检查的是 Chrome 当前布局里标题与卡片的矩形位置。它没有模拟真实用户滚轮，也没有检查 Safari、Firefox 或移动端浏览器。overflow: clip 的兼容性和焦点滚动行为，需要在目标浏览器里另测，不能从这一条日志推出。
遇到 sticky 不生效，先沿祖先链找 overflow，再判断滚动到底发生在哪一层。若要裁切而不滚动，测试 clip；若祖先就是滚动面板，就让 sticky 属于它。z-index 只处理遮挡，改它不会修正滚动参照系。
