Photo Gallery 啟用與批次上傳：概念、原理、實作與排錯 FAQ

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

Q1: 什麼是 Photo Gallery？

• A簡: 照片集中管理與呈現的系統，支援瀏覽、分類、上傳與搜尋，便於分享保存與組織大量相片內容。
• A詳: Photo Gallery 是用於集中管理與呈現影像資源的系統，核心是讓使用者能方便地瀏覽、分類、標籤、搜尋與分享照片。典型功能包含相簿結構、縮圖與原圖切換、上傳與批次匯入、權限控制與描述註記。應用場景涵蓋個人部落格、公司活動記錄、產品型錄到教學影像庫。本文情境中，原本的 Gallery 已可用，但面對大量相片，逐張上傳效率低，因而驅動「批次上傳」工具的需求與啟用。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q3, B-Q1, C-Q1

Q2: 為什麼需要啟用 Photo Gallery？

• A簡: 便於集中展示與管理照片，提升分享效率，並作為後續批次上傳與擴充功能的基礎平台。
• A詳: 啟用 Photo Gallery 的目的在於提供一致、容易導航的影像入口，減少分散檔案的找尋成本，並提升分享與協作效率。當照片數量成長時，手動整理與傳遞相片會變得困難；有了 Gallery，可建立相簿、標籤與描述，增強檢索。更重要的是，它提供上傳與權限的統一界面，為後續批次上傳、縮圖產生、CDN 加速與備份策略建立穩固基礎。本文反映了從可用到好用的轉變動機。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q4, B-Q2, C-Q5

Q3: 什麼是批次上傳（Batch Upload）？

• A簡: 一次上傳多張照片的流程，節省逐張上傳時間，提升大量內容匯入的效率與體驗。
• A詳: 批次上傳是指使用者在單一操作中選取多個檔案並同時傳送到伺服器的能力。它可透過瀏覽器多選、拖放區、壓縮包或批次匯入工具實現。相較逐張上傳，批次上傳可大幅減少重複動作、縮短等待時間，並利於後端進行統一的縮圖、去重、EXIF 解析與資料入庫。對於已有大量照片的使用者，批次上傳往往決定了是否願意把相片放上 Gallery 的關鍵。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, B-Q2, C-Q1, D-Q1

Q4: 單張上傳與批次上傳的差異是什麼？

• A簡: 單張上傳操作簡單但效率低；批次上傳效率高但需處理併發、錯誤與進度等複雜性。
• A詳: 單張上傳的優點是流程清楚、錯誤範圍小、前後端實作較簡單，但對大量內容非常耗時。批次上傳則以一次多檔提高效率，適合已有相片庫或活動大量相片上傳場景。然而它帶來挑戰：檔案大小控制、伺服器併發負載、部分失敗重試、進度回報、去重與整批事務性處理。選擇需兼顧使用者體驗與系統穩定性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, B-Q2, B-Q5, D-Q2

Q5: 為什麼大量相片情境下需要批次上傳？

• A簡: 可顯著降低重複操作成本，縮短匯入時間，並利於後端統一處理與資料一致性。
• A詳: 當照片數量上百上千，逐張上傳意味著大量重複選取、等待與提交，極易讓使用者放棄。批次上傳能一次選取並提交，後端可進行統一流程：檔案驗證、縮圖、EXIF 擷取、命名與去重、寫入資料庫與雲端存儲。這不僅縮短終端等待，也降低錯誤機會，並讓整體處理標準化，提高資料品質與可追蹤性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, B-Q3, C-Q1, D-Q4

Q6: Gallery 的核心價值是什麼？

• A簡: 提供可擴充的照片生命週期管理，從上傳、處理、呈現到搜尋與分享的一致體驗。
• A詳: Gallery 的價值在於將照片的生命週期流程化與工具化。上傳階段有權限與驗證，處理階段有縮圖、格式轉換與中繼資料解析，呈現階段有快速載入、無限滾動與自適應縮放，搜尋階段有標籤、相簿、關鍵字與EXIF查詢。透過一致介面與 API，減少人工管理成本，提升內容可見度與再利用性，並可逐步接入 CDN、備份與稽核。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, A-Q7, B-Q8, C-Q10

Q7: 什麼是縮圖（Thumbnail）與原圖的關係？

• A簡: 縮圖為快速預覽的小尺寸版本，原圖保留完整品質，兩者共同優化體驗與品質。
• A詳: 縮圖是從原始高解析度影像產生的小尺寸檔，用於列表與相簿格狀顯示以加速載入與節省頻寬。原圖則保存完整像素與質量，供查看細節或下載。一般流程為上傳原圖後產生多個尺寸（如小、中、大），前端依容器大小載入適合尺寸，並在需要時載入原圖。此方式兼顧速度與畫質，是 Gallery 的常見最佳實踐。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q7, C-Q3, D-Q6

Q8: EXIF 中繼資料在相片管理中的作用是什麼？

