拒絕死等：手寫實現(xiàn)異步加載，搞定圖片等待難題
配置環(huán)境就卡半天，這是很多剛入行嵌入式開發(fā)的兄弟最真實的寫照。
你盯著屏幕，代碼邏輯明明沒問題，為什么圖片就是不顯示？或者頁面加載時，圖片區(qū)域白花花一片，用戶以為系統(tǒng)卡死了。這時候，很多人只會用 setTimeout 或者簡單的 onload 事件，結果就是：要么時序錯亂，要么性能極差。
今天咱們不整虛的，直接上手。我要帶你手寫實現(xiàn)一個基于 Promise 的圖片加載等待機制。這不是為了炫技，而是為了讓你徹底搞懂瀏覽器/系統(tǒng)是如何處理異步資源加載的。在嵌入式 Web 界面（如 HMI 人機交互界面）或者高性能前端應用中，這種底層控制能力決定了你的界面響應速度。
概念速懂：為什么你需要控制“等待”
在嵌入式開發(fā)或者前端工程中，“等待圖片”不僅僅是讓圖片顯示出來那么簡單。
想象一下，你在開發(fā)一個工業(yè)控制屏的 Web 界面。屏幕上有 50 個狀態(tài)指示燈圖標，還有一個大的背景圖。如果這 50 個圖標是異步加載的，用戶點擊某個按鈕時，對應的圖標可能還沒加載完。這時候如果直接渲染，用戶看到的就是一個空的占位符，甚至報錯。
傳統(tǒng)的做法是：發(fā)請求，等瀏覽器回調。
現(xiàn)代的做法是：將“加載圖片”這個動作抽象成一個可等待的 Promise。
為什么非要手寫實現(xiàn)？可控性：你可以設置超時時間（Timeout），防止網絡抖動導致界面永久卡死。
并發(fā)控制：嵌入式設備資源有限（CPU、內存、網絡帶寬），你不能讓 100 張圖片同時發(fā)起請求，需要限制并發(fā)數(shù)。
調試友好：當出錯時，你能明確知道是哪一步失敗了，而不是得到一個模糊的 Load Error。從 RFC 規(guī)范的角度來看，HTTP 協(xié)議本身是無狀態(tài)的，而圖片加載本質上是 HTTP GET 請求。RFC 9110 中詳細定義了狀態(tài)碼和重試機制。雖然瀏覽器封裝了這些細節(jié)，但在底層實現(xiàn)或 Node.js 環(huán)境中，理解這些協(xié)議細節(jié)有助于我們寫出更健壯的資源加載器。
環(huán)境準備：不只是裝個 Node.js
既然要手寫實現(xiàn)，我們需要一個干凈的環(huán)境來驗證邏輯。對于嵌入式開發(fā)者來說，Node.js 是連接后端邏輯和前端界面的橋梁，非常適合用來模擬和測試加載策略。
所需工具：Node.js (v16+)：確保支持原生的 fetch 和 Promise。
一個本地 HTTP 服務器：用于模擬圖片資源。
VS Code：配合 ESLint 和 Prettier，保持代碼規(guī)范。避坑指南：
很多新手在配置環(huán)境時就卡半天，最常見的問題是 CORS（跨域資源共享）。如果你在本地直接 file:// 協(xié)議下運行腳本去請求本地圖片，瀏覽器會攔截。
解決方案：
務必使用本地服務器。這里提供一個極簡的 server.js：
const http = require('http');
const fs = require('fs');
const path = require('path');const server = http.createServer((req, res) = {// 簡單映射 /img 目錄到靜態(tài)文件const filePath = path.join(__dirname, 'public', req.url);if (req.url === '/img/test.png') {// 模擬網絡延遲，方便觀察加載過程setTimeout(() = {fs.readFile(path.join(__dirname, 'public', 'test.png'), (err, data) = {if (err) {res.writeHead(500);res.end('Not Found');} else {res.writeHead(200, { 'Content-Type': 'image/png' });res.end(data);}});}, 2000); // 故意延遲2秒，模擬慢速網絡} else {res.writeHead(404);res.end('404');}
});server.listen(3000, () = {console.log('Mock Server running on port 3000');
});關鍵點：模擬延遲：我在代碼里加了 setTimeout 2秒。這在嵌入式網絡環(huán)境中很常見，測試時如果沒有延遲，你很難感知到異步競態(tài)條件。
內容類型：正確設置 Content-Type 是圖片能被正確解析的前提。核心語法：手寫 Promise 包裝器
現(xiàn)在進入正題。我們要手寫實現(xiàn)一個 loadImage 函數(shù)。
核心思路：創(chuàng)建一個新的 Image 對象（在瀏覽器環(huán)境）或發(fā)起 fetch 請求（在 Node.js/通用環(huán)境）。
將異步回調轉換為 Promise 的 resolve 和 reject。
加入超時機制。這里我們以瀏覽器環(huán)境為主（因為嵌入式 HMI 通?；?Chromium 內核），但邏輯在 Node.js 中通過 fetch 也能通用。
代碼實現(xiàn)：
/*** 手寫實現(xiàn)：帶超時的圖片加載器* @param {string} src - 圖片URL* @param {number} timeout - 超時時間(毫秒)* @returns {PromiseHTMLImageElement} - 解析為加載完成的Image對象*/
function loadImage(src, timeout = 5000) {return new Promise((resolve, reject) = {const img = new Image();let isTimeout = false;// 1. 設置超時邏輯const timer = setTimeout(() = {isTimeout = true;img.src = ''; // 清除源，阻止后續(xù)事件觸發(fā)reject(new Error(`加載超時: ${src}`));}, timeout);// 2. 成功回調img.onload = () = {if (isTimeout) return; // 如果已經超時，忽略加載成功事件clearTimeout(timer); // 清除定時器，避免內存泄漏resolve(img); // 返回加載好的 Image 對象};// 3. 失敗回調img.onerror = (err) = {if (isTimeout) return;clearTimeout(timer);reject(new Error(`加載失敗: ${src}`));};// 4. 設置源，觸發(fā)加載img.src = src;});
}逐行解析：new Promise：這是異步編程的核心。我們將回調地獄扁平化。
isTimeout 標志位：這是一個經典的競態(tài)條件處理技巧。如果超時了，但圖片恰好在下一毫秒加載完成了，onload 還會觸發(fā)。如果不清除定時器或不加標志位，Promise 狀態(tài)就無法確定（雖然 Promise 一旦 settle 就不能改變，但資源釋放和邏輯混亂是隱患）。
img.src = ''：在超時后主動斷開連接，這是一種防御性編程。
resolve(img)：我們返回的是 img 對象，而不是 true。這樣調用者可以直接拿到 img.width 和 img.height，用于后續(xù)的布局計算。完整代碼示例：并發(fā)控制與實戰(zhàn)應用
單個圖片加載很簡單，難的是批量加載。在嵌入式界面初始化時，我們需要一次性加載幾十張圖標。如果全部并發(fā)，CPU 瞬間飆升，網絡隊列溢出。
這里引入一個進階技巧：并發(fā)限制（Concurrency Limit）。
我們手寫一個 pool 函數(shù)，限制同時進行的請求數(shù)。
/*** 并發(fā)限制執(zhí)行器* @param {Array} tasks - 任務數(shù)組(包含URL和名稱)* @param {number} limit - 最大并發(fā)數(shù)* @param {Function} onProgress - 進度回調* @returns {PromiseMapstring, HTMLImageElement} - 鍵為名稱，值為Image對象*/
async function loadImagesWithLimit(tasks, limit = 3) {const results = new Map();const queue = [...tasks];const active = new Set();let completedCount = 0;const total = tasks.length;return new Promise((resolve, reject) = {// 如果任務列表為空，直接返回if (queue.length === 0) {resolve(results);return;}const nextTask = () = {// 如果隊列空且沒有活躍任務，完成if (queue.length === 0 active.size === 0) {resolve(results);return;}// 如果活躍任務少于限制，啟動新任務while (active.size limit queue.length 0) {const task = queue.shift();const taskId = Symbol(); // 唯一標識active.add(taskId);loadImage(task.url, 10000) // 10秒超時.then(img = {results.set(task.name, img);completedCount++;onProgress onProgress(completedCount, total);}).catch(err = {// 這里可以選擇 reject 整個 Promise，或者記錄錯誤繼續(xù)console.error(`[ERROR] ${task.name}:`, err.message);// 為了演示健壯性，這里我們選擇記錄錯誤并繼續(xù)，不中斷整體流程// 如果業(yè)務要求嚴格，可以改為 reject(err)}).finally(() = {active.delete(taskId);nextTask(); // 遞歸調度下一個});}};nextTask();});
}實戰(zhàn)場景模擬：
假設我們要加載一個儀表盤的所有圖標。
const iconList = [{ name: 'power', url: '/img/power.png' },{ name: 'status', url: '/img/status.png' },{ name: 'alarm', url: '/img/alarm.png' },{ name: 'temp', url: '/img/temp.png' },{ name: 'fan', url: '/img/fan.png' }
];async function initDashboard() {console.log('開始初始化儀表盤...');const startTime = Date.now();try {// 限制并發(fā)為 2，模擬嵌入式設備帶寬限制const loadedImages = await loadImagesWithLimit(iconList, 2, (current, total) = {console.log(`進度: ${current}/${total}`);// 這里可以更新 UI 進度條document.getElementById('progress').value = (current / total) * 100;});const duration = Date.now() - startTime;console.log(`加載完成，耗時: ${duration}ms`);// 渲染邏輯loadedImages.forEach((img, name) = {const el = document.getElementById(`icon-${name}`);if (el) {el.src = img.src;// 可以利用 img.width/height 設置 aspect-ratioel.style.width = '50px';el.style.height = '50px';}});} catch (error) {console.error('初始化失敗:', error);// 顯示錯誤 UI}
}// 執(zhí)行
initDashboard();這段代碼的亮點：active Set：用集合追蹤當前正在運行的任務 ID，比簡單的計數(shù)器更可靠，防止閉包陷阱。
finally 中的遞歸：確保無論成功還是失敗，都會觸發(fā)下一個任務的調度，避免“死鎖”（即某個任務卡住，后續(xù)任務永遠不執(zhí)行）。
錯誤隔離：單個圖片加載失敗不會導致整個 Promise 鏈崩潰。這在嵌入式系統(tǒng)中非常重要，一個圖標加載失敗不應該導致整個 HMI 界面白屏。常見報錯與避坑指南
在手寫實現(xiàn)的過程中，我踩過無數(shù)坑。以下是三個最高頻的問題，直接給你解決方案。
1. 內存泄漏：Image 對象未釋放
現(xiàn)象：長時間運行后，瀏覽器內存持續(xù)增長，最終崩潰。
原因：img 對象被閉包引用，且 onload 和 onerror 事件監(jiān)聽器未被移除。雖然瀏覽器有 GC（垃圾回收），但在嵌入式資源受限環(huán)境下，主動清理是必須的。
修正方案：
在 loadImage 函數(shù)中，增加一個 destroy 方法或在 finally 中清理。
// 在 loadImage 的 Promise 執(zhí)行器中
img.onload = () = {clearTimeout(timer);resolve(img);// 可選：如果不需要保留 DOM 引用，可以移除監(jiān)聽器img.onload = null;img.onerror = null;
};注意：在 Web 標準中，Image 對象是輕量的，通常不需要手動 removeEventListener，除非你將其附加到 DOM 并綁定了大量其他事件。但在 Node.js 環(huán)境中，務必關閉連接。
2. 跨域污染：CORS 錯誤
現(xiàn)象：控制臺報錯 Cross-Origin Image request blocked by CORS policy。
原因：圖片服務器沒有返回 Access-Control-Allow-Origin 頭。
解決方案：前端：設置 img.crossOrigin = 'anonymous'。這會強制瀏覽器進行 CORS 檢查。如果服務器不支持，圖片將加載失?。ū褥o默失敗好，因為你能發(fā)現(xiàn)配置問題）。
后端：在 Nginx 或 Node.js 服務器中，務必添加響應頭：
res.setHeader('Access-Control-Allow-Origin', '*');3. 超時后的競態(tài)條件
現(xiàn)象：圖片明明加載成功了，但 Promise 卻 reject 了。
原因：超時定時器觸發(fā) reject 后，圖片的 onload 事件在微任務隊列中稍后執(zhí)行。
修正方案：
這就是我前面代碼中 isTimeout 標志位的作用。確保在 onload 中檢查該標志，如果已超時，直接 return，不再 resolve。
小結
通過這篇教程，我們不僅搞定了“等待圖片”這個看似簡單的問題，更重要的是掌握了手寫實現(xiàn)異步資源加載的核心邏輯。從回調到 Promise：理解了如何將瀏覽器原生事件封裝為現(xiàn)代異步編程接口。
超時與并發(fā)：學會了如何處理網絡不確定性，以及如何優(yōu)化資源有限的嵌入式環(huán)境下的加載性能。
RFC 與底層原理：雖然代碼層面是 JS，但背后是對 HTTP 協(xié)議和瀏覽器渲染引擎行為的深刻理解。在嵌入式開發(fā)中，界面響應速度直接影響用戶體驗。不要依賴框架的黑盒加載器，手寫實現(xiàn)底層邏輯，能讓你在面試中侃侃而談，更能在實際項目中解決那些“玄學”般的加載 Bug。
你更常用哪種寫法？是直接用 new Image() 還是借助 fetch 轉 Blob？或者你有更獨特的并發(fā)控制策略？評論區(qū)交流，我們一起避坑。 等待圖片面試必問
拒絕死等：手寫實現(xiàn)異步加載，搞定圖片等待難題
配置環(huán)境就卡半天，這是很多剛入行嵌入式開發(fā)的兄弟最真實的寫照。
你盯著屏幕，代碼邏輯明明沒問題，為什么圖片就是不顯示？或者頁面加載時，圖片區(qū)域白花花一片，用戶以為系統(tǒng)卡死了。這時候，很多人只會用 setTimeout 或者簡單的 onload 事件，結果就是：要么時序錯亂，要么性能極差。
今天咱們不整虛的，直接上手。我要帶你手寫實現(xiàn)一個基于 Promise 的圖片加載等待機制。這不是為了炫技，而是為了讓你徹底搞懂瀏覽器/系統(tǒng)是如何處理異步資源加載的。在嵌入式 Web 界面（如 HMI 人機交互界面）或者高性能前端應用中，這種底層控制能力決定了你的界面響應速度。
概念速懂：為什么你需要控制“等待”
在嵌入式開發(fā)或者前端工程中，“等待圖片”不僅僅是讓圖片顯示出來那么簡單。
想象一下，你在開發(fā)一個工業(yè)控制屏的 Web 界面。屏幕上有 50 個狀態(tài)指示燈圖標，還有一個大的背景圖。如果這 50 個圖標是異步加載的，用戶點擊某個按鈕時，對應的圖標可能還沒加載完。這時候如果直接渲染，用戶看到的就是一個空的占位符，甚至報錯。
傳統(tǒng)的做法是：發(fā)請求，等瀏覽器回調。
現(xiàn)代的做法是：將“加載圖片”這個動作抽象成一個可等待的 Promise。
為什么非要手寫實現(xiàn)？可控性：你可以設置超時時間（Timeout），防止網絡抖動導致界面永久卡死。
并發(fā)控制：嵌入式設備資源有限（CPU、內存、網絡帶寬），你不能讓 100 張圖片同時發(fā)起請求，需要限制并發(fā)數(shù)。
調試友好：當出錯時，你能明確知道是哪一步失敗了，而不是得到一個模糊的 Load Error。從 RFC 規(guī)范的角度來看，HTTP 協(xié)議本身是無狀態(tài)的，而圖片加載本質上是 HTTP GET 請求。RFC 9110 中詳細定義了狀態(tài)碼和重試機制。雖然瀏覽器封裝了這些細節(jié)，但在底層實現(xiàn)或 Node.js 環(huán)境中，理解這些協(xié)議細節(jié)有助于我們寫出更健壯的資源加載器。
環(huán)境準備：不只是裝個 Node.js
既然要手寫實現(xiàn)，我們需要一個干凈的環(huán)境來驗證邏輯。對于嵌入式開發(fā)者來說，Node.js 是連接后端邏輯和前端界面的橋梁，非常適合用來模擬和測試加載策略。
所需工具：Node.js (v16+)：確保支持原生的 fetch 和 Promise。
一個本地 HTTP 服務器：用于模擬圖片資源。
VS Code：配合 ESLint 和 Prettier，保持代碼規(guī)范。避坑指南：
很多新手在配置環(huán)境時就卡半天，最常見的問題是 CORS（跨域資源共享）。如果你在本地直接 file:// 協(xié)議下運行腳本去請求本地圖片，瀏覽器會攔截。
解決方案：
務必使用本地服務器。這里提供一個極簡的 server.js：
const http = require('http');
const fs = require('fs');
const path = require('path');const server = http.createServer((req, res) = {// 簡單映射 /img 目錄到靜態(tài)文件const filePath = path.join(__dirname, 'public', req.url);if (req.url === '/img/test.png') {// 模擬網絡延遲，方便觀察加載過程setTimeout(() = {fs.readFile(path.join(__dirname, 'public', 'test.png'), (err, data) = {if (err) {res.writeHead(500);res.end('Not Found');} else {res.writeHead(200, { 'Content-Type': 'image/png' });res.end(data);}});}, 2000); // 故意延遲2秒，模擬慢速網絡} else {res.writeHead(404);res.end('404');}
});server.listen(3000, () = {console.log('Mock Server running on port 3000');
});關鍵點：模擬延遲：我在代碼里加了 setTimeout 2秒。這在嵌入式網絡環(huán)境中很常見，測試時如果沒有延遲，你很難感知到異步競態(tài)條件。
內容類型：正確設置 Content-Type 是圖片能被正確解析的前提。核心語法：手寫 Promise 包裝器
現(xiàn)在進入正題。我們要手寫實現(xiàn)一個 loadImage 函數(shù)。
核心思路：創(chuàng)建一個新的 Image 對象（在瀏覽器環(huán)境）或發(fā)起 fetch 請求（在 Node.js/通用環(huán)境）。
將異步回調轉換為 Promise 的 resolve 和 reject。
加入超時機制。這里我們以瀏覽器環(huán)境為主（因為嵌入式 HMI 通?；?Chromium 內核），但邏輯在 Node.js 中通過 fetch 也能通用。
代碼實現(xiàn)：
/*** 手寫實現(xiàn)：帶超時的圖片加載器* @param {string} src - 圖片URL* @param {number} timeout - 超時時間(毫秒)* @returns {PromiseHTMLImageElement} - 解析為加載完成的Image對象*/
function loadImage(src, timeout = 5000) {return new Promise((resolve, reject) = {const img = new Image();let isTimeout = false;// 1. 設置超時邏輯const timer = setTimeout(() = {isTimeout = true;img.src = ''; // 清除源，阻止后續(xù)事件觸發(fā)reject(new Error(`加載超時: ${src}`));}, timeout);// 2. 成功回調img.onload = () = {if (isTimeout) return; // 如果已經超時，忽略加載成功事件clearTimeout(timer); // 清除定時器，避免內存泄漏resolve(img); // 返回加載好的 Image 對象};// 3. 失敗回調img.onerror = (err) = {if (isTimeout) return;clearTimeout(timer);reject(new Error(`加載失敗: ${src}`));};// 4. 設置源，觸發(fā)加載img.src = src;});
}逐行解析：new Promise：這是異步編程的核心。我們將回調地獄扁平化。
isTimeout 標志位：這是一個經典的競態(tài)條件處理技巧。如果超時了，但圖片恰好在下一毫秒加載完成了，onload 還會觸發(fā)。如果不清除定時器或不加標志位，Promise 狀態(tài)就無法確定（雖然 Promise 一旦 settle 就不能改變，但資源釋放和邏輯混亂是隱患）。
img.src = ''：在超時后主動斷開連接，這是一種防御性編程。
resolve(img)：我們返回的是 img 對象，而不是 true。這樣調用者可以直接拿到 img.width 和 img.height，用于后續(xù)的布局計算。完整代碼示例：并發(fā)控制與實戰(zhàn)應用
單個圖片加載很簡單，難的是批量加載。在嵌入式界面初始化時，我們需要一次性加載幾十張圖標。如果全部并發(fā)，CPU 瞬間飆升，網絡隊列溢出。
這里引入一個進階技巧：并發(fā)限制（Concurrency Limit）。
我們手寫一個 pool 函數(shù)，限制同時進行的請求數(shù)。
/*** 并發(fā)限制執(zhí)行器* @param {Array} tasks - 任務數(shù)組(包含URL和名稱)* @param {number} limit - 最大并發(fā)數(shù)* @param {Function} onProgress - 進度回調* @returns {PromiseMapstring, HTMLImageElement} - 鍵為名稱，值為Image對象*/
async function loadImagesWithLimit(tasks, limit = 3) {const results = new Map();const queue = [...tasks];const active = new Set();let completedCount = 0;const total = tasks.length;return new Promise((resolve, reject) = {// 如果任務列表為空，直接返回if (queue.length === 0) {resolve(results);return;}const nextTask = () = {// 如果隊列空且沒有活躍任務，完成if (queue.length === 0 active.size === 0) {resolve(results);return;}// 如果活躍任務少于限制，啟動新任務while (active.size limit queue.length 0) {const task = queue.shift();const taskId = Symbol(); // 唯一標識active.add(taskId);loadImage(task.url, 10000) // 10秒超時.then(img = {results.set(task.name, img);completedCount++;onProgress onProgress(completedCount, total);}).catch(err = {// 這里可以選擇 reject 整個 Promise，或者記錄錯誤繼續(xù)console.error(`[ERROR] ${task.name}:`, err.message);// 為了演示健壯性，這里我們選擇記錄錯誤并繼續(xù)，不中斷整體流程// 如果業(yè)務要求嚴格，可以改為 reject(err)}).finally(() = {active.delete(taskId);nextTask(); // 遞歸調度下一個});}};nextTask();});
}實戰(zhàn)場景模擬：
假設我們要加載一個儀表盤的所有圖標。
const iconList = [{ name: 'power', url: '/img/power.png' },{ name: 'status', url: '/img/status.png' },{ name: 'alarm', url: '/img/alarm.png' },{ name: 'temp', url: '/img/temp.png' },{ name: 'fan', url: '/img/fan.png' }
];async function initDashboard() {console.log('開始初始化儀表盤...');const startTime = Date.now();try {// 限制并發(fā)為 2，模擬嵌入式設備帶寬限制const loadedImages = await loadImagesWithLimit(iconList, 2, (current, total) = {console.log(`進度: ${current}/${total}`);// 這里可以更新 UI 進度條document.getElementById('progress').value = (current / total) * 100;});const duration = Date.now() - startTime;console.log(`加載完成，耗時: ${duration}ms`);// 渲染邏輯loadedImages.forEach((img, name) = {const el = document.getElementById(`icon-${name}`);if (el) {el.src = img.src;// 可以利用 img.width/height 設置 aspect-ratioel.style.width = '50px';el.style.height = '50px';}});} catch (error) {console.error('初始化失敗:', error);// 顯示錯誤 UI}
}// 執(zhí)行
initDashboard();這段代碼的亮點：active Set：用集合追蹤當前正在運行的任務 ID，比簡單的計數(shù)器更可靠，防止閉包陷阱。
finally 中的遞歸：確保無論成功還是失敗，都會觸發(fā)下一個任務的調度，避免“死鎖”（即某個任務卡住，后續(xù)任務永遠不執(zhí)行）。
錯誤隔離：單個圖片加載失敗不會導致整個 Promise 鏈崩潰。這在嵌入式系統(tǒng)中非常重要，一個圖標加載失敗不應該導致整個 HMI 界面白屏。常見報錯與避坑指南
在手寫實現(xiàn)的過程中，我踩過無數(shù)坑。以下是三個最高頻的問題，直接給你解決方案。
1. 內存泄漏：Image 對象未釋放
現(xiàn)象：長時間運行后，瀏覽器內存持續(xù)增長，最終崩潰。
原因：img 對象被閉包引用，且 onload 和 onerror 事件監(jiān)聽器未被移除。雖然瀏覽器有 GC（垃圾回收），但在嵌入式資源受限環(huán)境下，主動清理是必須的。
修正方案：
在 loadImage 函數(shù)中，增加一個 destroy 方法或在 finally 中清理。
// 在 loadImage 的 Promise 執(zhí)行器中
img.onload = () = {clearTimeout(timer);resolve(img);// 可選：如果不需要保留 DOM 引用，可以移除監(jiān)聽器img.onload = null;img.onerror = null;
};注意：在 Web 標準中，Image 對象是輕量的，通常不需要手動 removeEventListener，除非你將其附加到 DOM 并綁定了大量其他事件。但在 Node.js 環(huán)境中，務必關閉連接。
2. 跨域污染：CORS 錯誤
現(xiàn)象：控制臺報錯 Cross-Origin Image request blocked by CORS policy。
原因：圖片服務器沒有返回 Access-Control-Allow-Origin 頭。
解決方案：前端：設置 img.crossOrigin = 'anonymous'。這會強制瀏覽器進行 CORS 檢查。如果服務器不支持，圖片將加載失?。ū褥o默失敗好，因為你能發(fā)現(xiàn)配置問題）。
后端：在 Nginx 或 Node.js 服務器中，務必添加響應頭：
res.setHeader('Access-Control-Allow-Origin', '*');3. 超時后的競態(tài)條件
現(xiàn)象：圖片明明加載成功了，但 Promise 卻 reject 了。
原因：超時定時器觸發(fā) reject 后，圖片的 onload 事件在微任務隊列中稍后執(zhí)行。
修正方案：
這就是我前面代碼中 isTimeout 標志位的作用。確保在 onload 中檢查該標志，如果已超時，直接 return，不再 resolve。
小結
通過這篇教程，我們不僅搞定了“等待圖片”這個看似簡單的問題，更重要的是掌握了手寫實現(xiàn)異步資源加載的核心邏輯。從回調到 Promise：理解了如何將瀏覽器原生事件封裝為現(xiàn)代異步編程接口。
超時與并發(fā)：學會了如何處理網絡不確定性，以及如何優(yōu)化資源有限的嵌入式環(huán)境下的加載性能。
RFC 與底層原理：雖然代碼層面是 JS，但背后是對 HTTP 協(xié)議和瀏覽器渲染引擎行為的深刻理解。在嵌入式開發(fā)中，界面響應速度直接影響用戶體驗。不要依賴框架的黑盒加載器，手寫實現(xiàn)底層邏輯，能讓你在面試中侃侃而談，更能在實際項目中解決那些“玄學”般的加載 Bug。
你更常用哪種寫法？是直接用 new Image() 還是借助 fetch 轉 Blob？或者你有更獨特的并發(fā)控制策略？評論區(qū)交流，我們一起避坑。