Android Studio Inspection位置全解析：从菜单到结果面板

1. 找过的人都有这种感觉：inspection 不止一个“位置”

很多人在群里问“android studio inspection位置”，其实问的是完全不一样的三件事：有人要的是“运行代码检查”的菜单入口，有人要找的是“检查规则设置”那一整页选项，还有人已经在跑检查，但结果窗口死活不出来。这三个位置在 Android Studio 里对应三个不同的地方，如果一把抓地到处翻菜单，很容易越翻越乱。

先搞清楚 inspection 是什么，再谈位置会更好理解。inspection 在 Android Studio 里不是单个按钮，而是一整套静态代码扫描机制。它不需要编译和运行，直接扫源码就能发现潜在问题，比如空指针风险、资源引用错误、线程操作不当、代码风格异味等等。Android Studio 默认内置了几百条检查规则，覆盖 Kotlin、Java、XML、Gradle、Android 特有 API 等领域。编辑区右侧边距那些红黄小方块，其实就是在实时运行的 inspection。

编辑器内的小标记只是冰山一角，真正的集中入口体现在两个地方：一个叫“Inspect Code”（检查代码）的命令入口，一个叫“Inspections”（检查规则组）的设置页面。这俩一个负责“跑一遍”，一个负责“管规则”，位置完全不同。下面我从头把这两个东西和其他相关位置挨个拆开讲。

1.1 主菜单里找命令：也许在 Analyze，也许在 Code

如果你找的入口是“运行一次检查”的命令，这就要看版本了。早几年的 Android Studio 顶部菜单里有一个独立的“Analyze”菜单，点开后第一项就是“Inspect Code…”。很多教程、视频录制得早，到现在还是这么教的。但较新的版本里菜单结构做了调整，检查相关命令被挪到了“Code”菜单底部，名字依旧是“Inspect Code…”，功能和旧版基本一样。

我在 2023.1.1 和 2024.1 这代版本上实际确认过路径：

• Windows / Linux：顶部菜单 Code → Inspect Code…
• macOS：顶部菜单 Code → Inspect Code…

如果你照着“Analyze”这个路径去找，发现菜单里根本没有，很可能就是用上了新版本。这时候不要怀疑自己装错了，直接在“Code”菜单底部翻一下就行。如果两处都没有，请直接按两下 Shift 打开 Search Everywhere，输入“Inspect Code”，这是所有版本里最保险的定位手段。

1.2 右键菜单其实更直观

相比顶部菜单，我更推荐用右键入口来触发检查。在左侧 Project 面板里，选中一个文件、一个包、一个模块或者整个项目，直接右键，菜单里会有一组叫“Analyze”的操作，下面就有“Inspect Code…”。选中范围这个动作，天然就帮你决定了检查范围，不需要额外弹窗里再选一遍。

这种方式在处理局部问题的时候尤其好用。比如你最近改了三个类文件，可以在 Project 面板里按住 Ctrl（macOS 上是 Cmd）多选这几个文件，然后右键执行检查。Android Studio 就会把检查范围限制在这几个文件里，跑起来快，结果也聚焦。如果非要跑全项目，扫描时间和噪音都会直线上升，这是我建议平时少碰全项目检查的原因。

1.3 结果面板不是 Problems 窗口

检查执行完之后，底部会弹出一个专门显示结果的窗口，标题叫“Inspection Results”。很多新人把它和“Problems”工具窗口搞混，这是两回事：Problems 一般显示编译期和同步期的错误，而 Inspection Results 是静态检查输出的问题清单。

如果检查结束没看到结果面板，有几个办法手动调出来：

• 从顶部菜单 View → Tool Windows → Inspection Results
• 点击底部和侧边工具条里的对应图标
• 如果窗口被关闭，重新跑一次检查通常会再次自动弹出

面板左侧一般是树形分组，右侧显示具体代码位置、问题描述和修复建议。这部分细节比较多，我在第 4 章专门展开。

2. 从项目到单行：四种常用的启动检查方法

找到主入口只是第一步，实际写代码时靠鼠标点菜单太累人了。我的工作习惯是快捷键为主、右键为辅、菜单兜底。这里把四种最常用的启动检查方式列出来，你按自己的习惯选一套用熟就行。

2.1 标准“Inspect Code”启动

Windows / Linux 下默认快捷键是 Ctrl+Alt+Shift+I，macOS 下是对应 Option+Shift+Command+I。按下后弹出选择范围的对话框，和菜单点出来的效果是一样的。这里要注意：不同版本和不同 Keymap 方案会把快捷键略作调整，如果按了没反应，别硬记组合键，去 Settings → Keymap 里搜“Inspect Code”看一眼实际绑定，或者干脆自己改一个。