• A簡: EXIF 提供拍攝時間、相機資訊與方向等資料，利於排序、搜尋與自動校正顯示。
• A詳: EXIF（Exchangeable Image File Format）儲存相機拍攝的中繼資料，如拍攝日期、曝光參數、鏡頭、GPS 與方向。Gallery 可利用 EXIF 進行時間序排序、地點相簿、相機統計，並根據 Orientation 自動旋轉顯示。此外，EXIF 有隱私風險（GPS），需提供移除或匿名化選項。解析 EXIF 通常在上傳或處理管線中完成。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, C-Q8, D-Q3, D-Q9

Q9: 相簿（Album）與標籤（Tag）的差異？

• A簡: 相簿是階層式分組，標籤是多對多標記；相簿強結構，標籤強彈性與搜尋友好。
• A詳: 相簿通常表現為樹狀或分頁式集合，適合活動、事件或主題的清楚分組。標籤則可跨相簿、跨主題交叉標記，提供多維度檢索與聚合。實務上兩者並用：相簿提供基本導航與故事線，標籤支援細粒度搜尋與自動集錦（如「夕陽」「旅遊」）。資料庫設計上，標籤是多對多關係，需中介表支持。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, C-Q6, D-Q7

Q10: 自架 Gallery 與第三方雲端相簿的差異？

• A簡: 自架可控可擴充但需維運；雲端服務快速穩定省事但可客製化程度受限。
• A詳: 自架方案（自行開發或開源）提供資料與功能的完全掌控，便於客製批次上傳流程、整合系統與私有部署，但需承擔維運、安全與容量規劃。雲端相簿（如常見照片服務）上手快、可用性高、成本可預期，惟 API 與客製彈性有限，資料可攜性也需注意。選擇取決於資料主權、擴展需求與團隊能力。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, B-Q8, C-Q7, D-Q8

Q11: 為什麼要設計「批次上傳工具」而非手動整理？

• A簡: 自動化能大幅減少人工成本與錯誤，確保大量內容一致、完整且可追蹤。
• A詳: 手動整理面臨高重複性、易出錯與不一致命名等問題。批次上傳工具可標準化流程：自動命名、去重、尺寸處理、EXIF 解析與權限標記，並提供進度回報與重試。對於一次性匯入既有大量相片，工具化可在短時間完成，並保留完整審計紀錄與回滾能力，提升長期維護效率與資料品質。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q3, B-Q10, C-Q1, D-Q4

Q12: Gallery 啟用前應考量哪些需求？

• A簡: 照片量級、上傳方式、權限與隱私、效能與擴充、備份與成本等關鍵面向。
• A詳: 規劃時需估算相片量與成長率，決定是否必備批次上傳與後處理能力；權限與隱私政策（如 EXIF GPS）需先定義；效能面要考慮縮圖策略、CDN、快取與分頁；儲存選型（本機、物件儲存）與備份容災同樣重要；最後評估總擁有成本（雲成本與維運人力）。這些將影響架構與技術選擇。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q12, C-Q7, D-Q7

Q13: 為何要提供「相片頁先看再說」的入口？

• A簡: 先提供可用入口驗證價值與動線，再逐步補齊細節與文檔以降低上線阻力。
• A詳: 在產品迭代中，先讓使用者可使用核心功能（瀏覽相片）可快速驗證價值與收集回饋，再完善文件與工具細節。此策略減少「完美主義」延遲上線風險，並讓批次上傳等強化功能逐步導入。對內有助監測真實負載與瓶頸，對外則建立信心，使後續開發優先順序更貼近實際需求。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q20, D-Q6

Q14: 為何需關注使用者體驗（UX）與上傳流程設計？

• A簡: 好的 UX 降低學習與操作成本，提升成功率，減少放棄，特別在大量上傳場景。
• A詳: 大量上傳牽涉選檔、拖放、進度回報、錯誤提示、重試與完成後導覽。若缺乏清楚狀態與回饋，使用者易中斷或重做。UX 設計需提供批次選擇、明確限制（大小、格式）、逐檔與整批進度、可中止與恢復上傳，以及完成後的快速整理（批量加標籤、加入相簿）。良好 UX 直接影響系統採用度與滿意度。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q13, C-Q2, D-Q2

Q15: Gallery 效能的核心指標有哪些？

• A簡: 首屏載入時間、縮圖生成延遲、列表切換時間、上傳成功率與平均處理時長。
• A詳: 量測面向包含：相簿頁首屏載入（含縮圖與首批資料）、列表滾動延遲、點擊大圖切換時間；後端則有上傳成功率、平均與 P95 處理時長、縮圖佇列深度、錯誤種類分布；資源面則監控儲存容量與 CDN 命中率。這些指標能定位瓶頸（網路、IO、CPU 或資料庫），指導調優與擴容策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q8, D-Q7, D-Q6

Q16: 為什麼要限制上傳檔案大小與格式？

