直接写 <a href="/blog">← 返回博客列表</a> 即可，用绝对路径 /blog 避免404；面包屑用 <nav aria-label="面包屑"><a href="/">首页</a> > <a href="/blog">博客</a> > 当前文章</nav> 手动写死；顶部放 <header> 内，语义清晰且兼容性好。
HTML里怎么加个“返回博客列表”的链接
直接写一个 <a href="/blog">← 返回博客列表</a> 就行，不需要 JS 或框架。关键是路径别写错——如果博客列表页是 /blog/index.html，那 href 写成 /blog 或 /blog/ 都可以（服务器通常自动补 index.html），但别写成 blog.html（少斜杠会变成相对路径，容易 404）。
常见错误现象：
点击后跳到 https://site.com/current-page/blog（多了一级路径），就是因为用了相对路径 href="blog"；或者跳到根目录下不存在的 /blogs，是手误拼错了。
- 用绝对路径开头（
/blog）最稳，不受当前页面位置影响 - 如果整个站点部署在子路径（比如
https://site.com/my-site/），那就得用相对路径或 JS 动态算，但这种情况少见，先别加复杂逻辑 - 别依赖 CSS 伪元素画箭头（如
::before { content: "←" }），万一样式失效，用户就看不到返回提示了
面包屑导航能不能只用 HTML 实现
不能真正“动态”实现，但静态面包屑可以纯 HTML 写死。比如在一篇博客页里，手动写：<nav aria-label="面包屑"><a href="/">首页</a> > <a href="/blog">博客</a> > 当前文章</nav>。浏览器不会自动推导层级，全靠人维护。
使用场景：内容结构固定、更新不频繁的文档站或企业官网。一旦栏目改名或路径调整，所有相关页面的面包屑都得挨个改。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 必须加
aria-label="面包屑"，不然屏幕阅读器不知道这是导航流 - 末尾的当前页不要包
<a>，避免用户点自己，也符合语义（<nav>里混非链接文本没问题） - 别用
<ol>或<ul>——你被要求禁用这些标签，所以老实用<nav>包纯文本和链接就行
顶部链接放哪儿最合适、语义最清楚
放在 <header> 里，紧贴主标题上方或下方。不是必须用 <header>，但用它比用 <div> 更准确，搜索引擎和辅助工具能识别这是页面头部导航区。
性能 / 兼容性影响：零影响。纯 HTML 不触发重排重绘，所有浏览器都支持。
- 如果顶部要放多个链接（比如“关于”“归档”“RSS”），用空格或竖线分隔，别套列表——你不能用
<ul>，就写成：<header><a href="/about">关于</a> | <a href="/archive">归档</a></header> - 别把返回链接塞进页脚或侧边栏，用户预期它在顶部附近
- 移动端小屏时，这些链接可能换行或被截断，但那是 CSS 该管的事，HTML 层面保持结构清晰就行
为什么不用 JavaScript 自动生成返回链接
因为没必要。JS 获取 document.referrer 不可靠：用户从书签、外链、HTTP 跳转进来时，referrer 可能为空或被屏蔽；刷新页面后也丢失。硬要用，反而增加白屏时间、出错概率和维护成本。
真实痛点：有人想“智能判断上一页”，结果发现 Chrome 隐私模式下 referrer 直接清空，链接变成死的。
- 静态写死的
/blog永远指向明确位置，可控性强 - 如果真要“上一页”，应该由来源页负责传参（比如带
?from=/blog），而不是让目标页猜 - 服务端渲染或静态站点生成器（如 Hugo、Jekyll）倒是可以注入，但那是构建时的事，和纯 HTML 无关
最容易被忽略的是路径基准问题：本地双击打开 HTML 文件时，/blog 会指向磁盘根目录，打不开。这种场景只能用相对路径（如 ../blog/），但上线后又得改回来——所以开发时最好用本地服务器预览，别双击。
