一、为何需要通过 ESLint 限制 HTML 元素的使用范围
1.1 设计目标与一致性
在大型前端项目中，设计系统的一致性直接影响界面风格的统一和组件的复用性。通过对 HTML 元素使用的范围进行约束，可以确保团队成员遵循同一套 语义规范，从而提高可维护性与可访问性。
另一点关键是 代码风格的可预测性，避免在不同组件中混用废弃标签或自定义样式的方式导致样式冲突。通过 ESLint 的约束规则，可以在编译阶段就发现并阻止不符合规范的元素使用，从而降低后续的重构成本。
1.2 常见需要限制的 HTML 元素
一些已废弃或不推荐使用的标签，如 <font>、<marquee>、以及 <center> 等，往往会带来样式污染或可访问性问题。因此，确保在前端代码中禁用或限制这些元素，是持续交付过程中的重要环节。
此外，部分设计系统要求尽量减少低级 HTML 标签的直接使用，转而通过组件化封装来实现一致的行为与可测试性。这种降级到原生元素的趋势，更需要在代码检查阶段进行强制执行。通过 ESLint，可以将这类限制落地为可自动化的规则。
二、在 React/JSX 场景中应用 ESLint 限制 HTML 元素
2.1 使用 no-restricted-syntax 禁止特定 HTML 元素
在 React/JSX 项目中，JSX 的 AST 结构允许你通过 ESLint 规则来直接拦截某些元素的使用。使用 no-restricted-syntax 配置，可以对 JSXOpeningElement 进行精确筛选，从而限制特定标签的产生。
通过这样的做法，你可以实现“仅允许设计系统中的 HTML 标签集”的策略，避免团队成员在 JSX 中直接嵌入不符合规范的标签。
{"no-restricted-syntax": ["error",{"selector": "JSXOpeningElement[name.name='marquee']","message": "请使用 CSS 动画替代 <marquee> 标签。"},{"selector": "JSXOpeningElement[name.name='font']","message": "<font> 标签已废弃，请改用 CSS 字体相关属性。"}]
}
2.2 同时结合文件覆盖规则实现精确控制
对于不同文件类型或不同阶段的代码，可以通过 ESLint 的 overrides 机制来实现精细化控制。当你的代码基于 JSX 文件为主时，可以专门在某些文件规则里施加上述限制，从而避免在其他文件中产生冲突。
下面是一个简单的覆盖配置示例，展示如何在 .jsx、.tsx 文件中应用相同的禁用规则：
{"overrides": [{"files": ["*.jsx", "*.tsx"],"rules": {"no-restricted-syntax": ["error",{"selector": "JSXOpeningElement[name.name='marquee']","message": "请使用 CSS 动画替代 三、在 Vue 项目中通过模板 AST 限制 HTML 元素
3.1 使用 no-restricted-syntax 针对 VElement
在 Vue 项目中，模板解析的 AST 类型为 VElement，同样可以利用 no-restricted-syntax 来拦截不希望出现在模板中的标签。通过在规则中指定 VElement[name.name='marquee']，你可以直接禁止在模板中使用该标签。
这是实现跨框架一致性的有效路径，确保设计系统在 Vue 组件模板中的落地。
{"overrides": [{"files": ["*.vue"],"rules": {"no-restricted-syntax": ["error",{ "selector": "VElement[name.name='marquee']", "message": "请从模板中移除 3.2 实践：以设计系统为白名单的策略
除了直接禁用某些标签外，还可以通过自定义规则实现更细粒度的白名单策略，确保模板中仅允许被设计系统明确支持的标签集合使用。这种做法有助于维护 UI 语义的统一性，并降低非组件化标签对样式和行为的影响。
下面是一个简化的 Vue 适用示例，展示如何实现对 VElement 的白名单检测（简化版，仅供参考）：
{"plugins": ["vue"],"rules": {"no-restricted-syntax": ["error",{"selector": "VElement[name.name]","message": "请检查该元素是否在白名单中使用。"}]}
}
如果想要更强的控制，可以将白名单逻辑封装为自定义 ESLint 规则插件，在规则中维护一个允许的标签集合，并对 VElement 进行逐个比对与报告。自定义规则通常能带来更清晰的错误信息与可维护性。
// 简化的自定义规则示例（Vue 适用，VElement vs JSXElement 需按实际 AST 调整）
module.exports = {meta: { type: 'problem' },create(context) {const allowed = new Set(['div','span','p','a','button','input']);return {"VElement"(node) {const name = node.name && node.name.name;if (name && !allowed.has(name)) {context.report({ node, message: `元素 <${name}> 不在允许列表中。` });}}};}
};
四、实战要点与常见坑
4.1 如何维护 White/Black List 机制
在维护白名单或黑名单时，版本控制下的规则文件应保持与设计系统版本绑定，确保当设计系统更新时，规则也能同步演进。通过把需要禁用的标签清单集中在一个配置里，可以减少分散修改造成的矛盾。
建议把禁用的标签写成可读的消息，易于跨团队沟通，并在 PR 评审阶段作为检查点进行对齐。
4.2 兼容性、性能与维护成本
使用 ESLint 来限制 HTML 元素时，脚本执行成本、构建阶段的时间开销需要关注，尤其在大型代码库中。通过合理的 覆盖文件规则，避免对不相关文件进行重复检查，可以提升整体性能与体验。
同时，避免让规则变得过于繁杂，模块化规则与清晰的错误信息是保持长期可维护性的关键。