• A簡: 控制資源消耗與安全風險，確保處理流程穩定，避免惡意或錯誤檔案。
• A詳: 大檔會拉長上傳與處理時間，增高超時與記憶體風險；不支援格式（如 RAW 變體）會導致轉檔或縮圖失敗。限制大小與白名單格式（JPEG/PNG/WEBP/HEIC 等）能提升穩定性並縮小攻擊面。配合前端即時檢查、後端 MIME 驗證與病毒掃描，構成安全與可靠的入站閘道。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q14, D-Q1, D-Q10, C-Q1

Q17: 為何要做重複檔（Deduplication）？

• A簡: 避免重複儲存浪費成本，維持索引品質，減少重複處理與使用者困惑。
• A詳: 大量照片容易因多次匯入出現重複檔。透過檔案雜湊（SHA-256/MD5）、感知哈希（pHash）或名稱+時間組合，可識別重複並合併記錄。這節省儲存與縮圖資源，避免相簿中重複項干擾瀏覽。實作上可在上傳前中計算 hash，或上傳後以背景任務清理，並保留關聯關係與使用者提示。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, C-Q3, D-Q4

Q18: 為什麼需要背景處理（Background Jobs）？

• A簡: 將耗時任務非同步化，避免阻塞請求，提升上傳流暢與系統整體吞吐。
• A詳: 縮圖生成、EXIF 解析、病毒掃描、雲端上傳與索引更新屬於耗時作業。若在請求流程中同步執行，易導致超時與使用者等待。透過任務佇列（如 Redis-based）將重活丟到背景，前端收到接受回應，並由通知或輪詢更新狀態。此設計改善體驗並利於水平擴展，隔離失敗影響範圍。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, C-Q3, D-Q6

Q19: 圖片隱私與授權需注意什麼？

• A簡: 設定可見範圍、移除敏感 EXIF、權限分級與審核流程，並告知使用者政策。
• A詳: 照片可能包含個資與地理位置。需支援公開、非公開、密碼或限定連結等可見性；移除或匿名化 GPS 等 EXIF；提供上傳者與管理者權限分級；有需要時加上審核與舉報管道。政策面應清楚告知用途與保存期間，技術面加強存取控制與日誌以符合法規與信任。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, B-Q15, D-Q8

Q20: 啟用 Gallery 的最小可行版本（MVP）包含什麼？

• A簡: 基本相簿與縮圖瀏覽、多檔上傳、格式與大小驗證、最小權限與錯誤提示。
• A詳: 一個可用的 MVP 應涵蓋：相簿列表與相片網格顯示、點擊查看大圖；多檔上傳與進度顯示；後端對格式、大小與數量的驗證；縮圖生成與快取；基本權限（登入/可見性）與清楚錯誤訊息。後續可再加背景任務、CDN、標籤、搜尋與分享。先上線可驗證負載與 UX，逐步擴充。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q6, C-Q1, D-Q2

Q&A 類別 B: 技術原理類

Q1: HTTP 檔案上傳的基本原理是什麼？

• A簡: 透過 multipart/form-data 傳送檔案，伺服器解析邊界與字段，存儲並進行後續處理。
• A詳: 瀏覽器以 multipart/form-data 將表單欄位與檔案分段發送，分界線（boundary）標識每段。伺服器端解析後取得檔名、MIME、內容流，並根據策略存放於暫存或永久儲存。流程包含：請求解析、驗證、存儲、回應。核心組件：客戶端表單/JS、HTTP 伺服器、解析器（如 multer/busboy）、儲存層（磁碟或物件儲存）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q3, C-Q1, D-Q1

Q2: 批次上傳在協定與流程上如何運作？

• A簡: 客戶端一次送多檔或多請求並發，伺服器並行處理，提供進度、錯誤與重試機制。
• A詳: 批次上傳可透過單一 multipart 請求含多檔，或多個併發請求（每請求單檔）達成。流程：前端選檔與驗證，建立請求與進度監測；後端解析與驗證數量、格式、大小；寫入暫存，排入背景任務；回傳批次 ID 與狀態。核心組件：上傳控制器、併發與限流、任務佇列、狀態儲存與查詢介面。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, B-Q5, C-Q2, D-Q2

Q3: 壓縮包（ZIP）匯入與多檔上傳的差異原理？

• A簡: ZIP 將多檔封裝單一檔，需解壓與驗證；多檔上傳則每檔獨立處理與回報。
• A詳: ZIP 匯入可減少連線次數與瀏覽器限制，但伺服器需解壓、驗證路徑穿越、計算清單與逐檔管線。多檔上傳以瀏覽器多選或拖放形成多分段或多請求，便於逐檔進度與重試。選擇取決於網路品質、檔案數與 UX 要求。核心組件：ZIP 解析器、沙箱路徑、資安檢查與背景解壓任務。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q3, C-Q4, D-Q4

Q4: 瀏覽器端拖放上傳的運作機制是什麼？

• A簡: 透過 Drag and Drop API 取得檔案列表，配合 XHR/Fetch 與 FormData 發送內容。
• A詳: HTML5 Drag and Drop 讓使用者拖入檔案或資料夾（webkitdirectory），前端從 DataTransferItems 讀取 File 物件，建立 FormData 並以 XHR/Fetch 傳送。可監聽 progress 事件顯示進度。核心組件：拖放區、檔案驗證、進度條與錯誤處理。可搭配壓縮或預覽以優化體驗。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q2, B-Q5, D-Q2

