面包屑与路径导航本质不同：面包屑是语义化导航组件，须用<nav aria-label="breadcrumb">包裹、每级为可跳转<a>、末项标aria-current="page"；路径导航是系统位置标识，应以<code>展示URL原样。
面包屑（Breadcrumb）和路径导航（Path Navigation）在语义、用途和实现上根本不是一回事，选哪个不取决于“偏好”，而取决于你页面里实际要表达的信息结构。
HTML 面包屑必须用 <nav> + aria-label="breadcrumb"
纯视觉的“首页 > 分类 > 文章”不是面包屑，只是装饰。真正的 HTML 面包屑是辅助技术可感知的导航组件，必须满足两个硬性条件：
-
<nav>包裹，且带aria-label="breadcrumb"（不能只写role="navigation"） - 每个层级必须是真实可跳转的
<a>，不能是纯文本或<span> - 最末项用
<span>或aria-current="page"标明当前页，否则屏幕阅读器会误判为可点击
错误示例：<div class="breadcrumb">首页 > 产品 > 编辑器</div> —— 这对无障碍用户等于不存在。
路径导航（如 /admin/users/123/edit）不是面包屑，也不该渲染成面包屑
URL 路径反映的是服务器路由结构，和用户认知路径常不一致。比如 /v2/api/docs?version=latest 这种带查询参数的路径，强行拆成“首页 > API > 文档 > 最新版本”会误导用户，且无法生成有效链接。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 路径导航适合开发者后台、API 文档页等强调“系统位置”的场景，应以
<code>块展示，保持原样 - 若需同时提供语义化导航，应另建面包屑，基于业务逻辑（如“用户管理 > 用户列表 > 张三详情”），而非 URL 拆分
- 自动从 URL 生成面包屑的脚本（如正则匹配
/([^/]+)）极易出错，尤其遇到中英文混合、空格编码、版本号等边界情况
Vue/React 项目里，面包屑数据必须由路由元信息（meta）驱动，而非 useRoute().path
前端框架的路由对象暴露的 path 是运行时路径，但面包屑需要的是设计态的语义层级。直接解析 path 字符串会导致：
- 动态路由参数（如
/post/:id）被当作真实目录名显示 - 相同路径不同语义的页面（如
/settings在个人页和团队页下含义不同）无法区分 - 国际化时路径不变但面包屑文字需变，硬编码路径解析无法支持
正确做法：在路由定义里显式声明 meta: { breadcrumb: '用户设置' }，组件内用 useRoute().matched 遍历所有匹配的 meta.breadcrumb 拼接。
SEO 不靠面包屑 HTML 结构，靠 application/ld+json 结构化数据
Google 确实能识别面包屑，但它真正依赖的是 JSON-LD 标记。仅靠 <nav aria-label="breadcrumb"> 对搜索排名几乎无影响。
- 必须在页面
<head>中嵌入application/ld+json，类型为BreadcrumbList - 每个
itemListElement的position必须从 1 开始连续，不能跳号或重复 -
item的@id必须是完整可访问 URL（含协议和域名），不能是相对路径
漏掉 JSON-LD，再规范的 HTML 面包屑对 SEO 也基本无效；加了 JSON-LD，哪怕 HTML 面包屑只是 <div> 包裹，也能被正确抓取。
最常被忽略的一点：面包屑的“层级”不是技术路径深度，而是用户心智模型中的归属关系。一个电商商品页，它的上一级是“分类页”还是“搜索结果页”，取决于用户怎么到达它——这决定了面包屑该动态生成，而不是静态写死在路由配置里。
