掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
在前端開發(fā)過程中，常常遇到各種各樣的問題和坑點。尤其是隨著技術(shù)的不斷發(fā)展和更新，新的問題也不斷涌現(xiàn)。對于初學(xué)者而言，這些問題往往讓人感到十分困惑和無助。因此，本文將旨在探討一些前端開發(fā)過程中常見的問題和坑點以及解決方法，幫助讀者更加深入地了解前端開發(fā)，并解決實際工作中遇到的問題。
/**
* 為什么 010 會是 8
*/
const num1 = 09 // 9
const num2 = 010 // 8這邊是因為 0 開始的數(shù)字js會嘗試先把它轉(zhuǎn)成八進制的數(shù)字。如果你出現(xiàn)大于 8 的數(shù)字，他知道不是八進制還給你轉(zhuǎn)十進制。純粹的八進制應(yīng)該用 0o ，類似的還有 0b 二進制和 0x 十六進制，但是他們寫的不符合轉(zhuǎn)換條件的話會直接報錯。
0.1+0.2 // 0.30000000000000004
2.55.toFixed(1) // '2.5'
2.45.toFixed(1) // '2.5'
2.toFixed(1) // Uncaught SyntaxError: Invalid or unexpected token
2..toFixed(1) // '2.0'js 計算有精度問題呢？大家一定都是知道的， 今天就是來簡單解釋一下為什么會出現(xiàn)丟失精度的問題。這邊其實分兩部分，存儲和展示。存儲的時候 JavaScript 是以 64 位二進制補碼的方式來存儲。由于改方式是以 2 為底進行表示的，所以執(zhí)行某些運算時容易出現(xiàn)誤差、溢出、無限循環(huán)等問題。
圖片
我們可以發(fā)現(xiàn)本來應(yīng)該是 11001100 無限循環(huán)被截斷了，尾號 11001 的時候1被舍去了，然后進了一位 最后存儲成了上圖的 1101 的樣子。所以 0.1 其實存的比 0.1 要大一點點，0.2 也是一樣，而 0.3 比實際小一些。所以計算 0.1+0.2 的時候其實是拿二進制計算的，兩個都偏大的數(shù)字相加 誤差被近一步的放大了。
下面這張圖可以看到他們真實存下來的數(shù)據(jù)轉(zhuǎn)成十進制的樣子。實際顯示的時候會做近似處理，js 會判斷一個數(shù)字特別像 0.1 它就顯示 0.1 了。
圖片
toFixed 問題也是一樣。
圖片
還有就是有時候我們對一個數(shù)字使用 .toFixed .toString 會報錯。
0.toString() // Uncaught SyntaxError: Invalid or unexpected token
// 我們期待的是它會隱性轉(zhuǎn)換讓我們調(diào)用 Number 構(gòu)造函數(shù)上的方法，
// 但是程序會以為你在寫一個小數(shù)，小數(shù)還不合規(guī)，所以報錯了，
// 解決方法就是拿變量裝一下，或者 0..toString()在 JavaScript 中，采用 64 位二進制補碼表示數(shù)值類型，即雙精度浮點數(shù)。符號位(S)、指數(shù)位(E)和尾數(shù)位(M)的比特數(shù)分別為 1 位、11 位和 52 位。在使用 IEEE 754 標準表示雙精度浮點數(shù)時，使用一些特殊的位表示：其中一個隱含位表示數(shù)字 1，在正常項中省略，因此一共有 53 位表示有效數(shù)字。
長度問題：
function fn(a,b,c){
return a+b+c
}
fn.length // 3 一般來說fn的長度是形參的個數(shù) 但是形參有默認值就不同
function fn1(a = 1,b,c){
return a+b+c
}
fn1.length // 0
function fn2(a,b=1,c){
return a+b+c
}
fn2.length //1
// 它只會統(tǒng)計首個默認之前的參數(shù)對象排序問題：
a.b=1
a.a=1
a.c=1
a[2]=2
a[12]=2
a[1]=2
// 結(jié)果 {1: 2, 2: 2, 12: 2, b: 1, a: 1, c: 1}
// 對象的內(nèi)部key value的存儲順序是這樣的
// 如果屬性可以轉(zhuǎn)number，提前上來，按升序排列，其他的字符串屬性按添加的先后順序賦值中斷問題：js 里沒有事務(wù)的機制，不會恢復(fù)到操作之前的狀態(tài)。如果中途失敗了，之前賦值和操作過的數(shù)據(jù)是保留的，失敗后的操作不執(zhí)行。
定時器不準：這里說的不準還不是說一點小誤差。定時器由于渲染主進程阻塞也好，延時任務(wù)嵌套過深也好，事件循環(huán)優(yōu)先級被排隊到后邊也好。這些都可以認為是“誤差”，但是如果說你 setIntervel 是 10ms，結(jié)果它間隔 n 秒調(diào)一次函數(shù)，那可不是誤差了，可能直接會產(chǎn)生 bug。
這個問題的原因是：用戶在使用谷歌瀏覽器的過程中將窗口最小化或切換到其他應(yīng)用程序中去，瀏覽器會將當(dāng)前標簽頁和其中的 JavaScript 定時器掛起，這將導(dǎo)致定時器延遲調(diào)用。通常情況下，瀏覽器會盡可能保持定時器的準確性，并在恢復(fù)標簽頁后立即執(zhí)行延遲的定時器。但是，如果計算機負載過重或其他原因?qū)е?JavaScript 的執(zhí)行速度變慢，定時器可能會更加延遲。經(jīng)過測試，新版本的瀏覽器上基本都是至少 1 秒一次。
圖片
詳細參考 https://developer.mozilla.org/zh-CN/docs/Web/API/setTimeout
競態(tài)問題：異步的競態(tài)問題也是開發(fā)中經(jīng)常遇到的問題。舉個例子用戶輸入搜索就請求相應(yīng)的商品，用戶很快的輸入了“手機殼” 3 個字；“手”“手機”“手機殼” 3 個不同參數(shù)的請求幾乎同時發(fā)了出去，異步請求很難保證哪個請求，先回來哪個請求后回來。那加上防抖呢？其實這也不是防抖該應(yīng)用的場景，弱網(wǎng)環(huán)境下請求 5 秒、10 秒返回都說不準，防抖防幾秒都不太合適。我根據(jù)個人的經(jīng)驗總結(jié)了 3 種方式：
1. 鏈式調(diào)用
// 讓要執(zhí)行的異步函數(shù)通過一個鏈式方式調(diào)用
export class SequenceQueue {
promise = Promise.resolve();
excute (promise) {
this.promise = this.promise.then(() => promise);
return this.promise;
}
};2. 設(shè)置一個疊加器，每次調(diào)用就累加，回調(diào)函數(shù)內(nèi)就可以知道當(dāng)前是不是“最新”。antd 里有一段例子如下
const fetchRef = useRef(0);
const debounceFetcher = useMemo(() => {
const loadOptions = (value: string) => {
fetchRef.current += 1;
const fetchId = fetchRef.current;
setOptions([]);
setFetching(true);
fetchOptions(value).then((newOptions) => {
if (fetchId !== fetchRef.current) {
// for fetch callback order
return;
}
setOptions(newOptions);
setFetching(false);
});
};
return debounce(loadOptions, debounceTimeout);
}, [fetchOptions, debounceTimeout]);可以進一步封裝，將請求封裝成 request( url, [option], [queueName] ), 通過外部傳入來指定需要競態(tài)的映射名。也就是將上述的疊加器放在一個 Map 里，使用 queueName 做 Map 的 key。
“
如果作為通用的請求中間件封裝，處于內(nèi)存優(yōu)化考慮，此處可以將 Map 優(yōu)化成 weakMap。Map 鍵值對是強引用，如有一個鍵被引用，那么GC是無法回收對應(yīng)的值的，weakmap 不存在這樣的問題，但要注意 weakMap 只能使用對象做 key。
3. 新請求發(fā)出的時候取消老的請求。一般來說請求發(fā)出去了是追不回來的。但是 fetch 和原生 ajax 提供了 abort 之類的取消方法。如果你項目的請求是 fetch 或 XMLHttpRequest 就可以用他們自帶的方式取消。需要注意的是，如果請求已經(jīng)被發(fā)送到服務(wù)器，并且請求體數(shù)據(jù)已被上傳，那么 abort() 方法就無法中止請求。大多數(shù)情況項目用的可能是 axios、uni.request 等其他更熱門的請求庫，這時候我們可以利用 promise.race 來封裝一個可以取消的請求，傳一個自定義能帶取消方法的 promise 進 promise.race 來控制 真正要執(zhí)行的 promise 函數(shù)提前取消。
// 封裝
function cancelableRequest(requestPromise) {
const cancelToken = {};
const cancelablePromise = new Promise((resolve, reject) => {
cancelToken.cancel = () => {
reject(new Error('Request was canceled'));
};
Promise.race([requestPromise, cancelToken])
.then(resolve)
.catch(reject);
});
return { promise: cancelablePromise, cancel: cancelToken.cancel };
}
// 使用
const mockApi= () =>
new Promise(resolve => {
setTimeout(() => {
resolve([{ title: 'Post 1' }, { title: 'Post 2' }, { title: 'Post 3' }]);
}, 3000);
});
const { promise, cancel } = cancelableRequest(mockApi());
promise
.then(posts => console.log(posts))
.catch(error => console.error(error.message));
// 取消請求
cancel();定位：一般來說寫 position: fixed 都是想相對窗口定位實現(xiàn)一些彈窗、抽屜或者浮動組件等效果，但是如果父元素中存在 transform 屬性的話，固定效果將直接降級變成 position: absolute 的表現(xiàn)。這可能也是大多數(shù)UI庫選擇將 modal、drawer 之類的 fixd 元素都插入在 body 下，和應(yīng)用本身分離開，可能就是擔(dān)心有 transform 來影響定位。究其原因是因為包含塊的定義：
如果 position 屬性為 static、relative 或 sticky，包含塊可能由它的最近的祖先塊元素(比如說 inline-block, block 或 list-item 元素)的內(nèi)容區(qū)的邊緣組成，也可能會建立格式化上下文 (比如說 a table container, flex container, grid container, 或者是 the block container 自身)。
層疊計算：有的時候，如果引入了很多的庫，會發(fā)現(xiàn)樣式會偶發(fā)的發(fā)生錯誤。這是因為樣式?jīng)_突了，那樣式的優(yōu)先級是什么樣子的呢？css 全稱為 cascader style sheet, 層疊樣式表。其層疊的目的就是為了比對樣式?jīng)_突后的“勝出者”；mdn 里詳細的介紹了其比較計算的規(guī)則。https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Cascade_layers
比對分以下步驟進行
分層就是瀏覽器畫制圖畫的順序，瀏覽器會根據(jù)一定的規(guī)則劃分圖層，當(dāng)然代碼也能干預(yù)圖層的劃分比如定位、動畫等等，不同圖層直接不能相互影響，換句話說一個圖層在另一個圖層下面的話，盡管 z-index 是 0 也能覆蓋 z-index: 100 的元素。
11. 特定性就是 4 位數(shù)字( 0，0，0，0 )第一位代表是否是行內(nèi)樣式，后面3位就是 id，class，tag 的個數(shù)。統(tǒng)計完特定性的 4 個數(shù)字后，從前往后比較大小。比較極端的情況下如果你寫了足夠多的 class 是可以超過 id 選擇器的。例如，以下選擇器有 11 個 class 選擇器組成：
div.navbar ul ul.dropdown-menu li.active > a.btn-primary:hover span.icon {
/* styles */
}
// 雖然其中沒有 id 選擇器，但它顯然比單個 id 選擇器的優(yōu)先級更高。12. 全部比對完后還是沒有“勝出者”的話，我們就會根據(jù)源代碼書寫的順序，后來的覆蓋先來的。言歸正傳，所以我們樣式如果偶發(fā)的出現(xiàn)問題，可能是因為網(wǎng)絡(luò)原因 javascript 下載下來的時間不確定，從而導(dǎo)致執(zhí)行后插入 css 文件的順序不一致，最終呈現(xiàn)出一種偶發(fā)的現(xiàn)象
造成性能問題的原因是多種多樣的，大體可以分為 3 種，一是網(wǎng)絡(luò)，二是渲染，三是計算
為了避免頻繁的頁面重排和重繪，我們應(yīng)該盡量減少對 DOM 的訪問和修改。為了控制元素的樣式變化，應(yīng)該盡可能使用 CSS。這樣有助于提高頁面性能和用戶體驗。
懶加載和預(yù)加載：懶加載可以減少初始頁面渲染時間，當(dāng)用戶需要訪問到某個資源時，才去加載這個資源，而預(yù)加載可以預(yù)先加載即將用到的資源，加快用戶訪問其他頁面時的速度。
虛擬 DOM：使用 Virtual DOM，實現(xiàn)局部修改視圖而不是整體重新渲染，減少 DOM 的操作。
優(yōu)化 JavaScript 代碼：采用 JavaScript 模塊化、使用面試編程思想，減少頁面的 JavaScript 代碼，從而減少瀏覽器的工作量。
多線程：使用延時線程、網(wǎng)絡(luò)線程、Web Workers 等其他不會阻塞渲染的進程來完成工作。
運行時計算的手段：
優(yōu)化 JavaScript 代碼：采用 JavaScript 模塊化、使用面試編程思想，減少頁面的 JavaScript 代碼，從而減少瀏覽器的工作量。
算法優(yōu)化：用更加合理的數(shù)據(jù)結(jié)構(gòu)設(shè)計和算法，以更優(yōu)的方式完成需求。
事件委托：將事件綁定在父元素上，減少事件的處理次數(shù)。
函數(shù)節(jié)流和防抖：使用函數(shù)節(jié)流技術(shù)避免頻繁觸發(fā)事件處理。
合理的事件注冊和解綁
合理的釋放不使用的內(nèi)存
一些想當(dāng)然覺得應(yīng)該是一致的東西結(jié)果不一致，比如前瞻匹配和后瞻匹配的兼容是不一樣的。需要兼容IE的話就不能使用后瞻寫法
圖片
https://developer.mozilla.org/zh-CN/docs/Web/CSS/Containing_block
https://caniuse.com/
https://standards.ieee.org/ieee/754/6210/
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動版官網(wǎng)