静态代码分析工具实战：从Cppcheck到SonarQube的选型与集成

静态代码分析这个词，听起来像是实验室里的东西，但说白了它就是：写一个程序，把你的代码从头到尾读一遍，不运行、不部署，就凭空挑毛病。空指针、数组越界、未释放的资源、危险API、风格怪异的坏味道，都能被它提前翻出来。今天这篇我就是想把常见的静态代码分析软件挨个盘一遍，重点说说我实际用下来是什么感受，哪些值得花力气部署，哪些其实用不上。如果你正在纠结项目里该上什么静态分析工具，或者已经装了但发现没人看告警，这篇文章应该能给你省点时间。

我介绍的工具覆盖 C/C++、Java、Python、JavaScript/TypeScript 几大主流阵营，也会提到 SonarQube、Semgrep、CodeQL 这类平台型和规则引擎型产品。每一款我都会从它擅长什么、不擅长什么、真实使用体验怎么样这三个角度来讲，最后再聊一聊怎么把它们接进 CI，以及我踩过的坑。

1. 静态代码分析到底是什么，它值得花时间研究吗

1.1 从一次线上事故说起：不用静态分析的代价

我之前待过一个做嵌入式控制器的团队，产品已经量产了，结果在某个特定批次设备上报出偶发性崩溃，查了整整两周，最后发现是一个老模块里的指针在极端边界条件下越界写坏了一块内存。问题代码写得并不算多隐蔽，就是char buf[64];然后strcpy(buf, input);这种祖传写法，input 在某些输入下会超过 63 个字节。当时我就想，这种问题如果在上线之前有一个静态分析工具扫一遍，几乎不可能漏掉。

其实很多所谓“线上疑难杂症”，根因往往是初始化没做、变量被重复释放、分支条件写反这一类低级问题。这些问题有个共同点：人眼很难在 review 的时候一眼看出来，尤其代码量一大，人都读麻了。但程序可以，它可以一行一行追踪变量的生命周期、数据流、控制流，把这些潜在的错误路径全部标出来给你看。

这就是静态分析存在的意义。它相当于是给你每个 commit 配了一个不知疲倦的代码审查员，不跟你聊天，不跟你扯皮，只负责把你写得最有问题的那些模式挑出来。

1.2 静态分析的能力边界：能发现什么，不能发现什么

想要用好这些工具，必须先理解它的能力边界。静态分析是在不运行代码的前提下做检查的，所以它的检查深度差别很大。轻一点的只做词法和语法解析，用正则或者 AST 去匹配危险模式；重一点的会做控制流分析、数据流分析，甚至符号执行，把每条可能的执行路径都模拟一遍。

能发现的问题一般有这么几类：

• 语法错误、编译警告级别的明显问题
• 未初始化变量、空指针解引用、释放后使用
• 数组越界、整数溢出（部分工具能检）
• 资源泄漏：文件句柄、内存、锁没有释放
• 死代码、不可达分支、多余的变量赋值
• 危险 API 使用，比如不安全的字符串函数、弱加密算法
• 代码风格和坏味道，比如过长方法、过深嵌套、重复代码

但不要指望它解决所有事情。并发竞态、分布式系统里的时序问题、业务逻辑对不对、性能瓶颈在哪，静态分析基本是无能为力的。它最多能通过文档告诉你“这段代码有锁竞争风险”，但真正什么时候出问题、为什么出问题，还是得靠动态分析、性能剖析和人的判断。

所以我的理解是，静态分析是质量保障体系里的第一道闸门，但绝不是唯一一道闸门。把它和代码评审、单元测试、集成测试摆在一起用，效果才是最好的。

2. 常见静态代码分析软件汇总：按语言和场景划分

2.1 C/C++ 项目怎么选：Cppcheck、Clang Static Analyzer、PVS-Studio、Coverity

C/C++ 因为直接操作内存，静态分析的价值最大，工具也最多。我在不同阶段用过四款，感受差别还挺明显的。

第一款是Cppcheck，开源免费，GPL 协议。它的定位是快速、轻量、覆盖面广。命令行一敲就开始扫，对中小项目非常友好。缺点是规则深度有限，宏展开和模板解析经常让它误报，检测不了特别复杂的跨函数路径问题。

