vue-router同路由$router.push不跳轉怎么解決
你的問題可能是如何“刷新”當前頁面
當使用路由參數時，例如從/user/foo導航到/user/bar，原來的組件實例會被復用。
因為兩個路由都渲染同個組件，比起銷毀再創建，復用則顯得更加高效。
不過，這也意味著組件的生命周期鉤子不會再被調用。
復用組件時，想對路由參數的變化作出響應的話，$route.push無效，你可以簡單地watch(監測變化)$route對象：
constUser={
template:'...',
watch:{
'$route'(to,from){
//對路由變化作出響應...
}
}
}
或者使用2.2中引入的beforeRouteUpdate導航守衛：
constUser={
template:'...',
beforeRouteUpdate(to,from,next){
//reacttoroutechanges...
//don'tforgettocallnext()
}
}
如何是刷新當前頁面的話可使用先push到一個空頁再push回來，但是這個方案回導致一個空白效果，常用的是再app.vue定義一個reload方法，再子頁面中調用
//app.vue
<template>
<router-viewv-if="isRouterAlive"></router-view>
</template>
<script>
exportdefault{
name:"App",
provide(){
return{
routerReload:this.reload
};
},
data(){
return{
isRouterAlive:true
};
},
methods:{
reload(){
this.isRouterAlive=false;
this.$nextTick(()=>(this.isRouterAlive=true));
}
}
};
</script>
//頁面
exportdefault{
inject:["routerReload"],
methods:{
reload(){
this.routerReload()
}
}
}
vue刷新某個路由就404了是不是服務器還要配置什么
直接訪問url會被httpserver直接解析到該文件路徑，但是spa的路由是虛擬的，并不能直接找到這個file，所以會404；需要把所有的請求全部指向（不知道這么說是不是準確）index，然后讓js的router解析url，nginx需要配置try_files$url/index.html具體可以參考下vue-router的文檔，這一章HTML5History模式講到了這個問題，最近開發reactspa的時候也遇到了同樣的問題，都是因為spa中的路由是js渲染組件的配置，和真實瀏覽器中訪問的url不是一回事
rr是哪個輪子
rr是一個名為"react-router"的JavaScript庫中的一個輪子。
它提供了在React應用程序中實現路由功能的解決方案。
使用react-router，可以方便地定義應用程序的路由規則，并根據不同的URL路徑展示不同的組件內容。
這個庫非常流行，并且被廣泛應用于React開發中。
replace和push的區別
react中push與replace的區別：push跳轉會形成history，可返回到上一層；而replace跳轉不會形成history，不可返回到上一層，適用于登錄后，不需要重新回到登錄頁面。
本教程操作環境：windows7系統、react16版本，DellG3電腦。
react中push與replace的區別
push:a-b-c，可以回到上一級
push跳轉會形成history，可返回到上一層。
語法：
1
this.props.history.push('router地址')
replace:a-b-c回不到上一級適用于登錄后，不需要重新回到登頁面
replace跳轉不會形成history，不可返回到上一層。
語法：
1
this.props.history.replace('router地址')
React解決了前端開發中的哪些痛點
下面我分一下邏輯來詳述一下我對這個問題的見解。
1.前端開發中會有哪些問題需要考慮
2.目前解決這些問題的技術方案
3.React技術棧對上述問題的解決
一、前端開發中會有哪些問題需要考慮
討論這個問題我覺得應該回到問題的本質-【前端開發會考慮些什么問題】，這些問題即是前端開發過程中的痛點也是難點，了解了這些問題才能知道為什么會有React出現，以及React如何解決這些問題的。
首先，對于一個前端團隊來說，在進行前端技術規劃的時候都應該考慮的事情：
組件庫、模塊化
開發效率
運行效率
可維護性
體驗優化
組件庫、模塊化
首先是組件庫，任何一個前端業務團隊都會做的事情就是沉淀組件，公共基礎組件，業務組件，函數工具庫，這對于業界的前端來說是共識。組件庫也就是輪子庫，是提高團隊開發效率的最好方式，同時也是團隊的基礎沉淀（拿KPI的絕佳幫手）
然后是模塊化，在幾年前，經常會看到一個js幾千行的情況，但是基于可維護性和重用性的考慮，會把js拆分成模塊，模塊化的需求已經很普遍，出現了很多如`AMD``CMD``CommonJs``UMD`這些規范，以及`require.js``seaJs``Browserify``webpack`這些工具和庫來解決這些問題。
開發效率
開發效率是前端團隊對業務響應速度的反饋，如果一個業務交給前端團隊過后幾個月都沒有結果那必然會引起上下游的不滿，不管技術做的多棒，選什么框架，最終的目的都是完成業務。那哪些因素會影響開發效率呢？
1.業務代碼架構設計
2.可重用模塊和組件
第一點是業務代碼的架構設計，好的設計能夠極大的減少代碼量和出bug的可能。第二是擁有大量可重用的模塊和組件，能夠快速的實現交互
運行效率
運行效率是用戶體驗的關鍵，對于對效率要求極高的業務場景來說，這可能是選擇框架的第一標準
可維護性
前端開發中大多數在做的事情是：
1.新業務加功能
2.改版
3.解決bug
特別是在大公司的前端更是體會深刻，可能重來沒有做過新業務，都是在維護舊的代碼，填坑加埋坑。如果業務代碼設計差，可閱讀性差，很難定位bug。特別是千奇百怪的MVC設計，大控制器，復雜的Model，想要定位出哪里出了問題真是一件eggache的事情。
體驗優化
體驗已經成了現代化前端開發的必談之物，所以出現了當頁面應用(SPA)，InstantLoading，ApplicationShell]，Progresswebapp這些名詞。
二、目前解決這些問題的技術方案
組件化：webComponent、polymer、x-tag、react、jQuery-plugin、angular-directive
模塊化：webpack、browserify、require.js、sea.js
開發效率：MVC(Backbone)<Flux(React)<MVVM(Angular.js、vue、ember.js)
運行效率：Backbone、React
可維護性：Flux、Redux
現代化的一些框架幾乎都包含組件化的考慮，不過在其他方面各有其優勢，關鍵點是在開發效率和運行效率之間的平衡
三、React技術棧對上述問題的解決
注意我這里提的是React技術棧，并非題主說的React，個人認為在描述React的時候應該是在講React生態體系，那對于上面說的難點痛點在React中一一對應的解決方案。
組件化：React天生組件化，這是React的核心，除了能夠在團隊內部積累業務組件以外，也能找到眾多開源組件的實現
模塊化：基于webpack可以使用Es6或CommonJs的寫法實現模塊化代碼
開發效率：React的代碼基本就是組件的組合，分而治之的方式讓代碼的可閱讀性很高，容易理解。而且相比于MVC幾乎是去除了Controller的角色，只用關心一個render函數，不用關系視圖局部的修改。
運行效率：React實現了VirtualDOM，相比于MVVM框架具有更優的效率
可維護性：React基于flux或redux的架構設計，確定性的store很容易定位問題，無論是新增業務代碼還是查找業務bug都不再是難題
體驗：基于React可以很容易的實現SPA（React-router）
題外話：大多數人說React技術棧的學習成本太高，其實我想說的是真沒有那么難。。。。真的，如果要學React但又苦于沒有系統的學習資源，那我就打個小廣告，最近在維護LeanReact-知乎專欄，會系統的講解React生態的知識，有興趣的朋友可以關注
