瀏覽器載入流程解析
在優化之前,我們先了解瀏覽器從解析 HTML 到頁面完全互動的載入流程。整個過程可分為多個階段,每個階段都可能影響頁面速度：
HTML 解析與 DOM 建構
瀏覽器從上而下解析 HTML 檔,將標籤轉換為節點對象,組成 DOM 樹。若在解析過程中遇到外部資源,瀏覽器會一邊構建 DOM,一邊啟動下載。值得注意的是,若遇到沒有設定特殊屬性的普通 <script>,瀏覽器會暫停 HTML 解析,先下載並執行該腳本,執行期間會阻塞後續 DOM 的構建。這意味著一個體積龐大或載入緩慢的腳本檔,可能導致頁面長時間空白。為此,許多開發者會將傳統 <script> 標籤放在頁尾,避免阻塞前面的內容。
CSS 解析與渲染樹構建
HTML 中引用的 CSS（不論是 <style> 內嵌或 <link> 外部載入）則會被瀏覽器解析為 CSSOM 樹,與 DOM 樹合併產生渲染樹 (Render Tree)。CSS 檔案的載入雖不會阻塞 HTML 的解析,但會阻塞渲染輸出——瀏覽器通常會等待主要樣式載入完成,才進行後續的佈局和繪製,確保用戶不會看到「未套樣式」的內容閃爍 (FOUC)。因此,關鍵 CSS 應優先載入,而不要延遲或放在頁尾。
佈局和繪製
當 DOM 和 CSSOM 構建完畢,瀏覽器便據此計算每個節點的佈局（位置與大小）,接著將各節點像素繪製到螢幕上。首次內容繪製 (FCP) 就發生在這個階段——通常是第一個文字段落或圖像被繪出之時。接下來,瀏覽器可能還會持續載入後續資源,但至少使用者已經看見部分內容。
JavaScript 執行與互動準備
在 DOM 就緒後（HTML 完全解析完成）,瀏覽器會觸發 DOMContentLoaded 事件,這通常是 <script defer> 腳本開始執行的時機。此時使用者已可看到頁面,但仍可能無法完全互動,因為某些腳本可能正在執行初始化任務。如果有標記為 <script async> 的腳本,它們下載完成後就已即刻執行（不保證順序）,而標準的非 async/defer 腳本則可能更早已經執行過。最終,當所有資源都載入且初始腳本執行完畢、主執行緒空閒下來,頁面便達到了完全互動狀態。我們稱從開始載入到頁面可以快速響應使用者輸入的時間為 可互動時間（TTI, Time to Interactive）。隨後,當包括圖片在內的所有資源都下載完,會觸發 load 事件——但值得注意,load 事件的完成並不代表最佳的用戶體驗,我們更關心內容何時可見及可用,而非完全下載結束。
以上流程中的每一步,都可能因資源引入的順序與方式不同而影響速度。例如,把大型腳本檔放在 <head> 會阻塞 DOM 構建,將關鍵 CSS 延後載入會推遲首屏渲染。理解這些關係,才能有效優化。
資源載入順序對 FCP、LCP、TTI 的影響
現代網頁性能衡量常用三個重要指標：首次內容繪製 (FCP)、最大內容繪製 (LCP) 和 可互動時間 (TTI)。資源載入的順序與策略對這些指標有直接影響：
首次內容繪製（FCP）
FCP 指使用者第一次看到任何內容出現在螢幕上的時間,通常是文字、圖片或背景等元素。若關鍵內容的 HTML 和 CSS 準備就緒且未被阻塞,FCP 就會更早出現。相反地,以下情況會延後 FCP：
阻塞的腳本： 在 <head> 中載入了未使用 async/defer 的大型 JavaScript,瀏覽器必須先下載並執行它,才繼續解析後續 HTML,導致內容繪製被推遲。解決辦法是延後或異步載入這些腳本（稍後詳述）。
關鍵 CSS 載入延遲： 若主要的 CSS 檔案載入得太慢,瀏覽器會推遲呈現內容以避免沒有樣式的閃爍。這使得即使 HTML 已解析,第一段內容也無法繪製。確保關鍵 CSS 檔案優先且快速載入（例如內嵌關鍵樣式或預先載入CSS）有助於更早的 FCP。
網頁字體阻塞： 如果首屏內容使用了網頁字體 (Web Font),某些瀏覽器預設會等待字體檔案下載一段時間才渲染文字,避免「無字體」或替換字型的跳動。這也可能延後文字的首次繪製。為此,可以使用 font-display CSS屬性設定為 swap,讓瀏覽器先用後備字型渲染,稍後再替換為自定義字體,確保 FCP 不被字體下載拖累。
簡而言之,想要提升 FCP,就要讓最關鍵的內容盡快可繪製：避免在首屏內容出現前有任何不必要的阻塞任務,確保必要的資源（HTML、主要CSS、必要的圖像/字體）優先載入。
最大內容繪製（LCP）
LCP 衡量頁面主要內容載入完成的時間點,通常對應於用戶視窗中最大且最重要的元素被呈現之時（例如英雄圖像、主標題文字區塊）。優化 LCP 要確保最大元素及其資源被快速發現與載入：
大型圖片或媒體的載入順序： 例如頁面上最大的圖像（常為banner或Hero圖）如果延遲載入,LCP必然延後。若該圖像透過 CSS 背景或經 JavaScript 動態載入,瀏覽器可能在較晚階段才知道它需要下載。對策： 可在 HTML <head> 中使用 <link rel="preload" as="image"> 提示瀏覽器提早下載這張圖,或乾脆將重要圖片直接以 <img> 放在 HTML 中靠前位置。預先載入能提升這些關鍵資源的優先級,避免它們被淹沒在次要資源之後才開始下載。
大型文字區塊與字體： 若LCP元素是一個大段落或標題文字,但使用了尚未下載的Web字體,也會影響LCP（文字內容可能不顯示或顯示替代字體）。如前述,使用 font-display: swap 及預載字體 (<link rel="preload" as="font">) 可以加速主要文字的呈現。
CSS與JavaScript的間接影響： 最大內容元素可能依賴於 CSS 樣式（例如一個大區塊需要CSS定位）或由 JavaScript 插入。如果關鍵CSS沒載完或重要腳本尚未執行,LCP元素可能還沒渲染出來。確保關鍵CSS不要被延後,以及避免用腳本延遲輸出主要內容（若不得已,至少在腳本中盡早插入主要內容）。
Google 建議LCP應在2.5秒內完成（對於75%的用戶訪問）。雖然這只是指標,但我們的優化目標就是盡量讓主要內容的相關資源最先載入並快速渲染。
可互動時間（TTI）
TTI（互動延遲）是指頁面對用戶輸入（點擊、滾動等）做出有效響應所需的時間。具體來說,從頁面開始載入到瀏覽器主執行緒閒置並可迅速處理輸入的時刻。哪怕畫面看起來載入完成,如果此時有繁重的JavaScript任務在執行,使用者的點擊可能仍然沒有反應。載入順序對TTI的影響主要體現在腳本的下載與執行上：
腳本執行阻塞主執行緒： 大量同步的 JavaScript 會佔據主執行緒,導致瀏覽器無暇響應使用者操作。特別是當所有內容看似已顯示,但一個大腳本檔還在執行初始化（例如解析大JSON、渲染大量DOM）,TTI 就會被延後。解決辦法： 將繁重的腳本延後執行（例如使用 defer 屬性或在頁面載入後再動態載入）、拆分長任務（將一大段計算拆成多個小任務,讓主執行緒有機會空閒）或使用 Web Worker 將部分計算移出主執行緒。
過多的資源競爭： 如果載入順序不佳,例如非關鍵的第三方腳本過早載入並佔用了網絡帶寬與CPU時間,那麼關鍵腳本不得不延後,TTI 也跟著變慢。優化上,可以推遲非必要資源（如追蹤腳本、次要功能模組）到主要互動就緒之後再載。
懶載入對 TTI 的正面影響： 採用懶載入策略（Lazy Loading）對非關鍵內容（如非首屏圖像、次要資料）可以降低初始頁面負載,讓主執行緒更早空閒。這有助於更快達到互動就緒。然而,若懶載入實作不當（例如滾動時批量載入大量內容導致卡頓）,也可能影響後續的互動流暢度,所以需要權衡實施。
綜上,良好的資源引入順序可以使關鍵內容優先出現（優化 FCP/LCP）,並避免長時間鎖死主執行緒（優化 TTI）。接下來,我們將介紹如何運用 HTML 提供的屬性與技巧,實現這種順序上的掌控。
善用資源屬性最佳化載入順序
HTML5+ 提供了多種宣告式屬性,讓開發者可以調整瀏覽器的載入策略。善加利用這些屬性,我們能顯著提升頁面載入體驗。以下是幾種主要資源類型及其對應的優化屬性：
<script>：async 與 defer
腳本往往是大部分頁面最耗時的資源之一,但我們可以透過兩個神奇的屬性控制它們的下載與執行時機：
defer 屬性： 將 <script> 標籤設置 defer,腳本檔會在背景同時下載,但延後執行。瀏覽器會繼續解析後續 HTML,直到 DOM 完全構建完畢再按順序執行所有 defer 腳本。在執行完 defer 腳本後,瀏覽器觸發 DOMContentLoaded。換句話說,defer 保證了腳本執行順序與 HTML 中的順序一致,同時不阻塞頁面解析,非常適合需要等待 DOM 就緒才能運作的腳本（例如依賴 DOM 元素或需要按順序執行的自訂程式碼）。
async 屬性： 加上 async 屬性的腳本同樣會異步下載,下載完成後立即執行。與 defer 不同,async 腳本的執行不會等 DOM 完成解析,哪怕此時 HTML 還沒解析完,它也會立刻執行該腳本,因而可能暫時阻塞 DOM 構建。所以 async 腳本適合彼此獨立且不操作 DOM 的腳本（例如第三方分析、廣告）,因為它們執行時不保證與其他腳本的順序。此外,同一頁多個 async 腳本執行順序不可預期（誰先下載完就先執行）。因此切記：不要在 async 腳本中撰寫依賴其他腳本或 DOM 的程式。
簡而言之：需要依賴 DOM 或其他腳本的,用 defer；純獨立執行、無先後依賴的,用 async。兩者都能避免傳統同步腳本阻塞頁面解析,比把 <script> 放底部更進一步,因為它們在文件下載與解析同時進行,且 defer 還能確保執行順序。
<link>：preload 與 prefetch
對於樣式表、圖片、字體等非腳本資源,我們可以使用 <link> 來提示瀏覽器提早載入或預取：
preload 預先載入： 利用 <link rel="preload">,我們可以命令瀏覽器在背景高優先級下載指定資源。preload 最常用來提前載入當前頁面稍後需要的關鍵資源。例如：主要的 CSS、Hero 圖片、大型背景圖或 Web 字體。我們需要搭配屬性 as 說明資源類型（如 as="style"、as="script"、as="image"、as="font" 等）,讓瀏覽器優化下載策略。重要的是,preload只下載不執行（對於CSS、字體等「執行」是指應用/渲染；對JS則不會自動執行）,下載完成後仍需正常使用對應標籤引用該資源。例如預載 CSS 後,還是需要一個 <link rel="stylesheet"> 或動態設置 rel 才能應用樣式。Preload 的作用是在瀏覽器空閒或在解析階段提前把資源拉到本地,等真正需要時可直接取用,減少等待時間。
prefetch 預取資源： <link rel="prefetch"> 則表示瀏覽器空閒時可以下載的資源,優先級非常低。通常用於預先抓取下一步可能用到的資源,而非當前頁必須的內容。例如使用者當前在第1頁,我們可以 prefetch 第2頁的一些圖片或數據,等使用者點擊進第2頁時瞬間就緒。Prefetch 對於提升未來的體驗很有用,但對當前頁的指標（FCP/LCP）幾乎沒直接幫助,因為瀏覽器會把它排在閒時才載入,避免干擾當前內容的呈現。使用時也要注意不要預取過多不必要的資源,以免浪費流量。
簡單區分：preload 提前載入「當前頁需要」的東西（高優先權、幫助當下性能）,prefetch 提前載入「可能之後需要」的東西（低優先權、為未來導航做準備）。
圖片與影像：loading="lazy" 延遲載入
圖片通常佔據大量的流量與載入時間,但並非所有圖像都需要在頁面初始就馬上載入完畢。延遲載入 (Lazy Loading) 圖片是提升初始載入速度的有效手段。過去我們可能用 JavaScript 或框架實現懶載入,而現代瀏覽器已提供原生屬性：
loading="lazy"： 對於 <img>（或 <iframe>）元素,加上 loading="lazy",瀏覽器會自動延後載入該圖,直到用戶即將滾動到它附近時才進行加載。這意味著首屏外的圖片可以先不下載,減輕初始載入負擔。使用方式非常簡單：<img src="photo.webp" alt="描述文字" loading="lazy">。這樣非視窗內的圖像就不會立即抓取資源。需要注意的是：首屏範圍內的重要圖片不要使用 lazy,因為瀏覽器會等待用戶滾動再載入它們,導致可視區域內反而出現延遲。一般建議只對折疊以下的圖像（使用者一開始看不到的部分）使用 lazy。
響應式與佔位： 為避免懶載入圖片出現加載時的版面跳動,開發者應為圖像設定寬高（或使用 CSS 固定高度）作為佔位。此外,可搭配 <source srcset> 等屬性提供響應式圖像,確保在不同裝置下只下載所需大小的圖,也是一種性能優化。這些都能進一步縮短實際載入時間。
原生 lazy loading 支援目前已相當廣泛,能涵蓋大多數使用者環境。如需兼容不支援的舊瀏覽器,可以保留後備方案（例如 Intersection Observer 實現懶載入）。整體而言,善用 loading="lazy" 可以大幅減少初始必須下載的資源數量,改善首屏載入體驗,並將帶寬讓給更重要的內容。
字體資源最佳化
網頁字體讓版面更美觀,但處理不慎也會拖慢載入。這裡提供兩個建議：
字體預載： 使用 <link rel="preload" as="font" href="myfont.woff2" type="font/woff2" crossorigin> 提前下載關鍵字體。別忘了加上 crossorigin（若字體在不同網域）和對應的 type。預載字體確保瀏覽器在第一時間就取得字型檔案,避免文字必須等待字體下載才顯示。
font-display 策略： 在 CSS 中定義 @font-face 時,加上 font-display: swap 或 fallback。這樣瀏覽器在字體尚未下載完時,會先用系統替代字體渲染文字（立即顯示內容）,下載完成後再替換成自定義字體。如此一來,即使字體較晚到,內容也不至於不可見,提升感知性能。
透過以上方式,可以把字體對首屏的影響降到最低：該顯示的內容立即顯示,字體細節稍後優化,而非傻等著字體下載。
實際範例：運用現代 HTML 特性優化載入順序
理論講解之後,我們來看看實際代碼如何應用這些最佳化策略。以下示範一個簡化的 HTML 頁面,先是傳統寫法,再展示優化後的寫法,你可以直接複製這些範例代碼進行實驗。
範例 1：傳統寫法（未優化）
假設我們有以下簡單網頁結構：
<!DOCTYPE html> <html lang="zh-TW"> <head> <meta charset="UTF-8"> <title>示例頁面</title> <!-- 載入外部樣式和腳本 --> <link rel="stylesheet" href="styles.css"> <script src="app.js"></script> </head> <body> <!-- 首屏內容 --> <h1>歡迎光臨</h1> <img src="hero-banner.webp" alt="大型橫幅圖像"> <!-- 首屏下方的圖片縮略圖列表 --> <img src="thumb1.webp" alt="縮略圖1"> <img src="thumb2.webp" alt="縮略圖2"> <img src="thumb3.webp" alt="縮略圖3"> </body> </html>
問題分析： 上述寫法中,styles.css 和 app.js 會在 <head> 同步載入。app.js 的載入與執行會阻塞 HTML 解析,可能延遲顯示 <h1> 標題和首圖。同時,hero-banner.webp 與縮略圖們會在解析到各自的 <img> 時才開始下載；縮略圖雖在初始畫面看不到,卻仍然佔用了網絡資源。另外,如果 app.js 中還有額外請求（例如抓資料或載入更多圖片）,都可能進一步拖慢首次渲染。
範例 2：最佳化後的寫法
接下來,我們運用前述策略改寫上述頁面：
<!DOCTYPE html> <html lang="zh-TW"> <head> <meta charset="UTF-8"> <title>示例頁面</title> <!-- 預載關鍵資源 --> <link rel="preload" as="style" href="styles.css"> <link rel="preload" as="image" href="hero-banner.webp"> <!-- 載入樣式表（可選擇內嵌關鍵 CSS） --> <link rel="stylesheet" href="styles.css"> <!-- 延遲執行腳本 --> <script src="app.js" defer></script> </head> <body> <h1>歡迎光臨</h1> <!-- 首屏主要圖像,正常載入,已預載確保優先取得 --> <img src="hero-banner.webp" alt="大型橫幅圖像"> <!-- 首屏下方的縮略圖,使用 lazy 避免初始載入 --> <img src="thumb1.webp" loading="lazy" alt="縮略圖1"> <img src="thumb2.webp" loading="lazy" alt="縮略圖2"> <img src="thumb3.webp" loading="lazy" alt="縮略圖3"> </body> </html>
優化重點：
<link rel="preload">： 我們在 <head> 中預先聲明了需要高優先下載的資源：CSS 檔案和首屏大圖。這使瀏覽器在遇到它們的正式標籤前就開始下載,縮短等待時間。特別是大圖 hero-banner.webp,透過 preload,我們保證它會盡早取得資料,提高其在載入隊列中的順位。
<link rel="stylesheet">： 樣式表的載入方式保持不變（也可以考慮將關鍵部分的 CSS 直接寫在 <head> 內,以減少一次請求）。預載只是輔助其提前下載,並不代替正式引用。
<script defer>： JavaScript 檔改為使用 defer。瀏覽器會與解析 HTML 並行下載 app.js,但不阻塞 DOM 構建,且等 DOM 完成後才執行它。如此一來,<h1> 標題和圖像標籤可以更早解析和呈現,不用等待腳本執行完。app.js 若有多個,也會按順序執行且都在 DOMContentLoaded 前完成,確保程式正常初始化。
loading="lazy"： 縮略圖圖像使用 lazy loading。這些 <img> 在頁面載入時不會立即抓取資源,瀏覽器會先渲染頁面,其它資源忙完後,等用戶開始滾動接近它們時再行載入。這減輕了首屏階段的流量壓力,把帶寬讓給更重要的 CSS、主圖等。同時,由於我們只對非首屏圖使用 lazy,確保不會影響用戶進入頁面立即可見的內容。
透過這樣的改造,頁面首屏內容可以更快出現,且互動更即時：樣式和首圖已預載、主腳本不再卡住解析、非必要圖片延後載。整體用戶體驗將明顯提升。
利用瀏覽器開發者工具分析載入順序與瓶頸
要持續優化,我們必須懂得診斷頁面載入的瓶頸在哪裡。Chrome 等瀏覽器內建了強大的開發者工具,可視化地呈現載入時序和性能問題：
Network 面板： 打開開發者工具的 Network (網路) 面板,重新載入頁面。我們會看到所有資源請求的列表、大小和用時,以及瀏覽器何時開始下載它們。藉由 Network 瀏覽瀑布圖 (waterfall),可以直觀瞭解資源的載入順序和並行情況。如果某條資源線呈現出長條且阻塞後續資源,表示它可能是瓶頸。例如：一個巨大的 JS 檔案下載期間,其他項目都在等待；或者 CSS 檔案很晚才開始載入,導致首屏內容延遲。你可以點擊資源查看「Timing」細節,了解 DNS 解析、連線、等待、下載各階段耗時。透過 Network 面板,我們應確認關鍵資源 (HTML、首屏CSS、主要圖片、主JS) 是否在第一時間就發出請求,並快速響應。如果發現例如主要圖片直到最後才載,或某個第三方腳本一開始就阻塞了其他請求,那就是優化契機：調整順序或使用 preload/async 等手段改善。
Performance 面板： Network 著重網絡層面,Performance (效能) 面板則讓你錄製並檢視頁面的完整時序和主執行緒活動。在 Performance中點擊錄製並重新載入頁面,停止後你會得到一個時間軸：其中標註了 FCP、LCP 等關鍵指標發生的時間點,以及 CPU 的使用情況。你可以觀察哪段時間CPU被長任務佔滿（以粗長的橙色/黃色塊表示JS執行）,以及這些長任務是否出現在頁面載入早期並影響互動。還能展開「Main」執行緒查看各腳本函式調用和執行序列。如果 LCP 時間點遠遠落在後面,可以查看此刻之前主線程在做什麼——也許在解析大量 CSS/JS 或等待某些資源。Performance 面板還顯示幀率、頁面渲染過程,甚至 Memory、Layout 等資訊。雖然數據豐富,但對於載入順序優化,我們重點關注：(1) FCP/LCP 發生時間及相對順序；(2) 有無長時間的灰色空檔（表示空等待）或長橫條的腳本執行；(3) 繪製是否多次重複（可能是不必要的重排重繪）。找出問題後,就可對症下藥,例如某腳本耗時長——考慮拆解或延後；LCP 發生很晚——考慮預載相關資源等等。
其他工具： 開發者工具還有 Coverage 面板可檢視未使用的CSS/JS,能幫助我們發現是否載入了多餘的資源拖慢速度。也有 LightHouse（在 Audits 面板或 Chrome "性能分析"功能中）可以自動評測頁面,給出 FCP、LCP、TTI 分數和建議。如果懷疑某資源順序的問題,使用 Performance / Network 已足夠；若想要全面分析,Lighthouse 則可一鍵產生優化建議報告。
通過這些工具,我們可以像醫生診斷病人一樣檢查網頁,加深對載入機制的理解,並驗證我們採取的優化是否有效（例如加了 defer 後,可以看到 waterfall 中 JS 檔的加载沒有阻塞 HTML、或 FCP 時間的確提前）。
效能驗收:部署前的性能檢查
在完成優化並開發接近尾聲時,別忘了在正式部署前進行性能驗收,確保你的頁面在各種環境下都表現良好。以下是幾項建議的檢查步驟：
使用不同網路和裝置測試： 即使在本機跑得飛快,也要模擬一般使用者情境。例如在 Chrome 開發者工具中設置網絡節流（如 3G、慢 4G）和 CPU 降速,重新載入觀察 FCP/LCP 等時間。特別關注在較差環境下,頁面是否依然能迅速顯示基本內容並可互動。這有助於發現一些平時在高速網絡下被掩蓋的問題（比如一個小延遲在慢網下變成明顯的等待）。
核心指標達標： 檢視 Core Web Vitals 等關鍵數據。在無特別工具下,你可以透過開發者工具 Performance 得到 LCP 及 TTI 粗略值。或者使用瀏覽器內建的 Lighthouse 實作一次「性能審計」。Lighthouse 會模擬移動環境,給出如 FCP、LCP 的具體時間及評分。確保這些數值在「良好」範圍,例如 LCP < 2.5s。若有某項得分不理想（比如 TTI 偏慢）,仔細查看 Lighthouse 提供的建議,往往能對症下藥（可能是某腳本太大需要拆分,或圖片未壓縮等,但這超出我們本文範圍）。
檢查資源清單與順序： 再次審視最終部署版本的資源引入。在生產環境中,有些資源可能經過打包、壓縮、CDN 等處理。確保打包沒有引入未用到的巨大庫,CDN 提供的資源沒有意外延遲。此外,可在實際上線的網址上,用 Chrome 開發者工具或線上工具（如 PageSpeed Insights）驗證各資源載入順序與耗時。即便在本地一切正常,上線後的網域、證書、資源路徑變化都可能影響性能,務必再檢查一次。
用戶體驗點擊測試： 最後,用真實的操作體驗感受一下——在頁面可視內容出現後立即嘗試點擊按鈕、導航連結等。觀察是否立刻有反應或過程順暢。如果你在內容顯示後點擊某功能,卻發現瀏覽器還沒理會（例如按鈕點了沒反應幾秒才動作）,那表示 TTI 還沒達成,仍有腳本在忙碌或阻塞。這種情況下需要回頭調整腳本載入順序或優化邏輯。理想情況是內容一出現就可操作,互動無卡頓。
經過以上步驟的檢驗與調整,相信你的頁面在部署時已經達到最佳狀態。性能優化並非一次性工作,在開發過程中養成關注載入順序與資源體積的習慣,將大大減少日後改進的負擔。同時,一旦上線後透過分析工具發現新的瓶頸,也記得及時迭代優化——用戶體驗至上,速度永遠不嫌快！
常見疑問解答 Q&A
總結
以上指南希望讓你對頁面載入的內幕與資源順序最佳化有全面的理解。在實戰中靈活運用這些技巧,你的網站將更快地把內容送到使用者眼前,帶來更流暢的互動體驗。祝你在前端性能優化的道路上乘風破浪,打造既炫麗又飛快的網頁作品！
