html { scroll-padding-top } 是响应式首选方案，需写在 html 上并用 DevTools 实测导航栏总高度（含 padding、border），配合 CSS 变量和媒体查询适配不同断点。
固定导航栏遮挡内容，本质是脱离文档流后没给后续元素腾空间；响应式场景下更麻烦——因为 navbar 高度会随断点变化，写死 margin-top 或 padding-top 必然在某设备上失效。
为什么 body { margin-top: 60px } 在响应式里不靠谱
这个做法看似简单，但实际踩坑率极高：移动端 navbar 经常折叠、字体缩放、icon 大小调整，导致真实高度和你写的 60px 对不上；更糟的是，body 上设 margin-top 会破坏滚动锚点行为（比如点击 #faq 跳转后，标题被 navbar 盖住），且在 Safari 中可能触发意外的重排。
- 不要用
body做全局偏移，它不是可靠的布局容器 - 避免在
html或body上加transform、overflow: hidden，这些会直接禁用scroll-padding-top - 如果用了
position: sticky替代fixed，scroll-padding-top会失效——因为 sticky 不是根滚动上下文
html { scroll-padding-top } 是响应式首选方案
这是目前最干净、覆盖所有跳转路径（URL hash、JS element.scrollIntoView()、浏览器前进/后退）的解法，但必须写在 html 上才稳定生效。
- 查准数值：打开 DevTools → 选中导航栏 → 看 Computed 面板里的
height+padding-top+border-top-width，别只看 CSS 里写的height - 抽成 CSS 变量便于维护：
:root { --nav-height: 64px; }，然后写html { scroll-padding-top: var(--nav-height); } - 配合媒体查询适配移动端：
@media (max-width: 768px) { html { scroll-padding-top: 48px; } }
首个内容块用 pt-* / padding-top 更可控
当你的导航栏高度变化逻辑复杂（比如有 JS 动态增减 class、加载时高度未定），或者页面结构不允许依赖全局 scroll-padding-top（如嵌入 iframe 子页），就该在第一个内容容器上手动预留空间。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 优先作用于紧接
<nav>后的块级元素，比如<header class="pt-6">或<main style="padding-top: 72px;"> - 避免同时用
mt-*和pt-*，容易叠加错乱；也不要给<body>加padding-top，它会影响整个页面的滚动基准 - 若用 Bootstrap，
pt-6≈ 4rem = 64px 是安全起点，但务必用getComputedStyle(document.querySelector('.navbar')).height实测确认
滚动条被遮住？说明你还在用 position: fixed
这不是样式问题，是布局模型冲突。当 <main> 设了 overflow-y: scroll，而 <nav> 是 fixed，滚动条天然属于 <main> 的右边界，但被 fixed 元素盖住了。
- 真正解法是放弃
position: fixed，改用flex flex-col h-screen布局：<body class="flex flex-col h-screen">，让<nav>占首行，<main class="flex-1 overflow-y-scroll">自动填满剩余空间 - 这样滚动条属于
<main>内部，不会被任何元素遮挡，也无需额外 z-index 治理 - 缺点是导航栏不再“悬浮”于所有内容之上（比如弹窗会盖过它），此时需单独提升弹窗的
z-index，而非动 navbar
最易被忽略的一点：所有方案都依赖你准确测量导航栏的**视觉总高度**，而不是它 CSS 中声明的 height；哪怕只差 2px，锚点跳转时标题文字就会卡在 navbar 底边线下方一像素——这种错位在高分屏上尤其明显。
