position: fixed 元素脱离文档流，导致后续内容顶替其位置而被遮挡；需同步设置 top: 0、width: 100%、body/main 的 padding-top 及 z-index，并避免父容器 overflow/transform 干扰层叠上下文。
直接加 position: fixed 不行，内容会被盖住、移动端软键盘弹出后导航错位、z-index 失效——这些不是配置遗漏，而是 fixed 脱离文档流引发的连锁反应，必须同步处理。
为什么 position: fixed 加了却看不见或遮挡内容
fixed 元素完全脱离文档流，浏览器不会为它“留位置”，后续元素会顶上来，直接被导航栏盖住。这不是样式没生效，是布局逻辑被打破了。
- 检查是否漏设
top: 0和width: 100%—— 少一个就会偏移或缩窄 -
body或主容器没加padding-top（值必须等于导航栏实际高度），首屏文字大概率被截断 - 父容器用了
transform、overflow: hidden或will-change，会导致z-index分层失效，导航栏被压在底层 - 导航栏本身没设
background-color，滚动时底下内容透出来，误以为“没固定”
position: sticky 在模板里为什么静默失效
sticky 不是“兼容性问题”，而是对 DOM 结构和父级样式极其敏感。它只在滚动触发临界点时才激活，一旦条件不满足，就退化成普通 relative 定位，毫无提示。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 父容器不能有
overflow: hidden、overflow: auto或transform—— 这些会创建新层叠上下文，直接禁用 sticky - 导航栏必须有明确的
top值（如top: 0），且其兄弟元素总高度要大于视口，否则滚不到触发点 - 部分旧版 Safari 需要加
position: -webkit-sticky前缀，仅写position: sticky会不生效 - 如果导航栏高度不固定（比如响应式菜单展开后变高），sticky 无法自动适配，此时必须切回 fixed + JS 动态计算
HTML 模板中预留顶部空间的正确写法
别在 <nav></nav> 上硬设 height 再去匹配 margin-top，行高、内边距、字体渲染差异都会让高度对不上。最稳的方式是让主体区域自己撑开空间。
- 给
<main></main>或<div class="content"> 加 <code>padding-top: 60px（假设导航高 60px），比改body更可控 - 如果导航高度响应式变化（比如移动端折叠），用 CSS 自定义属性动态传递：
:root { --header-height: 60px; }，然后main { padding-top: var(--header-height); } - 锚点跳转时仍可能遮挡标题，补一句
h1, h2 { scroll-margin-top: 60px; }，浏览器原生支持，不用 JS - 避免在导航上用
bottom: 0或依赖视口高度的计算，只用top: 0和width: 100% - 禁用缩放：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">可缓解，但影响可访问性 - 更稳妥的是监听
resize事件，检测window.innerHeight突变，临时切回position: absolute并用top手动锚定 - 如果项目允许，改用
position: sticky—— 它不受软键盘引起的视口缩放影响，只要父容器合规就始终可靠
移动端软键盘弹出导致 fixed 导航错位怎么办
Android Chrome 和部分 iOS WebView 中，软键盘唤起会重算视口高度，fixed 元素可能被顶到页面中间甚至消失。这不是 bug，是视口缩放行为导致的定位基准偏移。
fixed 和 sticky 看似只差一个字母，但 fixed 是“强制钉死”，sticky 是“滚动到点才吸附”。模板里选哪个，取决于你愿不愿意为父容器清掉 overflow 和 transform —— 这往往是比写 CSS 更耗时的活。
