企业官网建设流程全解析

1. 先说结论：静态分析到底解决了什么痛点

我在不少团队里待过，发现一个很有意思的现象：代码评审会议上，大家最常吵的问题往往不是"这个功能怎么设计"，而是"这个变量怎么命名""这里为什么不判空""这个写法会不会出 bug"。这类问题占据了评审大量时间，但真正资深的工程师会告诉你，其中相当一部分本该在代码提交之前就被机器拦下来。

静态代码分析（Static Code Analysis）就是干这件事的——不运行代码，只通过词法、语法、数据流和控制流分析，在代码编写阶段就把潜在缺陷、安全漏洞、坏味道找出来。我自己的体感是，一套配置合理的静态分析流水线，至少能减少三成以上的低级 review 意见，让评审会议的讨论重心真正回到架构和业务逻辑上。

这篇东西不是工具文档的翻译，也不是把官网介绍抄一遍。我挑了几个真实在生产环境用过的工具，从选型思路、接入方式、误报处理到 CI 集成逐个聊，最后给出适合不同团队的搭配建议。如果你想引入静态分析但不知道从哪下手，或者已经用了但被误报搞得想砸键盘，这篇应该对你有用。

2. 工具全景：不同语言、不同规模的选型基准

静态分析这个赛道非常拥挤，几乎每种主流语言都有对应的工具，而且商业产品和开源产品之间的边界也越来越模糊。先把地图画清楚，后面聊感受才不会晕。

2.1 按语言和场景划分的主流工具

Java 方向：老牌的有 SpotBugs（前身是 FindBugs）、PMD、Checkstyle。Checkstyle 管风格，PMD 管坏味道和潜在缺陷，SpotBugs 专注字节码层面的 bug 模式检测。三者定位互补，很多 Java 团队是三个一起上。商业方案里有 Fortify 和 Veracode，主要面向安全合规。

JavaScript / TypeScript 方向：ESLint 基本是事实标准，配合 typescript-eslint 可以同时处理 TS 的规则检查。更严格的场景还有 SonarJS 插件，或者用 CodeQL 做深度的数据流分析。

Python 方向：老一代是 Pylint + Flake8 + Bandit（安全专用），新一代基本都往 Ruff 上收敛——它把 linter、formatter、import 排序全部集成到一个 Rust 写的二进制里，速度快得离谱。

C/C++ 方向：开源首选 Cppcheck，商业有 Coverity、PVS-Studio。这个方向难度最大，因为指针、内存管理带来的数据流分析复杂度远超托管语言。

跨语言平台型：SonarQube 是最典型的代表，支持几十种语言，提供统一的规则库、趋势图和质量门禁。GitHub 家的 CodeQL 则是另一个思路，用类似查询的语言（QL）描述缺陷模式，能做非常深的跨过程数据流分析。Semgrep 走的是轻量路线，规则用 YAML 写，模式匹配为主，胜在灵活。

这里多说一句，CodeQL 和 Semgrep 的定位差异值得理解。CodeQL 把整个代码库当成数据库来查，能追踪"用户输入从哪里进来，有没有经过危险函数"这种跨文件的污点传播，力量很强但学习成本高。Semgrep 则是局部模式匹配，写规则像写正则一样简单，适合团队自己定制团队的专属规范。两者的关系不是替代，而是互补。

2.2 开源和商业工具的差距到底在哪

很多人有个误区，觉得商业工具一定比开源工具强。以我用过的经验看，差距不在"能不能发现问题"，而在三个层面：

第一是误报率调教。Coverity 这类商业工具背后有大量真实项目的训练数据，规则内置的抑制条件更精细，开箱即用的误报率比开源工具低不少。而开源工具通常需要团队自己花时间调规则、配豁免，才能达到可接受的噪音水平。

第二是深度分析能力。商业工具在跨过程分析、路径敏感分析上的资源投入更大，对深层逻辑缺陷的检出率确实更高。比如 Coverity 能发现一些只有在特定执行路径组合下才会出现的引用空指针，这种级别的问题靠开源的 SpotBugs 是基本抓不到的。

第三是合规报表。安全合规驱动的大厂，需要生成格式化的审计报告，需要和威胁管理流程联动，这是商业工具的强项。开源工具虽然也能出报表，但要对接企业的安全运营体系，得做不少二次开发。

