『壹』 如何處理前端js跨域問題
前端跨域的解決方法非常的多，簡單的給你介紹一下吧。
iframe解決跨域，這種方法也比較常見
JSONP解決跨域，簡單，易上手
postMessage解決跨域，使用了比較新H5 API，所以存在一定的兼容問題；
伺服器代由訪問，方法對前端影響不大，但是後台相對會麻煩很多。
希望對您有幫助吧~~
『貳』 語音識別的前端處理
前端處理是指在特徵提取之前，先對原始語音進行處理，部分消除雜訊和不同說話人帶來的影響，使處理後的信號更能反映語音的本質特徵。最常用的前端處理有端點檢測和語音增強。端點檢測是指在語音信號中將語音和非語音信號時段區分開來，准確地確定出語音信號的起始點。經過端點檢測後，後續處理就可以只對語音信號進行，這對提高模型的精確度和識別正確率有重要作用。語音增強的主要任務就是消除環境雜訊對語音的影響。目前通用的方法是採用維納濾波，該方法在雜訊較大的情況下效果好於其它濾波器。
『叄』 什麼是前端處理機
前端處理機：前端處理機一般是小型或微型機，專門為大型主幹計算機處理數據通信控制功能。前端處理機能夠控制對網路的存取並允許注冊過的用戶才能使用系統；對信息指定優先權；登記所有的數據通信活動；統記全部網路活動；在網路鏈路間路由信息，大大釋放了大型主幹計算機的數據通信控制功能，使主機能從事其它信息處理任務。
lynn發表於2005-6-8 11:47:00
『肆』 幾個有效的前端數據處理的方法
一、JSON對象過濾數據（處理復雜數據時可以直接在內部過濾掉）
封裝方法：
function getTargetObject(targetObject, propsArray){if(typeof(targetObject) !=="object"|| !Array.isArray(propsArray)) {thrownewError("參數格式不正確"); }constresult = {};Object.keys(targetObject).filter(key=>propsArray.includes(key)).forEach(key=>{ result[key] = targetObject[key]; })returnresult;}
使用方法：
let arr = {a: '1', b:'2', c: '3'}
getTargetObject(arr, ['a', 'b'])
引用網站： https://segmentfault.com/q/1010000016133960/a-1020000016134570
二、數組切割（當後端傳來數據過多的時候，將數據切成幾個等分，用戶下拉的時候再展示）
* 將一個數組分成幾個同等長度的數組 * array[分割的原數組] * size[每個子數組的長度]
*/functionsliceArray(array, size) {
varresult = [];
for(varx = 0; x < Math.ceil(array.length / size); x++) {
varstart = x * size;
varend = start + size;
result.push(array.slice(start, end));
} returnresult }
引用網站： https://..com/question/941679549069381612.html?fr=iks&word=js%CA%FD%D7%E9%C7%D0%B7%D6&ie=gbk
三、數據過濾（使用JSON.stringify方法）
數據： persons: [
{apple: '蘋果'},
{watermelon: '西瓜'},
{lemon: '檸檬'},
{Blueberry: '藍莓'},
{orange: '橙子'}],
方法： handChange() {
let oneFruits = JSON.stringify(this.persons, function (inx, ite) {
if (inx === 'watermelon' || inx === 'orange') {
return undefined
} else {
return ite } })
this.persons = JSON.parse(oneFruits) }
結果：
四、通過$set給數據注入值並更新視圖（解決在vue中新增數據不更新視圖的問題）
數據： persons: [
{id: '1',name: '蘋果'},
{id: '2',name: '西瓜'},
{id: '3',name: '檸檬'},
{id: '4',name: '藍莓'} ]
方法： handChange() {
let oneFruits = JSON.parse(JSON.stringify(this.persons[0]))
let twoFruits = JSON.parse(JSON.stringify(this.persons[1]))
let newFruits = {id: '5', name: '葡萄'}
console.log(twoFruits)
this.$set(this.persons, 1, oneFruits) // 將西瓜的位置放上蘋果
this.$set(this.persons, 0, twoFruits) // 將蘋果的位置方式西瓜
this.$set(this.persons, 4, newFruits) // 添加葡萄並更新視圖
console.log(this.persons) }
結果：
『伍』 前端如果有成千上萬的頁面該如何處理
一、圖片處理
1. 圖片：大小的控制與使用
以淘寶為例，你搜索的所有產品的列表頁面，每個產品都有一個概略圖（小圖），
點開一個產品的頁面可以看到產品展示圖（中圖），點擊圖片後可以看到原始圖（大圖），如果上面提到的三個頁面都用用戶上傳的原始圖，僅用控制顯示大小，頁面性能如何，可想而知，用PC機還好，如果用戶用移動設備加3G網路訪問，5分鍾也打不頁面，就是打開了，流量也用完了。
所以我們說為你的網站針對不同的情況不同的頁面，採用不同的圖像文件，當然屏幕解析度也要考慮進去，如果有人用iphone打開和ipad打開，就不需要顯示像PC機上那麼大的圖片了，只要適應設備就可以了，那你可能要問怎麼做。
通過CSS Media Querises,可以輕松做到，你可以訪問http://css-tricks.com/snippets/css/media-queries-for-standard-devices/ 了解更多信息：
/* Smartphones (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 320px)
and (max-device-width : 480px) {
/* Styles */
}
/* Smartphones (landscape) ----------- */
@media only screen
and (min-width : 321px) {
/* Styles */
}
/* Smartphones (portrait) ----------- */
@media only screen
and (max-width : 320px) {
/* Styles */
}
/* iPads (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px) {
/* Styles */
}
/* iPads (landscape) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : landscape) {
/* Styles */
}
/* iPads (portrait) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : portrait) {
/* Styles */
}
/* Desktops and laptops ----------- */
@media only screen
and (min-width : 1224px) {
/* Styles */
}
/* Large screens ----------- */
@media only screen
and (min-width : 1824px) {
/* Styles */
}
/* iPhone 4 ----------- */
@media
only screen and (-webkit-min-device-pixel-ratio : 1.5),
only screen and (min-device-pixel-ratio : 1.5) {
/* Styles */
}
2. 壓縮
傳送圖像的時候單單控制適當的尺寸往往是不夠的。不少文件格式在不失真的前提下可以被壓縮很多。有一類應用程序可以達到這個效果。比如Photoshop有個很好的功能叫做Save for Web and Devices，還有我個人覺得多用PNG是個可以考慮的方案
3. Sprite
增加應用程序性能的方法之一，是減少到伺服器的請求數。每一個新圖像代表一個請求數。有一個辦法是將幾個圖片合並成一個，合並之後的圖像叫做一個sprite，這個功能在淘寶你也會發現，在CSS中改變背景層的位置，就能准確的把特定部分的圖像顯示出來。比如Twitter Bootstrap利用sprites來製作內部圖標，訪問http://getbootstrap.com/2.3.2/ 你會了解更多
在CSS中，你可以參照以下方式，顯示你喜歡的sprite部分：
.icon-edit {
background-image: url("../img/glyphicons-halflings-white.png
");
background-position: -96px -72px;
}
4. 超高速緩存
瀏覽器超高速緩存十分好用。盡管有時在開發過程中會導致一些非常有趣的情況，但它確實有助於提高你的網站的性能。所有瀏覽器的超高速緩存下來的內容包括圖片、JavaScript或者CSS。有幾種方法可以控制緩存，建議你閱讀相關文章。
5. 預讀取
HTML 5有一個很好的功能叫做預讀取，它讓瀏覽器提前下載你馬上需要用到的資源：
<link rel="prefetch" href="/images/background.jpg">
6. 數據URI方案/內聯圖像
幾年前我曾開發了一個簡單的網頁，只包含一個HTML文件夾，但當然裡面應該還包括一些我需要的圖像。數據URI方案幫助我解決了問題。我們的想法是將圖像轉換成一個base64編碼的字元串，並將其放置在src屬性中的img標簽里，例如：
Html代碼
<img src="data:image/png;base64,//8/==" alt="Red dot">
通過這種方法，你的圖像實際上在HTML中並保存了一個HTTP請求。你的圖像越大的話，字元串就越長。
『陸』 前端如何盡量正確地處理ajax的異常
如今前端領域是MVVM框架的天下，組件庫也層出不窮，但是，並沒有一個知名的組件庫提供ajax異常的成熟解決方案，所以今天我們就來研討一下，如何盡量正確地處理異常。
從業務上簡單說，凡是code不是200的，都是異常。這里code可以是HTTP狀態碼，也可以是響應體的code，就不細究了，反正本質沒差別。然後，根據code的不同，又可以細分成401 403 404 500等等。
如果你的後端夥伴以HTTP狀態碼表示404，以響應體code表示其他錯誤，而且你又無法勸說他們，那麼你應在axios的攔截器里把各種情況全考慮進去，比如：
超時很簡單，axios也支持，設定超時閾值即可。超時跟無響應的區別是，超時意味著HTTP三次握手成功，但是得不到響應體，瀏覽器知道介面是存在的，但是響應體又在規定時間內沒有拿到。無響應是根本無法HTTP握手，也就無法獲知介面存在。
處理超時，通常做法是在攔截器里重新請求一遍，還是超時的話就視為伺服器錯誤。
得不到響應又分成2種，可能是網斷了，也可能是伺服器停機了。
苛刻地說，你應分辨這2種情況，並給出不同的提示，畢竟網斷了，用戶可以尋找別的聯網方式，而伺服器停機了就給個重連按鈕，讓用戶有事沒事的嘗試重連一下。
關於解決方案，首先說，XHR對象無法區分到底斷網還是伺服器停機，axios對於2種情況都返回'Network Error'。在得到這個反饋之後，你接下來可以有這2種解決辦法：
你可以將 https://api.map..com/images/blank.gif 改成其他伺服器穩定且位元組小的圖片。或許你可以做一張幾位元組的圖片，傳到一個非常牛逼的CDN上。
MDN手冊： https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/connection
它不支持IE，就算你不在乎這一點，那麼它是不是一定準呢？對於需要登錄的VPN網路，它是否准呢？我也不知道，總體說，它真的不是最佳的方案。我推薦用方案1。
很簡單，分為3種：
通常，一個介面，只需要按照其中一種去處理即可，優先順序就是上面書寫順序。
容器內錯誤提示肯定是內容區的介面出錯才會出現。
處理方式：
局部報錯比較容易理解，比如一個List的介面出錯，那麼，上策是應當給這個容器盡量撐高到有內容時的高度，然後居中給一個錯誤圖標和錯誤描述。中策是不考慮有內容時候的高度，只讓錯誤提示和錯誤描述撐起一定高度即可。都不算錯。如果容器很小，比如就是一個3位數值，那麼用一個 - 表示錯誤也可以。
頁面整體報錯稍微復雜，比如一個左右結構的內容管理系統，前置介面有userInfo介面、全局字典介面、全局路由介面等，這些介面與眾不同的地方在於它們是基礎介面，它們出錯的話，網站乾脆就不能用，頁面骨架也是錯亂的，這種情況下可以有2種解決辦法：一是跳轉到專門的5xx報錯頁面，頁面中央有錯誤圖標、錯誤提示，以及「返回上一頁」的按鈕；二是用白板遮罩覆蓋瀏覽器視口，居中放一個錯誤圖標和錯誤文字以及「刷新頁面」的按鈕，本質是用一個fixed的遮罩壓住瀏覽器全部面積。用哪種方案都可。所以你要做的是決定哪些介面屬於全局報錯，哪些介面屬於局部報錯，並做不同的處理。
報錯內容：
根據ajax異常的分類，可能至少能分出3種：網路錯誤、伺服器宕機、伺服器錯誤。具體用什麼圖標和文字我就不多說了。
組件化：
容器內報錯應盡量組件化。該放返回上一頁或刷新按鈕的，一定要放按鈕。
排他性：
只要做了容器內報錯，就不要做另外報錯了。這也說明了一點，就是在axios攔截器里彈toast或者modal是愚蠢的方案，我在別的文章也提到過這種觀點。不做容器內報錯的情況，才應該考慮其他3種情況。
什麼樣的場景下使用容器隱藏？
比如頁面有一個角落顯示你的粉絲數、關注數、評論量……。如果有獲取到數據，則讓這個容器出現，沒有的話，則容器就保持隱藏。這一類場景往往應用於非主要內容，比如側邊欄的小內容塊。
由於這只適用於非主要內容，那麼主要內容也會有它自己的報錯，所以，你不必擔心用戶看不到「網路出錯」這類錯誤提示。
先簡單對比一下toast和modal。
很簡單，toast就是輕提示，不需要手動關閉，modal就是重提示，需要手動關閉。採用哪個，只要站在用戶角度思考問題就好了。比如有人說，異常應當用重提示。可以這么絕對化么？不可以。比如你在某個頁面點贊，提示你 「您已經點過贊了」 ，這用重提示嗎？肯定toast就夠了。同樣的，成功提示一定用輕提示嗎？比如提示 「感謝參與，工作人員將在3~5個工作日內聯系你」 ，這么長，能toast？能一閃而過？
什麼介面適用彈出提示？簡單說，只要跟UI顯示不相乾的，都最好是使用彈出提示。比如這幾種場景：
先說上傳數據斷網之類的錯誤，通常用modal，因為modal能夠攔截用戶動作，避免重復上傳，而且，還能給用戶足夠的時間讓用戶看清楚出錯原因，避免無謂的重試。
然後說數據內容錯誤，無論是表單提交，還是點個贊，錯誤提示一般用toast，畢竟用戶可能只是不小心填錯的，看一眼然後趕緊改正就好了。
最後說401錯誤，有2種做法，一是用modal，因為一般要強制用戶轉到登錄頁，但是轉之前也得讓用戶看明白為什麼要轉，所以可以先modal提示，點擊確定就跳轉到登錄頁；二是用toast，但是需要先跳轉，然後在登錄頁上提示toast「請先登錄」。
警告條
警告條是可關閉的、永久生命的、又不妨礙用戶繼續操作的彈出組件，一般在頁面頂部，或者在用戶操作區域的附近。什麼場景用警告條？
比如的MD編輯器，你只要輸入，就會自動給伺服器發送數據，頻率很快，有時候因為網路或者伺服器的問題，會出現保存失敗的可能性，這時候就會在頁面頂部出現一個比較長時間的警告條，告訴你保存失敗，但你依然可以繼續寫，什麼時候網路正常了，什麼時候toast才會自動消失，當然你也可以手動關閉它。
總之，toast、modal、警告條究竟什麼場合使用，要根據產品、業務具體而定，要注意優先使用容器內報錯和容器隱藏。
『柒』 記一下前端處理多非同步方法的思路
有的時候會有一個操作，一部分需要一個非同步請求的回調，另一部分需要另一個一部請求的回調，只有兩個都執行完了才算完整。
用Generator 函數是個不錯的思路。（ 詳細用法鏈接 ）
我的理解就是他是一種分段執行的函數。
定義方法是function和函數名之間有個星號。yield變數是分段的路標。
然後在兩個非同步方法的回調里都調Generator 函數的next方法。它就會先執行一段，再執行一段。
僅僅是個思路。後續有機會試一下行不行。
『捌』 網頁前端 數據處理
如果僅僅是前端項目，可以用localStorage把數據存儲在本地。
因為只是前端項目，沒法寫文件，只能用html5新增的loacalStorage本地存儲保存數據，只需調用幾個簡單的介面就可以完成數據存儲。
另外可以用cookie,sessionStorage，但是這些是有時限的，所以一般推薦用localStorage。