<br>本身不卡浏览器，但语义误用和排版滥用会拖慢开发、降低可维护性；它不创建DOM节点、不触发重排重绘，真正问题在于替代了结构或CSS职责。
<br> 标签本身几乎不消耗任何渲染性能，但它引发的排版问题和语义误用，才是实际项目中更常拖慢开发节奏、影响可维护性的根源。
为什么<br>不会卡浏览器，但会让开发者卡住
现代浏览器对 <br> 的处理是极轻量的：它不创建 DOM 节点（只是行内换行指令），不触发重排（reflow）或重绘（repaint）的额外开销。真正出问题的，往往不是它本身，而是你用它替代了本该由结构或 CSS 承担的责任。
- 连续写 5 个
<br>实现“空两行”——这其实是用表现逻辑掩盖语义缺失，后续改样式时必须全局搜<br>，不敢动 - 在
<div>里堆<br>模拟列表项间距——结果发现响应式下错位，又得加 media query 去“修”这个本不该存在的换行 - 把地址写成
<p>北京市<br>朝阳区<br>建国路8号</p>——看似省事，但屏幕阅读器会把整段读成一句，无障碍支持直接降级
<br> 和 <p> 在布局计算中的真实差异
两者触发的盒模型行为完全不同：<p> 是块级元素，默认带 margin-top 和 margin-bottom；<br> 不生成新块，也不自带 margin，它只让当前行结束、下一行从左边界开始。
- 如果你删掉某处的
<br>，视觉上可能只少了一行空隙，但 DOM 结构没变；删掉一个<p>，很可能整块内容塌缩或错位，因为它的 margin 可能被相邻元素合并（margin collapse） - CSS 中设置
p { margin: 0; }后，<p>的视觉效果可以接近<br>，但语义和可访问性仍保留 - 想让两个短文本垂直居中对齐？别用
<br>硬撑高度——用display: flex或line-height更可控
哪些场景下<br>确实不可替代
它不是坏标签，只是适用面窄。只有当内容天然属于同一语义单元、且换行位置固定不可变时，<br> 才是合理选择。
立即学习“前端免费学习笔记（深入）”；
- 诗歌、歌词：每行是意义整体，不能被断开或重组，
<pre>或<br>都比拆成多个<p>更准确 - 地址字段（纯展示，无结构化需求）：如
<address>上海市<br>徐汇区<br>漕溪北路18号</address>，注意这里用了语义化的<address>包裹，<br>只负责内部换行 - 表单内联标签+输入框之间：比如
<label>邮箱</label><br><input type="email">（虽然更好的做法是用display: block控制<label>）
CSS 替代方案比你想象中更简单
90% 的 <br> 使用场景，其实用一行 CSS 就能解耦结构与样式。关键不是“能不能”，而是“要不要把换行逻辑写死在 HTML 里”。
- 想让一段文字自动折行？不用
<br>，用white-space: normal（默认） + 容器定宽 - 需要“此处必须断行，且前后有间距”？给上一个元素加
margin-bottom: 1em，比塞<br>+<br>清晰得多 - 多行文本垂直居中？
display: flex; align-items: center;比反复调<br>数量靠谱 - 担心旧浏览器？
<br>兼容性确实好，但flex/grid在 2026 年已覆盖全部主流环境，没必要为兼容 IE 停留在 2005 年的写法
最常被忽略的一点：当你在代码里敲下第 3 个 <br> 时，问题通常已经不在换行本身，而在你还没想清楚这段内容到底该是什么结构——是段落？列表项？地址块？还是单纯一行说明文字？先定语义，再选标签，最后调样式，顺序错了，后面全是补丁。
