sonarQube扫描后发现某些目录没出现在代码页面或度量里，通常不是被系统吞了，而是扫描范围口径不一致，常见表现是项目根目录不对、源目录未纳入、排除规则过宽、或报告里的路径无法映射到源码。把缺失目录定位清楚后，再去写排除通配符，才能避免一边修一边越排越多。
一、sonarQube扫描结果缺少某些目录怎么办
先分清是目录完全没被索引，还是被当作测试目录或被排除导致不计入主代码，再按从配置到日志的顺序定位，能更快闭环。
1、先确认缺失发生在哪个页面层面
打开项目的【Code】页面搜索缺失目录名，如果代码页也搜不到，优先按未索引处理；如果代码页能搜到但覆盖率与缺陷统计里没有变化，多数是被当成测试或被排除出度量范围，需要回头核对sonar.sources与sonar.tests的划分口径。
2、核对项目根目录与扫描工作目录是否一致
在CI里最容易出现的问题是扫描命令在子目录执行，导致相对路径全部偏移；把扫描步骤的工作目录固定到仓库根目录，或在扫描参数里显式设置sonar.projectBaseDir指向仓库根目录，再复跑一次，看缺失目录是否恢复。
3、检查源目录配置是否把目录漏掉了
如果你用sonar-project.properties，打开文件检查sonar.sources是否只写了部分目录；如果你在流水线里用命令行传参，检查是否存在-Dsonar.sources覆盖了配置文件；如果你在界面里配置过范围，进入项目【Project Settings】用搜索框输入sources与scope，确认没有残留的旧配置把目录排除在外。
4、排查是否被排除规则误伤
检查sonar.exclusions与sonar.inclusions是否存在过宽匹配，比如把src下的子目录一并排掉；在项目【Project Settings】里搜索Exclusions，进入【Analysis Scope】相关项，核对Source File Exclusions是否包含会命中缺失目录的规则，临时把相关规则删除或缩窄后复跑，以验证是否为排除误伤。
5、确认目录内文件类型是否被识别为可分析源码
某些目录里可能是生成文件、模板文件或自定义后缀，扫描器可能不把它当作可分析语言文件；此时先用sonar.inclusions做一次最小包含验证，只包含该目录下少量代表性源码文件，确认能被索引后，再决定是调整后缀策略、迁移目录，还是把该目录明确标为生成物并排除。
6、检查是否被SCM忽略规则影响了索引
如果缺失目录在.gitignore里被忽略，或以子模块方式存在，扫描可能把它当作不应分析的内容；可以临时设置sonar.scm.exclusions.disabled为true做一次对照扫描，用来验证是否由SCM忽略导致目录被跳过，验证通过后再决定长期方案是修改忽略规则还是固定扫描口径。
7、用扫描日志把结论落到可复现证据
在CI里打开扫描调试日志，或在本地用更详细日志级别跑一次，搜索缺失目录名，重点看它是被标记为Excluded，还是根本没有被Indexed；把这段日志作为证据回填到问题单里，后续调整范围与排除规则时才能避免反复试错。
二、sonarQube排除规则通配符怎么写
排除规则写得好不好，核心看三点，匹配是以项目根目录为参照，路径分隔符口径统一，以及通配符语义是否精确到你要排除的层级。
1、先把规则写成相对路径口径再做扩展
排除项建议以项目根目录的相对路径来写，不要依赖机器绝对路径；这样本地与CI、不同构建节点切换时规则仍能稳定命中同一目录。
2、明确三类常用通配符的含义
一个星号表示匹配同一层级路径中的任意字符但不跨目录；两个星号表示可以跨多级目录匹配；问号表示匹配单个字符，适合固定命名规律但长度有差异的文件名场景。
3、写目录排除时优先用目录边界，避免误排同名文件
要排除目录时建议把规则写成包含目录边界的形式，例如排除所有层级下的dist目录可写为**/dist/**，排除build目录可写为**/build/**；这样能减少把文件名里带dist字样的源码误排掉。
4、写文件类型排除时用扩展名收口，别用模糊片段
例如排除压缩后的脚本文件可写为**/*.min.js，排除映射文件可写为**/*.map；不要用**/*min*这类过宽写法，否则容易把业务源码里正常包含min字样的文件也排除。
5、多个规则用逗号分隔并按类别分组维护
把第三方依赖、构建产物、生成代码分成三组写在同一处配置里，规则之间用逗号分隔；每次变更只改一组并立刻复跑验证，避免一次改太多导致难以回溯是哪条规则造成目录缺失。
6、区分源码排除与测试排除，别混在同一列里
需要排除测试目录时优先用sonar.test.exclusions或在测试范围配置里处理，不要把测试目录写进sonar.exclusions里一刀切；否则容易出现测试文件既不参与覆盖率也不参与统计，导致质量门禁口径被破坏。
7、写完规则后用反向验证确认没有误伤关键目录
在【Code】页面用搜索定位一两个关键文件，确认仍能被索引；再看缺失目录是否按预期消失或恢复，用这两点来判断规则是否精确，而不是只凭目录列表变化做判断。
三、sonarQube扫描范围口径怎么固定
扫描缺目录与排除规则难写，本质是口径不统一，想长期稳定就要把范围、排除、执行目录三件事固定成团队约定并可追溯。
1、把sources与tests的目录清单写成项目基线
在仓库里维护一份范围清单，明确哪些目录属于源码，哪些属于测试，哪些属于构建产物与生成物；后续任何人改目录结构都必须同步更新清单并在评审时说明原因。
2、只保留一个配置入口，避免界面与CI互相覆盖
选择sonar-project.properties或CI传参作为唯一生效入口，另一个入口只允许读取不允许写；每次变更后都用后台任务日志确认本次扫描实际生效的参数值，防止改了但没生效。
3、为排除规则建立变更记录与回退点
每次新增或修改排除规则，都记录规则内容、目的、验证方式与影响目录；一旦出现扫描缺目录，能快速回退到上一个已验证版本，而不是临时改一堆规则再猜测。
4、把关键目录索引校验变成上线前的固定检查
每次发布或合并前，用一个小脚本或人工清单检查关键目录是否出现在【Code】页面，至少覆盖核心业务源码目录与核心测试目录；一旦缺失立即阻断合并并回到第一段的证据链排查，避免缺失带到主干后影响全员度量。
5、对生成代码与第三方依赖单独立规，避免反复争议
生成代码与第三方依赖通常应排除出主度量，但仍可能需要保留可浏览性；把这类目录的处理原则写清楚，哪些要排除度量但保留可见，哪些直接不索引，用统一口径减少每次评审都重新讨论。
总结
sonarQube扫描结果缺少某些目录时，先用页面搜索与扫描日志确认是未索引还是被排除，再依次核对项目根目录、源目录范围、排除规则与SCM忽略影响。sonarQube排除规则通配符要以相对路径为参照，明确单星号、双星号与问号的匹配边界，目录排除写清目录边界，文件排除收口到扩展名，并用反向验证防止误伤关键源码目录，把范围口径固定后目录缺失问题会明显减少。