但对大多数中小团队来说，开源工具已经足够了。别为了"上先进工具"而付费，先想清楚你的核心诉求是质量还是合规。

2.3 快速选型对照表

我整理了一个在当前时间点比较靠谱的选型参考，按团队主要技术栈来分：

这个表里我特别想强调一点：工具不是越贵越好，也不是装得越多越好。工具引入的边际收益会递减，第二个工具带来的增量发现率通常远低于第一个。先把手头最主力的语言用好，比到处撒网更重要。

3. 逐个聊聊我真实上手过的工具感受

这节是全文最重的部分，全部是实际使用过程中的体感，包括让我觉得"值了"的地方，也包括让我想骂人的地方。

3.1 SonarQube：项目级的体检中心

SonarQube 是我在多个团队里都坚持引入的第一个静态分析平台。它不只是一个 linter，而是一套完整的质量管理体系。核心组件是服务端 + 各种语言的扫描器，扫描结果上传后在 Web 界面统一展示。

先说让我觉得值的地方。第一是质量门禁（Quality Gate），这是 Sonar 最核心的概念。你可以定义"新增代码的缺陷密度不能超过 X""阻塞级别问题必须为零"这样的阈值，合并请求接入后，门禁不通过就不能合入。这个硬性卡点比任何口头强调都管用，因为它把质量要求转成了开发流程的一部分。

第二是增量分析。Sonar 能基于基线（Branch）做差量计算，只检查新增和修改的代码，不会因为历史存量问题把新人吓跑。刚接入老项目时这个特性尤其重要——存量问题列表可以放在"技术债务"里慢慢还，但不阻碍新代码合入。

第三是规则生态。Sonar 内置了几百条规则，而且按"Bug""Vulnerability""Code Smell""Security Hotspot"分类，每种问题都有清晰的描述、示例代码和修复建议。它对 Java、Python、JS 等主流语言的覆盖深度在开源界是第一梯队。

再说让我纠结的地方。SonarQube 社区版（免费版）有一个挺大的限制：它只支持"一个项目一个分支"的分析，PR 级别的集成和分支策略需要开发者版（付费）才有。对用 Git Flow 的团队，这几乎等于逼你付费。另外社区版的规则热更新不如商业版频繁——商业版的"SonarSource 安全引擎"会持续推送新规则，社区版只能用到发布包自带的那些。

部署方面，社区版支持 Docker 方式，一个docker-compose就能拉起来，配一个 PostgreSQL 数据库即可。我这里给一个最小可用的编排思路：

services: sonarqube: image: sonarqube:lts-community ports: - "9000:9000" environment: - SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonar - SONAR_JDBC_USERNAME=sonar - SONAR_JDBC_PASSWORD=sonar depends_on: - db db: image: postgres:13 environment: - POSTGRES_USER=sonar - POSTGRES_PASSWORD=sonar - POSTGRES_DB=sonar

启动之后浏览器访问 9000 端口，默认管理员账号是admin/admin，第一次登录会强制改密码。然后新建项目，按提示生成一个 Token，在扫描器端配置sonar.login和sonar.host.url就能把分析结果推上去了。

实际使用的关键心得：Sonar 的价值要真正发挥出来，必须把"门禁"用起来，而不是只当报表看。我见过太多团队把 Sonar 部署完就扔在一边，偶尔想起来看一眼分数。这样和没装没区别。正确的姿势是接入 CI，合并请求不达标直接拦下。

3.2 ESLint：前端工程化的第一道闸门

前端圈的静态分析几乎被 ESLint 一家通吃。它的成功不是因为功能最多，而是因为可扩展性极强——所有规则都是插件，所有配置都是可覆盖的，生态里已经沉淀出eslint-config-airbnb、eslint-config-standard、eslint-config-alloy等一批高质量预设。

我个人的习惯是：新项目直接基于typescript-eslint的 recommended 配置起步，再叠加eslint-plugin-react-hooks和eslint-plugin-import的推荐规则，不做过多定制。react-hooks 插件里的exhaustive-deps规则值得单独说一句——它检查 useEffect 的依赖数组是否完整，能把"闭包捕获过期变量"这类非常隐蔽的状态 bug 直接挡在提交之前。这个规则我建议永远开着。