Q5: 上傳進度回報與可恢復上傳如何設計？

• A簡: 以分片與進度事件回報百分比，失敗時續傳缺片，後端維護會話與校驗。
• A詳: 分片上傳將檔案切片，前端逐片發送並監控進度；後端以檔案ID與片序追蹤，完成後合併並驗證哈希。進度可用 XHR progress、Streams API 或 WebSocket 推播。中斷時重傳缺片，避免重頭來。核心組件：分片管理、狀態儲存、合併器、哈希校驗與限流策略。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q2, C-Q5, D-Q2

Q6: 縮圖與多尺寸處理的技術要點？

• A簡: 以影像庫批量轉換生成多尺寸，結合快取與CDN，前端自適應載入最合適圖。
• A詳: 影像處理使用如 Sharp/Imagemagick 產生固定寬度多版本（e.g., 320/640/1280），並可壓縮與移除無用 metadata。產物存於快取層或物件儲存，透過 CDN 邊緣加速。前端用 srcset/sizes 選擇最合適尺寸。核心組件：處理管線、快取鍵策略、儲存路徑規約與回源控制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, C-Q3, D-Q6

Q7: 圖片格式（JPEG/PNG/WEBP/HEIC）取捨原理？

• A簡: 依內容特性與瀏覽器支援選擇，高壓縮高相容或高品質保真，各有適用情境。
• A詳: JPEG 適合相片類高壓縮，PNG 適用透明與圖形，WEBP/AVIF 提供更佳壓縮與畫質但相容性需評估，HEIC 在蘋果生態普遍但網頁支援有限。流程可轉存為 WEBP 供瀏覽，保留原檔備份。核心組件：轉碼器、相容性檢測與回退策略（Accept header/瀏覽器能力判斷）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, D-Q10, A-Q16

Q8: 圖片儲存架構如何設計（本機 vs 物件儲存）？

• A簡: 小規模可本機，成長後採物件儲存＋CDN，提升擴展、可靠與全球分發能力。
• A詳: 本機磁碟部署簡單、成本低，但擴容與多節點同步困難。物件儲存（S3/GCS）具高可用與彈性，結合 CDN 降延遲。設計時將原圖與派生圖分層存放，檔名或路徑含指紋避免覆蓋。核心組件：儲存 SDK、簽名網址、上傳策略（直傳/中轉）、CDN 配置與備份政策。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q7, D-Q8, A-Q12

Q9: 資料庫結構如何表達相片、相簿與標籤？

• A簡: 照片表、相簿表、標籤表與關聯表，含路徑、尺寸、EXIF、權限與排序欄位。
• A詳: 常見結構：photos(id, path, hash, width, height, exif_json, visibility, created_at)，albums(id, name, cover_id)，album_photos(album_id, photo_id, sort_order)，tags(id, name)，photo_tags(photo_id, tag_id)。可加 uploader_id 與軟刪除欄位。核心組件：唯一鍵與索引、外鍵關係、遷移工具與稽核欄位。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q6, D-Q4, A-Q9

Q10: 去重（Dedup）與哈希比對的運作機制？

• A簡: 以檔案內容哈希或感知哈希比對，發現重複即共用紀錄或忽略存儲。
• A詳: 上傳時計算內容哈希（SHA-256）作為唯一性鍵；如需容忍小改變，用 pHash/感知哈希比對相似度。若重複，回應已存在的 photo_id 並更新關聯。核心組件：哈希計算器、唯一索引、相似度閾值與衝突處理策略（合併或標註）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q17, C-Q3, D-Q4

Q11: 背景任務佇列如何支援影像管線？

• A簡: 任務佇列接收上傳事件，分發縮圖、EXIF、病毒掃描，監控重試與失敗。
• A詳: 前端上傳完成後，後端建立任務消息（含 photo_id、路徑、操作列表），佇列（如 Redis/RabbitMQ）分發至工作者。工作者執行縮圖、EXIF、掃毒與上傳雲端，結果回寫狀態並觸發通知。核心組件：隊列、worker、重試策略、死信隊列與監控儀表板。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q3, D-Q6

Q12: 併發控制與限流如何保障穩定？

• A簡: 設定每用戶與全局併發、頻率與隊列長度，避免資源耗盡與雪崩效應。
• A詳: 批次上傳易造成瞬時高併發。可採令牌桶/漏斗限流、每 IP/用戶並發限制、後端工作者數量上限、資料庫連線池與IO節流。過載時回應友善錯誤與重試指示。核心組件：反向代理限流、應用層中介、佇列深度監控與自動擴容。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q2, D-Q7, C-Q5

Q13: 上傳進度與狀態的前後端通訊機制？

