反射本质上属于运行时调用，被调用的功能甚至有可能是外部依赖库而非本身代码的，基本没办法通过静态检查工具（如 idea 的自动检查）进行有效的检查，这其实本质上也是反射特性带来的弊端。

个人有想到一些思路，仅供参考：
1、和开发一起梳理下项目里的代码，看有哪些涉及反射调用的，看涉及哪些功能。回归测试的时候，重点测试下这些相关的功能。
2、有些反射调用的地方，确认下是不是必须用反射，能不用的尽量不用，降低维护成本。
3、如果团队内有做覆盖率采集相关的工具，可以结合增量覆盖率，看看用到反射的模块的增量覆盖率情况。

PS：开发容易漏掉反射调用的修改，一定程度上说明开发自己要修改的代码调用情况还不够熟悉，过于依赖 ide 提供的自动重构功能。这块需要联合开发，通过一些手段把重构类的修改摘出来（比如要求必须单独 commit，或者独立分支之类的），对这部分修改做 review，避免遗漏，同时也帮助开发更好地熟悉整个项目内反射部分的关联，避免重复遗漏。

楼上的说差不多了，反射很多是静态代码工具检查不太出来的，你如果漏了场景没有发现，运行时就可能出错，这个可能去看代码这块到底影响了哪些业务场景，并自动化掉

谢谢你的回答
我也是查了很多的文章都没有什么特别的手段，才来这里问了一下，这里聚集的大神也多。 哈哈
我就是写了一个脚本来扫描源代码中所有通过反射调用的代码行，再对应到源码被反射的类代码，输出一个 check list
后续结合当前分支的改动，判断是否有改动涉及反射的代码，如果有再进一步测试验证。（只不过就是觉得这部分是不是可以优化一下）

其次也要求我们开发同学在所有反射调用的外层 try cache 中把堆栈信息输出出来，避免之前有些人直接在 cache 里写逻辑代码，异常给忽略掉了。

最后就是形成自动化测试来做场景覆盖。