弹出来之后可以选“Whole project”、“Module”、“Directory”、“Custom scope”等范围。绝大多数情况下选当前模块就够，整个项目容易把很多历史遗留问题一起带出来。检查过程中能看到底部进度，项目大的话跑个两三分钟很正常，不是卡死了。

2.2 按名称运行单条检查：“Run Inspection by Name”

这是被严重低估的一个功能。它的价值在于：你已经知道要查哪一类问题，只想看这一类，其他噪音全部过滤掉。

Windows / Linux 下快捷键是 Ctrl+Shift+Alt+I，macOS 下是 Shift+Option+Command+I。按下后会出现一个小输入框，让你输入检查规则名称。你可以输入“unused”去搜未使用相关规则，也可以输入“deprecated”去搜废弃 API 相关的检查。选定一条规则并指定范围后，Android Studio 只会执行这一条规则，结果列表里不会有其他规则的问题。

这个功能我特别推荐在版本发布前使用。比如要发一个稳定版本，我通常只查废弃 API 和 Android Lint 中跟资源回收相关的高优先级规则，避免把几百条代码风格问题混进来，一眼望去根本不知道哪些真正需要处理。

2.3 局部检查：在编辑器里点出来的规则

有时候你不想弹窗选范围，只想看看当前光标位置到底触发了哪些检查。把鼠标放到有波浪线或者高亮的代码附近，右键，找到“Analyze”或“Local Inspections”这一项，同一个位置的检查项会小窗口列出来。

日常里更顺手的是用 Alt+Enter（macOS 上是 Option+Enter）。把光标放在有警告标记的地方，按 Alt+Enter 会弹出 Quick Fix 建议，里面通常包含修复操作，也可能包含“更多检查”的子菜单，展开就能看到这一行代码命中的具体规则名称。我建议所有人养成的习惯是：代码标黄了就先 Alt+Enter，能就地修复就修，不能修就看一下规则名，不要一直眼不见为净。

2.4 一键分析整个目录并导出

项目级检查还有一种更完整的方式：选目录后右键，不点“Inspect Code”，而是看右键菜单里其他分析类操作。其中有些会直接生成 HTML 报告，有些是对比版本间的差异。虽然严格说它们不算同一个入口，但因为藏在同一个右键分组里，很容易被误点。

如果你选 Directory 并执行 Inspect Code，结果面板里只会显示目录下的内容。如果目录里全是 build 产物，结果几乎等于空跑。所以在执行之前，最好先确保选中目录是源码目录。注意别把 app/build、.gradle 这类自动生成目录选进去，否则扫描时间会拖长，结果里还可能混进模板代码问题。

3. 检查设置页和配置文件：真正管“规则”的地方

很多人找检查功能的真实诉求，其实是“我觉得某个检查太啰嗦，想关掉它”或者“我想把某个警告调成 error”。这种需求不在菜单命令里，而在设置页。

打开设置的路径是这样的：

打开以后是一个很大的双栏页面。左侧是树形规则列表，按类别分好级；右侧显示当前规则的说明、严重级别和启用状态。页面右上角有搜索框，支持直接输入关键词过滤。比如输入“Android”，就能把 Android Lint 相关规则筛出来。

3.1 大类拆解：哪些检查和你最相关

规则列表里常见的几个大类：

• Android Lint：布局、资源、Manifest、权限、API 调用等 Android 专属问题
• Java：与 Java 语言相关的语法和习惯问题
• Kotlin：与 Kotlin 语言相关的编译警告、推荐写法、协程误用等
• XML / JSON：文档结构与格式问题
• General：通用代码质量、命名、未使用变量、重复代码等
• Code Style：格式化风格相关规则

插件也会往这个列表里插东西。装了 Kotlin 插件会多一些 Kotlin 专用检查，装了 SonarQube 或 lint 增强插件也会把自己那一坨规则注册进来。所以如果你看到列表比同事的多了不少，先检查一下是不是装了额外的静态分析插件，未必是版本不同。

3.2 严重级别：不是把所有问题都调到 Error 就负责

每条检查都可以设置不同的严重程度，常见是 Error、Warning、Weak Warning、Info 这几种。严重级别不影响代码逻辑，只影响显示和排序，但会影响你处理的优先级。编辑器里红线一般是 Error 级别，橙线是 Warning 级别，灰暗的提示是弱警告或信息。

