判断依据其实很实际：

• 这块内容是否自带
  到
  ？没有标题就别套
  。
• 它能否脱离当前大屏页面被RSS抓取或单独推送？能，就用
  ；不能，才考虑
  。
• 它是否已有专用标签？比如设备列表用、告警日志用
  ，就不要再包一层
  。

  一个典型的错误写法是：

  当前在线设备：127台

  ——没标题、不可分发、无结构意义，纯粹是冗余嵌套。

  class命名如何避免在大屏项目中失控

  大屏系统迭代快、多人协作频繁，.red-alert、.big-num、.box-3这类类名上线三个月后就可能失效甚至误导：红色告警变成橙色，大数字改成了小字号，box-3被挪去显示地图图例。这种问题，等发现的时候往往已经积重难返。

  几个实操建议：

  • 聚焦功能或内容角色，比如.device-status-card、.realtime-temperature-chart、.alarm-log-list。
  • 采用BEM规范，模块+元素+修饰符分层，如.dashboard__header、.chart--loading。
  • 禁止用样式描述词（red、left、big）、缩写、拼音、数字序号。

  性能影响其实不大，但可维护性会断崖式下跌——改一个颜色，就要全局搜red-alert，再逐个判断哪些其实已不是红色。这种苦头，经历过的人应该都懂。

  标题层级断裂比不用语义标签更伤可访问性

  很多团队花力气换掉了

  ，却在标题上翻了车：大屏首页从

  开始、

  外堆了三个

  、设备详情页小节用了

  但主内容还没出现

  。这会让屏幕阅读器生成的文档大纲完全错乱，用户无法靠标题导航到关键区块。

  大屏系统里特别需要注意：

  • 内必须有明确的标题层级起点，通常用
    （整屏主题）或
    （若页面级
    已在
    中）。
  • 每个
    或
    应自带
    到
    ，且层级连续，不跳级、不回退。
  • 图表标题、告警标题、状态卡片标题，都应该是真实的h标签，而非仅靠CSS加粗模拟。

  复杂点在于：大屏常含动态加载区块，标题需随数据注入同步更新；容易被忽略的是，服务端渲染或SSR场景下，首屏标题结构必须一次性输出完整，不能靠JS后补。这一点，往往在项目初期就得定好规范。