同步需要等待回傳結果才能繼續，非同步不必等待，一般需要監聽非同步的結果。
同步是在一條直線上的隊列，非同步不在一個隊列上 各走各的。
1、同步與非同步之間究竟有什麼不同呢？
同步：提交請求->等待伺服器處理->處理完畢返回這個期間客戶端瀏覽器不能幹任何事
異步:請求透過事件觸發->伺服器處理（這是瀏覽器仍可作其他事情）->處理完畢
2、在什麼情況下使用呢？
1、一心一意：目前只能做一件事，其他事情必須等當前的事情完成，才能繼續後面的事情。
2、三心二意：同時可以做多件事情：左手按著空白鍵，右手可以不斷的擊打滑鼠，眼睛還要同時看著螢幕，很辛苦。
Ajax發送請求時候分為同步和非同步：
# 非同步傳輸方式是用的最多的也是預設的方式，他避免了伺服器檢索給使用者帶來的時間延遲。在非同步傳輸時候，它只是在後面悄悄進行著，用戶仍舊可以做他做的事情，不會給用戶任何的等待的感覺。在傳輸的資料量較大的時候，伺服器檢索的時間就更長了，但是用戶卻不知道，用戶仍舊專注於頁面上面的操作，根本就不知道伺服器都乾了些什麼，就給用戶良好的體驗。
非同步傳輸方式卻相反，他就好像是剛剛載入頁面的那一刻一樣，當發出了同步請求之後，瀏覽器就在等待，等待伺服器檢索完畢，返回結果。此時，滑鼠會變成等待的形狀，提醒我們的用戶請求還沒有相應，您什麼也不能做，我們的用戶就什麼也乾不成，能夠做的一件事就是——等待……雖然用戶已經習慣了等待整改頁面的加載，雖然在ajax裡面同步請求的時間一般不會大於整個頁面加載的時間，但是你要知道什麼都不做只是在那裡被動等待是多麼痛苦的一件事情。所以，這個同步請求要慎重使用…
說到這裡，我們不得不提出疑問，既然非同步請求這麼好，為啥不用非同步請求呢？乾脆不要同步請求得了。呵呵，你先別說的太急，假如有這麼一個情況，我們這一步請求的結果是下一步請求的前提，只有知道這一步請求的結果用戶以後所做的才有意義。那你說應該使用同步請求還是非同步請求呢？顯而易見，同步請求吧，為了下一步所做的更有意義，我們親愛的用戶等一下又有何妨？
同步請求和非同步請求，各有用處，沒有好壞之分，只又用的合適不合適的問題
Ajax優缺點 #
#Ajax
#)#Ajax
對使用Ajax最主要的批評是，它可能破壞瀏覽器後退按鈕的正常行為。在動態更新頁面的情況下，使用者無法回到前一個頁面狀態，這是因為瀏覽器只能記下歷史記錄中的靜態頁面。一個被完整讀入的頁面與一個已經被動態修改過的頁面之間的差別非常微妙；用戶通常都希望單擊後退按鈕，就能夠取消他們的前一次操作，但是在Ajax應用程式中，卻無法這樣做。不過開發者已經想出了種種辦法來解決這個問題，當中大多數都是在使用者點擊後退按鈕存取歷史記錄時，透過建立或使用一個隱藏的IFRAME來重現頁面上的變更。 （例如，當用戶在Google Maps中單擊後退時，它在一個隱藏的IFRAME中進行搜索，然後將搜索結果反映到Ajax元素上，以便將應用程式狀態恢復到當時的狀態。）
相關的觀點認為，使用動態頁面更新使得使用者難以將某個特定的狀態儲存到收藏夾中。該問題的解決方案也已出現，大部分都使用URL片段標識符（通常被稱為錨點，即URL中#後面的部分）來保持跟踪，允許用戶回到指定的某個應用程式狀態。 （許多瀏覽器允許JavaScript動態更新錨點，這使得Ajax應用程式能夠在更新顯示內容的同時更新錨點。）這些解決方案也同時解決了許多關於不支援後退按鈕的爭論。 進行Ajax開發時，網路延遲——即用戶發出請求到伺服器發出回應之間的間隔——需要慎重考慮。不給予使用者明確的回應[5]，沒有適當的預讀資料[6]，或對XMLHttpRequest的不當處理[7]，都會使用戶感到延遲，這是使用者不欲看到的，也是他們無法理解的[8]。通常的解決方案是，使用一個可視化的元件來告訴使用者係統正在進行後台操作並且正在讀取資料和內容。
一些手持裝置（如手機、PDA等）現在還不能很好的支援Ajax; 用JavaScript作的Ajax引擎，JavaScript的相容性和DeBug都是讓人頭痛的事; Ajax的無刷新重載，由於頁面的變化沒有刷新重載那麼明顯，所以容易給用戶帶來困擾――用戶不太清楚現在的數據是新的還是已經更新過的；現有的解決有：在相關位置提示、資料更新的區域設計得比較明顯、資料更新後給使用者提示等; 對串流媒體的支援沒有FLASH、Java Applet好;
