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 面板里按住 CtrlmacOS 上是 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 下默认快捷键是 CtrlAltShiftImacOS 下是对应 OptionShiftCommandI。按下后弹出选择范围的对话框和菜单点出来的效果是一样的。这里要注意不同版本和不同 Keymap 方案会把快捷键略作调整如果按了没反应别硬记组合键去 Settings → Keymap 里搜“Inspect Code”看一眼实际绑定或者干脆自己改一个。弹出来之后可以选“Whole project”、“Module”、“Directory”、“Custom scope”等范围。绝大多数情况下选当前模块就够整个项目容易把很多历史遗留问题一起带出来。检查过程中能看到底部进度项目大的话跑个两三分钟很正常不是卡死了。2.2 按名称运行单条检查“Run Inspection by Name”这是被严重低估的一个功能。它的价值在于你已经知道要查哪一类问题只想看这一类其他噪音全部过滤掉。Windows / Linux 下快捷键是 CtrlShiftAltImacOS 下是 ShiftOptionCommandI。按下后会出现一个小输入框让你输入检查规则名称。你可以输入“unused”去搜未使用相关规则也可以输入“deprecated”去搜废弃 API 相关的检查。选定一条规则并指定范围后Android Studio 只会执行这一条规则结果列表里不会有其他规则的问题。这个功能我特别推荐在版本发布前使用。比如要发一个稳定版本我通常只查废弃 API 和 Android Lint 中跟资源回收相关的高优先级规则避免把几百条代码风格问题混进来一眼望去根本不知道哪些真正需要处理。2.3 局部检查在编辑器里点出来的规则有时候你不想弹窗选范围只想看看当前光标位置到底触发了哪些检查。把鼠标放到有波浪线或者高亮的代码附近右键找到“Analyze”或“Local Inspections”这一项同一个位置的检查项会小窗口列出来。日常里更顺手的是用 AltEntermacOS 上是 OptionEnter。把光标放在有警告标记的地方按 AltEnter 会弹出 Quick Fix 建议里面通常包含修复操作也可能包含“更多检查”的子菜单展开就能看到这一行代码命中的具体规则名称。我建议所有人养成的习惯是代码标黄了就先 AltEnter能就地修复就修不能修就看一下规则名不要一直眼不见为净。2.4 一键分析整个目录并导出项目级检查还有一种更完整的方式选目录后右键不点“Inspect Code”而是看右键菜单里其他分析类操作。其中有些会直接生成 HTML 报告有些是对比版本间的差异。虽然严格说它们不算同一个入口但因为藏在同一个右键分组里很容易被误点。如果你选 Directory 并执行 Inspect Code结果面板里只会显示目录下的内容。如果目录里全是 build 产物结果几乎等于空跑。所以在执行之前最好先确保选中目录是源码目录。注意别把 app/build、.gradle 这类自动生成目录选进去否则扫描时间会拖长结果里还可能混进模板代码问题。3. 检查设置页和配置文件真正管“规则”的地方很多人找检查功能的真实诉求其实是“我觉得某个检查太啰嗦想关掉它”或者“我想把某个警告调成 error”。这种需求不在菜单命令里而在设置页。打开设置的路径是这样的系统路径Windows / LinuxFile → Settings → Editor → InspectionsmacOSAndroid Studio → Preferences → Editor → Inspections打开以后是一个很大的双栏页面。左侧是树形规则列表按类别分好级右侧显示当前规则的说明、严重级别和启用状态。页面右上角有搜索框支持直接输入关键词过滤。比如输入“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。按 CtrlShiftAmacOS 上是 CmdShiftA打开操作搜索框输入“Inspect Code”搜索结果会直接把该命令带出来。选中并回车就能执行。这一招是定位任何功能的底牌不管你用的是新版本还是装了一堆插件只要功能存在就一定能被搜到。5.2 快捷键按下没反应快捷键无效通常有三类原因。第一当前焦点在一个工具窗口里快捷键被窗口内部的编辑器或树形组件拦截了第二系统输入法占用了同一组组合键尤其 macOS 上 Option 和 Command 组合很容易和输入法冲突第三Keymap 被切换成别的预设方案比如 Eclipse 方案快捷键就完全对不上了。排查方式很简单去 Settings → Keymap 里搜“Inspect Code”看看当前绑定的是哪一组键。你可以直接修改为自己习惯的组合但改完以后建议稳定使用别频繁换键位。中文输入法环境里我通常避开带 Alt 的组合尽量选 CtrlShift 开头的组合冲突概率低很多。5.3 检查结果为空或者结果多到没法看结果为空最常见的原因就是选错范围。选了一个目录但目录下面全是生成文件扫描结果自然干净。或者项目还没做 Gradle 同步代码索引不完整检查范围里很多文件都没被纳入分析。结果太多的时候先不要慌。用顶部过滤按钮关掉弱警告和风格类问题只看 Error 和高优先级 Warning。任何一个大型项目全量检查结果里风格建议数量都会占一半以上先把这些噪音过滤掉剩下的才是真正需要判断的问题。5.4 检查进度条不走、一直卡着全项目扫描在大项目里确实要几分钟属于正常现象。但如果卡到十几分钟还没动静就要排查了。常见原因是项目里存在巨大生成目录没有排除比如 build、.gradle、node_modules 这类目录被纳入索引或检查范围。建议在 Project 面板右键排除这些目录或者设置里排除后再跑。插件的因素也很大。某些静态分析插件在 Inspect Code 时会给 IDE 挂载额外规则规则多了会显著拉慢分析速度。如果你装了很多第三方插件可以尝试禁用一部分对比一下检查速度有没有改善。下面这张表把常见坑和解决方案整理到一起方便直接存档现象原因方向解决建议菜单里找不到入口版本菜单差异 / 插件冲突用 Find Action 搜 Inspect Code快捷键无效焦点、键位、输入法冲突Keymap 里重新绑定结果窗口不出现工具窗口被关闭View → Tool Windows → Inspection Results结果为空范围选错或索引不完整重新选 src 目录并做 Gradle 同步结果太多风格类规则噪音大按严重级别过滤卡住、进度不动目录过大 / 插件过多排除 build 目录禁用多余插件6. 关于代码检查几个值得长期坚持的使用习惯把 inspection 的位置找齐只是第一步真正让它发挥作用的是使用习惯。我有几个感触比较深的经验顺便在这里分享一下。不要一开始就追求“全量检查零警告”。那几乎不可能而且你会被规则逼疯。更好的做法是建立自己的“问题分级”观念Error 级的问题必须处理Warning 级的问题通常也该处理弱警告和风格提示尤其是自动生成的代码产生的可以分批清理或者直接忽略。每天提交代码之前跑一次局部检查是目前对我帮助最大的流程改进。改动完一个类或一个功能模块后用右键选这个小范围跑一次检查把新出现的问题当场解决比攒到周末搞一轮大型清理要轻松得多。你可以试试把 Inspect Code 的快捷键记熟频率会显著提高。还有一个看着很不起眼的点把检查结果面板里的 Autoscroll 打开。这样你点哪条结果编辑器就跳到哪一行修完一条再点下一条整个流程很流畅。很多朋友处理检查结果觉得麻烦其实只是没把这两个小开关调好。最后说一句我踩过的坑团队项目里检查配置一定不要和代码改动混在一起提交。.Git 冲突的表象是配置文件冲突实际是每个人改了检查规则却不提前通知。把这个流程规范起来团队的代码风格和检查规则才会越来越稳定。