第二款是Clang Static Analyzer，它是 LLVM 项目的一部分，用scan-build命令包一层编译过程就能跑。它最大的特点是做路径敏感分析，能分析出某个分支条件下变量会是什么状态，所以对空指针、内存泄漏这类问题检出率很高。但前提是你得有一套能编译通过的代码环境，而且它默认只检查 Clang 编译的代码路径，遇到复杂的 build 系统需要额外配置。

第三款是PVS-Studio，商业软件，支持 C/C++、C#、Java 等。我对它的印象是误报率控制得非常好，每条告警都附带完整的说明和示例代码，对开发者很友好。它的检测器里有一批针对嵌入式、游戏引擎场景的规则，在商业项目里是相当能打的一款。缺点是收费，价格不算便宜，小团队可能得掂量一下。

第四款是Coverity，老牌商业工具。它的分析深度和历史积累都很强，适合大规模、高复杂度代码库，很多大公司用作安全合规检测的一部分。缺点是部署和使用成本很高，不是装个包就能跑的，一般得配合专门的安全团队或者 DevOps 团队来搞。

如果让我给个非常主观的结论：个人项目和 5 人以下小团队从 Cppcheck 起步就够了；公司项目预算充足且代码质量敏感，PVS-Studio 是非常值的投资；Coverity 更适合大型组织做统一安全管控，小团队别去硬上。

2.2 Java 项目怎么选：SpotBugs、PMD、Checkstyle

Java 生态的工具属于三件套组合打法：SpotBugs、PMD、Checkstyle。

SpotBugs的前身是 FindBugs，它分析的是编译后的字节码，不是源码。这意味着它能看到一些源码层面看不到的东西，比如某个类被序列化的时候会触发什么逻辑、异常处理是不是吞掉了关键信息。它规则的 bug 类目真的很细，配合 FindSecBugs 插件还能扫出不少常见安全漏洞。缺点是因为基于字节码，必须先把代码编译好再跑，稍微有点重。

PMD是直接分析源码的，侧重代码坏味道和潜在缺陷，比如空 if 分支、重复的 catch 块、过度复杂的表达式。它自带的 CPD 模块是做复制粘贴代码检测的，这个功能我很喜欢，团队里有人复制粘贴代码改个变量名当新模块用的情况，CPD 一抓一个准。

Checkstyle不查 bug，它专注编码规范：缩进、换行、import 顺序、魔法数、注释格式、命名词典。很多人觉得它烦，觉得管得太宽，但如果你团队代码风格常年不统一，Checkstyle 是最有效的强制手段。它的问题是规则太多太细，一开始就得花功夫裁剪配置，不然团队会被琐碎告警淹没。

这三个工具我的使用组合是：Checkstyle 管风格 + PMD 管坏味道 + SpotBugs 管 bug，最后统一进 SonarQube 汇总展示。单一工具永远有盲区，组合起来才像一个完整的静态分析体系。

2.3 Python 和 JavaScript 阵营：Pylint、Flake8、Bandit、ESLint

动态类型语言的静态分析，思路跟 C/C++、Java 又不太一样，规则驱动占主流。

Python 这边最老牌的是Pylint，它既能查风格（PEP 8），也能查错误和坏味道。优点是规则巨多，能给你非常详细的告警解释；缺点是噪声很大，默认配置下跑一个新的 Django 项目，几百条告警里可能一半是风格建议，一半是真问题，你得花时间调配置文件才能把信噪比提上来。

Flake8是 pycodestyle + pyflakes 的组合，主打快和简单。pycodestyle 管风格，pyflakes 管逻辑错误，比如导入了未使用的模块、变量定义了但没用，这类问题 Flake8 查得特别快。它适合做 pre-commit 钩子，作为第一道快速检查。

Bandit是专门做安全扫描的，目标是找代码里的不安全模式，比如使用了eval、pickle加载不可信数据、弱随机数、shell=True 调用子进程等。它对普通业务代码有时候会误报，但放在安全红线规则里特别好用。

JavaScript/TypeScript 这边其实是 ESLint 的天下。ESLint 灵活到令人发指，语法规则、插件、自定义规则全都有。TypeScript 项目配一个typescript-eslint，再加上eslint-plugin-security、eslint-plugin-no-secrets这类安全插件，基本就是一个完整可用的静态检查闭环。它跟 React、Vue 等框架的结合也都很成熟，前端项目基本绕不开它。

