在前端開發(fā)過程中，常常遇到各種各樣的問題和坑點(diǎn)。尤其是隨著技術(shù)的不斷發(fā)展和更新，新的問題也不斷涌現(xiàn)。對于初學(xué)者而言，這些問題往往讓人感到十分困惑和無助。因此，本文將旨在探討一些前端開發(fā)過程中常見的問題和坑點(diǎn)以及解決方法，幫助讀者更加深入地了解前端開發(fā)，并解決實(shí)際工作中遇到的問題。

數(shù)據(jù)類型

數(shù)字

1. 進(jìn)制轉(zhuǎn)化問題：

/**
*  為什么 010 會(huì)是 8
*/
const num1 = 09 // 9
const num2 = 010 // 8

這邊是因?yàn)?0 開始的數(shù)字js會(huì)嘗試先把它轉(zhuǎn)成八進(jìn)制的數(shù)字。如果你出現(xiàn)大于 8 的數(shù)字，他知道不是八進(jìn)制還給你轉(zhuǎn)十進(jìn)制。純粹的八進(jìn)制應(yīng)該用 0o ，類似的還有  0b  二進(jìn)制和 0x 十六進(jìn)制，但是他們寫的不符合轉(zhuǎn)換條件的話會(huì)直接報(bào)錯(cuò)。

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 計(jì)算有精度問題呢？大家一定都是知道的， 今天就是來簡單解釋一下為什么會(huì)出現(xiàn)丟失精度的問題。這邊其實(shí)分兩部分，存儲(chǔ)和展示。存儲(chǔ)的時(shí)候 JavaScript 是以 64 位二進(jìn)制補(bǔ)碼的方式來存儲(chǔ)。由于改方式是以 2 為底進(jìn)行表示的，所以執(zhí)行某些運(yùn)算時(shí)容易出現(xiàn)誤差、溢出、無限循環(huán)等問題。

圖片

我們可以發(fā)現(xiàn)本來應(yīng)該是 11001100 無限循環(huán)被截?cái)嗔?，尾?hào) 11001 的時(shí)候1被舍去了，然后進(jìn)了一位 最后存儲(chǔ)成了上圖的 1101 的樣子。所以 0.1 其實(shí)存的比 0.1 要大一點(diǎn)點(diǎn)，0.2 也是一樣，而 0.3 比實(shí)際小一些。所以計(jì)算 0.1+0.2 的時(shí)候其實(shí)是拿二進(jìn)制計(jì)算的，兩個(gè)都偏大的數(shù)字相加 誤差被近一步的放大了。

下面這張圖可以看到他們真實(shí)存下來的數(shù)據(jù)轉(zhuǎn)成十進(jìn)制的樣子。實(shí)際顯示的時(shí)候會(huì)做近似處理，js 會(huì)判斷一個(gè)數(shù)字特別像 0.1 它就顯示 0.1 了。

圖片

toFixed 問題也是一樣。

圖片

還有就是有時(shí)候我們對一個(gè)數(shù)字使用 .toFixed .toString 會(huì)報(bào)錯(cuò)。

0.toString() // Uncaught SyntaxError: Invalid or unexpected token
// 我們期待的是它會(huì)隱性轉(zhuǎn)換讓我們調(diào)用 Number 構(gòu)造函數(shù)上的方法，
// 但是程序會(huì)以為你在寫一個(gè)小數(shù)，小數(shù)還不合規(guī)，所以報(bào)錯(cuò)了，
// 解決方法就是拿變量裝一下，或者 0..toString()

在 JavaScript 中，采用 64 位二進(jìn)制補(bǔ)碼表示數(shù)值類型，即雙精度浮點(diǎn)數(shù)。符號(hào)位(S)、指數(shù)位(E)和尾數(shù)位(M)的比特?cái)?shù)分別為 1 位、11 位和 52 位。在使用 IEEE 754 標(biāo)準(zhǔn)表示雙精度浮點(diǎn)數(shù)時(shí)，使用一些特殊的位表示：其中一個(gè)隱含位表示數(shù)字 1，在正常項(xiàng)中省略，因此一共有 53 位表示有效數(shù)字。

