前端常見問題分析，你學會了嗎？
在前端開發過程中，常常遇到各種各樣的問題和坑點。尤其是隨著技術的不斷發展和更新，新的問題也不斷涌現。對于初學者而言，這些問題往往讓人感到十分困惑和無助。因此，本文將旨在探討一些前端開發過程中常見的問題和坑點以及解決方法，幫助讀者更加深入地了解前端開發，并解決實際工作中遇到的問題。
數據類型
數字
1. 進制轉化問題：
/**
* 為什么 010 會是 8
*/
const num1 = 09 // 9
const num2 = 010 // 8這邊是因為 0 開始的數字js會嘗試先把它轉成八進制的數字。如果你出現大于 8 的數字，他知道不是八進制還給你轉十進制。純粹的八進制應該用 0o ，類似的還有 0b 二進制和 0x 十六進制，但是他們寫的不符合轉換條件的話會直接報錯。
2. 精度丟失問題：
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 計算有精度問題呢？大家一定都是知道的， 今天就是來簡單解釋一下為什么會出現丟失精度的問題。這邊其實分兩部分，存儲和展示。存儲的時候 JavaScript 是以 64 位二進制補碼的方式來存儲。由于改方式是以 2 為底進行表示的，所以執行某些運算時容易出現誤差、溢出、無限循環等問題。
圖片
我們可以發現本來應該是 11001100 無限循環被截斷了，尾號 11001 的時候1被舍去了，然后進了一位 最后存儲成了上圖的 1101 的樣子。所以 0.1 其實存的比 0.1 要大一點點，0.2 也是一樣，而 0.3 比實際小一些。所以計算 0.1+0.2 的時候其實是拿二進制計算的，兩個都偏大的數字相加 誤差被近一步的放大了。
下面這張圖可以看到他們真實存下來的數據轉成十進制的樣子。實際顯示的時候會做近似處理，js 會判斷一個數字特別像 0.1 它就顯示 0.1 了。
圖片
toFixed 問題也是一樣。
圖片
還有就是有時候我們對一個數字使用 .toFixed .toString 會報錯。
0.toString() // Uncaught SyntaxError: Invalid or unexpected token
// 我們期待的是它會隱性轉換讓我們調用 Number 構造函數上的方法，
// 但是程序會以為你在寫一個小數，小數還不合規，所以報錯了，
// 解決方法就是拿變量裝一下，或者 0..toString()在 JavaScript 中，采用 64 位二進制補碼表示數值類型，即雙精度浮點數。符號位(S)、指數位(E)和尾數位(M)的比特數分別為 1 位、11 位和 52 位。在使用 IEEE 754 標準表示雙精度浮點數時，使用一些特殊的位表示：其中一個隱含位表示數字 1，在正常項中省略，因此一共有 53 位表示有效數字。
- 符號位：在數值類型的二進制補碼表示中，第一位表示符號位，0 表示正號，1 表示負號。
- 指數位：在數值類型的二進制補碼表示中，指數位用來表示科學計數法的指數部分。在雙精度浮點數中，指數部分使用11個位表示，其中 10 個位表示二進制整數，在運算前需要減去 2^n 的形式，剩下一位表示符號，1表示負指數，0表示正指數。可表示 -1023 ~ 1024 之間的范圍。
- 尾數位：尾數位用來表示實數的小數部分。在雙精度浮點數中，尾數部分使用 52 個位表示。這意味著 JavaScript 浮點數的精度是有限的，并且可能會發生舍入誤差。
長度問題：
function fn(a,b,c){
return a+b+c
}
fn.length // 3 一般來說fn的長度是形參的個數 但是形參有默認值就不同
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
// 它只會統計首個默認之前的參數對象排序問題：
a.b=1
a.a=1
a.c=1
a[2]=2
a[12]=2
a[1]=2
// 結果 {1: 2, 2: 2, 12: 2, b: 1, a: 1, c: 1}
// 對象的內部key value的存儲順序是這樣的
// 如果屬性可以轉number，提前上來，按升序排列，其他的字符串屬性按添加的先后順序賦值中斷問題：js 里沒有事務的機制，不會恢復到操作之前的狀態。如果中途失敗了，之前賦值和操作過的數據是保留的，失敗后的操作不執行。
異步
定時器不準：這里說的不準還不是說一點小誤差。定時器由于渲染主進程阻塞也好，延時任務嵌套過深也好，事件循環優先級被排隊到后邊也好。這些都可以認為是“誤差”，但是如果說你 setIntervel 是 10ms，結果它間隔 n 秒調一次函數，那可不是誤差了，可能直接會產生 bug。
這個問題的原因是：用戶在使用谷歌瀏覽器的過程中將窗口最小化或切換到其他應用程序中去，瀏覽器會將當前標簽頁和其中的 JavaScript 定時器掛起，這將導致定時器延遲調用。通常情況下，瀏覽器會盡可能保持定時器的準確性，并在恢復標簽頁后立即執行延遲的定時器。但是，如果計算機負載過重或其他原因導致 JavaScript 的執行速度變慢，定時器可能會更加延遲。經過測試，新版本的瀏覽器上基本都是至少 1 秒一次。
圖片
詳細參考 https://developer.mozilla.org/zh-CN/docs/Web/API/setTimeout
競態問題：異步的競態問題也是開發中經常遇到的問題。舉個例子用戶輸入搜索就請求相應的商品，用戶很快的輸入了“手機殼” 3 個字；“手”“手機”“手機殼” 3 個不同參數的請求幾乎同時發了出去，異步請求很難保證哪個請求，先回來哪個請求后回來。那加上防抖呢？其實這也不是防抖該應用的場景，弱網環境下請求 5 秒、10 秒返回都說不準，防抖防幾秒都不太合適。我根據個人的經驗總結了 3 種方式：
1. 鏈式調用
// 讓要執行的異步函數通過一個鏈式方式調用
export class SequenceQueue {
promise = Promise.resolve();
excute (promise) {
this.promise = this.promise.then(() => promise);
return this.promise;
}
};2. 設置一個疊加器，每次調用就累加，回調函數內就可以知道當前是不是“最新”。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] ), 通過外部傳入來指定需要競態的映射名。也就是將上述的疊加器放在一個 Map 里，使用 queueName 做 Map 的 key。
“
如果作為通用的請求中間件封裝，處于內存優化考慮，此處可以將 Map 優化成 weakMap。Map 鍵值對是強引用，如有一個鍵被引用，那么GC是無法回收對應的值的，weakmap 不存在這樣的問題，但要注意 weakMap 只能使用對象做 key。
3. 新請求發出的時候取消老的請求。一般來說請求發出去了是追不回來的。但是 fetch 和原生 ajax 提供了 abort 之類的取消方法。如果你項目的請求是 fetch 或 XMLHttpRequest 就可以用他們自帶的方式取消。需要注意的是，如果請求已經被發送到服務器，并且請求體數據已被上傳，那么 abort() 方法就無法中止請求。大多數情況項目用的可能是 axios、uni.request 等其他更熱門的請求庫，這時候我們可以利用 promise.race 來封裝一個可以取消的請求，傳一個自定義能帶取消方法的 promise 進 promise.race 來控制 真正要執行的 promise 函數提前取消。
// 封裝
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 都是想相對窗口定位實現一些彈窗、抽屜或者浮動組件等效果，但是如果父元素中存在 transform 屬性的話，固定效果將直接降級變成 position: absolute 的表現。這可能也是大多數UI庫選擇將 modal、drawer 之類的 fixd 元素都插入在 body 下，和應用本身分離開，可能就是擔心有 transform 來影響定位。究其原因是因為包含塊的定義：
如果 position 屬性為 static、relative 或 sticky，包含塊可能由它的最近的祖先塊元素(比如說 inline-block, block 或 list-item 元素)的內容區的邊緣組成，也可能會建立格式化上下文 (比如說 a table container, flex container, grid container, 或者是 the block container 自身)。
- 如果 position 屬性為 absolute ，包含塊就是由它的最近的 position 的值不是 static (也就是值為 fixed, absolute, relative 或 sticky )的祖先元素的內邊距區的邊緣組成。
- 如果 position 屬性是 fixed，在連續媒體的情況下 (continuous media) 包含塊是 viewport ,在分頁媒體 (paged media) 下的情況下包含塊是分頁區域 (page area)。
- 如果 position 屬性是 absolute 或 fixed，包含塊也可能是由滿足以下條件的最近父級元素的內邊距區的邊緣組成的：
- transform 或 perspective 的值不是 none
- will-change 的值是 transform 或 perspective
- filter 的值不是 none 或 will-change 的值是 filter(只在 Firefox 下生效)。
- contain 的值是 paint(例如：contain: paint;)
- backdrop-filter 的值不是 none(例如：backdrop-filter: blur (10px) ; )
層疊計算：有的時候，如果引入了很多的庫，會發現樣式會偶發的發生錯誤。這是因為樣式沖突了，那樣式的優先級是什么樣子的呢？css 全稱為 cascader style sheet, 層疊樣式表。其層疊的目的就是為了比對樣式沖突后的“勝出者”；mdn 里詳細的介紹了其比較計算的規則。https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Cascade_layers
比對分以下步驟進行
- 相關性: 為每個元素查找具有選擇器匹配的聲明塊。
- 重要性: 根據它們是正常的還是重要的對規則進行排序。重要的樣式是那些設置了 !important 標志的樣式。
- 來源: 在上面兩個重要性比較中，按作者、用戶或用戶代理來源對規則進行排序。
- 層級: 在每個六個來源重要性桶中，通過級聯層進行排序。正常聲明的層次順序是從第一層創建到最后一層，然后是未分層的正常樣式。重要樣式的順序是相反的，未分層的重要樣式優先級較低。
- 特定性: 對于來源層的競爭樣式，根據特定性對聲明進行排序。
- 出現順序: 當具有優先級的來源層中的兩個選擇器具有相同的特定性時，具有最高特定性的最后聲明的選擇器的屬性值獲勝。通俗的解釋一下：規則自上往下去執行，一旦找到了勝出者就不必向下執行了。
- 看選擇器選沒選中東西，有選中的“勝出”
- 多人勝出，看有沒有 !important，有的話勝出
- 還是分不出唯一的勝者的話，繼續看來源，按作者、用戶或用戶代理來源的優先級，其中【作者】就是代碼的你，【用戶】就是站點用戶，【用戶代理】就是瀏覽器默認樣式
- ( 相關性+重要性 )*來源 有 6 種情況，這些情況要按分層進行排序。先創建層級的比后創建的高，分層的比未分層優先級高，對于重要樣式，這個順序則被倒轉了。所有未進行圖層分層的重要樣式都會級聯在一起，形成一個隱含的層，這個層優先級高于所有未進行過轉換的普通樣式，但是優先級低于任何分層的重要樣式。下面是一張 apple 官網網頁的分層圖，我們可以清除的看見分層之間的關系
分層就是瀏覽器畫制圖畫的順序，瀏覽器會根據一定的規則劃分圖層，當然代碼也能干預圖層的劃分比如定位、動畫等等，不同圖層直接不能相互影響，換句話說一個圖層在另一個圖層下面的話，盡管 z-index 是 0 也能覆蓋 z-index: 100 的元素。
11. 特定性就是 4 位數字( 0，0，0，0 )第一位代表是否是行內樣式，后面3位就是 id，class，tag 的個數。統計完特定性的 4 個數字后，從前往后比較大小。比較極端的情況下如果你寫了足夠多的 class 是可以超過 id 選擇器的。例如，以下選擇器有 11 個 class 選擇器組成：
div.navbar ul ul.dropdown-menu li.active > a.btn-primary:hover span.icon {
/* styles */
}
// 雖然其中沒有 id 選擇器，但它顯然比單個 id 選擇器的優先級更高。12. 全部比對完后還是沒有“勝出者”的話，我們就會根據源代碼書寫的順序，后來的覆蓋先來的。言歸正傳，所以我們樣式如果偶發的出現問題，可能是因為網絡原因 javascript 下載下來的時間不確定，從而導致執行后插入 css 文件的順序不一致，最終呈現出一種偶發的現象
性能
造成性能問題的原因是多種多樣的，大體可以分為 3 種，一是網絡，二是渲染，三是計算
- 網絡優化的手段：
- 壓縮和合并資源，減少請求次數(一定程度的節省請求自身的消耗，請求本身就有一些請求頭、響應頭等固定開銷)
- 減小體積：按需打包加載，模塊化的同構相同邏輯的代碼
- 使用緩存：可以利用瀏覽器緩存機制，讓用戶再次訪問頁面時不必重新加載文件，從而加快頁面的載入速度。
- 利用 CDN：可以使用內容分發網絡( CDN )來分發資源，縮短用戶請求的時延。
- DNS 優化：預解析一下網站內的域名 ip，首次訪問的用戶能更快的請求到資源
- 合理安排依賴資源的加載模式和加載順序，例如將 JavaScript 代碼放置在頁面底部，避免影響頁面的首次渲染時間
- 渲染優化的手段：
為了避免頻繁的頁面重排和重繪，我們應該盡量減少對 DOM 的訪問和修改。為了控制元素的樣式變化，應該盡可能使用 CSS。這樣有助于提高頁面性能和用戶體驗。
懶加載和預加載：懶加載可以減少初始頁面渲染時間，當用戶需要訪問到某個資源時，才去加載這個資源，而預加載可以預先加載即將用到的資源，加快用戶訪問其他頁面時的速度。
虛擬 DOM：使用 Virtual DOM，實現局部修改視圖而不是整體重新渲染，減少 DOM 的操作。
優化 JavaScript 代碼：采用 JavaScript 模塊化、使用面試編程思想，減少頁面的 JavaScript 代碼，從而減少瀏覽器的工作量。
多線程：使用延時線程、網絡線程、Web Workers 等其他不會阻塞渲染的進程來完成工作。
運行時計算的手段：
優化 JavaScript 代碼：采用 JavaScript 模塊化、使用面試編程思想，減少頁面的 JavaScript 代碼，從而減少瀏覽器的工作量。
算法優化：用更加合理的數據結構設計和算法，以更優的方式完成需求。
事件委托：將事件綁定在父元素上，減少事件的處理次數。
函數節流和防抖：使用函數節流技術避免頻繁觸發事件處理。
合理的事件注冊和解綁
合理的釋放不使用的內存
兼容性
一些想當然覺得應該是一致的東西結果不一致，比如前瞻匹配和后瞻匹配的兼容是不一樣的。需要兼容IE的話就不能使用后瞻寫法
圖片
參考文獻
https://developer.mozilla.org/zh-CN/docs/Web/CSS/Containing_block
https://caniuse.com/
https://standards.ieee.org/ieee/754/6210/
