微前端中html质量需通过接口化机制保障：禁止完整文档结构、语义标签白名单过滤、domparser解析校验；子应用构建输出html-quality.json元数据供主框架验证；scopeid前缀强制class/id隔离；校验结果注入链路追踪并上报structured error。
微服务架构下，HTML 不再是单体页面的静态产物，而是多个前端服务协同输出的聚合结果。这意味着 HTML 代码质量不能只靠人工规范或构建时检查，必须通过可验证、可拦截、可上报的接口化机制嵌入整个微前端生命周期。
微前端容器层如何校验子应用 HTML 结构合法性
主框架（如 qiankun、Module Federation 容器）在 mount 子应用前，需对注入的 HTML 片段做最小可行性校验，避免非法结构破坏 DOM 树或触发 XSS。
- 禁止子应用返回包含
、、的完整文档结构，只允许<div> 及其子元素；校验失败应直接 throw 错误，不执行 <code>innerHTML注入 - 对子应用挂载节点的
outerHTML做语义标签白名单过滤：仅允许<header></header>、<nav></nav>、<main></main>、<section></section>、<article></article>、<footer></footer>等语义块级标签，拒绝<div class="wrapper"> 类无意义包裹 <li>使用 <code>DOMParser解析子应用 HTML 字符串，捕获解析错误（如未闭合标签、属性引号缺失），而非依赖浏览器容错渲染后检查 - 该文件应包含：
semantic_score（语义标签覆盖率）、kebab_case_class_count（符合 kebab-case 的 class 数量）、quoted_attr_count（带双引号属性数量）、max_nesting_depth（最大嵌套深度）等量化指标 - 构建脚本中集成
html-validate或自定义 AST 扫描器，在build后自动生成该 JSON，路径固定为dist/html-quality.json - 主框架可通过 fetch 加载该文件，在 dev 模式下警告低分子应用；CI 流程可配置阈值（如
semantic_score ）阻断部署 - 所有子应用在注册时必须声明
scopeId（如"user-center-v2"），该 ID 将作为 class/id 前缀硬性注入所有产出 HTML —— 例如user-center-v2__profile-card，而非自由命名 - 构建工具插件（如 webpack plugin）自动重写模板中的 class/id：遇到未加前缀的
class="card"，报错并提示 “missing scope prefix”，不生成产物 - 主框架提供运行时校验 API：
window.__checkHtmlScope(element)，传入挂载节点，返回冲突项列表（如发现两个子应用都用了id="modal"） - 每个子应用在注入 HTML 时，向全局 trace 上下文写入
html_validation_result字段，含校验时间、规则命中数、关键失败项（如 “found unquoted attr 'data-id'”） - 前端监控 SDK（如 Sentry、OpenTelemetry Web SDK）将该字段随 error report 一并上报，后端聚合服务按
subapp_id + trace_id关联定位 - 禁止将 HTML 校验逻辑放在 try/catch 中静默吞掉错误 —— 所有校验失败必须生成
html-validation-fail类型的 structured error，并携带子应用版本号
子应用构建阶段如何生成可消费的 HTML 质量元数据接口
每个子应用构建产物需附带一份机器可读的质量描述文件（如 html-quality.json），供主框架或 CI 工具调用验证。
跨子应用 class/id 冲突如何通过接口化命名约束解决
传统 BEM 或 CSS Modules 无法跨子应用生效，必须靠契约式接口强制命名隔离。
HTML 质量问题如何与微服务链路追踪打通
当用户端出现渲染异常（如屏幕空白、结构错乱），需快速定位是哪个子应用的 HTML 输出违规，而非陷入全链路日志大海。
真正难的不是写一堆校验规则，而是让每个子应用团队愿意暴露自己的 HTML 缺陷。接口化适配的关键，是把质量要求变成不可绕过的构建出口、运行时契约和可观测信号，而不是一份贴在 wiki 上的“建议”。
