大屏系统只能有一个main且不能包导航栏，因为main是辅助技术的语义锚点而非视觉容器，屏幕阅读器按M键跳转时依赖其唯一性；若将状态栏、菜单等导航内容塞入main，会导致跳转失效或行为不可预测，必须由根布局统一控制，仅包裹实时数据卡、图表等核心内容。
为什么大屏系统里只能有一个且不能包导航栏
大屏系统常把整个屏幕当“一张画布”，误以为
常见错误现象：Next.js 布局组件中重复渲染main；子页面自己又套一层main，导致 DOM 中出现多个；微前端子应用在 iframe 里擅自加main，脱离主文档上下文。
- 正确做法：全 DOM 树中确保唯一
main，且只包裹真正要操作/阅读的核心内容（如实时数据卡片区、折线图容器、告警列表） - 顶部状态栏、左侧设备树、右下角时间戳、底部滚动字幕——这些都不属于
main，该用header、aside、footer分而治之 - 若使用 React/Vue 渲染，建议在根布局组件统一控制
main出口，子模块禁止自行插入
什么时候该用，什么时候该用
大屏里一堆“实时温度”“设备在线率”“故障分布热力图”，容易一股脑全用section。但section不是div的语义升级版，它是为「有标题的独立逻辑分段」准备的；而article要求内容自包含、可独立分发。
判断依据很实际：
立即学习“前端免费学习笔记（深入）”；
- 这块内容是否自带
<h2>–<h6>？没有标题就别套section - 它能否脱离当前大屏页面被 RSS 抓取或单独推送？能→用
article；不能→才考虑section - 它是否已有专用标签？比如设备列表用
table、告警日志用dl，就别再包一层section
错误写法：<section><p>当前在线设备：127台</p></section>——没标题、不可分发、无结构意义，纯属冗余嵌套。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
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，再逐个判断哪些其实已不是红色。
标题层级断裂比不用语义标签更伤可访问性
很多团队花力气换掉了div，却在标题上翻车：大屏首页从<h2>开始、main外堆了三个<h1>、设备详情页小节用了<h3>但主内容还没出现<h2>。这会让屏幕阅读器生成的文档大纲完全错乱，用户无法靠标题导航到关键区块。
大屏系统特别要注意：
-
main内必须有明确的标题层级起点，通常用<h1>（整屏主题）或<h2>（若页面级<h1>已在header中） - 每个
section或article应自带<h2>–<h6>，且层级连续，不跳级、不回退 - 图表标题、告警标题、状态卡片标题，都该是真实
h标签，而非仅靠 CSS 加粗模拟
复杂点在于：大屏常含动态加载区块，标题需随数据注入同步更新；容易被忽略的是，服务端渲染或 SSR 场景下，首屏标题结构必须一次性输出完整，不能靠 JS 后补。
