HTML代码质量校验必须在CI构建阶段设断点，使用HTML解析器（如parse5）AST遍历拦截<script><iframe>等危险标签并直接失败，同时校验DOCTYPE、html结构完整性及表单属性与后端schema一致性。
前端交付标准里，HTML代码质量校验不能只靠“能跑就行”，必须在构建流中设断点——不是等上线才发现<script>被漏掉、required被绕过、或者pattern根本没生效。
构建阶段如何拦截危险HTML标签
CI流水线里直接扫描源码比等运行时更早、更准。关键不是“删不删”，而是“在哪个环节删、删完怎么反馈”。
-
<script>、<iframe>、含javascript:的href或src必须在构建早期被识别并阻断，否则后续所有校验都失去意义 - 用正则硬匹配风险高（比如
<scr<!--i-->pt>可绕过），推荐用HTML解析器（如parse5或cheerio）做AST遍历，查node.nodeName和node.attributes - 发现违规标签后，构建应直接失败（
process.exit(1)），而不是警告——交付标准里“可上线”不等于“有警告但没报错” - 例外白名单要显式配置（比如允许
<script type="application/ld+json">），且白名单规则必须走PR审批，不能写死在脚本里
HTML结构完整性校验该放在哪一步
W3C验证器适合人工抽查，不适合CI。构建流里需要轻量、可嵌入、可断言的结构检查。
- 必须检查
<!DOCTYPE html>是否存在且位置正确（不能在注释后、不能带空格） -
<html>必须有且仅有一个，且包裹<head>和<body>；<head>里必须含<title>（哪怕只是占位） - 闭合标签错误（如
<p>xxx没闭合）会导致浏览器纠错渲染，但构建时就能用parse5.parseFragment()捕获errors数组 - 不要依赖
innerHTML+document.createElement模拟渲染来判断——它会自动补全缺失标签，掩盖真实问题
表单校验属性是否该在构建阶段做一致性检查
是。前后端校验规则不一致，不是“bug”，是交付标准的系统性缺口。
立即学习“前端免费学习笔记（深入）”；
- 提取所有
input的type、required、pattern、min/max，生成一份校验元数据（JSON），和后端schema做diff（比如pattern正则字符串是否完全相同） -
type="email"这类属性本身不防攻击，但若前端写了pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"，后端却只用email-validator默认规则，就构成逻辑裂缝 - 构建脚本里加一行
if (frontendPattern !== backendPattern) throw new Error("pattern mismatch")，比上线后抓包排查快十倍 - 注意：移动端WebView对
minlength支持不一，构建检查时应同步标记该字段需JS层兜底，避免只信HTML属性
真正难的不是写检查逻辑，而是让校验规则在前端、后端、构建脚本、甚至文档里保持同一份源头。改一个pattern，如果没触发CI失败，说明整个防御链已经断了。
