做單頁應用，路由跳轉時我要把參數帶在URL上，產品經理說要放 window 下面帶過去，我該怎麼解釋？
產品要我上知乎提個問題，看看是各路網友挺哪種
把參數掛在URL上。
別的不說，如果你把這個做對的話，做測試的哥們一定會感激你的（也包括你自己）。
掛在window上，要隔離重現某一個場景，你得從應用的入口開始手工一步一步走到目標場景。這是一個浪費時間，變數多，又極易出錯的過程。很多開發和測試間「在我的機子上能跑到你那裡咋就不行了」「你不該這麼操作應該這麼操作」的撕逼大戰就是這麼開始的。
還是都掛在URL上吧。在JIRA／郵件／微信里，一行URL全解決。
充分利用URL來編碼app的狀態，有助於以後轉到原生app上。iOS和Android都支持特定域名用app打開。
URL編碼狀態有助於讓搜索引擎收錄特定想被收錄的頁面。
要做server side rendering你必須要用URL編碼。
用好URL編碼，給你自己，給測試，做搜索引擎優化，做app的哥們一條生路。
這道題得分情況來看：通過url攜帶參數的方式適用於數據永久有效的情況；掛載window的方式適用於數據本次訪問有效的情況。
舉個例子，從一個列表頁面點擊其中一個項目，跳轉到該項目的詳情頁面，這時候應該使用url攜帶一個id，然後在詳情頁面通過獲取url中的id去載入該項目的相關內容；而使用window來傳參的話，如果我在詳情頁面，這時候我瀏覽器一刷新，數據就丟失了，這個詳情頁面就沒有任何意義了，也不能分享出去。
再舉個例子，有一個抽獎頁面，點擊頁面上的按鈕，頁面向後台發送請求抽獎，返回抽獎信息，然後對應跳轉到一個對應的結果頁面（中獎或者不中獎），這時候就不適合使用url來傳遞中獎或是不中獎的信息，因為我如果中獎了，那我保存了這個頁面，就可以無限次找客服領獎了；如果我使用window掛載中獎信息，那我頁面一刷新，這個信息就丟失了，當次的中獎結果就不會被多次使用了。順便說一句，在結果頁面我可以做一個判斷，如果window沒有攜帶中獎或不中獎信息，說明用戶不是抽了獎再跳轉過來的，那我就跳回到抽獎頁就可以了。
當然，以上只是針對你提到的兩種選擇，其實相比掛載window，還有很多更優的處理方案，原理一樣。比如你可以在根級別的組件上保存數據，然後每個頁面都可以通過props獲取到，實現全局共享；你還可以使用狀態管理的插件，比如redux或者vuex等，來幫你託管這些公共數據，實現全局共享；最簡單的，你單獨把數據保存在一個文件里，變成一個模塊，然後在需要使用到的頁面里require或者import進來，就能在各個頁面里獲取和修改數據了，還不用擔心命名衝突問題。最差最差的情況，用cookie和storage保存數據的方式不也比你掛在window下強～
最後，不要跟外行人談技術，因為最後你會發現你根本沒辦法完全讓他懂行，反倒是浪費了很多幹活的時間；即便是同行，有時候一些經驗之談他沒經歷過也不是能夠理解的。
以上！
我覺得你應該聽產品的。比如把參數掛window .location .href上。。。
產品經理也兼職技術方面的工作么？或許需要請一個技術經理來壓陣了。
雖然是單頁應用，但跳轉頁面（URL）並傳遞參數的功能依然需要將附加信息寫到 URL 中，這樣新頁面的 URL 就是永久的。
比如用戶訪問知乎的這個問題頁面 http://zhihu.com/question/62611638 ，單頁應用中 URL 可能寫成 #/question/[questionId] 或 ?question=[questionId]，這樣瀏覽器在訪問這個 URL 時可以直達目標頁面。
如果把 questionId 參數寫到 window 中，讓用戶在開發者工具中輸入 window.question=[questionId] 來訪問？
當然，這種方式僅限跳轉新頁面，且該動作是冪等 冪等 的情況。
另一種情況是做非冪等操作，比如添加物品到購物車，操作完成後打開購物車頁面。這種操作不應該簡單地通過 URL 實現（如 #/cart?item=[itemId]quantity=2），否則每次訪問這個 URL，都會往購物車中添加兩個同樣的物品。
注意，這個添加物品到購物車的操作也不應該簡單地通過 window 傳參數來實現。window 上就不該添加什麼東西上去，readonly 比較好。
沉住氣，好好解釋，別打人。
在我的理解中，前後端通過HTTP進行的通信基本只有四種方式吧，GET/PST/PUT/DELETE
而這個題目的問題，其實是，url參數 vs request body吧
url參數的特點是，誰都看得到，瀏覽器歷史記錄直接點就可以喜加一，四種方法通用，長度限制
用請求體的話，GET沒有請求體，不能直接看到，喜加一比較麻煩，如果人家想喜加一的話依然是可以的，想寫啥寫啥因為是contentLength控制的
所以其實我覺得，如果傳遞的東西比較小的話，沒人規定不能用url參數，除非有很好的用POSTrequest body的理由這你不噴死他 留著過年啊 技術的事產品摻合個雞兒啊
要麼解釋清楚，要麼一個字。就是干。參數不多的情況下，肯定url帶過去。參數非常多非常大的話？我還真不知道怎麼傳。掛window盡量少用少跟外行斯比。少跟外行斯比。少跟外行斯比。
那用戶複製url再訪問不就完蛋了
放window是啥？window.navigate？
不放url的話，還能怎麼辦？
產品經理自認為懂一點，這種是最憂傷的，這個時候就看你的實力了。論開發過程中最重要一課-----手撕每一個逼。
其實很多時候老大就是過來裝個逼，你如果開始就是用的在window下，那他可能又會讓你用url了
既然你們做的是單頁應用，應該用框架吧，比如說vue、ng，如果用了的話，用window傳參，真的就是一個很傻的行為。如果沒用或者是公司自己封裝的，那就根據封裝的套路玩就好，window傳參，被污染了，誰都不知道，而且f12直接就能查看
順帶提一句，如果你們的產品和架構是一個，那就考慮跳槽吧。
不是的話，技術方面的問題，讓產品經理，有多遠滾多遠。分享外鏈就掛在url上，不分享外鏈就隨意啊
你直接跟產品說，我說怎麼做就怎麼做，要不你行你來干。不能培養他這種習慣，要不他們喜歡騎在你頭上。
首先看你要傳遞的是什麼參數，不說場景談方案都是耍流氓