• A簡: 使用 XHR progress、Polling 或 WebSocket，同步顯示整批與單檔進度與結果。
• A詳: 前端以 XHR/Fetch 搭配 onprogress 或 ReadableStream 計算百分比；整批狀態可輪詢批次ID API 或以 WebSocket/SSE 推播。後端需持久化狀態（如 Redis）並提供查詢端點。核心組件：進度事件、狀態模型、推播通道與重試策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, C-Q5, D-Q2

Q14: 上傳安全：MIME 驗證與病毒掃描機制？

• A簡: 雙重驗證副檔名與MIME，內容檢測與沙箱掃描，阻擋惡意檔與偽裝格式。
• A詳: 先檢查副檔名白名單，再以伺服器端讀頭或庫辨識真正 MIME；對可疑或大檔排入病毒掃描（ClamAV 等），隔離結果。避免 ZIP 炸彈與路徑穿越。核心組件：MIME 檢測、白名單策略、掃描服務、隔離區與告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, D-Q10, C-Q1

Q15: EXIF 擷取與方向校正的技術流程？

• A簡: 解析 EXIF 获取拍攝資訊與方向，按 Orientation 自動旋轉並保存處理後版本。
• A詳: 上傳後讀取 EXIF，抽取日期、GPS、相機與 Orientation。若 Orientation 指定旋轉或翻轉，於處理階段應用校正，再生成縮圖。可選擇移除敏感 EXIF 並將必要欄位轉存資料庫。核心組件：EXIF 解析器、影像轉換器與隱私過濾器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, C-Q8, D-Q3

Q16: 交易性與一致性如何在批次上傳中保障？

• A簡: 以批次ID與狀態機追蹤，失敗時可重試與補償，維持資料與檔案一致。
• A詳: 批次包含多照片，部分成功部分失敗常見。以批次ID建模狀態（pending、processing、partial、done、failed），對成功項即時落庫，失敗項記錄錯誤並支援重試或補償（刪除孤兒檔）。核心組件：狀態機、事務邊界、補償動作與審計日誌。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q4, C-Q5, B-Q11

Q17: /photos 路由與前端展示的架構關係？

• A簡: 路由提供相簿與列表 API，前端以網格與分頁載入縮圖，點擊載入大圖。
• A詳: 後端設計 /photos 與 /albums API 提供分頁資料與過濾參數；前端以 Masonry/網格呈現縮圖，使用懶載入與無限滾動；點擊後以輕盒或新頁載入大圖與資訊。核心組件：路由控制器、分頁索引、圖片服務與前端列表元件。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, B-Q6, C-Q10

Q18: 觀測性（Logging/Tracing/Metrics）如何落地？

• A簡: 記錄上傳與處理事件、追蹤請求鏈與任務耗時，用指標面板追蹤健康狀況。
• A詳: 上傳入口記錄使用者、檔名、大小、結果；處理管線記錄任務開始/完成/錯誤與耗時；分配 request-id 與 trace-id 串聯前後端；指標包含 QPS、錯誤率、佇列深度、處理延遲。核心組件：日誌管道、Tracing（如 OpenTelemetry）、Metrics（Prometheus）與告警。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q6, A-Q15, B-Q11

Q19: 快取與 CDN 在 Gallery 的角色？

• A簡: 快取降低重複生成與回源，CDN 將縮圖與靜態資源分發至邊緣加速載入。
• A詳: 縮圖結果可緩存在本地或物件儲存，加上 CDN 以 Cache-Control 與指紋檔名長期快取，減少後端負載。對列表 API 可實施短時快取與條件請求。核心組件：HTTP 快取頭、CDN 規則、回源與失效策略、指紋化資源命名。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q7, D-Q7

Q20: 漸進式上線與風險控制如何規劃？

• A簡: 以小範圍啟用與特性旗標控管，監測指標與回滾方案，逐步擴大流量。
• A詳: 新功能（如批次上傳）先對內部或少量使用者開啟，透過特性旗標控制人群；監控錯誤率、延遲與資源；準備回滾（關閉旗標/降級到單檔上傳）。逐步擴大並收集回饋以優化。核心組件：Feature Flag、灰度發布、監控與回滾流程。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, D-Q6, C-Q5

Q&A 類別 C: 實作應用類（10題）

Q1: 如何用 Node.js + Express + Multer 實作多檔上傳？

• A簡: 安裝 Multer 設定 array 接收，驗證格式與大小，儲存暫存後觸發背景處理。
• A詳: 步驟：1) npm i express multer。2) 建立上傳路由，使用 multer.array(‘photos’, 50)。3) 驗證 mimetype 與檔案大小。4) 寫入暫存目錄，回傳批次ID。5) 送入背景任務生成縮圖。程式碼片段: const upload = multer({ limits:{fileSize:1010241024}, fileFilter:(req,f,cb)=>/^image\//.test(f.mimetype)?cb(null,true):cb(null,false) }); app.post(‘/upload’, upload.array(‘photos’,50),(req,res)=>{ /* enqueue jobs */ res.json({batchId}) }); 注意：設定 Nginx client_max_body_size，避免超時，並記錄失敗項。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q2, D-Q1

Q2: 如何實作拖放上傳與進度條（前端）？

• A簡: 使用拖放區與 FormData，上傳時監聽 XHR progress，顯示單檔與整批進度。
• A詳: 步驟：1) 建立拖放區 div，監聽 dragover/drop。2) 從 DataTransfer.files 取檔案。3) 逐檔或批次建立 FormData。4) XHR.upload.onprogress 更新進度。5) 顯示成功/失敗清單。程式碼片段: drop.on(‘drop’, e=>{ const files=[…e.dataTransfer.files]; const fd=new FormData(); files.forEach(f=>fd.append(‘photos’,f)); const xhr=new XMLHttpRequest(); xhr.upload.onprogress=(e)=>{/* update */}; xhr.open(‘POST’,’/upload’); xhr.send(fd); }); 注意：前端先檢查大小與格式，提示限制與剩餘可上傳數。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q13, D-Q2