1. 符號(hào)位：在數(shù)值類型的二進(jìn)制補(bǔ)碼表示中，第一位表示符號(hào)位，0 表示正號(hào)，1 表示負(fù)號(hào)。
2. 指數(shù)位：在數(shù)值類型的二進(jìn)制補(bǔ)碼表示中，指數(shù)位用來表示科學(xué)計(jì)數(shù)法的指數(shù)部分。在雙精度浮點(diǎn)數(shù)中，指數(shù)部分使用11個(gè)位表示，其中 10 個(gè)位表示二進(jìn)制整數(shù)，在運(yùn)算前需要減去 2^n 的形式，剩下一位表示符號(hào)，1表示負(fù)指數(shù)，0表示正指數(shù)。可表示 -1023 ~ 1024 之間的范圍。
3. 尾數(shù)位：尾數(shù)位用來表示實(shí)數(shù)的小數(shù)部分。在雙精度浮點(diǎn)數(shù)中，尾數(shù)部分使用 52 個(gè)位表示。這意味著 JavaScript 浮點(diǎn)數(shù)的精度是有限的，并且可能會(huì)發(fā)生舍入誤差。

長度問題：

function fn(a,b,c){
  return a+b+c
}
fn.length // 3 一般來說fn的長度是形參的個(gè)數(shù) 但是形參有默認(rèn)值就不同
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
// 它只會(huì)統(tǒng)計(jì)首個(gè)默認(rèn)之前的參數(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的存儲(chǔ)順序是這樣的
// 如果屬性可以轉(zhuǎn)number，提前上來，按升序排列，其他的字符串屬性按添加的先后順序

賦值中斷問題：js 里沒有事務(wù)的機(jī)制，不會(huì)恢復(fù)到操作之前的狀態(tài)。如果中途失敗了，之前賦值和操作過的數(shù)據(jù)是保留的，失敗后的操作不執(zhí)行。

異步

定時(shí)器不準(zhǔn)：這里說的不準(zhǔn)還不是說一點(diǎn)小誤差。定時(shí)器由于渲染主進(jìn)程阻塞也好，延時(shí)任務(wù)嵌套過深也好，事件循環(huán)優(yōu)先級被排隊(duì)到后邊也好。這些都可以認(rèn)為是“誤差”，但是如果說你 setIntervel 是 10ms，結(jié)果它間隔 n 秒調(diào)一次函數(shù)，那可不是誤差了，可能直接會(huì)產(chǎn)生 bug。

這個(gè)問題的原因是：用戶在使用谷歌瀏覽器的過程中將窗口最小化或切換到其他應(yīng)用程序中去，瀏覽器會(huì)將當(dāng)前標(biāo)簽頁和其中的 JavaScript 定時(shí)器掛起，這將導(dǎo)致定時(shí)器延遲調(diào)用。通常情況下，瀏覽器會(huì)盡可能保持定時(shí)器的準(zhǔn)確性，并在恢復(fù)標(biāo)簽頁后立即執(zhí)行延遲的定時(shí)器。但是，如果計(jì)算機(jī)負(fù)載過重或其他原因?qū)е?JavaScript 的執(zhí)行速度變慢，定時(shí)器可能會(huì)更加延遲。經(jīng)過測試，新版本的瀏覽器上基本都是至少 1 秒一次。

圖片

詳細(xì)參考 https://developer.mozilla.org/zh-CN/docs/Web/API/setTimeout

競態(tài)問題：異步的競態(tài)問題也是開發(fā)中經(jīng)常遇到的問題。舉個(gè)例子用戶輸入搜索就請求相應(yīng)的商品，用戶很快的輸入了“手機(jī)殼” 3 個(gè)字；“手”“手機(jī)”“手機(jī)殼” 3 個(gè)不同參數(shù)的請求幾乎同時(shí)發(fā)了出去，異步請求很難保證哪個(gè)請求，先回來哪個(gè)請求后回來。那加上防抖呢？其實(shí)這也不是防抖該應(yīng)用的場景，弱網(wǎng)環(huán)境下請求 5 秒、10 秒返回都說不準(zhǔn)，防抖防幾秒都不太合適。我根據(jù)個(gè)人的經(jīng)驗(yàn)總結(jié)了 3 種方式：

