一、缘起
很久没有写文记录自己开发中遇到的问题了。这几天开发遇到一个问题，牵扯的知识点还是比较多的。所以，想记录下来，顺便梳理一下思路。
二、开始
在开发中，经常看到ResourceHandlerRegistry，但是不知道起准确的使用方式和目的。具体解释看了这篇博文：https://blog.csdn.net/andy_zhang2007/article/details/89133798；
主要讲了这个类的代码逻辑。没有讲使用场景的前因后果。
前因是这样的，在我们使用很久以前，开发普通java web应用的时候，
可以看一下此博文的介绍：https://www.cnblogs.com/hongchengshise/p/10371309.html；
我们的静态资源是直接放在项目根目录下的。Tomcat作为一个HTTP服务器，可以直接把这些静态资源映射成为url，提供给浏览器访问。在以前也没有细究过其中的原因，可以看看这篇博文：https://www.cnblogs.com/chuonye/p/10816345.html；这让我们使用起来非常方便，不受tomcat中的filter，listener，servlet的配置的影响，可以始终能够访问静态资源。后来引入Spring MVC之后，情况就开始发生了变化，DispatcherServlet前端控制器，所有的请求都有经过它来统一分发。这导致把Tomcat给架空了，导致Tomcat静态资源的映射功能不能使用了。这其实是对以前的开发模式的一种破坏。所以，在Spring MVC中可以配置：
<resources mapping="/resources/**" location="/resources/" />
解决这个问题。说白了，就是以前Tomcat要做的静态资源映射服务，由于Spring MVC介入过深，他自己要把这个事情给处理掉。随着时代的发展，注解配置逐渐取代XML配置。那么，静态资源配置该如何使用注解配置，就要回到开头，我们的主角 - ResourceHandlerRegistry了。
到此处，好像也没有什么稀奇。问题是，时代依旧在发展，在我们不断引入新技术的时候，会把以前不成问题的问题，变成一个新问题。
在上面的基础上，我们再引入shiro，来解决权限的问题。shiro是通过filter拦截http请求来处理权限的。这里，不好意思，又会“误伤”到静态资源的访问。因为filter是在servlet之前访问的。正常流程是：用户获取到shiro的权限，shiro从filtr中放行，然后，到了spring mvc处理servlet中，spring的DispatcherServlet分发请求，ResourceHandlerRegistry接手处理静态资源请求，返回静态资源响应流。
但是，我们想要静态资源不要权限就可以访问，就需要让shiro匿名放行。
三、另外一个问题
问题到此处就结束了吗？没有。如果此时，我们再引入了Nginx。这时候，我们正常请求静态资源当然是没有问题的。但是，如果我们是上传文件后，返回文件的下载路径呢？由于Nginx做了反向代理，所以，web应用中拿不到真实的请求地址，就不能组装一个完整的下载地址出来。我们需要配置Nginx，才可以拿到真实的请求地址。但是，我们组装下载地址依然要考虑Nginx中是如何配置我们的反向代理的请求映射的。这样虽然能够解决问题，但是，很明显这里的代码非常依赖外部环境的配置。如果外部环境一旦变化，这里的代码就会出错。说到底，就是因为，我们把静态资源的访问和servlet的请求处理放在一起了。这样做也没有不可以。对于java web应用把这两种只有同等看待和处理也是可以的。只是，我们为了达到这个目的，需要配置Nginx，Shiro，Spring mvc,还有修改代码逻辑。解决问题的成本代价实在感人。从这个角度也引出另外一个解决方案，其实也不能说是解决方案，是引入新组件后的擦屁股大法。
Nginx本来就是http服务器，那么由他代理静态资源的请求再好不过了。在Nginx中直接配置静态资源映射。实现了动静分离。这样就实现了匿名访问静态资源的问题。
四、总结
一番梳理下来，我的感受就是引入新的框架、新的组件、新的软件，总会引入新的问题，一个原来不成问题的问题。这就是让人头痛的地方。
