必须掌握的7个基础标签是、、、–、、、；典型误用包括漏写骨架标签致解析异常、缺失引发中文乱码、包裹破坏语义层级、缺href触发跳顶、缺alt影响无障碍与SEO、滥用/削弱结构语义。

必须掌握的 7 个基础标签及其典型误用

不是所有标签都值得花时间记，真正影响页面能否正常显示、SEO 是否友好、语义是否清晰的，就那几个。漏掉 或 会导致浏览器解析异常；写错 会让中文变乱码；把

套在

外面会破坏语义层级。

• ：根元素，必须有且只能有一个，lang 属性建议显式声明（如 lang="zh-CN"），否则屏幕阅读器可能读错语言
• ：不显示内容，但缺了 或 ，页面标题为空、中文乱码、搜索引擎无法识别主题
• ：所有可见内容的容器，不能嵌套在 里，也不能漏写——有些老教程省略它，现代浏览器虽能容错，但校验工具会报错

• 到
  ：标题层级必须线性递进，
  全页只能一个，不能因为“想加粗”就滥用

• ：段落单位，不是换行工具；
才是换行，但仅限诗歌、地址等需保留人工折行的场景
• ：链接必须带 href，空值（href="#"）或缺失会触发默认跳顶行为，交互逻辑易失控
• ：src 缺失时显示断图，alt 缺失则无障碍访问失败，且 SEO 权重下降

和 的边界在哪？

这两个标签本身没语义，纯靠 class 或 id 驱动样式和 JS 操作，但滥用会导致结构松散、维护困难。关键不是“能不能用”，而是“该不该用”。

• 是块级容器，适合划分区域（如

  ），但别用来替代语义标签：导航用

  ，侧边栏用

  ，不要全塞
• 是行内容器，只应在已有块级结构内做局部样式包裹，比如

  这是一句重点话

  

  DeepBI DHTML 页面生成器

  生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

  下载
  ；直接写 标题 是反模式
• HTML5 已提供更明确的语义标签（
  、
  、
  、
  等），优先选它们，
  只作为兜底

  表单标签最容易踩的三个坑

  表单是用户输入入口，错误配置直接影响数据收集成功率和可访问性。很多问题现场看不出，提交时才暴露。

  • 必须有 action（后端接收地址）和 method（get 或 post），漏掉 method 默认为 get，敏感信息会暴露在 URL 中
  • 的 type 决定行为：用 type="text" 做密码框，手机键盘不会弹出数字/密码模式；用 type="submit" 而非 type="button"，才能触发表单默认提交逻辑
  • 每个 应配 id，对应 ，否则屏幕阅读器无法关联提示文本，WCAG 合规性不达标

  为什么 不该用来做布局？

  虽然历史上有人用表格排版，但现在它唯一合理用途就是展示二维结构化数据（如成绩单、价格对比表）。用它做页面整体布局会带来真实代价。

  • 语义错位：

  告诉浏览器“这是数据表格”，而导航栏、轮播图不是数据，辅助技术会错误朗读

  响应式灾难：表格宽度由内容撑开，移动端无法自然流式收缩，display: table 伪表格布局也难控制断点

  维护成本高：增删一列要同步改

  和 描述用途，用 / 区分结构，否则表格复杂后可访问性几乎归零。

  ，CSS Grid 或 Flexbox 修改一行样式就能调整整块区域

  真正需要表格时，记得用