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