1. 鏈?zhǔn)秸{(diào)用

// 讓要執(zhí)行的異步函數(shù)通過一個(gè)鏈?zhǔn)椒绞秸{(diào)用
export class SequenceQueue {
  promise = Promise.resolve();
  excute (promise) {
    this.promise = this.promise.then(() => promise);
    return this.promise;
}
};

2. 設(shè)置一個(gè)疊加器，每次調(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]);

可以進(jìn)一步封裝，將請求封裝成 request( url, [option], [queueName] ), 通過外部傳入來指定需要競態(tài)的映射名。也就是將上述的疊加器放在一個(gè) Map 里，使用 queueName 做 Map 的 key。

“

如果作為通用的請求中間件封裝，處于內(nèi)存優(yōu)化考慮，此處可以將 Map 優(yōu)化成 weakMap。Map 鍵值對是強(qiáng)引用，如有一個(gè)鍵被引用，那么GC是無法回收對應(yīng)的值的，weakmap 不存在這樣的問題，但要注意 weakMap 只能使用對象做 key。

3. 新請求發(fā)出的時(shí)候取消老的請求。一般來說請求發(fā)出去了是追不回來的。但是 fetch 和原生 ajax 提供了 abort 之類的取消方法。如果你項(xiàng)目的請求是 fetch 或 XMLHttpRequest 就可以用他們自帶的方式取消。需要注意的是，如果請求已經(jīng)被發(fā)送到服務(wù)器，并且請求體數(shù)據(jù)已被上傳，那么 abort() 方法就無法中止請求。大多數(shù)情況項(xiàng)目用的可能是 axios、uni.request 等其他更熱門的請求庫，這時(shí)候我們可以利用 promise.race 來封裝一個(gè)可以取消的請求，傳一個(gè)自定義能帶取消方法的 promise 進(jìn) 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 都是想相對窗口定位實(shí)現(xiàn)一些彈窗、抽屜或者浮動(dòng)組件等效果，但是如果父元素中存在 transform 屬性的話，固定效果將直接降級變成 position: absolute 的表現(xiàn)。這可能也是大多數(shù)UI庫選擇將 modal、drawer 之類的 fixd 元素都插入在 body 下，和應(yīng)用本身分離開，可能就是擔(dān)心有 transform 來影響定位。究其原因是因?yàn)榘瑝K的定義：

如果 position 屬性為 static、relative 或 sticky，包含塊可能由它的最近的祖先塊元素(比如說 inline-block, block 或 list-item 元素)的內(nèi)容區(qū)的邊緣組成，也可能會(huì)建立格式化上下文 (比如說 a table container, flex container, grid container, 或者是 the block container 自身)。

1. 如果 position 屬性為 absolute ，包含塊就是由它的最近的 position 的值不是 static (也就是值為 fixed, absolute, relative 或 sticky )的祖先元素的內(nèi)邊距區(qū)的邊緣組成。
2. 如果 position 屬性是 fixed，在連續(xù)媒體的情況下 (continuous media) 包含塊是 viewport ,在分頁媒體 (paged media) 下的情況下包含塊是分頁區(qū)域 (page area)。
3. 如果 position 屬性是 absolute 或 fixed，包含塊也可能是由滿足以下條件的最近父級元素的內(nèi)邊距區(qū)的邊緣組成的：

1. transform 或 perspective 的值不是 none
2. will-change 的值是 transform 或 perspective
3. filter 的值不是 none 或 will-change 的值是 filter(只在 Firefox 下生效)。
4. contain 的值是 paint(例如：contain: paint;)
5. backdrop-filter 的值不是 none(例如：backdrop-filter: blur (10px) ; )

