举个例子:
页面中的css、js等配置路径:
<script src="js/jquery-1.10.2.min.js" th:src="@{/js/jquery-1.10.2.min.js}"></script>
<script src="js/jquery-ui-1.9.2.custom.min.js" th:src="@{/js/jquery-ui-1.9.2.custom.min.js}"></script>
<script src="js/jquery-migrate-1.2.1.min.js" th:src="@{/js/jquery-migrate-1.2.1.min.js}"></script>
<script src="js/bootstrap.min.js" th:src="@{/js/bootstrap.min.js}"></script>
<script src="js/modernizr.min.js" th:src="@{/js/modernizr.min.js}"></script>
<script src="js/jquery.nicescroll.js" th:src="@{/js/jquery.nicescroll.js}"></script>
都用了@。假设一个登陆验证的场景,有一些网页只有登录了才能访问,拦截器对于任何没有登录就访问的请求都拦截下来,这时会自动跳转到登录页面(注意,此时不会触发404请求,首先走拦截器,通过拦截器的非法请求才会转404)。比如,我们访问:localhost:8080/css/css/dasdf.css 此时跳转登录页面,跳转用的是:
request.getRequestDispatcher(“/”).forward(request,response);
发现地址栏依然是:localhost:8080/css/css/dasdf.css,这也就意味着,如果你不用@符号,那么html解析的页面js等静态资源的路径就是
对于前缀,也就是刚才我们随便写的访问请求/css/css/dasdf.css,页面解析是考虑这个前缀的。这就导致跳转后的前台页面拿不到这些静态资源,也就只能显示文字,页面完全乱了。而@{/……}则可以避免这种情况,它会自动忽略这些前缀,依然去静态目录/js/……等目录下去找文件,而不是静态目录/css/css/……巴拉巴拉,换句话说不受人为干预影响。