另外提一下Mypy，它做的是类型检查，本质上也是静态分析。动态语言项目里的历史烂代码，经常是读着读着不知道变量是什么类型，Mypy 能在不运行代码的情况下推导类型并找出类型不匹配，对代码可维护性提升非常明显。我在 Python 项目里会把 Mypy 也放进静态检查套餐里。

2.4 多语言平台型工具：SonarQube、Semgrep、CodeQL

如果你不想给每个语言单独配工具，想有一个统一平台管理规则和报告，那重点看这三款。

SonarQube是一个代码质量管理平台，不只是一个分析器。它能扫描几十种语言，把规则、问题等级、技术债、复杂度、覆盖率全部汇总展示在 Web 界面上，还能在 CI 里做质量门禁。我用它的最大感受是：它把一个团队对代码质量的要求“平台化”了，你可以在一个地方看所有项目的健康度，能对“新增代码引入了多少问题”做硬性门禁控制，这对持续改进非常关键。

不过有个大坑：SonarQube 社区版虽然是免费的，但对 C/C++、C# 这些语言的核心安全规则是不开放的，你用社区版扫 C++ 项目会发现很多规则根本没有。如果你主要开发语言是 Java、Python、JavaScript，社区版非常好用；如果主力是 C++，就得认真考虑商业版，或者用其他工具补位。

Semgrep是 Morphisec 公司开源的规则引擎，核心思路是“模式匹配 + 语义化”。它不像编译器那样做完整的控制流分析，而是用类似代码片段的模式去匹配源码，但速度非常快，而且不需要编译环境。最吸引我的是自定义规则极其简单，写一个 YAML 文件就能定义“项目中不允许出现某种代码模式”，对业务团队来说，这是一个门槛低到离谱的定制化静态检查工具。

CodeQL是 GitHub 的安全实验室产品。它的思路更硬核：把代码当成数据库，通过写查询语言去找特定模式。Security Lab 团队维护了大量安全查询规则，能查 CVE 级别的漏洞模式。它主要用于安全审计和漏洞研究，普通业务团队日常用它有点杀鸡用牛刀的感觉，但如果你做的是金融、安全、基础设施这类领域，CodeQL 是值得专攻的利器。

这三款工具的定位差异也很明显，我后面会用一个表格来对比。

3. 我实测过的几款工具，具体使用感受

3.1 Cppcheck：轻量、快、误报我能接受

有一段时间我负责的是一个用 C 写的嵌入式通信模块，代码量大概在 10 万行上下，整体结构比较老，函数之间耦合严重，但编译环境特别简单，就是 GCC 加一堆 Makefile。当时我选择第一个落地的工具就是 Cppcheck。

实际使用非常简单：

cppcheck --enable=warning,style,performance --std=c99 src/

第一次跑完大概输出 400 多条警告，其中确实有分量的，比如一个memset的第三个参数写错了，导致只清了一半结构体；还有一个if (p)在 p 被释放之后才判断，属于明显的使用后释放。这两类问题如果靠 code review 发现，不知道要过多少轮才能看到。

但也有不少误报，典型场景是宏展开导致的误判。嵌入式代码里到处都是#define配置宏，Cppcheck 有时候会把宏展开后的结果分析成越界或者空指针，实际上根本不会。刚开始我一条条看告警，心态有点崩。后来仔细研究了一下，发现它支持--suppress参数和抑制配置文件，把项目里确定是误报的规则和文件名写进配置文件，下一次跑就干净多了。

我的经验是：Cppcheck 适合作为免费的基础防线，扫一轮能拦住不少低级 bug，但别指望它做深度分析。它输出的报告用cppcheck-htmlreport生成 HTML 页面很方便，可以在 CI 里作为 artifacts 保存下来，给团队每个人看。

3.2 SpotBugs 和 PMD：Java 项目的日常组合

另一个项目是维护一个老 Spring 服务，代码不多，但历史包袱重，有些模块从 2012 年加到今天，没有人敢大改。我在这项目里把 SpotBugs 和 PMD 配了一起用。