層疊計(jì)算：有的時(shí)候，如果引入了很多的庫，會(huì)發(fā)現(xiàn)樣式會(huì)偶發(fā)的發(fā)生錯(cuò)誤。這是因?yàn)闃邮經(jīng)_突了，那樣式的優(yōu)先級是什么樣子的呢？css 全稱為 cascader style sheet, 層疊樣式表。其層疊的目的就是為了比對樣式?jīng)_突后的“勝出者”；mdn 里詳細(xì)的介紹了其比較計(jì)算的規(guī)則。https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Cascade_layers

比對分以下步驟進(jìn)行

1. 相關(guān)性: 為每個(gè)元素查找具有選擇器匹配的聲明塊。
2. 重要性: 根據(jù)它們是正常的還是重要的對規(guī)則進(jìn)行排序。重要的樣式是那些設(shè)置了 !important 標(biāo)志的樣式。
3. 來源: 在上面兩個(gè)重要性比較中，按作者、用戶或用戶代理來源對規(guī)則進(jìn)行排序。
4. 層級: 在每個(gè)六個(gè)來源重要性桶中，通過級聯(lián)層進(jìn)行排序。正常聲明的層次順序是從第一層創(chuàng)建到最后一層，然后是未分層的正常樣式。重要樣式的順序是相反的，未分層的重要樣式優(yōu)先級較低。
5. 特定性: 對于來源層的競爭樣式，根據(jù)特定性對聲明進(jìn)行排序。
6. 出現(xiàn)順序: 當(dāng)具有優(yōu)先級的來源層中的兩個(gè)選擇器具有相同的特定性時(shí)，具有最高特定性的最后聲明的選擇器的屬性值獲勝。通俗的解釋一下：規(guī)則自上往下去執(zhí)行，一旦找到了勝出者就不必向下執(zhí)行了。
7. 看選擇器選沒選中東西，有選中的“勝出”
8. 多人勝出，看有沒有 !important，有的話勝出
9. 還是分不出唯一的勝者的話，繼續(xù)看來源，按作者、用戶或用戶代理來源的優(yōu)先級，其中【作者】就是代碼的你，【用戶】就是站點(diǎn)用戶，【用戶代理】就是瀏覽器默認(rèn)樣式
10. ( 相關(guān)性+重要性 )*來源 有 6 種情況，這些情況要按分層進(jìn)行排序。先創(chuàng)建層級的比后創(chuàng)建的高，分層的比未分層優(yōu)先級高，對于重要樣式，這個(gè)順序則被倒轉(zhuǎn)了。所有未進(jìn)行圖層分層的重要樣式都會(huì)級聯(lián)在一起，形成一個(gè)隱含的層，這個(gè)層優(yōu)先級高于所有未進(jìn)行過轉(zhuǎn)換的普通樣式，但是優(yōu)先級低于任何分層的重要樣式。下面是一張 apple 官網(wǎng)網(wǎng)頁的分層圖，我們可以清除的看見分層之間的關(guān)系

分層就是瀏覽器畫制圖畫的順序，瀏覽器會(huì)根據(jù)一定的規(guī)則劃分圖層，當(dāng)然代碼也能干預(yù)圖層的劃分比如定位、動(dòng)畫等等，不同圖層直接不能相互影響，換句話說一個(gè)圖層在另一個(gè)圖層下面的話，盡管 z-index 是 0 也能覆蓋 z-index: 100 的元素。

11. 特定性就是 4 位數(shù)字( 0，0，0，0 )第一位代表是否是行內(nèi)樣式，后面3位就是 id，class，tag 的個(gè)數(shù)。統(tǒng)計(jì)完特定性的 4 個(gè)數(shù)字后，從前往后比較大小。比較極端的情況下如果你寫了足夠多的 class 是可以超過 id 選擇器的。例如，以下選擇器有 11 個(gè) class 選擇器組成：

div.navbar ul ul.dropdown-menu li.active > a.btn-primary:hover span.icon {
  /* styles */
}
// 雖然其中沒有 id 選擇器，但它顯然比單個(gè) id 選擇器的優(yōu)先級更高。