ESLint 的一个使用误区是把它当格式工具。其实格式化是 Prettier 的活，ESLint 应该专注在代码正确性和反模式上。很多团队为了让 ESLint 接管格式，配了一堆indent、quotes之类的排版规则，结果和 Prettier 冲突，互相打架。正确分工是：Prettier 管格式，ESLint 管质量，两者用eslint-config-prettier关掉 ESLint 里的格式规则。

再提一个前端特有的问题：规则降级。ESLint 的错误级别有error和warn两种，但我不建议用warn。因为大多数 CI 脚本只对error级非零退出，warn太多会让输出变成一堵墙，真正的错误反而被淹没。宁可少开规则，开了就error。

命令行接入很简单：

eslint src/ --ext .ts,.tsx --max-warnings=0

--max-warnings=0这个参数强烈建议加上，它能把警告数量清零作为硬性要求，强迫团队认真对待每一条提示。

3.3 Pylint 与 Ruff：Python 圈的新老交替

Python 静态分析的传统三件套是 Pylint、Flake8 和 Black。Pylint 规则最全但速度最慢，Flake8 轻量但扩展依赖一堆插件，Black 管格式化。这里重点聊聊新一代的 Ruff。

Ruff 是 Astral 公司用 Rust 写的 Python linter/formatter，号称比 Pylint 快 10 到 100 倍。我第一次跑的时候确实被惊到了——一个几万行的项目，Pylint 要跑十几秒，Ruff 基本是秒出结果。它不只是快，还内置了超过 800 条规则，覆盖了 Flake8 及其大部分生态插件、Pyflakes、pycodestyle、甚至一部分 Pylint 的规则。也就是说，以前要装五六个包才能凑齐的能力，现在一个 Ruff 全搞定。

Ruff 的配置写在pyproject.toml里，非常简洁。一个我在生产环境用过的基线配置：

[tool.ruff] line-length = 100 target-version = "py311" [tool.ruff.lint] select = ["E", "F", "W", "I", "N", "UP", "B", "A", "S", "C4"] ignore = ["S101"] # 允许 assert 用于测试

这里每个字母代表一类规则：E/W是 pycodestyle 的错误和警告，F是 Pyflakes 的逻辑错误，I是 import 排序，UP是升级语法到新版本建议，B是 bugbear 的潜在 bug 检查，A是内置变量遮蔽检查，S是 Bandit 的安全检查，C4是组合写法简化建议。这套组合对常规项目的覆盖已经相当全面。

Ruff 还有几个特性值得单独夸。第一是--fix自动修复，很多规则（import 排序、无用的变量、旧式类型注释）可以一键修掉，开发者不需要手动改。第二是它内置了ruff format，兼容 Black 的格式风格，彻底解决"用 Black 还是用 autopep8"的争论。第三是 pre-commit 集成特别顺滑：

- repo: https://github.com/charliermarsh/ruff-pre-commit rev: v0.6.9 hooks: - id: ruff args: [--fix, --exit-non-zero-on-fix] - id: ruff-format

我说到这儿不是劝你立刻把所有项目迁到 Ruff。如果你的存量项目已经配置好 Pylint 并且规则跑得很稳，迁移其实有一个成本点：Pylint 的某些高级规则（比如各类代码复杂度计算）在 Ruff 里还没有完全实现。但从新项目的角度，我会毫不犹豫选 Ruff。

至于 Bandit，它专注的是 Python 安全问题的模式匹配，比如硬编码密码、SQL 注入、assert用于安全检查等。它的规则集和 Pylint 几乎不重叠，建议和 Ruff 一起使用，但不要在 CI 里卡得太死——Bandit 的误报率偏高，尤其是文件路径处理这类场景，需要花时间维护豁免清单。

3.4 SpotBugs：Java 老项目的"考古"工具

SpotBugs 是 FindBugs 的继任者，通过分析 Java 字节码来检测 bug 模式。它的定位和 PMD、Checkstyle 完全不同——那些是基于源码的分析，SpotBugs 是在编译后的 class 文件上做分析，所以能发现一些源码层面看不出来的问题，比如序列化相关的隐患、equals/hashCode不一致、资源没有正确关闭等。