SpotBugs 给我的印象是它有很强的“问题意识”，尤其对一些非常具体、非常真实的坑非常敏感。举个例子，它曾经抓到一个类没重写equals和hashCode，但是那个类的实例被放进了HashSet。开发人员当时的逻辑是“我保证这个类不会被拿去比较”，但下一次维护的老哥把这个类塞进了一个Set做去重，行为就变得越来越诡异。SpotBugs 对这种“违反契约”的问题检测率特别高，因为它看的是字节码层面的调用关系。

PMD 给我的感觉是更“亲源码”。它直接对 Java 文件做解析，因此很多问题一目了然，例如某个catch块里吞掉了异常没有记录日志、某个循环体里创建了本可以提到外面的对象、两段代码的长度和结构高度相似。它那个 CPD 模块是我个人最依赖的功能，跑一次能找出十几处复制粘贴的代码，我拿这个列表去跟业务方聊代码重构，说服力很强。

不过它们两个一起跑有个问题：告警重复。同一个场景，PMD 报“方法过长”，SonarQube 再报一次类似规则，SpotBugs 又报一次。这就需要一个统一的平台去汇总和去重，而不是让开发者去三个工具页面里对账。

3.3 SonarQube：质量门禁的真正落地

我很早就听说过 SonarQube，但真正动手部署是在一个有 6 个后端项目、3 个前端项目的团队里。当时选的是社区版 9.x，部署在一台 8G 内存的服务器上，用 Docker Compose 一套就能起来。

第一次扫描完，打开 Web 控制台的那一刻，我意识到静态分析以前只是“在跑”，而 SonarQube 把它变成了“在管”。它把所有项目的问题统一展示出来，按严重等级排布，还能看到技术债的估算值，甚至能看单个文件圈复杂度。更重要的是 Quality Gate 质量门禁功能：配置一条规则，比如“新增代码不允许引入任何 Blocker 或 Critical 级别的问题”，然后在 CI 里把分析结果推过来，门禁不过就不允许合并代码。这相当于把静态分析从“建议”变成了“规定”。

但我必须吐槽社区版的限制。我之前以为 SonarQube 支持 C/C++，是全面支持，结果用的时候才发现，社区版里 C++ 的分析规则非常薄，很多核心安全规则只存在于商业版。我的嵌入式项目如果想用 SonarQube 统一管理，就得付费。所以后来我的方案是：Java/Python/JS 项目统一进 SonarQube，C/C++ 项目继续用 Cppcheck 加自己维护的规则，两条线并行。

配置 SonarQube 也需要有点耐心。扫描器那块要设置sonar.host.url、sonar.projectKey、sonar.sources，在 CI 里还要跑sonar-scanner，首次接入的配置成本不低。但这些配置一次搞定之后收益非常稳定，尤其对需要做团队质量度量的场景，SonarQube 是唯一能给你持续趋势图的工具。

3.4 Semgrep：自定义规则是真香

Semgrep 是我最近两年用得越来越频繁的工具，因为它的“自定义规则”能力实在太舒服了。

举个例子，前阵子我们团队引了一个内部加密库，文档里明确要求从某个版本开始禁止使用旧接口encrypt_v1()，必须切换到encrypt_v2()。这种事情靠 code review 根本盯不住，旧写法在几十个模块里都有。我在 Semgrep 里写了一个 30 行的 YAML 规则：

rules: - id: no-encrypt-v1 languages: [python] message: | encrypt_v1 已废弃，请使用 encrypt_v2。 severity: ERROR patterns: - pattern: encrypt_v1($ARGS)

跑一次全仓库，几百个文件几秒钟扫完，所有旧接口调用全部列出来。这种针对业务规则的检查，用传统静态工具得翻规则库找有没有对应规则，大概率找不到；用 Semgrep 就是分分钟的事。

Semgrep 的另一个好处是不需要编译，拿过来源码就能跑，所以和 CI 集成非常轻。缺点是深度有限，它做的是语法层面的模式匹配，不做完整的路径分析。如果一个漏洞需要跨函数追踪数据流，Semgrep 会明显不如 CodeQL 这类工具。但它和传统工具不冲突，反而可以互补。

4. 把这些工具接入 CI 的实操过程

4.1 接入前要做的准备

很多人一上来就把工具装好，然后直接对全量代码跑一遍，接着就傻眼了：几千条告警，谁去改？改不完，最后结果就是“工具装了，但没人看”。我在团队里踩过这个坑之后，总结了一套相对靠谱的接入步骤。

