HTML中不存在独立的“格式化标签”，所谓格式化实为语义化结构与CSS呈现的结合；滥用<br>、<div>及错误缩进会损害可访问性、SEO与可维护性。
HTML里没有“格式化标签”这种独立分类，所谓“格式化”实际是语义化结构 + CSS控制呈现的组合结果。直接用 <b>、<i> 或 <hr> 做布局，短期看似快，长期必然导致结构混乱、响应式失效、可访问性崩坏。
别把 <br> 当换行工具用
很多人用多个 <br> 强制制造空行或对齐，这是最典型的误用。它不表达任何语义，纯属视觉 hack，且在不同屏幕尺寸下完全不可控。
- 浏览器会忽略连续
<br>的间距差异，移动端可能塌成一团 - 屏幕阅读器会逐个读出“换行”，干扰内容流
- 后续想改成 margin/padding 时，得先全局搜索替换所有
<br>
正确做法：用 <p> 包裹段落，用 CSS 的 margin-bottom 控制段间距；需要小空隙时，加一个带 class 的 <div> 并设 height: 1rem 或 margin: 1em 0。
<div> 和 <section> 别混着用
用一堆 <div> 套娃实现“布局”，代码看起来整齐，但机器和人都不知道哪块是导航、哪块是正文、哪块是侧边栏。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<div>是无语义的通用容器，只在确实没有更合适语义标签时才用 -
<header>、<nav>、<main>、<article>、<aside>、<footer>才是真正的“布局标签”——它们自带语义和默认 display 行为 - 搜索引擎和辅助技术依赖这些标签理解页面结构，乱用等于主动放弃 SEO 和无障碍支持
例如，导航区域写成 <div class="nav"> 不如直接用 <nav>，既少写 class，又多一层语义保障。
缩进不是为了好看，是为了快速定位嵌套层级
VS Code 保存时自动格式化（editor.formatOnSave）能解决大部分缩进问题，但关键在于你选的 formatter 是否理解 HTML 语义。
- Prettier 默认对 HTML 的缩进规则较保守，遇到
<table>或内联 SVG 容易错位，建议在.prettierrc中加"htmlWhitespaceSensitivity": "ignore" - 不要手动用 Tab 混合空格缩进，统一设为 2 或 4 空格，并在项目根目录放
.editorconfig锁定规则 - 深层嵌套（超过 4 层）大概率说明结构有问题，优先考虑拆分成组件或用 CSS Grid/Flexbox 降级 DOM 深度
真正影响维护效率的，从来不是某一行缩进多了一格，而是 <div> 里套了 7 层 <div> 后，你根本不确定删掉第 5 个会不会让整个侧边栏消失。
语义标签本身不决定样式，但它是所有后续工作的前提：CSS 选择器靠它精准命中，JavaScript 靠它安全操作节点，自动化测试靠它稳定定位元素。格式化的终点不是“看着顺眼”，是“改起来不心虚”。
