在一般的Web項目中都多少需要點權限認證什么的，用Spring的福音，SpringFramework出了一個可以進行權限認證的小東西，原先是叫ACEGI，很初級的一個東西，使用起來很麻煩，就像當年的JDBC一樣，現在Spring把它大大的包裝了一下，叫Spring Security 2，表示一個新面孔的產品，使用起來大大的簡化，功能也強大起來，就像現在遍地的ORM比如Hibernate之類的。

說起來，東西雖好，但是用起來還是要慎重，就像一把搶，不要亂用哦。
一般來說SS2用在系統登陸驗證方面應當很不錯，沒什么大問題，支持的驗證種類也很多，
想用的盡管用吧。
上面也說過，他的功能很強大，不止局限于登陸驗證，還可以對系統所有URL級別的訪問進行訪問權限控制，以及業務中的方法級進行控制，但是，我們要看到，如果使用這些功能，必然導致性能的下降，很明顯，你既然要求它干這些工作，那么，他就任勞任怨的對所有訪問系統的URL和方法進行檢查，雖然它不怕麻煩，但是，你卻必須為此付出不菲的開銷，如果驗證的規則再稍微那么復雜一點，呵呵，對不起，花銷更大。

并不僅僅是SS2有這個問題，所有的這種需求都會導致這種問題，所以，如果你要想用，就必須要慎重。

首先，盡量減少URL和方法驗證的規則的簡約化，讓它在驗證的時候，最好一矢中的，不要七拐八拐的才找到目標，要知道每拐一次費用就會增加一倍甚至更多。
其次，盡量減少要驗證的URL和方法的數量，這個也很主要，但是有人要問了，明明都是需要驗證的怎么減少？這個可以從兩個方面來看，對于URL，可以把有相同權限的URL盡量的歸并到一個大的組/目錄中，對這個上級目錄進行控制豈不是就減少了數量？對于方法，盡量對它的更上級進行控制，比如SSH項目中的Manager或者Service中的主方法，而不是DAO中的那些零散的方法。
再次，分散權限檢查到其它部分，雖然SS2可以做所有的檢查，但是也不是非要他做不可，比如一些業務權限劃分明確的一些業務模塊，可以把這些模塊通過目錄菜單等的方式或者權限標簽的方式，控制他們的顯示和不顯示，從而降低無權限的角色對權限以外的資源的請求，從而降低底端的驗證開銷。還有就是不要把多個權限的操作放到一個頁面中，盡量拆分開，一種權限一個頁面，讓菜單來控制它，也能降低開銷。
最后，如果你的這個系統服務器很強大，訪問量很低，比如一個用戶量很少的OA什么的系統，根本不在乎什么性能上的這點開銷，那你還等什么，統統給他加上，即顯示出來你們的產品功能的強大，又滿足了客戶的變態要求，何樂而不為？