语义化标签是浏览器、屏幕阅读器和搜索引擎理解页面结构的唯一可靠依据；用错或不用会导致可访问性降级、seo权重稀释、维护成本上升。

语义化标签不是“锦上添花”，而是浏览器、屏幕阅读器和搜索引擎理解你页面结构的唯一可靠依据；用错或不用，直接导致可访问性降级、SEO权重稀释、维护成本上升。

为什么 <div> 套 <code><div> 会让屏幕阅读器“失明” <p>当整个页面只用 <code><div> 和 <code><span></span> 构建时，辅助技术（如 VoiceOver、NVDA）无法识别“这是导航栏”“那是文章主体”“此处是页脚”。它们只能读出“div，div，div……”，用户被迫靠猜。

• 真实场景：视障用户想跳转到主要内容，但页面没用 <main></main>，只能逐个 <div> 听过去 <li>后果不止于体验：Google 明确表示会参考语义结构判断内容重要性，<code><article></article> 内的标题比同级 <div> 内的 <code><h2></h2> 权重更高
• 修复很简单：把包裹导航的 <div class="nav"> 换成 <code><nav></nav>，把主内容区换成 <main></main>

  <section></section> 和 <article></article> 到底怎么分？看内容是否“可独立分发”

  两者都表示主题性区块，但关键区别在“独立性”——<article></article> 的内容必须能脱离当前页面被单独引用、重用或聚合（比如 RSS 订阅）；<section></section> 只是逻辑分组，不强调独立存在。

  • 用 <article></article>：博客正文、新闻条目、用户评论、产品卡片（每个都带完整标题、作者、时间）
  • 用 <section></section>：首页的“关于我们”“服务列表”“客户评价”模块（依赖上下文才有意义）
  • 常见错误：<section></section> 里嵌套多个 <article></article> 是合理模式；但反过来，把整篇博客包进 <section></section> 就丢失了语义

  <aside></aside> 不等于“右边栏”，它代表与当前内容“相关但非核心”

  很多开发者以为 <aside></aside> 只能放在右侧浮动区域，其实它的语义完全取决于上下文位置和内容关系。

  

  Claude风格HTML汇报文件

  生成Claude风格的精美单页HTML汇报文件。当用户需要生成"汇报"、"周报"、"月报"、"项目进度"、"复盘"、"演示"、"slide deck"、"状态报告"、"工作总结"时触发。支持6种模板：周报(weekly)、项目进度(project)、月度总结(monthly)、复盘报告(postmortem)、演示文稿(slid

  下载
  • 在 <article></article> 内部的 <aside></aside>：可能是术语解释、补充数据图表、作者简介（与该文章强相关但非主线）
  • 在 级别的 <aside></aside>：才是传统侧边栏，比如全站最新文章、广告位（与整页相关，但非主要内容）
  • 避坑点：<aside></aside> 不能替代 <footer></footer> 或 <nav></nav>；如果里面放的是站点导航，就该用 <nav></nav>

  <time></time> 标签不只是好看，它让机器真正“读懂”时间

  单纯写“2024年3月15日”对人友好，但对爬虫或日历应用毫无意义；加上 <time datetime="2024-03-15">2024年3月15日</time>，机器就能解析、排序、提醒、转换时区。

  • 必须加 datetime 属性才有效，且格式要严格（YYYY-MM-DD 或 YYYY-MM-DDThh:mm）
  • 常见误用：<time>昨天</time> —— “昨天”无法被解析，应换算为具体日期再写
  • 性能影响几乎为零，但可访问性和结构化数据收益明确；搜索引擎结果页常展示 <time></time> 中的日期

  最易被忽略的是嵌套层级：语义标签不是贴标签，而是建结构。比如 <header></header> 必须作为其父容器的“头部”，不能脱离上下文孤立使用；<nav></nav> 应该包裹一组导航链接，而不是单个 <a></a>。结构错一层，语义就断一截。