第一步，先明确目标和范围。你是想拦 bug，还是想统一风格，还是想做安全合规？目标不一样，工具和规则配置完全不一样。想拦 bug 就把 Alert Level 高的规则打开，风格规则先全关；想统一风格就反过来。

第二步，先离线跑一次全量代码，生成问题清单。这步不是让你立刻改，而是用来评估现有代码的“欠债水平”，顺便统计误报率。误报率超过一个阈值（比如三成以上），这个工具的规则就得先裁剪，不然团队会被噪声折腾到放弃。

第三步，设定增量检查策略。历史债务一口吃不成胖子，最好的做法是：只检查本次提交新增或修改的代码，而不是全量检查。SonarQube 天然支持新代码 vs 旧代码的区分；命令行工具的话，可以通过 Git diff 拿到变更文件列表，再传给检查工具，或者用增量模式。

4.2 一个可以抄作业的 GitLab CI 示例

以一个 C 项目接 Cppcheck 为例，我在 GitLab CI 里的最小配置长这样：

static-analysis: stage: test script: - cppcheck --enable=warning,performance --std=c99 --xml --xml-version=2 src/ 2> cppcheck.xml - cppcheck-htmlreport --file=cppcheck.xml --report-dir=reports --title="MyProject" artifacts: paths: - reports/ when: always

这段配置的套路是：跑分析，结果以 XML 形式输出，再用cppcheck-htmlreport生成 HTML 报告，最后作为 CI artifacts 保存下来，开发者可以直接在流水线页面点开看。when: always保证即使告警数量很多导致命令返回非零，报告也还是会保留下来。

如果要在新增告警数量上做门禁，可以在脚本后面再加一段逻辑：统计本次 XML 里的告警数，和上次基线做 diff，超过阈值就让流水线失败。这类脚本不复杂，但很有价值——它让团队既能保留历史问题跟踪记录，又不会因为存量问题堵住所有人的合入流程。

Java 项目接 SonarQube 则是另一种套路，用sonar-scanner跑完执行sonarqube-quality-gate阶段，质量门禁的状态会直接决定流水线是否通过。前端项目则可以在package.json里加一个lint脚本，CI 里跑npm run lint -- --max-warnings=0。

4.3 处理误报的系统性方法

误报是每个静态分析工具都躲不开的话题。我见过最极端的情况是，一个工具某条规则在一个项目里的误报率超过 70%，开发者点开告警一看全是例子错误，然后整个工具被拉黑。所以处理误报不能靠人肉一条条判断，要系统化。

第一步，建立基线。第一次跑完整扫描之后，把告警全量导出，人工快速过一遍，把确定要修的挑出来，确定不修的从报告里过滤掉。这个过滤结果就是一个基线文件，后续扫描默认不显示这些历史问题。

第二步，对剩余告警按严重级别排序。Blocker 和 Critical 级别的必须修，Major 级别的排期修，Minor 级别的记录在案。千万不要一口气全改，否则不仅工作量爆炸，还容易改出新 bug。

第三步，对确实不可能修的误报，用工具提供的抑制机制，在代码里留一个可以追溯的标记。比如 SonarQube 是// NOSONAR注释，Cppcheck 是// cppcheck-suppress rule_name，ESLint 是// eslint-disable-next-line。这些标记一定要带上注释说明为什么忽略，否则以后回头看完全不知道当初是怎么想的。

第四步，在 CI 门禁里只卡新增问题。存量问题进“遗留水池”，新引入的问题必须当场解决。这样既能保持代码质量持续上升，又不会因为历史债务阻碍日常开发。

5. 选型建议和踩坑记录

5.1 没有最好的工具，只有最匹配的场景

如果让我重新选择一套静态分析组合，我会这么定：

• 个人项目或者极小的团队，单语言场景，直接选该语言社区最主流的那一个就够了。C/C++ 选 Cppcheck，Java 选 PMD，Python 选 Flake8 加 Bandit，前端选 ESLint。
• 企业级 Java/Python/JS 技术栈，直接上 SonarQube 社区版，配合各语言各自的工具作为补充，SonarQube 统一做质量门禁和趋势管理。
• 对安全性要求很高的领域，比如金融、医疗、安全工具开发，加一个 Semgrep，自定义规则盯住业务侧的高风险模式；预算够再考虑 CodeQL 或者商业工具。
• C/C++ 场景且代码质量要求极高，建议认真评估 PVS-Studio。它的检测深度和误报控制确实值那个钱，很多在《JetBrains 开发者报告》和各大安全会议上被公开的 bug 案例，就是 PVS-Studio 团队从开源项目里翻出来的。