给老项目接 SpotBugs 是一件痛并快乐的事。快乐的是它确实能翻出很多陈年隐患，我接过一个维护了七八年的支付系统，第一轮扫描找到了二十多处资源泄漏风险，其中有两处是真实会发生的：一个是在异常分支里没有正确关闭数据库连接，一个是缓存写入失败后被静默吞掉。这些 bug 在线上潜伏了数年，靠 code review 根本发现不了，靠测试也不一定能触发。

痛的是存量问题太多了。老项目第一次跑 SpotBugs，几百个告警是常态，如果全量清零会让团队陷入漫长的"改老代码"泥潭，而且改动老代码本身有回归风险。我的做法是把存量问题打上@SuppressFBWarnings注解或者配置到 exclude 文件里，然后从增量代码开始要求零新增问题。等新代码质量稳定了，再安排专门迭代还技术债。

SpotBugs 的规则也是分级别的，从最严格的Rank 1到Rank 20。建议只把Rank 1-4的规则在 CI 里设为阻断，其他级别保留提示但不阻塞。我踩过的坑是某次把Rank 9的"装箱拆箱性能提示"也设成阻断，结果团队提交一次代码要被警告打断四次，群情激愤，最后只保留了两天就回滚了。性能提示类规则适合当建议，不适合当门禁，因为它们的置信度远低于正确性规则。

配套使用的话，PMD 负责源码层的坏味道和复杂度检测。它内置的CyclomaticComplexity（圈复杂度）规则非常有用，我会把阈值设成 10，超过就报警。圈复杂度超过 10 的函数几乎必然需要拆分，这不是教条，是经验——高复杂度的函数测试难写、改动易错、review 也看不懂。Checkstyle 则纯粹管风格，import 顺序、行长度、命名规范，这些用 IDE 的格式化插件基本能自动解决，Checkstyle 更多是兜底。

3.5 Semgrep：可自定义规则的轻骑兵

如果说 Sonar 是体检中心，那 Semgrep 就是一把手术刀——它最大的价值在于团队可以自己写规则。Semgrep 的规则用 YAML 描述，继承了灵活的 pattern 匹配语法，可以在不运行代码的情况下做一些"看起来需要人为判断"的检查。

举一个实际例子。我们团队规定日期处理必须统一走自研的日期工具类，不允许直接new SimpleDateFormat()。这种规范用 eslint 或 sonar 的重度规则很难表达，但 Semgrep 可以轻松做到：

rules: - id: no-simpledateformat pattern: new SimpleDateFormat(...) message: 请使用 DateUtils 代替 SimpleDateFormat languages: [java] severity: ERROR

工作流简化到：先在本地跑规则，通过后推到仓库里的规则目录，CI 自动检测。整个上手周期不到半天，一个普通后端工程师就能掌握。

Semgrep 还有一个免费注册的公共规则库 Semgrep Registry，里面有大量安全团队维护的现成规则，比如各种 OWASP Top 10 的模式。你可以用--config=auto一键启用，也可以把 Registry 的规则拉下来和自研规则合并使用。对于安全人力紧张的小团队，这几乎是零成本获得安全扫描能力的最佳路径。

不过 Semgrep 也有明确的边界。它本质是模式匹配+有限的数据流分析，遇到需要精确路径判断、复杂对象图分析的场景（比如"这个对象在某个分支被赋了 null，后面又在另一个分支被解引用"），它的准确率不如 CodeQL 或 Coverity。所以我的定位是：Semgrep 做团队规范和安全模式的快速落地，重型缺陷检测交给 Sonar 或 CodeQL。

4. 接入 CI 的完整落地过程和踩坑记录

工具选得再好，接不进流程等于摆设。这一节讲我在多个团队里总结出的落地方案和踩过的坑。

4.1 增量扫描还是全量扫描：必须提前想清楚

接入 CI 后第一个要做的决策是增量还是全量。我强烈建议默认增量，定期全量。

增量扫描只检查本次改动涉及的代码，速度快、反馈及时，适合挂在合并请求上作为硬性门禁。全量扫描所有代码，适合在主干分支上定时跑（比如每天夜间），用于追踪整个项目的技术债趋势。

两个方案都有对应工具支持。SonarQube 天然支持增量分析（基于与基线的差异计算）；ESLint 和 Ruff 本身不做增量，但可以通过只扫描变更文件的脚本实现；Semgrep 同样只针对传入的文件集。这里分享一个在 GitLab CI 里筛选变更文件的通用思路：

