SonarQube默认不扫描HTML内联JS错误，因其将HTML视为web类型仅做结构校验，JS分析需满足三条件：显式配置sonar.web.file.suffixes、启用SonarJS插件、HTML路径在sonar.sources内且未被排除。
直接说结论：SonarQube 本身不扫描 HTML 文件内容逻辑（比如 DOM 操作错误、XSS 漏洞），但能识别 HTML 中的内联 script 和 style 块，以及模板语法（如 Angular、Vue 的插值表达式）——前提是配置对了语言解析器和规则集。纯静态 HTML 文件默认只被当作文本处理，不会触发 JS 或 CSS 的语义分析。
为什么 sonar-scanner 默认不报 HTML 里的 JS 错误？
SonarQube 的扫描行为由 sonar.language 和实际启用的插件决定。HTML 文件默认归类为 web 语言类型，但该类型仅做基础结构校验（如标签闭合、属性合法性），不激活 JavaScript 引擎。真正执行 JS 分析的是 javascript 插件，它只扫描后缀为 .js、.jsx 等明确声明的文件。
-
sonar.sources路径若只包含.html，JS 代码块会被忽略 - 即使 HTML 里有
<script>alert("xss")</script>，也不会触发javascript:S1186（XSS 检测）规则 - Vue/React 模板中的
{{ user.input }}同样不会被当作 JS 表达式分析，除非启用对应框架插件
让 HTML 中的脚本参与扫描的三个必要条件
必须同时满足以下三点，HTML 内联脚本才可能被 JS 插件捕获并分析：
- 在
sonar-project.properties中显式添加sonar.web.file.suffixes=.html,.htm,.xhtml - 确保项目已安装并启用
SonarJS插件（SonarQube 9.9+ 默认内置，旧版需手动安装） - HTML 文件路径需落在
sonar.sources范围内，且不能被sonar.exclusions过滤
示例配置片段：
立即学习“前端免费学习笔记（深入）”；
sonar.projectKey=my-web-app sonar.sources=. sonar.web.file.suffixes=.html,.htm,.xhtml sonar.javascript.file.suffixes=.js,.jsx,.ts,.tsx,.vue,.svelte sonar.exclusions=**/node_modules/**,**/dist/**
常见踩坑点：Vue/React 模板扫描失效
Vue 单文件组件（.vue）或 JSX 文件里的 HTML 片段，容易被误认为“只是 HTML”而跳过 JS 分析。根本原因是 SonarQube 默认按文件后缀路由到不同语言处理器：
-
.vue文件由sonar-vue-plugin处理，但该插件默认不启用 JS 规则，需额外配置sonar.javascript.libraries和sonar.javascript.nodejs.executable -
.jsx文件若未声明sonar.javascript.file.suffixes，会被当成纯文本 - 使用
v-html或dangerouslySetInnerHTML的地方，必须开启sonar.javascript.security.enabled=true才能触发 XSS 规则
检查是否生效：扫描后进入 SonarQube Web 页面 → 项目 → “Issues” → 筛选 “Component” 包含 .html 或 .vue，再看是否有 javascript: 开头的规则 ID（如 javascript:S2076）。
替代方案：提取脚本单独扫描更可靠
对 HTML 中内联脚本的扫描始终存在局限性。生产环境更推荐的做法是：
- 禁止在 HTML 中写
<script>块，全部抽离为独立.js文件 - 用构建工具（Webpack/Vite）自动提取模板中绑定的表达式，生成可分析的 JS 模块
- 对 SSR 渲染输出的 HTML，改用专用工具如
owasp-zap或dompurify做运行时安全检测，而非依赖 SonarQube 静态分析
HTML 不是执行环境，它的“质量”更多体现在语义结构、无障碍支持和模板安全性上 —— 这些恰恰是 SonarQube 最弱的一环。别指望靠它发现 <button onclick="location.href='?id='+x"> 这类漏洞，得靠专门的前端安全扫描器或人工 Code Review。