下面这个表格是我个人对各工具的核心印象：

5.2 我踩过的几个坑

第一个坑是全量开规则。我在一个 Python 项目里用 Pylint 的时候，想着一句话“全开规则扫得全面”，直接把所有规则启用，结果第一次跑回来 3000 多条告警，其中至少一半是风格建议，一半是重复问题。团队成员开了个会讨论花两周去清理，最后还是放弃了。后来我把规则裁剪到以 error、fatal 和几个关键 warning 为主，才慢慢有人愿意看告警。

第二个坑是没建基线就在 CI 里全量禁止。当时我直接给 C 项目配了流水线，规定“只要有告警就构建失败”。因为存量代码问题太多，流水线一天到晚是红的，大家从最开始还点开看看，到后面已经无视了，等于没配。后来改成“只卡新增问题”，流水线才恢复稳定。这里的关键是别让 CV（持续集成）变成“日常红”。

第三个坑是 SonarQube 社区版对 C++ 规则支持的误解。我已经踩过一次了，现在分享出来，希望大家少走弯路：社区版对 Java、Python、JS/TS 支持非常完整，但对 C/C++、C# 等语言，它只开放有限规则，而且一些核心安全规则只能在商业版里解锁。如果团队主力语言是 C++，用社区版 SonarQube 会非常难受，测出来问题少并不是因为代码好，而是因为它根本没查多少东西。

第四个坑是工具告警简单相加，没有去重。不同的工具针对同一个代码问题，告警表述完全不一样，比如“空指针可能被解引用”“变量可能为空”“Potential null pointer access”，实际上是在描述同一件事。如果直接把所有工具告警数量加起来做统计，成本被虚高，团队很容易失去信心。正确做法是选一个主平台汇总，人工去重，或者只针对某个工具做门禁。

5.3 一些实践心得

经过这些年反复折腾，我对静态分析这件事的认知也在慢慢变化。它不是一个“装了就完事”的东西，而是一个需要持续运营的工程实践。规则不是越多越好，而是越适合越好；工具不是越贵越好，而是越能被团队接受越好。

我会建议团队每周看一眼静态分析的趋势图，关注两个指标：新增问题数量和存量问题消减速度。新增问题数量持续下降，说明开发人员在变好；存量问题在减少，说明团队在还技术债。这两个指标一个管增量一个管存量，结合起来看，代码质量是在往上走还是原地踏步，一目了然。

另外，静态分析报告一定要和项目管理打通。我见过很多公司工具选得很好，但告警结果只是放在一个没人访问的服务器上，开发人员根本不去看。现在很多团队会直接把静态分析结果作为 MR/PR 的评论自动贴出来，开发者在合并代码页面就能看到哪里有问题，改完再推一版，评论自动更新。这种反馈闭环，才是静态分析真正产生价值的地方。

还有一点值得提一下：静态分析规则也要“玩出花”。不要只依赖工具自带的规则库，可以根据自己的历史故障、线上事故、Review 高频问题，自己写一批定制规则。以 Semgrep 为例，你完全可以把团队踩过的十个坑变成十条规则，让工具替你再踩一次。这类规则的价值往往是商业工具自带规则库都比不上的，因为那是你自己代码库的真实伤痕。

我现在的习惯是：新项目从第一天就接上静态分析，不管项目多小、多简单。因为一旦项目代码量涨起来再补，历史债务会让人完全没有动力去改。一开始就保持告警为零，之后每条新告警都会被重视。这比“攒了一堆再清理”要轻松太多。

如果让我给还没上静态分析的人一个最接地气的起点，我会说：先别急着把工具全家桶都装起来，挑一个能跑通最小闭环的——比如你的主力语言挑一款命令行工具，加进 CI 里，以新增问题数来卡门禁。跑一个月之后，你会发现很多低级 bug 真的在下游就消失不见了。等团队习惯了，再慢慢往里面加规则、加工具。我自己的团队到现在也才稳定在五六个工具的组合，够用、可控，比什么都重要。