CHANGED_FILES=$(git diff --name-only --diff-filter=ACMRT "${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-main}"...HEAD | grep '\.py$' || true) if [ -n "$CHANGED_FILES" ]; then ruff check $CHANGED_FILES fi

注意--diff-filter这个参数，它限制只保留新增、修改、重命名等类型的文件，过滤掉删除的文件——否则删除文件后扫描一个不存在的文件会报错。这是我实际踩过的坑。

4.2 误报处理：建立规则豁免的可见化机制

静态分析落地最大的阻力不是技术，而是"狼来了"效应——如果工具产生大量误报，开发者就会形成习惯性忽略，真正的问题也会被淹没。所以误报处理是接入过程中最需要投入精力的环节。

我的流程是三步走：

第一步，基线期。刚接入时先跑一次全量扫描，记录当前的问题数据作为基线，不做清零要求。这个基线同时也是后续衡量改进的起点。

第二步，分类期。把基线里的问题按规则维度聚合，找出高频误报的规则。比如 ESLint 的no-non-null-assertion在业务代码里误报率很高，因为 TypeScript 的非空断言在一些场景下是合理写法。这类规则的处理方式是：要么调低级别，要么在配置里加exclude白名单，要么允许在代码里用// eslint-disable-next-line显式豁免。

第三步，管控期。把白名单做成显式配置，并且定期 review 白名单的合理性。这里有一个容易被忽略的点：被豁免的规则应该有"过期时间"的概念。我们的做法是在配置里给每条豁免加注释说明原因和 review 日期，每个季度清理一次白名单，防止白名单无限膨胀。

下面是我对误报率管理的经验值：

误报率超过 50% 的规则，建议直接关掉或降低级别，因为它的信噪比太低，对团队注意力是净消耗。

4.3 扫描速度优化和资源占用控制

静态分析在大型项目上有个现实问题：慢。Sonar 全量扫描一个百万行级别的 Java 项目，跑 20 分钟是常态；CodeQL 的构建甚至能跑到 40 分钟以上。这个速度对合并请求级别的快速反馈是致命的。

我的优化思路按优先级排列：

第一，缓存增量构建。CI 里把依赖缓存和编译产物缓存做好，能让扫描的基准时间大幅缩短。比如 Sonar 的sonar.java.binaries指向的编译产物目录如果命中缓存，能跳过重新编译过程。Semgrep 也有--cache参数，做模式解析的缓存。

第二，拆分任务。把全量扫描和增量扫描拆成两个独立流程。增量流程挂合并请求，几十秒内出结果，只报告本次改动引入的问题；全量流程挂夜间定时任务，做完整的技术债快照。这样不影响开发速度，还能持续跟踪全项目质量趋势。

第三，资源控制。Sonar 扫描器的默认 JVM 堆内存偏小，大项目容易 OOM。通常我会显式设置：

export SONAR_SCANNER_OPTS="-Xmx4g -Xms1g"

CodeQL 则建议在配置文件里限制maxRam，避免把 CI 机器的内存吃满影响其他任务。

还有一个很多人不知道的细节：Sonar 扫描器的 CPU 线程数默认是机器核数，在共享 CI 机器上最好手动限制，比如-Dsonar.scanner.internal.externalAnalyzers.responsive=true和 CPU 相关的配置，否则一次扫描能把机器搞到"假死"状态，其他并行任务全被拖垮。

5. 把静态分析用好的几个关键习惯

工具只是开始，真正的差异在于使用方式。这里总结我在多个团队里验证过的经验，也是踩坑踩出来的教训。

5.1 规则必须按团队情况裁剪，不能照搬默认

很多团队接静态分析的第一个动作是打开所有默认规则，然后被铺天盖地的告警淹没。这是一个经典错误。默认规则集往往追求通用覆盖，对具体团队的需求来说，要么过严要么过松。

正确的做法是：从推荐配置起步，然后花一到两个迭代周期基于真实告警数据做规则裁剪。先跑一轮扫描，统计哪些规则高频触发、哪些是误报、哪些和团队编码规范冲突，然后逐条调整。这个过程需要有经验的工程师主导，不能交给新人直接开开关关。

