解析)
3步搞定fill耳機報錯，高頻面試題實戰(zhàn)解析
剛接了個新需求，后端接口返回的數(shù)據(jù)結(jié)構(gòu)里有個字段叫 fill，前端渲染耳機列表時突然炸了。控制臺全是紅字，StackTrace 長得像天書，一眼望去全是 TypeError: Cannot read properties of undefined (reading 'map')。這種時候最搞心態(tài)，明明數(shù)據(jù)看起來沒問題，一跑代碼就崩。更坑的是，這題最近面試老被問，屬于那種“看似簡單實則坑多”的高頻面試題。今天不整虛的，直接拆源碼，看看底層到底咋回事，順便把 fill 這個 API 的進階用法扒個底朝天。
入口定位：報錯到底在哪
很多新手遇到報錯，第一反應(yīng)是去查 MDN 文檔，但往往查不到點子上。因為報錯信息里的 fill 可能指代兩個東西：一是數(shù)組方法 Array.prototype.fill，二是業(yè)務(wù)邏輯里的“填充”操作。在我們這個耳機列表的場景里，問題出在數(shù)據(jù)預(yù)處理階段。
假設(shè)后端返回的數(shù)據(jù)是這樣的：
{headphones: [{ id: 1, name: Sony WH-1000XM5, price: 2999 },{ id: 2, name: AirPods Max, price: 4399 },{ id: 3, name: Bose QC45, price: 2499 }],fill: default_color
}前端代碼里為了初始化樣式，寫了一段類似這樣的邏輯：
const defaultStyles = new Array(3).fill(null);
const processedHeadphones = data.headphones.map((item, index) = {return {...item,style: defaultStyles[index] || 'default'};
});乍一看沒問題，對吧？new Array(3).fill(null) 創(chuàng)建了一個長度為3的全 null 數(shù)組。但如果后端數(shù)據(jù)變動，比如突然加了第4款耳機，或者 headphones 字段缺失，這里就會炸。更隱蔽的問題是，如果 data 本身是 undefined 或 null，data.headphones 這一步就會直接拋出 TypeError。
這時候你需要打開瀏覽器的 DevTools，點擊那個紅色的報錯圖標(biāo)，查看 Call Stack。你會發(fā)現(xiàn)調(diào)用棧最頂層通常是 map，但根本原因往往在 data 的解構(gòu)或訪問上。記住，報錯的最后一行才是線索，報錯的第一行才是現(xiàn)場。
核心片段：源碼級拆解
要真正理解 fill 的坑，得看它是怎么實現(xiàn)的。雖然 Array.prototype.fill 是內(nèi)置方法，但我們可以看看它的簡化實現(xiàn)邏輯，以及它在現(xiàn)代框架（如 React 或 Vue）中是如何被誤用的。
片段一：Array.fill 的底層邏輯模擬
這是 ES6 新增的方法，但在實際項目中，我們很少直接用它來處理動態(tài)數(shù)據(jù)，更多是用于靜態(tài)初始化。下面這段代碼模擬了 fill 的核心行為，注釋里標(biāo)出了容易踩的坑：
/*** 模擬 Array.prototype.fill 的核心邏輯* @param {Array} arr - 目標(biāo)數(shù)組* @param {*} value - 填充值* @param {number} start - 起始索引，默認為 0* @param {number} end - 結(jié)束索引，默認為數(shù)組長度* @returns {Array} 修改后的數(shù)組*/
function customFill(arr, value, start = 0, end = arr.length) {// 坑點1：如果 arr 不是數(shù)組，直接拋錯，這就是 StackTrace 里 TypeError 的來源之一if (!Array.isArray(arr)) {throw new TypeError('Cannot call fill on non-array');}const len = arr.length;// 坑點2：start 和 end 的邊界處理，很多人忽略負數(shù)索引let from = start 0 ? Math.max(len + start, 0) : Math.min(start, len);let to = end === undefined ? len : (end 0 ? Math.max(len + end, 0) : Math.min(end, len));// 核心循環(huán)：從 from 到 to-1 進行賦值for (let i = from; i to; i++) {arr[i] = value; // 坑點3：這里是淺拷貝，如果 value 是對象，所有位置引用同一個對象}return arr;
}// 測試用例
const arr1 = new Array(5).fill(null); // [null, null, null, null, null]
const arr2 = new Array(5).fill(0); // [0, 0, 0, 0, 0]// 危險操作演示
const obj = { id: 1 };
const arr3 = new Array(3).fill(obj);
arr3[0].id = 999;
console.log(arr3[1].id); // 輸出 999，因為 arr3[0] 和 arr3[1] 是同一個對象引用這段代碼揭示了為什么在耳機列表場景中，如果不小心用了對象填充，會導(dǎo)致所有耳機共享同一個樣式對象，一改全改。
片段二：結(jié)合業(yè)務(wù)場景的修復(fù)方案
回到我們的耳機列表，正確的做法不是硬用 fill，而是根據(jù)實際數(shù)據(jù)長度動態(tài)生成占位符，并做好防御性編程。
/*** 安全處理耳機列表數(shù)據(jù)，避免 undefined 報錯* @param {Object} data - 后端返回的原始數(shù)據(jù)* @returns {Array} 處理后的耳機數(shù)組*/
function processHeadphoneData(data) {// 防御性編程：確保 data 和 data.headphones 存在const headphones = (data Array.isArray(data.headphones)) ? data.headphones : [];// 如果數(shù)據(jù)為空，返回空數(shù)組，而不是一個全 null 的數(shù)組if (headphones.length === 0) {return [];}// 使用 map 而不是 fill 來初始化樣式，確保每個項獨立return headphones.map(item = {// 如果 item 本身缺失，提供默認值if (!item || typeof item !== 'object') {return { id: 0, name: 'Unknown', price: 0, style: 'default' };}return {...item,// 關(guān)鍵：這里用邏輯運算符確保 style 有默認值，避免 undefinedstyle: item.style || 'default',// 如果業(yè)務(wù)需要填充缺失的字段，用顯式賦值而不是 fill...getMissingFields(item)};});
}// 輔助函數(shù)：處理缺失字段
function getMissingFields(item) {const defaults = {name: 'No Name',price: 0,color: 'Black'};// 只填充缺失的字段，不影響已有數(shù)據(jù)return Object.keys(defaults).reduce((acc, key) = {if (item[key] === undefined) {acc[key] = defaults[key];}return acc;}, {});
}注意這里的關(guān)鍵區(qū)別：fill 適合靜態(tài)初始化，不適合動態(tài)數(shù)據(jù)映射。在真實業(yè)務(wù)中，數(shù)據(jù)是流動的，用 map + 解構(gòu)賦值更安全。
設(shè)計思想：為什么框架不直接用 fill
你可能會問，為什么 React 的 useState 或者 Vue 的 ref 內(nèi)部不使用 fill 來初始化數(shù)組？這涉及到底層性能和數(shù)據(jù)一致性的設(shè)計思想。引用一致性：fill 填充對象時，所有元素指向同一引用。在響應(yīng)式框架中，這會導(dǎo)致依賴追蹤混亂。比如 Vue 3 的 reactive，如果數(shù)組里所有項是同一個對象，修改一項會觸發(fā)所有項的更新，造成不必要的重渲染。
惰性初始化：現(xiàn)代框架傾向于惰性加載。比如虛擬列表（Virtual List），只有在視口內(nèi)的元素才會被真實創(chuàng)建。如果一開始就用 fill 填充了 10000 個空對象，內(nèi)存直接爆掉。
不可變性原則：前端開發(fā)越來越推崇不可變數(shù)據(jù)。fill 是原地修改（In-place），而 map 返回新數(shù)組，更符合函數(shù)式編程思維，也更容易調(diào)試。在實際項目中，我見過太多因為誤用 fill 導(dǎo)致的 Bug。比如在一個電商后臺，管理員批量設(shè)置耳機庫存時，用了 new Array(count).fill({ stock: 0 })，結(jié)果所有耳機的庫存都綁定到了同一個對象，改一個全變。這種 Bug 在測試階段很難發(fā)現(xiàn)，因為單看一個數(shù)據(jù)是對的，但批量操作時就露餡了。
手寫簡化版：面試必考的手動實現(xiàn)
既然提到了高頻面試題，這里必須手寫一個簡化版的 fill，這是考察你對數(shù)組索引、邊界處理掌握程度的經(jīng)典題目。
/*** 手寫 Array.prototype.fill* 要求：支持 start 和 end 參數(shù)，支持負數(shù)索引* * @param {*} value - 填充值* @param {number} start - 起始位置* @param {number} end - 結(jié)束位置* @returns {Array} 當(dāng)前數(shù)組（原地修改）*/
Array.prototype.myFill = function(value, start = 0, end) {// 1. 邊界檢查：確保 this 是數(shù)組if (this === undefined || this === null || !Array.isArray(this)) {throw new TypeError('Cannot call myFill on non-array');}const len = this.length;// 2. 處理 start 索引// 如果 start 是負數(shù)，從末尾往前數(shù)let from = start 0 ? Math.max(len + start, 0) : Math.min(start, len);// 3. 處理 end 索引// 如果 end 未定義，默認為 len// 如果 end 是負數(shù)，從末尾往前數(shù)let to = end === undefined ? len : (end 0 ? Math.max(len + end, 0) : Math.min(end, len));// 4. 確保 from 不大于 to，否則直接返回if (from to) {return this;}// 5. 執(zhí)行填充for (let i = from; i to; i++) {this[i] = value;}return this;
}// 測試
console.log([1, 2, 3, 4, 5].myFill(0)); // [0, 0, 0, 0, 0]
console.log([1, 2, 3, 4, 5].myFill(0, 1)); // [1, 0, 0, 0, 0]
console.log([1, 2, 3, 4, 5].myFill(0, -1)); // [1, 2, 3, 4, 0]
console.log([1, 2, 3, 4, 5].myFill(0, 1, 3)); // [1, 0, 0, 4, 5]
console.log([1, 2, 3, 4, 5].myFill(0, 3, 1)); // [1, 2, 3, 4, 5] (from to)面試時，考官往往會追問：“如果 value 是對象，你的實現(xiàn)有什么隱患？” 這時候你要主動指出引用共享的問題，并建議在生產(chǎn)環(huán)境中避免用 fill 填充對象，或者在填充后立即深拷貝每個元素。
應(yīng)用場景：從耳機列表到通用工具
回到開頭的 fill耳機 場景，現(xiàn)在我們有了完整的解決方案。除了修復(fù) Bug，還可以把這種模式封裝成通用工具。
在 NPM 生態(tài)中，有很多包專門處理數(shù)據(jù)轉(zhuǎn)換，比如 lodash 的 _.fill 或 _.defaults。但為了減小包體積，我們可以自己寫一個輕量級的工具函數(shù)：
/*** 安全填充數(shù)組，避免引用共享問題* @param {number} length - 數(shù)組長度* @param {Function|*} factoryOrValue - 工廠函數(shù)或固定值* @returns {Array}*/
function safeFillArray(length, factoryOrValue) {const arr = new Array(length);for (let i = 0; i length; i++) {if (typeof factoryOrValue === 'function') {// 每次調(diào)用工廠函數(shù)，生成新對象arr[i] = factoryOrValue(i);} else {// 如果是基本類型，直接賦值// 如果是對象，需要深拷貝（這里簡化處理，實際項目建議用 structuredClone）arr[i] = typeof factoryOrValue === 'object' factoryOrValue !== null ? { ...factoryOrValue } : factoryOrValue;}}return arr;
}// 使用示例：初始化耳機列表的樣式
const headphoneCount = 3;
const styles = safeFillArray(headphoneCount, () = ({color: 'black',size: 'medium',icon: 'headphone'
}));// 修改第一個耳機的顏色，不影響其他耳機
styles[0].color = 'red';
console.log(styles[1].color); // 輸出 'black'，正確！這個 safeFillArray 函數(shù)比原生 fill 更安全，特別是在處理對象時。在實際項目中，我建議你把這個函數(shù)放在 utils 目錄，全局使用。
另外，關(guān)于數(shù)據(jù)源，一定要確保從可信渠道獲取。比如耳機的價格、庫存等關(guān)鍵數(shù)據(jù)，應(yīng)該來自官方 API 或經(jīng)過驗證的 NPM/PyPI 官方包提供的 SDK，而不是隨意抓取的第三方接口。這不僅是為了數(shù)據(jù)準(zhǔn)確性，也是為了避免法律風(fēng)險。
結(jié)尾互動
聊到這里，fill 的坑基本都講透了。從報錯定位到源碼實現(xiàn)，再到手寫面試技巧，希望這篇文章能幫你避開那些隱蔽的 Bug。
最后拋個問題：在你日常開發(fā)中，更常用 Array.prototype.fill 還是 new Array(n).fill()？有沒有遇到過因為引用共享導(dǎo)致的靈異 Bug？評論區(qū)交流一下，咱們互相避坑。 3步搞定fill耳機報錯，高頻面試題實戰(zhàn)解析
3步搞定fill耳機報錯，高頻面試題實戰(zhàn)解析
剛接了個新需求，后端接口返回的數(shù)據(jù)結(jié)構(gòu)里有個字段叫 fill，前端渲染耳機列表時突然炸了。控制臺全是紅字，StackTrace 長得像天書，一眼望去全是 TypeError: Cannot read properties of undefined (reading 'map')。這種時候最搞心態(tài)，明明數(shù)據(jù)看起來沒問題，一跑代碼就崩。更坑的是，這題最近面試老被問，屬于那種“看似簡單實則坑多”的高頻面試題。今天不整虛的，直接拆源碼，看看底層到底咋回事，順便把 fill 這個 API 的進階用法扒個底朝天。
入口定位：報錯到底在哪
很多新手遇到報錯，第一反應(yīng)是去查 MDN 文檔，但往往查不到點子上。因為報錯信息里的 fill 可能指代兩個東西：一是數(shù)組方法 Array.prototype.fill，二是業(yè)務(wù)邏輯里的“填充”操作。在我們這個耳機列表的場景里，問題出在數(shù)據(jù)預(yù)處理階段。
假設(shè)后端返回的數(shù)據(jù)是這樣的：
{headphones: [{ id: 1, name: Sony WH-1000XM5, price: 2999 },{ id: 2, name: AirPods Max, price: 4399 },{ id: 3, name: Bose QC45, price: 2499 }],fill: default_color
}前端代碼里為了初始化樣式，寫了一段類似這樣的邏輯：
const defaultStyles = new Array(3).fill(null);
const processedHeadphones = data.headphones.map((item, index) = {return {...item,style: defaultStyles[index] || 'default'};
});乍一看沒問題，對吧？new Array(3).fill(null) 創(chuàng)建了一個長度為3的全 null 數(shù)組。但如果后端數(shù)據(jù)變動，比如突然加了第4款耳機，或者 headphones 字段缺失，這里就會炸。更隱蔽的問題是，如果 data 本身是 undefined 或 null，data.headphones 這一步就會直接拋出 TypeError。
這時候你需要打開瀏覽器的 DevTools，點擊那個紅色的報錯圖標(biāo)，查看 Call Stack。你會發(fā)現(xiàn)調(diào)用棧最頂層通常是 map，但根本原因往往在 data 的解構(gòu)或訪問上。記住，報錯的最后一行才是線索，報錯的第一行才是現(xiàn)場。
核心片段：源碼級拆解
要真正理解 fill 的坑，得看它是怎么實現(xiàn)的。雖然 Array.prototype.fill 是內(nèi)置方法，但我們可以看看它的簡化實現(xiàn)邏輯，以及它在現(xiàn)代框架（如 React 或 Vue）中是如何被誤用的。
片段一：Array.fill 的底層邏輯模擬
這是 ES6 新增的方法，但在實際項目中，我們很少直接用它來處理動態(tài)數(shù)據(jù)，更多是用于靜態(tài)初始化。下面這段代碼模擬了 fill 的核心行為，注釋里標(biāo)出了容易踩的坑：
/*** 模擬 Array.prototype.fill 的核心邏輯* @param {Array} arr - 目標(biāo)數(shù)組* @param {*} value - 填充值* @param {number} start - 起始索引，默認為 0* @param {number} end - 結(jié)束索引，默認為數(shù)組長度* @returns {Array} 修改后的數(shù)組*/
function customFill(arr, value, start = 0, end = arr.length) {// 坑點1：如果 arr 不是數(shù)組，直接拋錯，這就是 StackTrace 里 TypeError 的來源之一if (!Array.isArray(arr)) {throw new TypeError('Cannot call fill on non-array');}const len = arr.length;// 坑點2：start 和 end 的邊界處理，很多人忽略負數(shù)索引let from = start 0 ? Math.max(len + start, 0) : Math.min(start, len);let to = end === undefined ? len : (end 0 ? Math.max(len + end, 0) : Math.min(end, len));// 核心循環(huán)：從 from 到 to-1 進行賦值for (let i = from; i to; i++) {arr[i] = value; // 坑點3：這里是淺拷貝，如果 value 是對象，所有位置引用同一個對象}return arr;
}// 測試用例
const arr1 = new Array(5).fill(null); // [null, null, null, null, null]
const arr2 = new Array(5).fill(0); // [0, 0, 0, 0, 0]// 危險操作演示
const obj = { id: 1 };
const arr3 = new Array(3).fill(obj);
arr3[0].id = 999;
console.log(arr3[1].id); // 輸出 999，因為 arr3[0] 和 arr3[1] 是同一個對象引用這段代碼揭示了為什么在耳機列表場景中，如果不小心用了對象填充，會導(dǎo)致所有耳機共享同一個樣式對象，一改全改。
片段二：結(jié)合業(yè)務(wù)場景的修復(fù)方案
回到我們的耳機列表，正確的做法不是硬用 fill，而是根據(jù)實際數(shù)據(jù)長度動態(tài)生成占位符，并做好防御性編程。
/*** 安全處理耳機列表數(shù)據(jù)，避免 undefined 報錯* @param {Object} data - 后端返回的原始數(shù)據(jù)* @returns {Array} 處理后的耳機數(shù)組*/
function processHeadphoneData(data) {// 防御性編程：確保 data 和 data.headphones 存在const headphones = (data Array.isArray(data.headphones)) ? data.headphones : [];// 如果數(shù)據(jù)為空，返回空數(shù)組，而不是一個全 null 的數(shù)組if (headphones.length === 0) {return [];}// 使用 map 而不是 fill 來初始化樣式，確保每個項獨立return headphones.map(item = {// 如果 item 本身缺失，提供默認值if (!item || typeof item !== 'object') {return { id: 0, name: 'Unknown', price: 0, style: 'default' };}return {...item,// 關(guān)鍵：這里用邏輯運算符確保 style 有默認值，避免 undefinedstyle: item.style || 'default',// 如果業(yè)務(wù)需要填充缺失的字段，用顯式賦值而不是 fill...getMissingFields(item)};});
}// 輔助函數(shù)：處理缺失字段
function getMissingFields(item) {const defaults = {name: 'No Name',price: 0,color: 'Black'};// 只填充缺失的字段，不影響已有數(shù)據(jù)return Object.keys(defaults).reduce((acc, key) = {if (item[key] === undefined) {acc[key] = defaults[key];}return acc;}, {});
}注意這里的關(guān)鍵區(qū)別：fill 適合靜態(tài)初始化，不適合動態(tài)數(shù)據(jù)映射。在真實業(yè)務(wù)中，數(shù)據(jù)是流動的，用 map + 解構(gòu)賦值更安全。
設(shè)計思想：為什么框架不直接用 fill
你可能會問，為什么 React 的 useState 或者 Vue 的 ref 內(nèi)部不使用 fill 來初始化數(shù)組？這涉及到底層性能和數(shù)據(jù)一致性的設(shè)計思想。引用一致性：fill 填充對象時，所有元素指向同一引用。在響應(yīng)式框架中，這會導(dǎo)致依賴追蹤混亂。比如 Vue 3 的 reactive，如果數(shù)組里所有項是同一個對象，修改一項會觸發(fā)所有項的更新，造成不必要的重渲染。
惰性初始化：現(xiàn)代框架傾向于惰性加載。比如虛擬列表（Virtual List），只有在視口內(nèi)的元素才會被真實創(chuàng)建。如果一開始就用 fill 填充了 10000 個空對象，內(nèi)存直接爆掉。
不可變性原則：前端開發(fā)越來越推崇不可變數(shù)據(jù)。fill 是原地修改（In-place），而 map 返回新數(shù)組，更符合函數(shù)式編程思維，也更容易調(diào)試。在實際項目中，我見過太多因為誤用 fill 導(dǎo)致的 Bug。比如在一個電商后臺，管理員批量設(shè)置耳機庫存時，用了 new Array(count).fill({ stock: 0 })，結(jié)果所有耳機的庫存都綁定到了同一個對象，改一個全變。這種 Bug 在測試階段很難發(fā)現(xiàn)，因為單看一個數(shù)據(jù)是對的，但批量操作時就露餡了。
手寫簡化版：面試必考的手動實現(xiàn)
既然提到了高頻面試題，這里必須手寫一個簡化版的 fill，這是考察你對數(shù)組索引、邊界處理掌握程度的經(jīng)典題目。
/*** 手寫 Array.prototype.fill* 要求：支持 start 和 end 參數(shù)，支持負數(shù)索引* * @param {*} value - 填充值* @param {number} start - 起始位置* @param {number} end - 結(jié)束位置* @returns {Array} 當(dāng)前數(shù)組（原地修改）*/
Array.prototype.myFill = function(value, start = 0, end) {// 1. 邊界檢查：確保 this 是數(shù)組if (this === undefined || this === null || !Array.isArray(this)) {throw new TypeError('Cannot call myFill on non-array');}const len = this.length;// 2. 處理 start 索引// 如果 start 是負數(shù)，從末尾往前數(shù)let from = start 0 ? Math.max(len + start, 0) : Math.min(start, len);// 3. 處理 end 索引// 如果 end 未定義，默認為 len// 如果 end 是負數(shù)，從末尾往前數(shù)let to = end === undefined ? len : (end 0 ? Math.max(len + end, 0) : Math.min(end, len));// 4. 確保 from 不大于 to，否則直接返回if (from to) {return this;}// 5. 執(zhí)行填充for (let i = from; i to; i++) {this[i] = value;}return this;
}// 測試
console.log([1, 2, 3, 4, 5].myFill(0)); // [0, 0, 0, 0, 0]
console.log([1, 2, 3, 4, 5].myFill(0, 1)); // [1, 0, 0, 0, 0]
console.log([1, 2, 3, 4, 5].myFill(0, -1)); // [1, 2, 3, 4, 0]
console.log([1, 2, 3, 4, 5].myFill(0, 1, 3)); // [1, 0, 0, 4, 5]
console.log([1, 2, 3, 4, 5].myFill(0, 3, 1)); // [1, 2, 3, 4, 5] (from to)面試時，考官往往會追問：“如果 value 是對象，你的實現(xiàn)有什么隱患？” 這時候你要主動指出引用共享的問題，并建議在生產(chǎn)環(huán)境中避免用 fill 填充對象，或者在填充后立即深拷貝每個元素。
應(yīng)用場景：從耳機列表到通用工具
回到開頭的 fill耳機 場景，現(xiàn)在我們有了完整的解決方案。除了修復(fù) Bug，還可以把這種模式封裝成通用工具。
在 NPM 生態(tài)中，有很多包專門處理數(shù)據(jù)轉(zhuǎn)換，比如 lodash 的 _.fill 或 _.defaults。但為了減小包體積，我們可以自己寫一個輕量級的工具函數(shù)：
/*** 安全填充數(shù)組，避免引用共享問題* @param {number} length - 數(shù)組長度* @param {Function|*} factoryOrValue - 工廠函數(shù)或固定值* @returns {Array}*/
function safeFillArray(length, factoryOrValue) {const arr = new Array(length);for (let i = 0; i length; i++) {if (typeof factoryOrValue === 'function') {// 每次調(diào)用工廠函數(shù)，生成新對象arr[i] = factoryOrValue(i);} else {// 如果是基本類型，直接賦值// 如果是對象，需要深拷貝（這里簡化處理，實際項目建議用 structuredClone）arr[i] = typeof factoryOrValue === 'object' factoryOrValue !== null ? { ...factoryOrValue } : factoryOrValue;}}return arr;
}// 使用示例：初始化耳機列表的樣式
const headphoneCount = 3;
const styles = safeFillArray(headphoneCount, () = ({color: 'black',size: 'medium',icon: 'headphone'
}));// 修改第一個耳機的顏色，不影響其他耳機
styles[0].color = 'red';
console.log(styles[1].color); // 輸出 'black'，正確！這個 safeFillArray 函數(shù)比原生 fill 更安全，特別是在處理對象時。在實際項目中，我建議你把這個函數(shù)放在 utils 目錄，全局使用。
另外，關(guān)于數(shù)據(jù)源，一定要確保從可信渠道獲取。比如耳機的價格、庫存等關(guān)鍵數(shù)據(jù)，應(yīng)該來自官方 API 或經(jīng)過驗證的 NPM/PyPI 官方包提供的 SDK，而不是隨意抓取的第三方接口。這不僅是為了數(shù)據(jù)準(zhǔn)確性，也是為了避免法律風(fēng)險。
結(jié)尾互動
聊到這里，fill 的坑基本都講透了。從報錯定位到源碼實現(xiàn)，再到手寫面試技巧，希望這篇文章能幫你避開那些隱蔽的 Bug。
最后拋個問題：在你日常開發(fā)中，更常用 Array.prototype.fill 還是 new Array(n).fill()？有沒有遇到過因為引用共享導(dǎo)致的靈異 Bug？評論區(qū)交流一下，咱們互相避坑。