anything-to-html
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
下载
html标签是触发浏览器解析引擎动作的指令，通过词法分析和语法分析构建dom树，其解析过程受规范约束且容错机制各异。
HTML标签不是“写完就能用”的静态符号，而是触发浏览器解析引擎一系列动作的指令。它不直接决定页面长什么样，而是参与构建 DOM 树这一中间结构——后续样式、脚本、渲染全依赖这个树。
HTML解析器如何把<div><p>hello</p></div>变成树？
浏览器拿到 HTML 字节流后，并不逐行读取，而是走一套确定的解析流程：
- 先做词法分析（Tokenization）：把输入切分成
startTag（<div>）、<code>text（"hello"）、endTag（ - 再语法分析（Parsing）：用栈维护当前上下文，遇到
<div> 就新建节点压栈，<code><p></p> 是子节点继续压，
再弹一次
文本节点会被合并：连续的换行、空格、制表符在解析后通常只剩一个 Text 节点，不是“原样保留”
<table> 类标签有隐式包裹逻辑：没写 <code><tbody>，DOM 里也会自动补上，这是 HTML5 规范强制要求，不是浏览器“好心帮忙”
<h3>
<code>里的标签为什么顺序重要？
-
<meta charset="UTF-8"> 必须靠前，否则前面字节可能被错误解码，导致乱码或解析中断
-
<link rel="preload"> 和 <script defer></script> 的位置决定预加载/延迟执行是否生效；放在 <title></title> 后比放在最末更早触发
-
<script></script> 没加 defer 或 async 会阻塞 HTML 解析，此时栈中未闭合的元素可能挂载异常，比如 <div>
<script>...</script><p>content</p>
</div> 中的 <p></p> 可能被误挂到
-
<base> 标签影响所有相对 URL 解析，必须在第一个 <link> 或 <script></script> 前声明，否则后续资源路径可能出错
为什么不同工具解析同一段 HTML 得到的 DOM 不一样？
浏览器原生解析器遵循 HTML5 Living Standard，但服务端工具（如 cheerio、BeautifulSoup、lxml）各自实现解析逻辑，差异集中在容错策略：
-
cheerio 默认按 XML 规则处理，遇到自闭合标签如 <img> 会报错，而浏览器接受 <img>、<img>、<img> 三种写法
-
BeautifulSoup 的 html.parser 和 lxml 对缺失结束标签的推断不同：一个可能把 <p>foo</p>
<div>bar</div> 解成 <p>foo</p>
<div>bar</div>，另一个可能让 <div> 成为 <code><p></p> 的子节点
- 标签大小写：浏览器不区分
<div> 和 <code><div>，但 <code>lxml 在 strict mode 下会视为不同节点
- 属性值引号：
<a href="example.com"></a> 在浏览器中合法，在部分解析器中可能被截断为 href=example
真正容易被忽略的，是解析器对“错误恢复”的定义——它不是 bug，而是规范的一部分。比如 <div><p><span>hello</span></p></div> 这种错嵌套，浏览器会主动闭合 <span></span> 和 <p></p> 再处理
