尧图网站建设 
简介SonarQube 7.9是开源代码质量管理平台的重要版本面向开发、测试与运维人员解决代码漏洞、坏味道及规范一致性难以统一追踪的问题。压缩包为zip格式约196.67MB内含bin、conf、data、extensions、lib、web等目录bin用于启停服务conf设置数据库与端口extensions支持按语言扩展分析规则内置Elasticsearch加速质量数据检索。已有470人学习下载。部署后可通过Web界面查看项目质量概况、历史趋势与问题定位辅助团队建立质量门禁在开发阶段提前拦截缺陷提升可维护性与安全性。适合计划搭建或升级SonarQube实例的工程师作为完整安装包直接使用。1. 为什么现在还在折腾 SonarQube 7.91.1 7.9 到底是什么版本SonarQube 7.9 是 2019 年发布的 LTS 版本官方全称是 SonarQube 7.9 LTS很多老开发对它的印象是“SonarQube 历史上最稳的版本之一”。它在功能上最大的变化是从这一代开始强制依赖 Java 11 运行时同时官方明确将 MySQL 数据库的支持降级推荐使用 PostgreSQL。后面 8.x、9.x 的版本虽然功能更多但对机器配置、数据库版本的要求也水涨船高很多公司内部的老项目至今还锁在 7.9 这个版本上。我这次重新部署 SonarQube 7.9是因为团队要恢复一套遗留 Java 项目的代码质量门禁。翻新代码不现实换最新版 SonarQube 又要调整硬件、数据库、Jenkins 插件版本折腾一圈下来成本不小。相比之下 7.9 这个 LTS 版本依然能覆盖大部分静态代码分析需求而且它支持的插件生态很成熟SonarJava、SonarJS、SonarPython 等都是旧版本就能正常工作的没必要盲目追新。1.2 为什么旧版本反而更合适选 SonarQube 7.9 的核心原因有三个。第一是资源占用可控Team 的服务器只有 4G 内存新版 SonarQube 光 Elasticsearch 组件就可能吃掉 2G 以上7.9 在调优后能稳定运行在 1G~1.5G 堆内存上下。第二是兼容性好很多公司内部还有大量基于 JDK 8 或 Spring Boot 2.x 的老工程SonarQube 7.9 的扫描器对这类项目的兼容性非常好扫描结果不会因为语言版本问题产生太多误报。第三是升级路径清晰7.9 是 LTS 版本官方提供从 7.9 到 8.x、9.x 的升级路线先在这个版本把规范跑起来后面想升级也更容易做数据迁移。当然选老版本也不是没有代价。7.9 的 Web UI 比新版朴素很多安全规则库也停留在当年水平对 CWE、OWASP 的覆盖不如新版全面。但如果你只是做基础代码质量监控、重复率检查、圈复杂度统计它的结果完全够用。关键是它能跑起来团队能坚持用下去这才是最重要的。2. 本地部署 SonarQube 7.9 的实操记录2.1 环境准备与参数选择SonarQube 7.9 的部署条件其实比想象中简单但有几个参数必须提前确认。官方要求是 JDK 11实测在 JDK 11 下运行最稳如果你还在用 JDK 8建议先升级。操作系统方面Windows Server、CentOS 7、Ubuntu 18.04 都行我这次用的是 CentOS 7.9。数据库推荐 PostgreSQL我用的是 10.x 版本如果你想用 MySQL需要确认版本在 5.7 或 8.0 之间并且要手动创建数据库和用户。内存设置是这里最容易踩坑的地方。SonarQube 启动时会同时拉起 Elasticsearch、Web Server、Compute Engine 三个进程如果机器只有 2G 内存默认配置会直接启动失败。我的做法是修改conf/sonar.properties里的参数sonar.web.javaOpts-Xmx512m -Xms256m -XX:MaxPermGen128m sonar.ce.javaOpts-Xmx512m -Xms256m sonar.search.javaOpts-Xmx512m -Xms256m如果机器内存稍微宽裕一点建议把sonar.search.javaOpts的-Xmx调到 1G因为 Elasticsearch 是内存大户。数据库连接也要在同一个配置文件里配好sonar.jdbc.usernamesonar sonar.jdbc.passwordsonar123 sonar.jdbc.urljdbc:postgresql://localhost/sonar2.2 从下载到启动的完整步骤部署流程不复杂按顺序操作即可。先在 SonarQube 官网下载 7.9 的安装包注意不要下载最新版要找sonarqube-7.9.x.zip这个文件名或者从 GitHub Releases 里找历史版本。下载完成后解压到/opt/sonarqube然后创建一个专门运行 sonar 的系统用户绝对不要用 root 跑否则 Elasticsearch 会报无法以 root 身份运行的错误。接下来是初始化数据库。PostgreSQL 需要先建库和用户CREATE USER sonar WITH PASSWORD sonar123; CREATE DATABASE sonar OWNER sonar; GRANT ALL PRIVILEGES ON DATABASE sonar TO sonar;然后切换到 sonar 用户执行启动脚本su - sonar -c /opt/sonarqube/bin/linux-x86-64/sonar.sh start第一次启动会比较慢因为要初始化数据库、下载插件依赖建议用tail -f logs/sonar.log观察进度。看到类似SonarQube is up的日志后浏览器访问http://服务器IP:9000默认管理员账号密码是admin/admin登录后第一件事就是改密码。2.3 端口冲突与防火墙问题部署过程中最常见的两个问题是端口占用和防火墙拦截。SonarQube 默认端口是 9000如果被占用可以在sonar.properties里改sonar.web.port19000改完后重启服务。防火墙方面CentOS 下要执行firewall-cmd --permanent --add-port9000/tcp并 reloadWindows 环境则需要去防火墙高级设置里放开入站规则。我遇到过明明服务起来了但浏览器访问不了的情况排查半天发现是 ECS 安全组没放行 9000 端口这个需要结合云平台的安全组配置一起看。3. 用 SonarQube 7.9 扫描本地代码3.1 准备 SonarQube Scanner 扫描器服务端跑起来之后还需要一个扫描工具才能把代码送给 SonarQube 分析。推荐用官方提供的 SonarQube Scanner它是一个命令行工具下载解压后配置环境变量即可。7.9 适用的 Scanner 版本是 4.x不要用新版 Scanner如 5.x、6.x去配 7.9否则协议版本可能不兼容反而报错。解压后需要修改conf/sonar-scanner.properties告诉 Scanner 服务端地址sonar.host.urlhttp://localhost:9000 sonar.sourceEncodingUTF-8然后在系统环境变量里加上SONAR_SCANNER_HOME把%SONAR_SCANNER_HOME%/bin加入 PATH。验证是否安装成功执行sonar-scanner -v能正常输出版本信息就说明环境没问题。这个工具在 Linux、Windows、macOS 都有对应版本我这边团队既有 Windows 开发机也有 Mac 开发机统一用同一个扫描器配置只是路径略有不同。3.2 生成 Token 并配置客户端扫描本地代码时推荐用 Token 认证而不是直接传密码。浏览器登录 SonarQube进入右上角“我的账号”打开“安全”标签页生成一个 Token这个 Token 建议单独用于扫描任务权限也可以只在项目范围内授权。生成后保存好扫描时会用到。你可能还需要先在 SonarQube 服务端创建项目。7.9 的界面里点“创建新项目”填一个项目标识project key比如my-legacy-java-app然后显示的项目密钥就是扫描时用的sonar.projectKey。如果不提前建项目也没关系扫描时指定了不存在的项目标识服务端会自动创建但提前创建可以顺便配置质量门槛和权限更干净。3.3 执行一次完整的本地扫描进入项目根目录创建一个sonar-project.properties文件。以 Java Maven 项目为例sonar.projectKeymy-legacy-java-app sonar.projectName我的遗留Java应用 sonar.projectVersion1.0.0 sonar.sourcessrc sonar.java.binariestarget/classes sonar.sourceEncodingUTF-8如果你用的是 Gradle可以不写sonar-project.properties直接在项目里集成org.sonarqube.gradle插件然后执行gradle sonarqube -Dsonar.host.urlhttp://localhost:9000 -Dsonar.login你的TokenMaven 项目也是类似的原理用官方 sonar-maven-plugin 即可。我个人还是习惯统一用 Scanner因为不依赖构建工具版本配置一次所有项目都能复用。执行扫描命令sonar-scanner -Dsonar.login你的Token扫描过程中会输出进度最后提示ANALYSIS SUCCESS就代表上传成功了。这时候回服务端 Web 界面进入项目页面就能看到代码质量问题清单、指标统计、圈复杂度、重复率这些数据。第一次扫描结果可能很吓人几千个 issue 都正常关键是得让团队有一个 Baseline后续每次扫描对比增量和新增问题。4. SonarQube 7.9 与 IDE 集成的中文问题4.1 先理清“IDE 中文”这个需求到底是什么很多人在网上搜“sonarqube for ide 怎么改中文”其实这里有两层意思。第一层是 SonarQube 服务端 Web 界面的中文显示第二层是 IDE 里安装 SonarLint 插件后插件本身的界面和提示信息是否跟随中文。这两者经常被混为一谈但解决方式完全不同。如果你只是想让 SonarQube 服务端的管理界面、项目页面、规则描述显示成中文那需要装中文语言包。7.9 版本在 Administration Marketplace 里搜索Chinese Pack插件安装后重启服务即可。需要注意的是7.9 的中文语言包版本和最新版不通用必须选择兼容 7.9 的版本否则装不上或者界面显示错乱。4.2 给 SonarQube 服务端安装中文语言包在 SonarQube 7.9 上装中文包最简单的途径是 Web 界面在线安装。以管理员身份登录进入“Administration” “Marketplace”在搜索框输入“Chinese”找到Chinese Pack插件后点击 Install。安装过程会下载插件包完成后系统会提示重启重启后就变成中文了。如果服务器无法联网或者国外插件源被限制也可以手动下载 Chinese Pack jar 包放进/opt/sonarqube/extensions/plugins目录然后重启服务。这个 jar 包在 GitHub 上有对应的 release 版本注意下载时选 7.9 兼容的 tagged 版本文件名里通常会标注sonar-l10n-zh-pack-7.9之类的名称。重启后如果界面还是英文检查一下插件目录权限确保 sonar 用户可读。4.3 SonarLint 插件与本地代码扫描的联动IDE 里配套的工具是 SonarLint 插件它支持 Eclipse、IntelliJ IDEA、VS Code。在 IDEA 里安装完 SonarLint 插件后可以直接连接 SonarQube 服务端然后拉取项目规则配置这也是很多人说的“sonarqube for ide”的真正含义。连接方式是在 IDEA 的 Setting 里找到 SonarLint配置 SonarQube 服务器地址、Token然后绑定你当前项目。至于 IDE 插件本身的中文问题SonarLint 插件的界面语言是跟随 IDE 语言的IDEA 如果设置成中文SonarLint 的提示框和规则名也会尽量显示中文。但规则描述文本来自 SonarQube 服务端的规则库如果服务端是英文环境SonarLint 里显示的规则描述也还是英文。所以想让 IDE 里看到中文规则分析服务端中文语言包同样要装好连接后 SonarLint 会同步规则和本地化信息。还有一个小技巧SonarLint 在分析本地代码时不一定要连服务端也能跑它会用插件内置的默认规则集先扫一遍。但内置规则数量和团队自定义规则相差很大还是建议绑定到 SonarQube 服务端让 IDE 分析和服务端扫描用同一套规则这样本地看到的 issue 才和服务端扫描结果一致。5. 避坑与常见问题5.1 Elasticsearch 启动失败的排查思路SonarQube 7.9 自带的 Elasticsearch 是坑最多的地方报错通常集中在两个点一是“max virtual memory areas vm.max_map_count [65530] is too low”这是 Linux 内核参数问题编辑/etc/sysctl.conf加一行vm.max_map_count262144然后执行sysctl -p即可。二是“bootstrap checks failed”中的内存锁限制需要修改/etc/security/limits.conf给 sonar 用户加nofile和nproc限制。另外千万不要在 root 用户下启动 SonarQube。Elasticsearch 出于安全设计会直接拒绝 root 启动报错日志会写can not run elasticsearch as root。解决办法是按要求创建一个普通用户比如sonar并给/opt/sonarqube目录授权。如果这些配置都改好了还是起不来把logs/es.log里的完整报错贴到搜索引擎基本都能找到答案这类问题在 7.9 社区里已经被讨论过很多轮了。5.2 扫描结果为空或扫描不到 source 文件扫描本地代码时最让人头疼的问题就是扫描完提示成功但 Web 界面上没有任何 issue。这种情况十有八九是sonar.sources路径配置不对。Maven 项目源码默认在src/main/java但历史上有些项目结构不标准比如源码直接放在java目录或者用了自定义sourceDirectory这些都是扫不出来的原因。如果是 Java 项目还要确认sonar.java.binaries是否指向了编译输出目录。如果 target/classes 不存在SonarJava 分析器会因为无法解析依赖而跳过大量规则最终表现为 issue 数量极少。解决办法是先mvn compile或gradle classes确保有编译产物再执行扫描。另外要注意编码问题如果源码是 GBK 而配置里是 UTF-8Scanner 会读取乱码甚至报错建议在sonar-project.properties里显式写好sonar.sourceEncodingGBK或者统一把工程源码转成 UTF-8。5.3 升级与迁移时的注意点如果你将来打算从 7.9 升级到新版本有几个点现在就要心里有数。第一升级前必须先备份数据库SonarQube 的数据全在数据库里文件目录只是程序备份了 PostgreSQL 的 dump 就能随时回滚。第二升级不能跨版本跳太多官方要求先升到相邻的 LTS再逐级升比如 7.9 升 8.9再升 9.9不能一次性跳到最新版。第三升级前检查自定义插件兼容性一些三方插件在新版里可能直接失效导致加载不了。如果团队短期内没有升级计划建议把 7.9 的配置文件和相关文档完整归档。我见过很多老环境因为长期没人维护SonarQube 数据还在但配置文件丢了花了大量时间重新搭建。把部署文档、数据库连接信息、扫描器配置统一放进项目仓库的docs/sonar目录这样后人接手成本会低很多。5.4 质量门禁与团队落地建议最后聊一点经验和团队落地层面的建议。新部署的 SonarQube 7.9 默认质量门禁是“不引入新问题”看起来合理但对老项目很不友好。老项目已经存在几千个 issue每次扫描都会因为存量问题导致门禁失败。这种情况建议在 7.9 里配置“新代码”维度的质量门禁只看本次改动新增的问题存量问题单独建一个技术债清单逐步处理而不是一棒子打死。我实际操作中还有一个小技巧扫描前用sonar.projectDate参数设置一个基线日期把历史代码全部算作存量后续新增问题才会被记录。这个参数对于治理老项目特别有用配合质量门禁可以让团队在不被历史债务淹没的前提下逐步把质量问题收敛下来。7.9 虽然老但只要配置得当作为团队代码质量管理的基础设施完全能胜任。本文还有配套的精品资源点击获取 SonarQube 7.9 LTS本地部署实战：旧项目代码质量门禁落地指南
简介SonarQube 7.9是开源代码质量管理平台的重要版本面向开发、测试与运维人员解决代码漏洞、坏味道及规范一致性难以统一追踪的问题。压缩包为zip格式约196.67MB内含bin、conf、data、extensions、lib、web等目录bin用于启停服务conf设置数据库与端口extensions支持按语言扩展分析规则内置Elasticsearch加速质量数据检索。已有470人学习下载。部署后可通过Web界面查看项目质量概况、历史趋势与问题定位辅助团队建立质量门禁在开发阶段提前拦截缺陷提升可维护性与安全性。适合计划搭建或升级SonarQube实例的工程师作为完整安装包直接使用。1. 为什么现在还在折腾 SonarQube 7.91.1 7.9 到底是什么版本SonarQube 7.9 是 2019 年发布的 LTS 版本官方全称是 SonarQube 7.9 LTS很多老开发对它的印象是“SonarQube 历史上最稳的版本之一”。它在功能上最大的变化是从这一代开始强制依赖 Java 11 运行时同时官方明确将 MySQL 数据库的支持降级推荐使用 PostgreSQL。后面 8.x、9.x 的版本虽然功能更多但对机器配置、数据库版本的要求也水涨船高很多公司内部的老项目至今还锁在 7.9 这个版本上。我这次重新部署 SonarQube 7.9是因为团队要恢复一套遗留 Java 项目的代码质量门禁。翻新代码不现实换最新版 SonarQube 又要调整硬件、数据库、Jenkins 插件版本折腾一圈下来成本不小。相比之下 7.9 这个 LTS 版本依然能覆盖大部分静态代码分析需求而且它支持的插件生态很成熟SonarJava、SonarJS、SonarPython 等都是旧版本就能正常工作的没必要盲目追新。1.2 为什么旧版本反而更合适选 SonarQube 7.9 的核心原因有三个。第一是资源占用可控Team 的服务器只有 4G 内存新版 SonarQube 光 Elasticsearch 组件就可能吃掉 2G 以上7.9 在调优后能稳定运行在 1G~1.5G 堆内存上下。第二是兼容性好很多公司内部还有大量基于 JDK 8 或 Spring Boot 2.x 的老工程SonarQube 7.9 的扫描器对这类项目的兼容性非常好扫描结果不会因为语言版本问题产生太多误报。第三是升级路径清晰7.9 是 LTS 版本官方提供从 7.9 到 8.x、9.x 的升级路线先在这个版本把规范跑起来后面想升级也更容易做数据迁移。当然选老版本也不是没有代价。7.9 的 Web UI 比新版朴素很多安全规则库也停留在当年水平对 CWE、OWASP 的覆盖不如新版全面。但如果你只是做基础代码质量监控、重复率检查、圈复杂度统计它的结果完全够用。关键是它能跑起来团队能坚持用下去这才是最重要的。2. 本地部署 SonarQube 7.9 的实操记录2.1 环境准备与参数选择SonarQube 7.9 的部署条件其实比想象中简单但有几个参数必须提前确认。官方要求是 JDK 11实测在 JDK 11 下运行最稳如果你还在用 JDK 8建议先升级。操作系统方面Windows Server、CentOS 7、Ubuntu 18.04 都行我这次用的是 CentOS 7.9。数据库推荐 PostgreSQL我用的是 10.x 版本如果你想用 MySQL需要确认版本在 5.7 或 8.0 之间并且要手动创建数据库和用户。内存设置是这里最容易踩坑的地方。SonarQube 启动时会同时拉起 Elasticsearch、Web Server、Compute Engine 三个进程如果机器只有 2G 内存默认配置会直接启动失败。我的做法是修改conf/sonar.properties里的参数sonar.web.javaOpts-Xmx512m -Xms256m -XX:MaxPermGen128m sonar.ce.javaOpts-Xmx512m -Xms256m sonar.search.javaOpts-Xmx512m -Xms256m如果机器内存稍微宽裕一点建议把sonar.search.javaOpts的-Xmx调到 1G因为 Elasticsearch 是内存大户。数据库连接也要在同一个配置文件里配好sonar.jdbc.usernamesonar sonar.jdbc.passwordsonar123 sonar.jdbc.urljdbc:postgresql://localhost/sonar2.2 从下载到启动的完整步骤部署流程不复杂按顺序操作即可。先在 SonarQube 官网下载 7.9 的安装包注意不要下载最新版要找sonarqube-7.9.x.zip这个文件名或者从 GitHub Releases 里找历史版本。下载完成后解压到/opt/sonarqube然后创建一个专门运行 sonar 的系统用户绝对不要用 root 跑否则 Elasticsearch 会报无法以 root 身份运行的错误。接下来是初始化数据库。PostgreSQL 需要先建库和用户CREATE USER sonar WITH PASSWORD sonar123; CREATE DATABASE sonar OWNER sonar; GRANT ALL PRIVILEGES ON DATABASE sonar TO sonar;然后切换到 sonar 用户执行启动脚本su - sonar -c /opt/sonarqube/bin/linux-x86-64/sonar.sh start第一次启动会比较慢因为要初始化数据库、下载插件依赖建议用tail -f logs/sonar.log观察进度。看到类似SonarQube is up的日志后浏览器访问http://服务器IP:9000默认管理员账号密码是admin/admin登录后第一件事就是改密码。2.3 端口冲突与防火墙问题部署过程中最常见的两个问题是端口占用和防火墙拦截。SonarQube 默认端口是 9000如果被占用可以在sonar.properties里改sonar.web.port19000改完后重启服务。防火墙方面CentOS 下要执行firewall-cmd --permanent --add-port9000/tcp并 reloadWindows 环境则需要去防火墙高级设置里放开入站规则。我遇到过明明服务起来了但浏览器访问不了的情况排查半天发现是 ECS 安全组没放行 9000 端口这个需要结合云平台的安全组配置一起看。3. 用 SonarQube 7.9 扫描本地代码3.1 准备 SonarQube Scanner 扫描器服务端跑起来之后还需要一个扫描工具才能把代码送给 SonarQube 分析。推荐用官方提供的 SonarQube Scanner它是一个命令行工具下载解压后配置环境变量即可。7.9 适用的 Scanner 版本是 4.x不要用新版 Scanner如 5.x、6.x去配 7.9否则协议版本可能不兼容反而报错。解压后需要修改conf/sonar-scanner.properties告诉 Scanner 服务端地址sonar.host.urlhttp://localhost:9000 sonar.sourceEncodingUTF-8然后在系统环境变量里加上SONAR_SCANNER_HOME把%SONAR_SCANNER_HOME%/bin加入 PATH。验证是否安装成功执行sonar-scanner -v能正常输出版本信息就说明环境没问题。这个工具在 Linux、Windows、macOS 都有对应版本我这边团队既有 Windows 开发机也有 Mac 开发机统一用同一个扫描器配置只是路径略有不同。3.2 生成 Token 并配置客户端扫描本地代码时推荐用 Token 认证而不是直接传密码。浏览器登录 SonarQube进入右上角“我的账号”打开“安全”标签页生成一个 Token这个 Token 建议单独用于扫描任务权限也可以只在项目范围内授权。生成后保存好扫描时会用到。你可能还需要先在 SonarQube 服务端创建项目。7.9 的界面里点“创建新项目”填一个项目标识project key比如my-legacy-java-app然后显示的项目密钥就是扫描时用的sonar.projectKey。如果不提前建项目也没关系扫描时指定了不存在的项目标识服务端会自动创建但提前创建可以顺便配置质量门槛和权限更干净。3.3 执行一次完整的本地扫描进入项目根目录创建一个sonar-project.properties文件。以 Java Maven 项目为例sonar.projectKeymy-legacy-java-app sonar.projectName我的遗留Java应用 sonar.projectVersion1.0.0 sonar.sourcessrc sonar.java.binariestarget/classes sonar.sourceEncodingUTF-8如果你用的是 Gradle可以不写sonar-project.properties直接在项目里集成org.sonarqube.gradle插件然后执行gradle sonarqube -Dsonar.host.urlhttp://localhost:9000 -Dsonar.login你的TokenMaven 项目也是类似的原理用官方 sonar-maven-plugin 即可。我个人还是习惯统一用 Scanner因为不依赖构建工具版本配置一次所有项目都能复用。执行扫描命令sonar-scanner -Dsonar.login你的Token扫描过程中会输出进度最后提示ANALYSIS SUCCESS就代表上传成功了。这时候回服务端 Web 界面进入项目页面就能看到代码质量问题清单、指标统计、圈复杂度、重复率这些数据。第一次扫描结果可能很吓人几千个 issue 都正常关键是得让团队有一个 Baseline后续每次扫描对比增量和新增问题。4. SonarQube 7.9 与 IDE 集成的中文问题4.1 先理清“IDE 中文”这个需求到底是什么很多人在网上搜“sonarqube for ide 怎么改中文”其实这里有两层意思。第一层是 SonarQube 服务端 Web 界面的中文显示第二层是 IDE 里安装 SonarLint 插件后插件本身的界面和提示信息是否跟随中文。这两者经常被混为一谈但解决方式完全不同。如果你只是想让 SonarQube 服务端的管理界面、项目页面、规则描述显示成中文那需要装中文语言包。7.9 版本在 Administration Marketplace 里搜索Chinese Pack插件安装后重启服务即可。需要注意的是7.9 的中文语言包版本和最新版不通用必须选择兼容 7.9 的版本否则装不上或者界面显示错乱。4.2 给 SonarQube 服务端安装中文语言包在 SonarQube 7.9 上装中文包最简单的途径是 Web 界面在线安装。以管理员身份登录进入“Administration” “Marketplace”在搜索框输入“Chinese”找到Chinese Pack插件后点击 Install。安装过程会下载插件包完成后系统会提示重启重启后就变成中文了。如果服务器无法联网或者国外插件源被限制也可以手动下载 Chinese Pack jar 包放进/opt/sonarqube/extensions/plugins目录然后重启服务。这个 jar 包在 GitHub 上有对应的 release 版本注意下载时选 7.9 兼容的 tagged 版本文件名里通常会标注sonar-l10n-zh-pack-7.9之类的名称。重启后如果界面还是英文检查一下插件目录权限确保 sonar 用户可读。4.3 SonarLint 插件与本地代码扫描的联动IDE 里配套的工具是 SonarLint 插件它支持 Eclipse、IntelliJ IDEA、VS Code。在 IDEA 里安装完 SonarLint 插件后可以直接连接 SonarQube 服务端然后拉取项目规则配置这也是很多人说的“sonarqube for ide”的真正含义。连接方式是在 IDEA 的 Setting 里找到 SonarLint配置 SonarQube 服务器地址、Token然后绑定你当前项目。至于 IDE 插件本身的中文问题SonarLint 插件的界面语言是跟随 IDE 语言的IDEA 如果设置成中文SonarLint 的提示框和规则名也会尽量显示中文。但规则描述文本来自 SonarQube 服务端的规则库如果服务端是英文环境SonarLint 里显示的规则描述也还是英文。所以想让 IDE 里看到中文规则分析服务端中文语言包同样要装好连接后 SonarLint 会同步规则和本地化信息。还有一个小技巧SonarLint 在分析本地代码时不一定要连服务端也能跑它会用插件内置的默认规则集先扫一遍。但内置规则数量和团队自定义规则相差很大还是建议绑定到 SonarQube 服务端让 IDE 分析和服务端扫描用同一套规则这样本地看到的 issue 才和服务端扫描结果一致。5. 避坑与常见问题5.1 Elasticsearch 启动失败的排查思路SonarQube 7.9 自带的 Elasticsearch 是坑最多的地方报错通常集中在两个点一是“max virtual memory areas vm.max_map_count [65530] is too low”这是 Linux 内核参数问题编辑/etc/sysctl.conf加一行vm.max_map_count262144然后执行sysctl -p即可。二是“bootstrap checks failed”中的内存锁限制需要修改/etc/security/limits.conf给 sonar 用户加nofile和nproc限制。另外千万不要在 root 用户下启动 SonarQube。Elasticsearch 出于安全设计会直接拒绝 root 启动报错日志会写can not run elasticsearch as root。解决办法是按要求创建一个普通用户比如sonar并给/opt/sonarqube目录授权。如果这些配置都改好了还是起不来把logs/es.log里的完整报错贴到搜索引擎基本都能找到答案这类问题在 7.9 社区里已经被讨论过很多轮了。5.2 扫描结果为空或扫描不到 source 文件扫描本地代码时最让人头疼的问题就是扫描完提示成功但 Web 界面上没有任何 issue。这种情况十有八九是sonar.sources路径配置不对。Maven 项目源码默认在src/main/java但历史上有些项目结构不标准比如源码直接放在java目录或者用了自定义sourceDirectory这些都是扫不出来的原因。如果是 Java 项目还要确认sonar.java.binaries是否指向了编译输出目录。如果 target/classes 不存在SonarJava 分析器会因为无法解析依赖而跳过大量规则最终表现为 issue 数量极少。解决办法是先mvn compile或gradle classes确保有编译产物再执行扫描。另外要注意编码问题如果源码是 GBK 而配置里是 UTF-8Scanner 会读取乱码甚至报错建议在sonar-project.properties里显式写好sonar.sourceEncodingGBK或者统一把工程源码转成 UTF-8。5.3 升级与迁移时的注意点如果你将来打算从 7.9 升级到新版本有几个点现在就要心里有数。第一升级前必须先备份数据库SonarQube 的数据全在数据库里文件目录只是程序备份了 PostgreSQL 的 dump 就能随时回滚。第二升级不能跨版本跳太多官方要求先升到相邻的 LTS再逐级升比如 7.9 升 8.9再升 9.9不能一次性跳到最新版。第三升级前检查自定义插件兼容性一些三方插件在新版里可能直接失效导致加载不了。如果团队短期内没有升级计划建议把 7.9 的配置文件和相关文档完整归档。我见过很多老环境因为长期没人维护SonarQube 数据还在但配置文件丢了花了大量时间重新搭建。把部署文档、数据库连接信息、扫描器配置统一放进项目仓库的docs/sonar目录这样后人接手成本会低很多。5.4 质量门禁与团队落地建议最后聊一点经验和团队落地层面的建议。新部署的 SonarQube 7.9 默认质量门禁是“不引入新问题”看起来合理但对老项目很不友好。老项目已经存在几千个 issue每次扫描都会因为存量问题导致门禁失败。这种情况建议在 7.9 里配置“新代码”维度的质量门禁只看本次改动新增的问题存量问题单独建一个技术债清单逐步处理而不是一棒子打死。我实际操作中还有一个小技巧扫描前用sonar.projectDate参数设置一个基线日期把历史代码全部算作存量后续新增问题才会被记录。这个参数对于治理老项目特别有用配合质量门禁可以让团队在不被历史债务淹没的前提下逐步把质量问题收敛下来。7.9 虽然老但只要配置得当作为团队代码质量管理的基础设施完全能胜任。本文还有配套的精品资源点击获取