Q3: 如何在上傳後自動生成縮圖與多尺寸？

• A簡: 以背景 worker 使用 Sharp 讀取原圖，輸出多尺寸，寫入儲存並更新資料庫。
• A詳: 步驟：1) 接收上傳後將 photo_id 與路徑丟入佇列。2) worker 讀取原圖，利用 Sharp 產生 320/640/1280。3) 儲存至指紋化路徑，回寫 photos_sizes 表。程式碼片段: await sharp(src).resize(640).jpeg({quality:80}).toFile(dst640); 注意：維持色彩空間，移除無用 metadata，處理旋轉（根據 EXIF）。失敗重試，避免阻塞。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q11, D-Q6

Q4: 如何支援 ZIP 匯入並安全解壓？

• A簡: 上傳 ZIP 後在沙箱目錄解壓，過濾路徑與格式，逐檔排入影像處理。
• A詳: 步驟：1) 後端驗證 mimetype=application/zip。2) 使用 unzip 庫解壓到 sandbox。3) 檢查檔名避免 ../ 路徑穿越。4) 過濾非影像與超限檔。5) 逐檔進入與多檔相同處理流程。程式碼片段: 解壓時對每 entry 檢查 entry.path 不含 .. 並匹配白名單。 注意：限制 ZIP 大小與內含檔數，防 ZIP 炸彈，並記錄異常。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q3, D-Q4, B-Q14

Q5: 如何設計可恢復的分片上傳與進度查詢？

• A簡: 前端切片與哈希，後端記錄片序與狀態，完成後合併與校驗，提供查詢接口。
• A詳: 步驟：1) 前端以 slice 切片並計算整檔哈希。2) 逐片附檔ID與序號上傳。3) 後端存片並寫入狀態。4) 全部上齊後合併與雜湊驗證。5) 提供 GET /upload/:id 狀態。程式碼：合併時串流寫入避免 OOM。注意：片大小動態調整、重試次數、並發限制與清理過期片段。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q5, B-Q12, D-Q2

Q6: 如何為 Gallery 設計基本資料庫 Schema？

• A簡: 建立照片、相簿、標籤與關聯表，加入索引、唯一鍵與審計欄位以利查詢。
• A詳: 步驟：1) 建 photos(id, path, hash unique, width, height, created_at)。2) albums(id, name, cover_id)。3) album_photos(album_id, photo_id, sort_order index)。4) tags 與 photo_tags 關聯。SQL 片段: CREATE TABLE photos(…, hash VARCHAR(64) UNIQUE, …); 注意：時間索引、可見性欄位、軟刪除與外鍵完整性。為列表頁建立複合索引提升分頁效率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, D-Q4, A-Q9

Q7: 如何把圖片存到 S3 並使用簽名上傳與 CDN？

• A簡: 生成預簽名 URL 讓前端直傳 S3，後端記錄資源，CDN 綁定加速與快取。
• A詳: 步驟：1) 後端用 SDK 生成 putObject 預簽名 URL。2) 前端直接 PUT 上傳檔案。3) 上傳完成 Call back，寫資料庫與 enqueue 處理。4) 前綴路徑規劃與 CloudFront 綁定。程式碼片段：s3.getSignedUrlPromise(‘putObject’,{Bucket,Key,ContentType,Expires}).注意：CORS 設定、ACL 私有、透過簽名讀取或 CDN 公開路徑。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, B-Q19, D-Q8

Q8: 如何抽取 EXIF 並處理旋轉與隱私？

• A簡: 用 EXIF 解析庫讀取資訊，依 Orientation 旋轉，移除敏感 GPS 再保存。
• A詳: 步驟：1) 上傳後以 exiftool/exifr 解析。2) 取得 Orientation 套用旋轉。3) 建立 exif_json 存必要欄位。4) 清理 GPS/序號等敏感資訊。程式片段：exifr.parse(file).then(meta=>{/* rotate and strip */}).注意：HEIC/HEIF 支援，失敗時採用預設旋轉與欄位空值。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, D-Q3, A-Q19

Q9: 如何設定 Nginx 與伺服器避免上傳超時與大小限制？

