❶ angularjs路由是什麼意思
AngularJS路由功能是一個純前端的解決方案，與我們熟悉的後台路由不太一樣。後台路由，通過不同的URL會路由到不同的控制器上 (controller)，再渲染(render)到頁面(HTML)。AngularJS的前端路由，需求提前對指定的(ng-app)，定義路由規則 (routeProvider)，然後通過不同的URL，告訴(ng-app)載入哪個頁面(HTML)，再渲染到(ng-app)視圖(ng- view)中。
AngularJS的前端路由，雖然URL輸入不一樣，頁面展示不一樣，其實完成的單頁(ng-app)視圖(ng-view)的局部刷新。這樣來看，AngularJS做單頁應用就有點標配的感覺了。
❷ Jquery和Angularjs的區別
1.不要首先設計好你的頁面，然後再通過DOM操作去修改它
在jQuery中，你首先設計了一個page，然後再去動態修改它的內容，這是因為jQuery被設計用來進行擴展並在這個前提下大幅度地增加和修改內容，但是在angularjs中，你必須在心中先設計好你的架構，
從一開始，你就要摒棄「我擁有一個DOM元素並且想讓它去做某件事」，代之為「需要完成什麼任務，然後接著設計你的應用，最後再去設計你的視圖view層」。
2.不要使用angularjs去擴展jQuery
相應地，不要存在說讓jQuery去干某些事情，然後在此基礎上添加angularjs的功能讓它去管理model以及controller的想法。所以一般不推薦AngularJS開發新手同時使用jQuery，至少在他們還沒有適應AngularJS的開發模式之前不會去推薦這樣做，但是當你真正開始適應angularjs 的方式之後，你會發覺這是一件很誘人的事情。
曾經看到過很多開發者採用將150到200行代碼的jQuery插件利用angularjs的回調以及$apply方法封裝起來，這種方式使得代碼看起來極其復雜，但是實際上他們讓這些插件跑起來了！問題在於，在大部分情況下jQuery插件能夠用angularjs進行重寫，並且可能只會使用很少量的代碼，同時這種重寫使得代碼很直觀且易於理解，這顯然好過於將jQuery代碼直接做封裝。
所以最後說，當你遇見問題的時候，首先要以angularjs的思維進行思考，如果找不到解決方案，可以求助於社區，如果說沒有人能夠給出一個簡單的方案，那麼才考慮使用jQuery，不要讓jQuery成為你的拐杖，否則你永遠掌握不了AngularJS。
3.要以架構為中心進行思考
首先你要知道單頁應用屬於web應用，它們不是傳統的多網頁網站，所以要同時作為一個服務端和客戶端開發者的思維進行思考，需要思考如何將我們的應用分為獨立的，可擴展的以及可測試的部分。
數據綁定
這是到目前為止AngularJS最令人矚目的特性了，在數據綁定方面它舍棄了對DOM的操作方式，而這一切都是由AngularJS來自動更新視圖，你不必寫操作dom的代碼，在jQuery中，常常按照響應事件並修改視圖
區別model層
在jQuery中，DOM類似於一種model，但是在AngularJS中，擁有不同於jQuery中的model層以便可以以任何我們想要的方式去管理它，它是完全獨立於視圖之外的。這種方式是有助於進行數據綁定並且可以保持對分離的關注，而且可以具備更好的可測試性。
關注點分離
以上所講都和這個總體的話題相關：讓你關注分離，你的視圖層顯示記錄，你的model層代表數據，你還有個服務層用來執行這些可復用的任務。你使用directive來執行dom操作並擴展你的視圖，並將它和controller連接起來，這也就是在其他方面提到的有關於增強可測試性的原因。
依賴注入
幫助解決關注點分離的是依賴注入（DI），如果你是一個服務端開發者（java或者PHP），你可能已經很熟悉這個概念了，但是如果你是從事客戶端開發的，你會覺得這個概念可能有些多餘和純屬追求時髦，但是實際上不是這樣。
從廣義的角度講，DI意味著你可以自由地聲明組件然後從這些組件中進行實例化，這是理所當然的。你不必知道載入順序，文件位置等諸如此類的事情，這種魔力不是能夠立即看到，但是會給出一個例子：測試。
說在應用中，需要一個依賴於應用狀態和本地存儲的服務用來通過一個rest API來執行服務端存儲，當我們測試我們的controller時，不必和服務端進行通信，畢竟只是在測試controller而已。僅添加一個與我們最初組件相同的mock服務，注入器能夠確保controller獲得一個虛擬的服務，controller自身不必也不需要了解這種差異。
4.以測試驅動的開發
這部分是一個架構的第三部分，但是他是很重要的，以至於需要將它放在最重要的位置。
在所有見過的，用過的以及寫過的jQuery插件中，有多少具有一套測試組件呢？其實並不多，這是因為jQuery在測試上不易控制，但是AngularJS卻與此不同。
在jQuery中，測試的唯一方法是使用一個demo頁去創建一個獨立組件來使得的測試可以執行dom操作。接下來我們必須開發一個獨立的組件然後將它集成到的應用中來，這是多不方便啊！在很多情況下，當使用jQuery開發實際上是做了很多重復開發而不是以測試驅動的開發，
但是在AngularJS中我們可以關注分離點，所以可以做一些測試驅動的開發。
5.從概念上講，指令不是打包的jQuery
你常常聽說，dom操作只能在指令中，這是必須的，你必須嚴肅對待。
深入討論，
某些指令僅僅是裝飾視圖（例如ngClass），因此有時候直接操作dom是可以的，但是當一個指令類似於一個小物件並且擁有自己的模板，那麼它應該當做一個分離的關注點，這就是說，它的模板需要和link中的執行邏輯以及其他controller函數分離開。
AngularJS擁有一整套的工具可以是這種分離更簡單，使用ngClass指令，可以動態地更新class,使用ngBind可以進行雙向數據綁定，使用ngShow和ngHide 我們
可以採用編程的形式顯示和隱藏一個元素，也包括自己寫的很多指令。換句話說，可以不用Dom操作而完成所有工作，dom操作越少，指令越容易測試，越容易指定他們的style屬性，就越容易在將來改變他們，那麼他們就越容易復用和分發。
看過很多AngularJS新手使用指令封裝一大串 jQuery代碼，換句話說，既然不能在controller裡面進行dom操作，那麼我可以將他放在指令中，雖然這相對於直接操作dom好很多，但是任然是錯誤的。
看看在上面的記錄，即使我們將其放在一個指令中，任然需要以Angular的方式去操作它，這種方式不執行dom操作！在很多時候dom操作是需要的，但是這種情況比你想的要少得多。當需要做dom操作的時候先問問自己這里是否必須這樣做，這才是一種更好的方式。
總結
不要總使用jquery ,甚至不要去引用它，它會阻止你前進，當回到這個問題—你知道你怎麼在AngularJS中以jquery方式解決問題，但是當你使用諸如$等選擇器時，你要想想它們實際上是禁錮了AngularJS，如果你不知道怎麼不用jQuery實現，那麼去請教別人，一次一次去問，最好的方式是不需要使用jQuery，使用jQuery只會導致你的工作量提升。
❸ 對比jQuery和AngularJS的不同思維模式
jQuery是dom驅動，AngularJS是數據驅動，這里有一篇文章闡述的非常好，建議看看
本文來自StackOverFlow上How do I 「think in AngularJS」 if I have a jQuery background?一題中得票最高的回答。該回答得票超過3000次，回答者Josh David Miller是活躍於開源社區的開發者，也是Emergenesis公司的聯合創始人。該答案最初由數雲架構師韓錚翻譯並發布在自己的博客上，在徵得Josh同意後由韓錚本人推薦給 InfoQ進行分享，並在經過InfoQ社區編輯崔康審校後發布在此。
1. 不要先設計頁面，然後再使用DOM操作來改變它的展現
在jQuery中，你通常會設計一個頁面，然後再給它動態效果。這是因為jQuery的設計就是為了擴充DOM並在這個簡單的前提下瘋狂的生長的。
但是在AngularJS里，必須從頭開始就在頭腦中思考架構。必須從你想要完成的功能開始，然後設計應用程序，最後來設計視圖，而非「我有這么一個DOM片段，我想讓他可以實現XXX效果」。
2. 不要用AngularJS來加強jQuery
類似的，不要以這樣的思維開始：用jQuery來做X，Y和Z，然後只需要把AngularJS的models和controllers加在這上面。這在剛開始的時候顯得非常誘人，這也是為什麼我總是建議AngularJS的新手完全不使用jQuery，至少不要在習慣使用「Angular Way」開發之前這么做。
我在郵件列表裡看到很多開發者使用150或200行代碼的jQuery插件創造出這些復雜的解決方案，然後使用一堆callback函數以及$apply把它粘合到AngularJS里，看起來復雜難懂；但是他們最終還是把它搞定了！問題是在大多數情況下這些jQuery插件可以使用很少的AngularJS代碼重寫，而且所有的一切都很簡單直接容易理解。
這里的底線是：當你選擇解決方案時，首先「think in AngularJS」；如果想不出一個解決方案，去社區求助；如果還是沒有簡單的解決方案，再考慮使用jQuery。但是不要讓jQuery成為你的拐杖，導致你永遠無法真正掌握AngularJS。
3. 總是以架構的角度思考
首先要知道Single-page應用是應用，不是網頁。所以我們除了像一個客戶端開發者般思考外，還需要像一個伺服器端開發者一樣思考。我們必須考慮如何把我們的應用分割成獨立的，可擴展且可測試的組件。
那麼如何做到呢？如何「think in AngularJS」？這里有一些基本原則，對比jQuery。
視圖是「Official Record」
在jQuery里，我們編程改變視圖。我們會將一個下拉菜單定義為一個ul ：
<ul class="main-menu">
<li class="active"> <a href="#/home">Home</a> </li>
<li> <a href="#/menu1">Menu 1</a>
<ul>
<li><a href="#/sm1">Submenu 1</a></li>
<li><a href="#/sm2">Submenu 2</a></li>
<li><a href="#/sm3">Submenu 3</a></li>
</ul>
</li>
<li> <a href="#/home">Menu 2</a> </li>
</ul>
在jQuery里，我們會在應用邏輯里這樣啟用這個下拉菜單：
$('.main-menu').dropdownMenu();
當我們只關注視圖，這里不會立即明顯的體現出任何（業務）功能。對於小型應用，這沒什麼不妥。但是在規模較大的應用中，事情就會變得難以理解且難以維護。
而在AngularJS里，視圖是基於視圖的功能。ul聲明就會像這樣：
<ul class="main-menu" dropdown-menu> ... </ul>
這兩種方式做了同樣的東西，但是在AngularJS的版本里任何人看到這個模版都可以知道將會發生什麼事。不論何時一個新成員加入開發團隊，他看到這個就會知道有一個叫做dropdownMenu的directive作用在這個標簽上；他不需要靠直覺去猜測代碼的功能或者去看任何代碼。視圖本身告訴我們會發生什麼事。清晰多了。
首次接觸AngularJS的開發者通常會問這樣一個問題：如何找到所有的某類元素然後給它們加上一個directive。但當我們告訴他：別這么做時，他總會顯得非常的驚愕。而不這么做的原因是這是一種半jQuery半AngularJS的方式，這么做不好。這里的問題在於開發者嘗試在 AngularJS的環境里「do jQuery」。這么做總會有一些問題。視圖是official record（譯者註：作者可能想表達視圖是一等公民）。在一個directive外，絕不要改變DOM。所有的directive都應用在試圖上，意圖非常清晰。
記住：不要設計，然後寫標簽。你需要架構，然後設計。
數據綁定
這是到現在為止最酷的AngularJS特性。這個特性使得前面提到的很多DOM操作都顯得不再需要。AngularJS會自動更新視圖，所以你自己不用這么做！在jQuery里，我們響應事件然後更新內容，就像這樣：
$.ajax({
url: '/myEndpoint.json',
success: function ( data, status ) {
$('ul#log').append('<li>Data Received!</li>');
}
});
對應的視圖:
<ul class="messages" id="log"> </ul>
除了要考慮多個方面，我們也會遇到前面視圖中的問題。但是更重要的是，需要手動引用並更新一個DOM節點。如果我們想要刪除一個log條目，也需要針對DOM編碼。那麼如何脫離DOM來測試這個邏輯？如果想要改變展現形式怎麼辦？
這有一點凌亂瑣碎。但是在AngularJS里，可以這樣來實現：
$http('/myEndpoint.json').then(function (response) {
$scope.log.push({
msg: 'Data Received!'
});
});
視圖看起來是這個樣子的：
<ul class="messages"> <li ng-repeat="entry in log"></li> </ul>
但是其實還可以這樣來做：
<div class="messages"> <div class="alert" ng-repeat="entry in log"> </div> </div>
現在如果我們想使用Bootstrap的alert boxes，而不是一個無序列表，根本不需要改變任何的controller代碼！更重要的是，不論log在何處或如何被更新，視圖便會隨之更新。自動的。巧妙！
盡管我沒有在這里展示，數據綁定其實是雙向的。所以這些log信息在視圖里也可以是可編輯的。只需要這么做：
<input ng-model="entry.msg" />
。簡單快樂。
清晰的模型（Model）層
在jQuery里，DOM在一定程度上扮演了模型的角色。但在AngularJS中，我們有一個獨立的模型層可以靈活的管理。完全與視圖獨立。這有助於上述的數據綁定，維護了關注點的分離（獨立的考慮視圖和模型），並且引入了更好的可測性。後面還會提到這點。
關注點分離
上面所有的內容都與這個願景相關：保持你的關注點分離。視圖負責展現將要發生的事情；模型表現數據；有一個service層來實現可復用的任務；在 directive裡面進行DOM操作和擴展；使用controller來把上面的東西粘合起來。這在其他的答案里也有敘述，我在這里只增加關於可測試性的內容，在後面的一個段落里詳述。
依賴注入
依賴注入幫我們實現了關注點分離。如果你來自一個伺服器語言（java或php），可能對這個概念已經非常熟悉，但是如果你是一個來自jQuery的客戶端開發者，這個概念可能看起來有點傻而多餘。但其實不是的。。。
大體來講，DI意味著可以非常自由的聲明組件，然後在另一個組件里，只需要請求一個該組件的實例，就可以得到它。不需要知道（關心）載入順序，或者文件位置，或類似的事情。這種強大可能不會立刻顯現，但是我只提供一個（常見。。）的例子：測試。
就說在你的應用里，我們需要一個服務通過REST API來實現伺服器端存儲，並且根據不同的應用狀態，也有可能使用（客戶端）本地存儲。當我們運行controller的測試時，不希望必須和伺服器交互 —— 畢竟是在測試controller邏輯。我們可以只添加一個與本來使用的service同名的mock service，injector會確保controller自動得到假的那個service —— controller不會也不需要知道有什麼不同。
說起測試……
4. 總是 —— 測試驅動開發
這其實是關於架構的第3節。但是它太重要了，所以我把它單獨拿出來作為一個頂級段落。
在所有那些你見過，用過或寫過的jQuery插件中，有多少是有測試集的？不多，因為jQuery經不起測試的考驗。但是AngularJS可以。
在jQuery中，唯一的測試方式通常是獨立地創建附帶sample/demo頁面的組件，然後我們的測試在這個頁面上做DOM操作。所以我們必須獨立的開發一個組件，然後集成到應用里。多不方便！在使用jQuery開發時，太多的時間，我們挑選迭代而非測試驅動開發。誰又能責怪我們呢？
但是因為有了關注點分離，我們可以在AngularJS中迭代地做測試驅動開發！例如，想要一個超級簡單的directive來展現我們的當前路徑。可以在視圖里聲明：
<a href="/hello" when-active>Hello</a>
OK，現在可以寫一個測試：
it('should add "active" when the route changes', inject(function () {
var elm = $compile('<a href="/hello" when-active>Hello</a>')($scope);
$location.path('/not-matching');
expect(elm.hasClass('active')).toBeFalsey();
$location.path('/hello');
expect(elm.hasClass('active')).toBeTruthy();
}));
執行這個測試來確認它是失敗的。然後我們可以開始寫這個directive了：
.directive('whenActive', function ($location) {
return {
scope: true,
link: function (scope, element, attrs) {
scope.$on('$routeChangeSuccess', function () {
if ($location.path() == element.attr('href')) {
element.addClass('active');
} else {
element.removeClass('active');
}
});
}
};
});
測試現在通過了，然後我們的menu按照請求的方式執行。開發過程既是迭代的也是測試驅動的。太酷了。
5. 概念上，Directives並不是打包的jQuery
你經常會聽到「只在directive里做DOM操作」。這是必需的。請給它應有的尊重！
但讓我們再深入一點……
一些directive僅僅裝飾了視圖中已經存在的東西（想想ngClass）並且因此有時候僅僅直接做完DOM操作然後就完事了。但是如果一個 directive像一個「widget」並且有一個模版，那麼它也要做到關注點分離。也就是說，模版本身也應該很大程度上與其link和 controller實現保持獨立。
AngularJS擁有一整套工具使這個過程非常簡單;有了ngClass我們可以動態地更新class；ngBind使得我們可以做雙向數據綁定。ngShow和ngHide可編程地展示和隱藏一個元素；以及更多地 —— 包括那些我們自己寫的。換句話說，我們可以做到任何DOM操作能實現的特性。DOM操作越少，directive就越容易測試，也越容易給它們添加樣式，在未來也越容易擁抱變化，並且更加的可復用和發布。
我見過很多AngularJS新手，把一堆jQuery扔到directive里。換句話說，他們認為「因為不能在controller里做DOM操作，就把那些代碼弄到directive里好了」。雖然這么做確實好一些，但是依然是錯誤的。
回想一下我們在第3節里寫的那個logger。即使要把它放在一個directive里，我們依然希望用「Angular Way」來做。它依然沒有任何DOM操作！有很多時候DOM操作是必要的，但其實比你想的要少得多！在應用里的任何地方做DOM操作之前，問問你自己是不是真的需要這么做。有可能有更好的方式。
這里有一個示例，展示出了我見過最多的一種模式。我們想做一個可以toggle的按鈕。（注意：這個例子有一點牽強、啰嗦，這是為了表達出使用同樣方式處理問題的更復雜的情況。）
.directive('myDirective', function () {
return {
template: '<a class="btn">Toggle me!</a>',
link: function (scope, element, attrs) {
var on = false;
$(element).click(function () {
if (on) {
$(element).removeClass('active');
} else {
$(element).addClass('active');
}
on = !on;
});
}
};
});
這里有一些錯誤的地方。首先，jQeury根本沒必要出現。我們在這里做的事情都根本用不著jQuery！其次，即使已經將jQuery用在了頁面上，也沒有理由用在這里。第三，即使假設這個directive依賴jQuery來工作，jqLite(angular.element)在載入後總會使用jQuery！所以我們沒必要使用$ —— 用angular.element就夠了。第四，和第三條緊密關聯，jqLite元素不需要被$封裝 —— 傳到link里的元素本來就會是一個jQuery元素！第五，我們在前面段落中說過，為什麼要把模版的東西混到邏輯里？
這個directive可以（即使是更復雜的情況下！）寫得更簡單：
.directive('myDirective', function () {
return {
scope: true,
template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
link: function (scope, element, attrs) {
scope.on = false;
scope.toggle = function () {
scope.on = !$scope.on;
};
}
};
});
再一次地，模版就在模版里，當有樣式需求時，你（或你的用戶）可以輕松的換掉它，不用去碰邏輯。重用性 —— boom！
當然還有其他的好處，像測試 —— 很簡單！不論模版中有什麼，directive的內部API從來不會被碰到，所以重構也很容易。可以不碰directive就做到任意改變模版。不論你怎麼改，測試總是通過的。
所以如果directive不僅僅是一組類似jQuery的函數，那他們是什麼？Directive實際是HTML的擴展。如果HTML沒有做你需要它做的事情，你就寫一個directive來實現，然後就像使用HTML一樣使用它。
換句話說，如果AngularJS庫沒有做的一些事情，想想開發團隊會如何完成它來配合ngClick，ngClass等。
總結
不要用jQuery。連include也不要。它會讓你停滯不前。如果遇到一個你認為已經知道如何使用jQuery來解決的問題，在使用$之前，試試想想如何在AngularJS的限制下解決它。如果你不知道，問！20次中的19次，最好的方式不需要jQuery。如果嘗試使用jQuery會增加你的工作量。
這是我目前最長的Stack Overflow回答。事實上，這個答案太長了，我都要填一個Captcha了。但是就如我常說的：能說多時候說的少其實就是懶。
希望這個答案對你有用。