HTML代码质量自愈机制需融合语义理解、模板AST分析与无障碍树模拟，而非仅依赖静态Lint；它必须适配EJS/React/Vue混合项目，在构建阶段介入并生成可审慎修复的警告，同时避免引入技术债。
HTML代码质量自愈机制不是加个Lint就能解决的事，它必须能感知语义断裂、结构退化和可访问性衰减，并在不破坏现有渲染逻辑的前提下自动修复。单纯依赖静态规则（如“必须用<nav>代替<div class="nav">”）会在真实项目中频繁误报或漏修——尤其当模板被EJS/Handlebars等引擎动态包裹时。
为什么HTML自愈不能只靠HTMLHint或axe-core
这些工具擅长检测已渲染的DOM快照，但无法理解“正在构建中的HTML”所承载的工程意图。比如：
-
<div class="card-header">可能正被CSS-in-JS动态注入语义，强制替换成<header>会破坏样式隔离 - 一个
<table>用于布局（虽不推荐）但被业务方明确要求保留，axe-core会报错，而自愈系统需识别上下文并跳过 - EJS模板里
<% if (user.isAdmin) { %><button>删除</button><% } %>缺少aria-hidden或role，但修复必须同步更新JS交互逻辑，否则屏幕阅读器会读出不可操作的按钮
真正可用的自愈，得把HTML解析器、模板AST、无障碍树模拟器和CSS作用域分析器串成一条链，而不是只跑一遍DOM校验。
如何让自愈适配EJS/React/Vue混合项目
关键不在“支持多少种模板语法”，而在能否提取出统一的语义图谱。以EJS为例，res.render('user-profile', { user })调用后，自愈系统要能：
立即学习“前端免费学习笔记（深入）”；
- 从
user-profile.ejs中识别出所有<%=表达式绑定的变量路径（如user.name），并标记其是否可能为空 - 扫描
<%脚本块，判断是否有条件分支影响语义标签选择（如if (isMobile) { <header class="mobile"> }） - 对每个
<include>子模板递归执行相同分析，确保header.ejs里的<div id="top-bar">不会被单独修复成<header>而与父级<header>冲突 - 生成修复建议时，优先用
<div role="banner">而非直接替换标签——既满足无障碍树要求，又不破坏CSS类名体系
自愈触发必须绑定构建阶段而非编辑阶段
在VS Code里实时提示<img>缺alt是友好，但真正防止上线事故的是在CI流水线中拦截。实操要点：
- 把自愈检查嵌入Webpack/Vite的
html-webpack-plugin或vite-plugin-html的transformHtml钩子，在HTML字符串生成后、写入磁盘前介入 - 对EJS，监听
app.set('view engine', 'ejs')后的res.render()调用，用代理函数捕获模板路径与数据，再调用自愈引擎 - 修复动作必须返回
{ html: string, warnings: Array<{ code: string, message: string, fix: () => string }> }结构，让CI能决定是自动提交补丁还是阻断构建 - 禁用“静默修复”：即使
<img src="logo.png">明显缺alt，也要生成warning而非直接插alt=""——空alt在无障碍场景下等同于隐藏，必须由人确认语义
最易被忽略的一点：自愈机制本身会产生技术债。每次添加新规则（如“<time>必须带datetime属性”），都要同步更新测试用例集、文档说明和团队培训材料。没有配套的Harness Engineering设计，自愈会从保障变成枷锁。
