HTML不被esbuild解析，故需用html-validate等专用工具做质量保障，而非强求esbuild检查；应并行集成、commit前校验，避免塞入build流程拖慢速度。
HTML 本身没有“代码质量检查”机制，esbuild 也不解析 HTML 文件里的结构或语义——它只处理你明确传入的 entryPoints。想在 esbuild 构建流中做 HTML 质量保障，必须绕过“让 esbuild 检查 HTML”这个错误前提，转而用独立工具链协同工作。
HTML 不被 esbuild 解析，所以 ESLint/Prettier 对它完全无效
esbuild 的设计原则是“只构建你指定的 JS/TS/CSS 入口”，<script src="app.js"></script> 这类引用不会触发任何扫描或校验。即使 HTML 文件里有拼错的属性、缺失的闭合标签、或不符合 ARIA 规范的写法，esbuild 既不报错，也不警告。
- 常见错误现象：
npm run build成功，但页面加载后按钮无法聚焦（tabindex写成tabIndex），ESLint 完全没提示 - 根本原因：ESLint 默认只 lint
.js/.ts文件；Prettier 对 HTML 的支持需显式启用且单独配置 - 正确做法：把 HTML 当作独立资源，用
html-validate或axe-core（运行时）这类专用工具覆盖
如何让 HTML 校验接入开发流程而不拖慢 esbuild 速度
不能把 HTML 校验塞进 esbuild 的 build() 流程里——那会破坏它的内存编译优势，也违背“职责分离”原则。应该用并行、轻量、可缓存的方式集成。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 推荐组合：
html-validate+prettier --parser html+lint-staged - 避免在
--watch中实时校验 HTML：每次保存index.html都触发一次完整校验，延迟明显；改为仅在git commit前跑一次 - 配置示例（
html-validate.json）：{ "extends": ["html-validate:recommended"], "rules": { "valid-attr": "error", "no-inline-style": "warn", "require-sri": ["error", {"algorithms": ["sha256"]}] } } - 关键点：不要用
esbuild-plugin-html来“自动打包 HTML”——它解决的是入口发现问题，不是质量检查
动态生成 HTML 的场景（如 SSR、模板字符串）怎么保障质量
当 HTML 是从 JS 拼出来的（document.body.innerHTML = <div class="foo">${text}</div>），或由框架（如 Svelte/Vue）编译生成时，静态校验就失效了。这时得靠运行时检测 + 类型约束。
立即学习“前端免费学习笔记（深入）”；
- JSX/TSX 场景：用
@types/react+ TS 的 JSX.Element 类型检查，能捕获大部分属性拼写错误（比如clasName） - 纯字符串拼接：改用
lit-html或htm，它们在编译期就能报出未闭合标签、非法属性等错误 - SSR 输出：在 Node 端加一层
parse5+html-validate的简单 wrapper，只对最终输出的 HTML 字符串做一次校验（非每次请求） - 注意：不要在 esbuild 的
onLoad插件里解析 HTML 字符串做 lint——AST 构建开销大，且和 esbuild 的并行模型冲突
最常被忽略的一点：HTML 质量工具和 esbuild 之间没有数据通道。你不能指望 esbuild.build() 的返回值里包含 HTML 错误列表——它们是两条平行线，靠约定（文件路径、hook 时机、exit code）协作，而不是 API 集成。
