将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
dom结构异常不会触发error事件，因浏览器对非法嵌套静默修正而不抛错，故window.onerror和sentry均无法捕获；唯一准确定位方式是使用w3c validator校验内容模型，并通过queryselectorall遍历检测孤立节点。
DOM结构异常不会触发error事件，前端错误收集系统默认收不到——你监控到的全是JS报错，但页面错位、样式失效、事件丢失的真实元凶，往往藏在浏览器静默修正后的DOM里。
为什么window.onerror和Sentry都抓不到DOM嵌套错误
浏览器对非法嵌套（如<p></p>
<div></div>
console.error。它直接按HTML5解析算法重排DOM树，整个过程无日志、无警告、不中断加载。所以：
- window.onerror监听不到任何东西
- Sentry这类基于error或unhandledrejection的SDK完全失焦
- 你看到的“JS查询不到元素”，根源是document.querySelector('p div')本就该返回null——因为<p></p>了用document.querySelectorAll('*')快速扫描孤立节点
那些被浏览器“踢出来”的节点，失去父级上下文，却不会报错。执行这行代码能立刻暴露它们：document.querySelectorAll('*').forEach(el => { if (!el.parentElement) console.log('孤立元素:', el); });
常见触发场景包括：
- <ul></ul>里直接塞<div>
- <code><table>中漏写<code><tr>或<code><td>
- <code><p></p>内写了<h2></h2>或<section></section>
这些节点在DevTools Elements面板里通常显示为灰色、半透明、缩进突兀，且无法响应body > div这类依赖层级的选择器
W3C Validator才是唯一能定位首个嵌套错误的工具
DevTools看的是“修正后”的DOM，而W3C Validator（validator.w3.org）按HTML规范逐条校验内容模型（content model），告诉你“谁不该出现在谁里面”。例如：
- 报错Element div not allowed as child of element p → 必须把<div>移出<code><p></p>
- 提示Element img is not closed → <img>写法违法，要改成<img>或<img>（HTML5允许省略斜杠，但必须不带闭合标签）
关键操作：粘贴HTML片段 → 选“Validate by Input” → 优先修复第一条Error，后续大量Warning常是连锁反应
服务端渲染和模板引擎中如何提前拦截
JSX、Vue SFC、PHP模板等编译阶段不校验HTML合法性，错误会一直潜伏到浏览器解析时才爆发。可行的拦截点：
- 在CI流程中集成html-validate或htmlhint，对产出HTML做静态检查
- 使用jsdom加载模板输出，再比对document.body.innerHTML.length与原始字符串长度——若偏差超过阈值（如±10%），大概率存在未闭合标签引发的结构雪崩
- 对SSR输出加一层简单守卫：if (html.includes('<p></p>
<div>') || html.includes('<ul><div>')) throw new Error('illegal nesting detected');
注意：Prettier、ESLint-<a style="color:#f60; text-decoration:underline;" title="html" href="https://m.php.cn/zt/15763.html" target="_blank">html</a>等格式化/语法工具对嵌套合法性完全不敏感，别指望它们发现这类问题<p>最危险的不是报错，而是“看起来正常”——DOM已被重写，你却还在源码里找逻辑bug。修复顺序永远是：先跑W3C Validator，再查孤立节点，最后动JS逻辑。</p>
</div></ul>
</div>