• A簡: 在 Nginx 設 client_max_body_size 與 proxy_read_timeout，應用層亦設定超時。
• A詳: 步驟：1) nginx.conf http { client_max_body_size 20m; proxy_read_timeout 120s; }。2) 後端上調 body parser 限制與請求超時。3) 加入斷點續傳與重試策略。注意：謹慎提高限制，防濫用；加上驗證與限流。記錄上限與提示使用者最佳大小。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, B-Q12, B-Q5

Q10: 如何打造相片列表頁的高效網格與懶載入？

• A簡: 使用自適應網格與 IntersectionObserver 懶載入縮圖，提高首屏速度與流暢性。
• A詳: 步驟：1) CSS Grid/Masonry 佈局。2) 或 IntersectionObserver 懶載入。3) 使用 srcset 自適應尺寸。4) 分頁或無限滾動呼叫 /photos API。程式片段：observer.observe(img) 於進入視窗時設置 src。注意：預留佔位避免跳動，使用 CDN 與快取頭。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q19, A-Q15

Q&A 類別 D: 問題解決類（10題）

Q1: 遇到「413 Request Entity Too Large」怎麼辦？

• A簡: 提高反向代理與應用層大小限制，並引導使用者控制單檔與批次大小。
• A詳: 症狀：上傳立即失敗回 413。原因：Nginx/應用層 body 限制過低或未配置。解法：調整 Nginx client_max_body_size、上游 proxy_max_temp_file_size；應用層提高限制與明確錯誤訊息。預防：設定合理限制、前端預檢大小與分片上傳，文件說明最大值。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q9, B-Q1, A-Q16

Q2: 批次上傳中常見超時或進度卡住如何處理？

• A簡: 分片上傳、限流併發、背景處理與進度查詢，提供重試與恢復機制。
• A詳: 症狀：長時間無回應、部分檔失敗。原因：請求過長、伺服器過載、網路抖動。解法：改為分片上傳、降低同時數、後端背景處理與狀態 API；失敗片段自動重試。預防：合理超時、健康檢查、佇列深度告警與灰度發布。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q12, C-Q5

Q3: 上傳後照片方向顛倒怎麼辦？

• A簡: 解析 EXIF Orientation 並在處理階段自動旋轉，前端避免再次旋轉。
• A詳: 症狀：部分手機照片橫豎顛倒。原因：EXIF Orientation 未處理。解法：處理管線解析 EXIF 並旋轉輸出；若移除 EXIF，需先套用旋轉再清 EXIF。預防：測試多設備、記錄無 EXIF 時的預設策略，確保前端不重複旋轉。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q15, C-Q8, A-Q8

Q4: 批次上傳出現重複照片與資料不一致？

• A簡: 啟用內容哈希去重，批次狀態機與補償機制，清理孤兒檔與重建關聯。
• A詳: 症狀：相簿重複項、關聯錯亂。原因：多次重試、無去重、部分失敗。解法：上傳前後計算哈希建唯一索引；批次狀態機處理 partial 狀態；清理孤兒檔；重建 album_photos。預防：Idempotent 設計、重試去重與事務邊界清楚。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, B-Q16, C-Q6

Q5: 記憶體不足或 CPU 飆高導致處理失敗？

• A簡: 以串流處理避免載入整檔，限流並發，將重活分散到背景工作者。
• A詳: 症狀：OOM、CPU 100% 導致崩潰。原因：一次性讀入大檔、併發過高。解法：使用串流與臨時檔，限制同時處理數；影像處理調整品質與尺寸；切分工作至多個 worker。預防：資源監控、壓力測試與自動擴容。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, B-Q11, C-Q3

Q6: 縮圖缺失或列表載入很慢如何排查？

• A簡: 檢查處理佇列、縮圖路徑與快取頭，確保 CDN 命中與懶載入生效。
• A詳: 症狀：列表出現空白或慢載。原因：縮圖未生成、路徑錯誤、快取配置不當。解法：檢查佇列是否積壓、日誌錯誤；驗證檔案存在與權限；調整 Cache-Control 與 CDN 規則；前端啟用懶載入。預防：監控佇列深度、生成失敗告警與回補任務。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q19, C-Q10

Q7: Gallery 首屏慢與滾動卡頓的原因與改善？

• A簡: 大量同步請求與圖尺寸不當，改善以分頁、懶載與合適尺寸與快取。
• A詳: 症狀：進入相簿延遲、滾動卡。原因：載入太多原圖、缺少分頁與懶載、無快取。解法：分頁/無限滾動、縮圖與 srcset、自動壓縮、CDN；減少同步請求、優化 DOM。預防：性能指標監控與 Lighthouse 分析。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, B-Q19, C-Q10

Q8: 上傳出現 403/權限錯誤怎麼處理？

• A簡: 檢查認證與授權、簽名效期與 CORS，確保用戶與路徑權限正確。
• A詳: 症狀：403 禁止或簽名過期。原因：Token 無效、角色無權、S3 簽名逾期、CORS 阻擋。解法：刷新憑證、修正 IAM/ACL、延長簽名效期；設定正確 CORS。預防：明確權限模型、最小授權、簽名時間與時鐘同步。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q7, B-Q8, A-Q19