以 Python 的 Ruff 为例，推荐配置里E501（行长度）这条规则我们通常会关掉，因为团队已经统一用line-length = 100的 formatter，再用 linter 报行长度就是重复劳动。而B006（可变默认参数）这类规则虽然触发频率低，但一旦触发就是真 bug，必须保持 error 级别。这种"按命中率和危害度分类治理"的思路，适用于所有工具。

5.2 让开发者处理自己刚引入的问题，而不是一次性清理存量

这是我反复强调的一个原则：静态分析的反馈要快，且要落在"引入问题的人"身上。合并请求里新增代码引入的告警，必须在合入前清零；存量代码的历史告警，不要在新需求里混着改。

原因很简单：存量问题通常牵扯复杂的上下文，改起来风险高，而且容易和当前需求产生代码冲突。新引入的问题则上下文简单，修改成本低，让开发者当场改掉是最顺畅的流程。这个"增量守恒"策略能让代码库的质量只升不降，而不是陷入"清理存量-产生新的-又清理"的循环。

实际推行时，可以用 CI 门禁配合团队约定来保证：合并请求里出现新增阻塞级问题，流水线直接红色；出现存量问题，只提示不阻断。这样开发者的"抗性"会小很多，因为他们不需要为历史债负责。

5.3 不要迷信工具分数，分数是过程指标不是目标

SonarQube 会给项目打一个"可靠性分数"和"可维护性分数"，很多管理层非常喜欢看这个数字。我见过有团队为了让分数从 A 提到 A+，把大量规则调低甚至关闭，或者写一堆讨巧但没意义的代码来满足复杂度规则。这是典型的"指标绑架"。

我的态度是：质量分数是团队内部的自省工具，不应该作为 KPI 或对外招牌。它真正的价值在于趋势——这周比上周多了几个问题，这个迭代比上个迭代减少了多少技术债，这些趋势能指导团队做持续改进。至于绝对分数，能反映一定问题但别把它当圣旨，因为不同项目的历史包袱不同，拿一个刚起步的微服务和维护十年的核心系统比分数毫无意义。

更值得关注的是问题修复时间。Sonar 里有一个指标叫"问题平均存续期"，我们团队会定期回顾这个指标。如果一个问题从引入到修复平均超过两周，说明流程上有漏洞——要么是 CI 门禁没生效，要么是团队没有及时处理。这个指标比单纯的分数更能反映流程健康度。

6. 最后说点实在的：我的选型建议与心态

我把话收一收，给不同阶段的团队一个可以直接抄的作业。

小团队、起步阶段：先上轻量级方案。前端项目就 ESLint，Python 项目就 Ruff，Java 项目就 SpotBugs + PMD，不急着搭 SonarQube 平台。在 CI 里跑起来，把全量告警控制在个位数以内，先养成"提交前跑一遍"的习惯。

中大型团队、有专职效能人员：上 SonarQube 平台，配上增量门禁和 PB级质量趋势看板。语言侧的工具继续保留，Sonar 作为统一入口。新增代码的问题密度作为硬性门禁，存量技术债用专项迭代慢慢还。

安全敏感场景（金融、医疗、政企）：在 Sonar 基础上叠加 Semgrep（做自定义安全规则）和商业化安全扫描工具之一（做合规报表）。这个组合覆盖了团队规范、通用安全模式、深层次漏洞三个层次。

选型前先问问自己：你是想提高代码质量，还是想通过安全审计？这两个诉求对应的工具组合差异很大，别一上来就堆工具。

至于心态，有句话我想送给每个准备引入静态分析的人：静态分析工具不是银弹，它是脚手架。它不会让你的代码自动变好，但它能让"坏"的代价变得更小、更早暴露。真正决定代码质量的，永远是人——工具的规则谁来维护、误报谁来清理、门禁谁来执行，这些都需要团队有质量意识的人持续投入。

我自己的经历是：第一次在团队里推行 Sonar 门禁时，被吐槽"流程太严""工具不懂业务"，推行了一个月，大家慢慢发现合并请求里的低级错误少了，评审会议短了，线上故障也少了。到现在，团队里最反感"被工具管着"的那位老哥，反而是最坚持门禁不能关的人。工具的价值，往往是在实践之后才被真正认可的。

如果你也在准备引入静态分析，我的建议是从一个模块、一条规则开始，跑通流程后逐步放大。别追求一步到位，静态分析是一场持久战，细水长流才是常态。