我见过非常多人刚上手时把所有规则全调成 Error，结果编译期一片红，心情直接爆炸。合理做法是先保持默认，只把团队最在意的几条规则调高一级。比如对安卓开发团队来说，“Notification 构造器已废弃”这类规则调到 Warning 就足够，没必要所有废弃 API 都变成 Error 卡住编译。

3.3 检查配置文件的真实位置

检查设置页里改的每一项，最终会保存到项目目录下的配置文件里。正常情况下路径是：

• 项目根目录/.idea/inspectionProfiles/Project_Default.xml

如果创建了自定义检查方案，会在同一个目录下生成对应的 XML 文件。同时还有一个 profiles_settings.xml 文件记录当前默认使用哪个方案。这些文件都可以提交到 Git 仓库，跟着项目走。

这里有一个团队协作的坑：如果你和别人合作用同一个仓库，千万别每人一份自定义检查配置然后乱提交。每次改动都会让拉代码的人遭遇一波配置冲突，协调起来特别痛苦。我建议的做法是，项目一开始统一定好检查配置，之后只在配置版本更新时提交一次，不要拿它当工作文件频繁改动。

3.4 创建自定义的 Inspection Profile

如果团队内不同项目想用不同规则集，可以在检查设置页顶部的 Profile 下拉菜单里选择新建或复制。复制一份“Project_Default”之后，在新配置里调整规则，再切换使用。Android Studio 会以新的 Profile 名称生成对应的 XML 文件放回 .idea/inspectionProfiles 目录。

这样做的实际意义是，你可以在多个检查方案之间快速切换。比如平时开发用一个宽松 Profile，只查高危问题；发布审查看另一个严格的 Profile，全量规则跑一遍。切换操作纯属配置层面，不影响代码运行，很安全。

4. 结果面板几个小技巧：筛、修、导出一次到位

很多教程只告诉你入口，不讲结果面板怎么用。其实检查跑完只是开始，真正的价值在结果处理。我自己带过几个新人，发现他们经常对着结果面板发呆，因为上千条的 warning 扑过来，根本不知道从哪里下手。这一节就把结果面板的实际用法讲透。

4.1 面板结构和基本操作

Inspection Results 面板打开后，左侧是一棵问题树。默认先按严重程度分组，比如 Error 一组、Warning 一组；每组下面再按规则名分一层，接着按包、类、方法继续往下分层。这种分组的好处是你可以先看 Error 是不是很多，再决定处理的优先级。

右侧显示问题描述和代码片段。如果该问题有快速修复，面板上会出现“Apply Fix”按钮，可以直接把修复应用到当前出现的位置。更实用的是下拉展开的“Fix All”选项，它会让你选择修复所有同类问题。比如项目里充满了多余的 import 和未使用变量，用 Fix All 可以一键清理一大批，效率肉眼可见。

4.2 筛选高价值问题

结果面板顶部有一排过滤按钮，可以按严重级别过滤、按模块过滤、按文件过滤。我最常用的是严重级别过滤：把 Warning 和弱警告隐藏掉，只看 Error，清单一下子短很多。处理完 Error 之后，再放开 Warning 逐个过。

另外一个按钮是“Autoscroll from Source”，开启后你点左侧任意一条结果，编辑器会立即跳到对应代码行。逐条修代码时这个功能非常顺手，不用在窗口和编辑器之间手动切换。如果你发现点击结果后代码没跳转，检查一下这个按钮是不是被关闭了。

4.3 HTML/XML 导出：怎么把问题交给别人看

结果面板每个分组或节点旁边有保存图标，点击可以把检查结果导出为 HTML、XML 或者纯文本。HTML 格式适合直接发给同事或放到共享盘里，浏览器打开就能看到分组情况，非技术人员也能看懂。XML 格式适合程序解析，比如再接一层脚本把结果推送到 CI 系统的消息通知里。

导出文件默认包含问题发生的位置、严重级别、规则名和描述。如果只是口头汇报，也可以直接用截图，不过长期项目记录还是建议导出 HTML 存档，方便日后对比高频问题的变化趋势。

4.4 和构建 Lint 的关系要拎清楚

Android 里还有一个很出名的 Lint 检查，位置在 Build 菜单下，也可以命令行跑 gradlew lint。很多人以为 Inspect Code 就是 Lint，或者反过来，其实它们有重叠但不完全一样。