Q9: EXIF 解析失敗或導致崩潰怎麼辦？

• A簡: 對異常格式加防護，失敗回退預設，避免阻塞整批流程並記錄告警。
• A詳: 症狀：特定檔解析時崩潰。原因：損壞檔、非標準 EXIF、HEIC 支援不足。解法：try-catch 包裝、限制解析時間；失敗時跳過敏感欄位，保留基本處理；升級庫或轉換格式。預防：上傳前驗證，黑名單問題裝置，增加單元測試樣本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, B-Q15, C-Q8

Q10: 使用者上傳不支援格式或巨大原檔的處理？

• A簡: 前端即時檢查並提示，後端白名單與轉碼，提供壓縮與轉換協助。
• A詳: 症狀：上傳失敗或處理時間過長。原因：格式不支援（RAW/HEIC）或檔案過大。解法：前端限制檔案類型與大小；後端 MIME 驗證；提供上傳前壓縮或轉碼建議（如轉 JPEG/WEBP）；背景轉碼。預防：清楚告示限制與最佳尺寸建議。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q7, B-Q14, C-Q1

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 Photo Gallery？
  • A-Q2: 為什麼需要啟用 Photo Gallery？
  • A-Q3: 什麼是批次上傳（Batch Upload）？
  • A-Q4: 單張上傳與批次上傳的差異是什麼？
  • A-Q5: 為什麼大量相片情境下需要批次上傳？
  • A-Q7: 什麼是縮圖（Thumbnail）與原圖的關係？
  • A-Q9: 相簿（Album）與標籤（Tag）的差異？
  • A-Q13: 為何要提供「相片頁先看再說」的入口？
  • A-Q16: 為什麼要限制上傳檔案大小與格式？
  • A-Q20: 啟用 Gallery 的最小可行版本（MVP）包含什麼？
  • B-Q1: HTTP 檔案上傳的基本原理是什麼？
  • C-Q10: 如何打造相片列表頁的高效網格與懶載入？
  • D-Q1: 遇到「413 Request Entity Too Large」怎麼辦？
  • D-Q3: 上傳後照片方向顛倒怎麼辦？
  • D-Q10: 使用者上傳不支援格式或巨大原檔的處理？
• 中級者：建議學習哪 20 題
  • A-Q6: Gallery 的核心價值是什麼？
  • A-Q8: EXIF 中繼資料在相片管理中的作用是什麼？
  • A-Q12: Gallery 啟用前應考量哪些需求？
  • A-Q14: 為何需關注使用者體驗（UX）與上傳流程設計？
  • A-Q15: Gallery 效能的核心指標有哪些？
  • A-Q17: 為何要做重複檔（Deduplication）？
  • A-Q18: 為什麼需要背景處理（Background Jobs）？
  • A-Q19: 圖片隱私與授權需注意什麼？
  • B-Q2: 批次上傳在協定與流程上如何運作？
  • B-Q4: 瀏覽器端拖放上傳的運作機制是什麼？
  • B-Q6: 縮圖與多尺寸處理的技術要點？
  • B-Q7: 圖片格式（JPEG/PNG/WEBP/HEIC）取捨原理？
  • B-Q8: 圖片儲存架構如何設計（本機 vs 物件儲存）？
  • B-Q9: 資料庫結構如何表達相片、相簿與標籤？
  • B-Q11: 背景任務佇列如何支援影像管線？
  • B-Q13: 上傳進度與狀態的前後端通訊機制？
  • C-Q1: 如何用 Node.js + Express + Multer 實作多檔上傳？
  • C-Q2: 如何實作拖放上傳與進度條（前端）？
  • C-Q3: 如何在上傳後自動生成縮圖與多尺寸？
  • D-Q7: Gallery 首屏慢與滾動卡頓的原因與改善？
• 高級者：建議關注哪 15 題
  • B-Q3: 壓縮包（ZIP）匯入與多檔上傳的差異原理？
  • B-Q5: 上傳進度回報與可恢復上傳如何設計？
  • B-Q12: 併發控制與限流如何保障穩定？
  • B-Q15: EXIF 擷取與方向校正的技術流程？
  • B-Q16: 交易性與一致性如何在批次上傳中保障？
  • B-Q18: 觀測性（Logging/Tracing/Metrics）如何落地？
  • B-Q19: 快取與 CDN 在 Gallery 的角色？
  • B-Q20: 漸進式上線與風險控制如何規劃？
  • C-Q4: 如何支援 ZIP 匯入並安全解壓？
  • C-Q5: 如何設計可恢復的分片上傳與進度查詢？
  • C-Q7: 如何把圖片存到 S3 並使用簽名上傳與 CDN？
  • C-Q9: 如何設定 Nginx 與伺服器避免上傳超時與大小限制？
  • D-Q2: 批次上傳中常見超時或進度卡住如何處理？
  • D-Q4: 批次上傳出現重複照片與資料不一致？
  • D-Q5: 記憶體不足或 CPU 飆高導致處理失敗？