現在已經做了比較長一段時間的 web項目了，很多人會覺得web項目的技術難度不是很大，我個人感覺這有幾方面的原因，一個是目前的程序員是從事web項目的（包擴.net,php,j2ee)人比較多，而從事其他方面的人員相對要少一些，所以擱行如擱山，大多程序員有個很優秀的品質，對於不瞭解的東西回比較謹慎，所以會認爲其它方面的技術比較難（實 際上當你去了解其他的方面就會看到技術都是可以很快的運用和掌握的，擔任到精通的地步就需要化費很多的時間和個人的努力了，呵呵）；另一個比較重要的原因在於web項目的入門門檻確實不高，但實際要想真正做到一個好的web項目的程序員或是能夠真正達到一個更高層次的架構師的水準，其所要掌握的技術列表還是相當長的，需要學習很多的技術方面和積累很多的實際經驗，所以你如果僅僅挺留在入門階段你會覺得比較簡單，實際上你學要做的功課還有很多；還有一個方面就是在web項目中還有一個比較複雜的地方在於對實際業務的轉化，說白了就是用戶的需求分析，這一點是很麻煩的（不像一些通用項目是一開發人員的想法爲中心）。
羅嗦了這麼多，沒到這篇blog的主要內容了，下面我主要就在開發web項目中容易忽略的幾個問題談一談，可能這些方面都比較簡單，但經驗也是這樣一點一點積累的。
首先看看對於web項目中的單點登陸的問題，我們一般在web項目的開始一般都有一個用戶驗證，通過以後執行後面的一些流程，那麼在這當中不做處理，則有可能會被人直接用url加傳參數的方法直接調用後面的流程處理，比較簡單的處理方法就是在後續的流程中都做一個檢查（比如對session的某個屬性做檢查，而這個session的屬性是由開始的驗證步驟加入的),雖然比較麻煩 ，但目前來說我還沒看到比較好的方法，對於常用的web框架struts,webwork,包括spring中也沒有給予好的解決（或與是太簡單了，框架本身就不去做了，呵呵，也或是我沒注意到）；但這裏還有一個問題就是後續的操作可能不是有一個服務器來完成的，可能是後續流程步驟多，訪問大，要有多臺服務器做羣集，所以要做到跨服務器的session維護和驗證，還有如果後續的步驟可能是有不同系統集成來完成（包括..net,j2ee等）這時也是要跨服務器的session維護和驗證，再用簡單的驗證就不行了，當然這對具體的問題有相應的解決方法，一個比較可行的方案是對session做臨時的持久化，用來驗證，當然也可以在cookie上做文章，現在有的服務器在做這方面的工作，我所瞭解的php方面可以，j2ee方面沒注意，雖然我主要是玩這個的，呵呵，可能jboss等有把，有時間google一下，看看。
還有一個很著名的就是sql注入的問題，這個有很多方法可以解決，一個是對傳入的數據庫參數做過濾，還有用orm來做持久層（或是在jdbc中用preparestatement來做，它不存在組裝sql語句的問題，所以就沒有sql注入的漏洞了），也能解決這個問題。
還有一個問題對於併發量很大的系統的同步的問題，一般服務器是用多線程來滿足客戶的併發，如果對於單一用戶的響應時間比較長（相對的），這樣在同一用戶很短時間的多次請求服務器在響應時可能會出問題，有可能產生數據的不一致（特別是對與一些人採用“暴力”方式極端時間大量請求處理，問題就更容易出現），解決的方法就是線程的同步問題，但一定要注意同步的粒度問題，如果同步的粒度太大，則多線程的響應就會變慢，造成客戶大兩排隊，所以粒度的考慮很重要，一個方案是對請求的用戶名做緩存，對於讀寫刪緩存用戶名的方法做同步，這樣即保證了單用戶信息的同步問題，有考慮到了多線程併發的響應問題。
上述是在實際運用中可能要多考慮的幾個地方，當然還有很多地方需要考慮，這個在以後的文章中再敘述，經驗就是這樣一點一點積累出來的！！！