Inspect Code 是 IDE 的静态检查，它会调起包括 Android Lint 在内的很多规则集，范围点击鼠标就能选定。而命令行 Lint 是 Android Gradle 插件提供的独立分析工具，也能发现问题并生成 HTML/XML 报告，主要应用场景是 CI 流程和构建卡点。两者规则有交叠，但入口、输出方式和跟踪方式都不同。日常开发用 Inspect Code 快速排查就够了，发布前的自动化检查位应该留给 gradle lint。

5. 常见问题排查：为什么你找不到检查位置

“找不到”这个问题，其实有很多非显而易见的原因。我自己接触过不少案例，汇总几个典型场景，方便你直接对号入座。

5.1 菜单里根本没有 Inspect Code

新版 Android Studio 对不同平台、不同版本的菜单会做微调，加上插件冲突时菜单项还可能被隐藏。如果你在 Code 和 Analyze 菜单里都找不到，最省事的办法是使用 Find Action。

按 Ctrl+Shift+A（macOS 上是 Cmd+Shift+A），打开操作搜索框，输入“Inspect Code”，搜索结果会直接把该命令带出来。选中并回车就能执行。这一招是定位任何功能的底牌，不管你用的是新版本还是装了一堆插件，只要功能存在，就一定能被搜到。

5.2 快捷键按下没反应

快捷键无效通常有三类原因。第一，当前焦点在一个工具窗口里，快捷键被窗口内部的编辑器或树形组件拦截了；第二，系统输入法占用了同一组组合键，尤其 macOS 上 Option 和 Command 组合很容易和输入法冲突；第三，Keymap 被切换成别的预设方案，比如 Eclipse 方案，快捷键就完全对不上了。

排查方式很简单，去 Settings → Keymap 里搜“Inspect Code”，看看当前绑定的是哪一组键。你可以直接修改为自己习惯的组合，但改完以后建议稳定使用，别频繁换键位。中文输入法环境里，我通常避开带 Alt 的组合，尽量选 Ctrl+Shift 开头的组合，冲突概率低很多。

5.3 检查结果为空，或者结果多到没法看

结果为空最常见的原因就是选错范围。选了一个目录，但目录下面全是生成文件，扫描结果自然干净。或者项目还没做 Gradle 同步，代码索引不完整，检查范围里很多文件都没被纳入分析。

结果太多的时候，先不要慌。用顶部过滤按钮关掉弱警告和风格类问题，只看 Error 和高优先级 Warning。任何一个大型项目，全量检查结果里风格建议数量都会占一半以上，先把这些噪音过滤掉，剩下的才是真正需要判断的问题。

5.4 检查进度条不走、一直卡着

全项目扫描在大项目里确实要几分钟，属于正常现象。但如果卡到十几分钟还没动静，就要排查了。常见原因是项目里存在巨大生成目录没有排除，比如 build、.gradle、node_modules 这类目录被纳入索引或检查范围。建议在 Project 面板右键排除这些目录，或者设置里排除后再跑。

插件的因素也很大。某些静态分析插件在 Inspect Code 时会给 IDE 挂载额外规则，规则多了会显著拉慢分析速度。如果你装了很多第三方插件，可以尝试禁用一部分，对比一下检查速度有没有改善。

下面这张表把常见坑和解决方案整理到一起，方便直接存档：

6. 关于代码检查，几个值得长期坚持的使用习惯

把 inspection 的位置找齐只是第一步，真正让它发挥作用的是使用习惯。我有几个感触比较深的经验，顺便在这里分享一下。

不要一开始就追求“全量检查零警告”。那几乎不可能，而且你会被规则逼疯。更好的做法是，建立自己的“问题分级”观念：Error 级的问题必须处理，Warning 级的问题通常也该处理，弱警告和风格提示，尤其是自动生成的代码产生的，可以分批清理或者直接忽略。

每天提交代码之前跑一次局部检查，是目前对我帮助最大的流程改进。改动完一个类或一个功能模块后，用右键选这个小范围，跑一次检查，把新出现的问题当场解决，比攒到周末搞一轮大型清理要轻松得多。你可以试试把 Inspect Code 的快捷键记熟，频率会显著提高。

还有一个看着很不起眼的点：把检查结果面板里的 Autoscroll 打开。这样你点哪条结果，编辑器就跳到哪一行，修完一条再点下一条，整个流程很流畅。很多朋友处理检查结果觉得麻烦，其实只是没把这两个小开关调好。

最后说一句我踩过的坑：团队项目里，检查配置一定不要和代码改动混在一起提交。.Git 冲突的表象是配置文件冲突，实际是每个人改了检查规则却不提前通知。把这个流程规范起来，团队的代码风格和检查规则才会越来越稳定。