3
这是nacos中的ControllerMethodsCache，作用是通过HttpServletRequest获取controller中处理该request的方法，然后获取Secured注解
既然已经注入到spring容器中了，为什么不用现成的RequestMappingHandlerMapping方法来处理
Q
[alibaba/nacos]关于authFilter中的ControllerMethodsCache，完全没必要做这个事情
A
回答
6
看了一下DistroFilter同理，都是注入容器中的，单独写一个扫包加处理class是不是太繁琐了，如果没有额外功能应该是能通过第二种方式优化掉的
7
目的是找到url所映射的controller类的方法， 从而找到该方法是否被特殊注解，并且能获取到这个特殊注解。
之前也想过应该要可以直接用Spring 的mapping，但是一直没有时间做， 如果你有空可以做一下优化， 先找一个注解，比如Distro做一个替换测试，没问题之后再全面替换和删除。
这里有几个比较特殊的点：
- 配置中心接口中有使用param来区分方法的情况，需要确认可以实现。
- 一些特殊的url写法，也要能够命中方法，比如
/xx/xx/,/xx/xx,/xx/xx?,//xx/xx之类的需要等价，主要是防止绕过鉴权。
1
那完全用RequestMappingHandlerMapping取代ControllerMethodsCache之后，是否要将ControllerMethodsCache该类移除掉呢。我有意来做这个修改工作
1
我理解如果平替掉的话就可以移除掉了，包括RequestMappingInfo这些类，都是很老版本的东西了，直接复用spring提供的能力更好
8
在尝试修改成RequestMappingHandlerMapping 获取 Method的时候。
出现了问题。
HandlerExecutionChain executionChain = handlerMapping.getHandler(req); --获取失败
出现了
Expected lookupPath in request attribute "org.springframework.web.util.UrlPathHelper.PATH".报错
源码分析定位
结论：spirngBoot版本太高出现，修改失败。 该问题就是源自springboot 2.6.0后的新特性。 @KomachiSion @985492783
0
我项目里的解决方案是添加spring.mvc.pathmatch.matching-strategy=ant_path_matcher，但是没有深究这两者的区别，如果要替换还得仔细研究研究会不会有不兼容的地方
2
如果是在项目里使用配置来处理，那么就应该会影响到全局的配置。 个人觉得要自定义拦截器或特定的RequestMappingHandlerMapping实例来处理特定的请求路径。这样可以更细粒度地控制路径匹配策略的应用范围。
9
这样实现是否可以 @KomachiSion
6
没看懂，具体想要怎么做
8
建议PR中的修改：
- 先不要彻底移除，添加一个代理层和开关，方便新机制使用过程中有问题快速切换回旧机制。
- Any-matcher会不会导致安全问题？
6
第一点:可以修改实现。 第二点:无法评估，这个是springBOot方面的问题。
看是否还要继续修改@KomachiSion
3
- 需要修改，在稳定前有能力立刻切换回旧的ControllerMethodCache， 毕竟这个经历过这么多个版本，稳定性足够。
- 调研一下Any-matcher不设置会有什么问题，为什么一定要设置成， 如果设置成是否存在相关安全隐患
6
1.如果不设置Any-matcher， 在springBoot版本大于2.6.0. (HttpServletRequest) request 使用 RequestMappingHandlerMapping 获取 method 会有官方的bug出现。 获取不到method 。所有才设置Any-matcher。
- 安全隐患这方面，具体还不可知，我认为安全隐患不存在于nacos，应该存在于springBoot。（具体还要通过测试）
2
我觉得在不明确的情况下， 最好还是不要替换了， 因为即使这个安全隐患存在于spring boot， 但spring boot默认不开启Any-matcher，而nacos开启， 最后就会变成是nacos的安全漏洞，而不是spring boot的。 这点类似于actuator配置路径为*导致的内存dump泄漏等安全问题。
1
或者等spring boot修复了这个问题，我们升级了对应的修复版本，再进行替换。