12. 全部比對完后還是沒有“勝出者”的話，我們就會(huì)根據(jù)源代碼書寫的順序，后來的覆蓋先來的。言歸正傳，所以我們樣式如果偶發(fā)的出現(xiàn)問題，可能是因?yàn)榫W(wǎng)絡(luò)原因 javascript 下載下來的時(shí)間不確定，從而導(dǎo)致執(zhí)行后插入 css 文件的順序不一致，最終呈現(xiàn)出一種偶發(fā)的現(xiàn)象

性能

造成性能問題的原因是多種多樣的，大體可以分為 3 種，一是網(wǎng)絡(luò)，二是渲染，三是計(jì)算

1. 網(wǎng)絡(luò)優(yōu)化的手段：

1. 壓縮和合并資源，減少請求次數(shù)(一定程度的節(jié)省請求自身的消耗，請求本身就有一些請求頭、響應(yīng)頭等固定開銷)
2. 減小體積：按需打包加載，模塊化的同構(gòu)相同邏輯的代碼
3. 使用緩存：可以利用瀏覽器緩存機(jī)制，讓用戶再次訪問頁面時(shí)不必重新加載文件，從而加快頁面的載入速度。
4. 利用 CDN：可以使用內(nèi)容分發(fā)網(wǎng)絡(luò)( CDN )來分發(fā)資源，縮短用戶請求的時(shí)延。
5. DNS 優(yōu)化：預(yù)解析一下網(wǎng)站內(nèi)的域名 ip，首次訪問的用戶能更快的請求到資源
6. 合理安排依賴資源的加載模式和加載順序，例如將 JavaScript 代碼放置在頁面底部，避免影響頁面的首次渲染時(shí)間

2. 渲染優(yōu)化的手段：

3. 為了避免頻繁的頁面重排和重繪，我們應(yīng)該盡量減少對 DOM 的訪問和修改。為了控制元素的樣式變化，應(yīng)該盡可能使用 CSS。這樣有助于提高頁面性能和用戶體驗(yàn)。

4. 懶加載和預(yù)加載：懶加載可以減少初始頁面渲染時(shí)間，當(dāng)用戶需要訪問到某個(gè)資源時(shí)，才去加載這個(gè)資源，而預(yù)加載可以預(yù)先加載即將用到的資源，加快用戶訪問其他頁面時(shí)的速度。

5. 虛擬 DOM：使用 Virtual DOM，實(shí)現(xiàn)局部修改視圖而不是整體重新渲染，減少 DOM 的操作。

6. 優(yōu)化 JavaScript 代碼：采用 JavaScript 模塊化、使用面試編程思想，減少頁面的 JavaScript 代碼，從而減少瀏覽器的工作量。

7. 多線程：使用延時(shí)線程、網(wǎng)絡(luò)線程、Web Workers 等其他不會(huì)阻塞渲染的進(jìn)程來完成工作。

8. 運(yùn)行時(shí)計(jì)算的手段：

9. 優(yōu)化 JavaScript 代碼：采用 JavaScript 模塊化、使用面試編程思想，減少頁面的 JavaScript 代碼，從而減少瀏覽器的工作量。

10. 算法優(yōu)化：用更加合理的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)和算法，以更優(yōu)的方式完成需求。

11. 事件委托：將事件綁定在父元素上，減少事件的處理次數(shù)。

12. 函數(shù)節(jié)流和防抖：使用函數(shù)節(jié)流技術(shù)避免頻繁觸發(fā)事件處理。

13. 合理的事件注冊和解綁

14. 合理的釋放不使用的內(nèi)存

兼容性

一些想當(dāng)然覺得應(yīng)該是一致的東西結(jié)果不一致，比如前瞻匹配和后瞻匹配的兼容是不一樣的。需要兼容IE的話就不能使用后瞻寫法

圖片

參考文獻(xiàn)

https://developer.mozilla.org/zh-CN/docs/Web/CSS/Containing_block

https://caniuse.com/

https://standards.ieee.org/ieee/754/6210/