我曾經花了多到離譜的深夜時間，在除錯那些本來應該只是「抓個檔案就走人」的腳本。十次裡有九次，問題都不是 cURL 壞掉，而是它完全照著我下的指令做，卻不是我真正想要的結果。說到底，「curl -O 可以用」和「curl -O 能在正式環境穩定運作」之間，差了一大截。
這份指南就是要補上那個落差。cURL 預先安裝在 macOS、大多數 Linux 發行版，以及 Windows 10 之後的版本裡，代表你現在手邊的電腦八成已經有它了。不過，從靜默的重新導向失敗、莫名其妙的 403，到從「下載一個檔案」進化成「一次下載 500 個檔案還不把終端機搞掛」，中間其實很容易卡關。接下來我會帶你看真正重要的參數、我實際會用的逐步指令、最常踩到的錯誤，以及 cURL 真的幫不上忙時，該改用什麼工具。
cURL 是什麼？為什麼你應該在意？
cURL 是一款免費、開源的命令列工具，用來透過 URL 與伺服器之間傳輸資料。它支援 HTTP、HTTPS、FTP、SFTP，以及一長串其他協定，所以你會在 bash 腳本、Dockerfile、CI 流程裡到處看到它。你在終端機輸入的 curl 指令，底層其實是呼叫 libcurl 這個 C 語言傳輸函式庫，很多應用程式與語言綁定都會把它嵌進去。PHP 的 cURL 擴充就是一個例子；Python 很多人在用的 Requests 則是建立在 urllib3 上的獨立 HTTP 用戶端，並不是 libcurl。
截至撰寫當下，最新穩定版是 curl 8.21.0，於 2026 年 6 月發布——但別假設你的作業系統就剛好附了這個版本。各發行版套件庫裡的 curl 常常會比上游專案慢上幾個月，甚至更久，所以在你以為某個參數（像 --parallel）可用之前，最好先跑一次 curl --version。
為什麼要用 cURL 下載檔案？常見應用場景
我常被問，既然瀏覽器也能下載檔案，為什麼還要特地用命令列工具。老實說：瀏覽器很方便，但一旦你需要自動化，它的優勢就沒那麼明顯了。
| 使用情境 | cURL 的優勢 |
|---|---|
| 在 CI/CD 流程中下載二進位檔 | 可腳本化，不需要圖形介面 |
| 取得 API 回應或資料匯出檔 | 支援自訂標頭、驗證與輸出管道 |
| 透過 SSH 續傳大型檔案 | 內建續傳支援（-C -） |
| 自動化週期性下載（cron 工作） | 輕量、可與 shell 腳本靈活組合 |
| 下載需要驗證的檔案 | 彈性的驗證參數（基本驗證、Token、Cookie、.netrc） |
瀏覽器下載通常只是手動點一下的一次性動作。cURL 則能把同樣的動作變成可排程、可串接流程、可失敗重試，而且還能在上百台伺服器上完全一致地執行。這就是它真正吸引人的地方——不是比較炫，而是可重複。
cURL 下載檔案必備的核心參數
我幾乎 90% 的工作都離不開那十幾個參數。下面這份速查表，是我希望自己幾年前就有人交給我的版本，我按實際用途整理好了。
輸出與檔名儲存參數
-O（--remote-name）會直接用 URL 最後一段當檔名。很方便，但如果本機已經有同名檔案，它可能會直接覆蓋而不提醒你。-o <filename>（--output）讓你自己指定檔名：curl -o report.pdf https://example.com/downloads/file.pdf。-J（--remote-header-name）會採用伺服器Content-Disposition標頭裡的檔名，而不是 URL。這對 API 下載很方便，但要把伺服器提供的檔名當成不可信輸入來看——最好下載到專用資料夾，不要直接丟進家目錄，這也是 curl 官方安全建議 的方向。
每次下載都該有的行為參數
-L（--location）會讓 curl 跟隨 HTTP 重新導向。沒加的話，3xx 回應可能會被存成一小段 HTML 轉址頁，而不是你真正要的檔案——這就是我最常看到的「為什麼我的下載壞掉了」的原因。-C -（--continue-at -）可以從中斷的位置續傳下載。-s/-S會安靜執行，但仍顯示錯誤訊息——很適合不想讓進度條塞滿日誌的腳本。--limit-rate 1M會限制頻寬（在共享網路或不想吃掉計量流量時很好用）。--connect-timeout 10與--max-time 300可以避免卡住的連線把腳本永遠凍住。--retry 3與--retry-delay 5會在短暫性失敗時自動重試——依照 curl 手冊頁 的說明，只有在重複同一個請求確實安全時，才應該再搭配--retry-all-errors。
進度與除錯參數
-#會顯示簡單的進度條，而不是預設的統計表格。-v會輸出詳細資訊，包括完整請求／回應標頭——只要哪裡怪怪的，我最常先用它。-I（--head）只抓回應標頭，正式下大檔前先做一次預檢很實用。-w可以在傳輸後印出自訂內容，例如curl -o /dev/null -s -w "%{http_code}\n" <url>只看狀態碼。
開始前先確認
- 難度： 初學到中階（批次下載與驗證那幾節會稍微進階一點）
- 所需時間： 完成核心指令約 15–20 分鐘
- 你需要準備： 終端機（macOS Terminal、Linux shell 或 Windows PowerShell/WSL）、已安裝的 curl（可用
curl --version檢查），以及一個測試 URL——我會以公開的 GitHub release 檔案為例，因為它穩定又能自由存取
如何使用 cURL 下載檔案：逐步教學
第 1 步：下載單一檔案
最基本的用法是：curl -O <url> 會用原始檔名儲存，而 curl -o myfile.zip <url> 則可以在下載時順便改名。
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
我現在預設都會加上 -L，而且是毫無例外地加——我已經被太多次「看似下載成功，其實只是轉址成一個 400 位元組的 HTML 檔」教訓過了。你應該會在終端機看到進度條一路跑到 100%，最後檔案出現在目前目錄。
指令成功後，進度條會到 100%，而 curl-8.21.0.tar.gz 會出現在目前目錄。使用前先確認檔案存在：
ls -lh curl-8.21.0.tar.gz
第 2 步：下載並重新命名檔案
當你想指定本機檔名，而不是網址最後那段的名稱時，就用 -o：
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
這裡的 -S 會把錯誤訊息重新打開，避免你在其他腳本區段已經用了 -s 之後，完全看不到錯誤。這組 -L -o <name> -S 幾乎就是我預設的單檔下載指令。
第 3 步：續傳中斷的下載
如果大型檔案下載到一半斷掉了（像是網路不穩、VPN 抽風，任何狀況都可能），不要從頭來過。直接執行：
curl -C - -LO https://example.com/large-file.iso
但要注意：這只有在伺服器支援位元組範圍請求時才有效。Accept-Ranges: bytes 是一個有幫助的正面訊號，但它的缺席不代表一定不支援範圍請求。最可靠的方式，是觀察伺服器對真正範圍請求的回應：可續傳的回應通常會回傳 206 Partial Content，並帶有有效的 Content-Range。執行續傳指令時，可搭配 -v 或 -D - 查看狀態；如果伺服器忽略範圍或拒絕偏移，就應該明確重跑，而不是假設部分檔案可以安全接著用。
第 4 步：顯示進度條，或完全靜默下載
如果你是在互動式終端機裡，想要畫面更乾淨一點，可以用：curl -# -LO <url>。如果是腳本或 cron 工作，只想保留錯誤、不想看到雜訊，就用：curl -sS -LO <url>。除了手動除錯時，我幾乎到處都用靜默版本。
第 5 步：限制下載速度
在辦公室共用網路上，或者當我不想在視訊會議時變成那個「把頻寬吃光的人」時，我會用這樣限制速度：
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
單位分別是 K、M、G，代表每秒千位元組、百萬位元組與十億位元組。
第 6 步：把回應標頭也一起存下來
有時候我需要知道伺服器到底回了什麼——像是內容類型、快取標頭之類的資訊——又不想讓終端機畫面太亂：
curl -L -D headers.txt -o file.zip https://example.com/file.zip
這樣回應標頭會寫進 headers.txt，而實際檔案則會存成 file.zip。這對除錯 content-type 不一致，或確認 CDN 是否真的在快取你以為它快取的內容，非常有幫助。
小技巧與常見陷阱
- 小技巧： 預設就加上
-L。老實說，我想不到不加它有什麼好處，而且我真的因為忘了加它，白白浪費過好幾個小時。 - 小技巧： 在腳本中把
--fail一起加進下載指令，這樣非 2xx 回應才會讓腳本直接報錯退出，而不是默默把錯誤頁存成你的檔案。 - 陷阱： 不要把
-C -和--remove-on-error配在一起——curl 文件明確說它們不相容，因為續傳需要那個部分檔案還留著。 - 陷阱：
-O可能在沒有警告的情況下覆蓋檔案。如果你要批次下載到共用資料夾，請用--output-dir把檔案集中管理。
如何用 cURL 下載多個檔案與批次下載
單檔範例只是起點。我實際做過的工作——例如抓取每晚的資料匯出、在多台建置伺服器間同步二進位檔——都需要並行處理，而多數教學偏偏就停在這裡。下面這三種方法值得認識，複雜度也會逐步提高。
方法 1：在同一個 cURL 指令中放入多個 URL
最簡單的做法就是直接列出多個網址：
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
這樣可以用，但它是依序執行的——curl 會先把第一個檔案完整下載完，才會開始下一個。三個檔案還行，三百個就很痛苦了。
方法 2：用 --parallel 並行下載（curl 7.66+）
從 curl 7.66 開始，你可以加上 --parallel（或 -Z）一次並行抓多個 URL：
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
值得知道的是，預設的 parallel max 其實是 50，這比大多數伺服器（甚至你自己的網路）真正會感謝的併發連線數還要高。我通常都會明確指定一個保守值——通常是 4 到 8——而不是直接相信預設值。
方法 3：用 xargs 與 Bash 迴圈，從 URL 清單進行並行下載
如果是一長串放在文字檔裡的網址，我通常會先想到 xargs：
cat urls.txt | xargs -n1 -P 8 curl -O -L
或者，如果我想更精細控制每個工作發生什麼事，就會用背景程序的 bash 迴圈：
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
最後那個 wait 很重要——沒有它，腳本會在背景下載還沒跑完之前就提前結束。
什麼時候該改用 wget 或 aria2
我直接講白一點：cURL 不是永遠都最適合的工具。如果你需要鏡像整個網站目錄樹，wget -r 本來就內建遞迴抓取，這是 cURL 根本不是為此設計的。如果你需要多來源、分段下載，以達到單一超大檔案的最高吞吐量，aria2c 的速度真的比較快。
| 工具 | 最適合的用途 |
|---|---|
| cURL | 精準控制、腳本化、單檔或小批次下載、API 互動 |
| wget | 遞迴／鏡像網站下載、較簡單的大量靜態檔抓取 |
| aria2 | 多來源／分段下載、將大型檔案吞吐量拉到最大 |
cURL 一直以來最強的地方都是精準與可組合性——管線傳輸、腳本化、協定彈性——而不是暴力式抓取。
如何使用 cURL 下載受保護檔案：驗證模式
大多數 cURL 教學都只停在 -u user:pass，然後就收工了。那其實是比較早期網路時代的作法。到了 2026 年，我實際下載的檔案多半來自 REST API、以 session 為基礎的儀表板，以及 CI 系統——而這些情境各自需要不同型態的憑證。
基本驗證
curl -u username:password -O https://legacy-server.example.com/file.zip
這對老式 FTP 伺服器或簡單 HTTP 端點都還算方便。但要知道，密碼很可能會出現在 shell 歷史與行程清單裡，除非你很小心——這種方式我不會拿來處理任何敏感資料。
Bearer / OAuth Token 驗證
這是很多指南很少著墨、但我現在最常用的一種：
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
這是拉取私有 GitHub release 資源的真實模式——把 token 和 asset ID 換成你的即可。REST API 與受 OAuth2 保護的資源，現在基本上都這樣溝通。
基於 Cookie 的 Session 驗證
對於登入後會建立 session 的網頁應用，可以在登入時把 cookie jar 存起來，下載時再重用：
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
適用於腳本與 CI 環境的 .netrc 檔案
如果是無人值守執行的工作，我最推薦這個方法。建立一個 ~/.netrc 檔案（Windows 上是 _netrc）：
machine example.com
login myusername
password mypassword
再用 chmod 600 ~/.netrc 把權限鎖好，然後這樣引用它：
curl --netrc -LO https://example.com/protected-file.zip
它的好處是憑證不會出現在 shell 歷史或腳本原始碼裡——這在 CI/CD 裡特別重要，因為腳本常常會被完整記錄下來。
| 驗證方式 | 參數／選項 | 最適合的情境 |
|---|---|---|
| 基本驗證 | -u user:pass | 傳統 FTP、簡單 HTTP |
| Bearer token | -H "Authorization: Bearer <token>" | REST API、OAuth2 |
| Cookie 驗證 | -b cookies.txt（另可用 -c 儲存） | 基於 session 的網頁應用 |
.netrc 檔案 | --netrc 或 --netrc-file | CI/CD、腳本化環境 |
常見 cURL 下載失敗的排除方法
這一段其實是我當年最希望有人寫給我的，因為幾乎沒什麼人會真的把它講清楚。「為什麼我的 curl 下載不能用」是一個非常常見、也很讓人崩潰的搜尋，而一旦知道原因，修正方式通常只有一行指令。
| 症狀 | 可能原因 | 修正方式 |
|---|---|---|
curl: (60) SSL certificate problem | 自簽憑證或憑證過期 | --cacert <file> 或 -k（僅限開發） |
403 Forbidden / 空檔案 | 伺服器封鎖預設 curl User-Agent | -A "Mozilla/5.0..." 或 -H "User-Agent: ..." |
搭配 -C - 後又從 0 開始下載 | 伺服器不支援 Range | 用 curl -I <url> 檢查是否有 Accept-Ranges: bytes |
| 儲存成 0 位元組檔案 | 沒有跟隨重新導向 | 加上 -L 參數 |
curl: (28) Operation timed out | 伺服器太慢或網路不穩 | --connect-timeout 10 --max-time 300 + --retry 3 |
| 存成 HTML 頁面而不是檔案 | 頁面需要 JavaScript 渲染 | curl 無法執行 JS——請看下方說明 |
SSL 憑證錯誤：代表什麼、怎麼修
錯誤 60 表示 curl 無法驗證伺服器的 SSL 憑證——通常是因為它是自簽、過期，或是 curl 不信任的 CA 所簽發。如果你能控制伺服器，就把正確的 CA bundle 用 --cacert /path/to/ca.pem 指給 curl。-k（--insecure）會完全跳過驗證，這在本機開發環境沒問題，但只要碰到正式環境或真實使用者資料，我就完全不建議。
403 Forbidden 與空白下載
不少伺服器會擋掉那些把自己識別成 curl/8.21.0 的請求（這是 curl 預設的 User-Agent），因為它們會把這類流量當成機器人或爬蟲。通常的解法就是假裝自己是瀏覽器：
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
如果我想在下載完整檔案前先確認伺服器到底回了什麼，我會跑：curl -o /dev/null -s -w "%{http_code}\n" <url>。
逾時、重試與不穩定連線
如果我夠勇敢，我大概會把這條指令刺在手臂上。
我最常用的下載指令，也是我實際在正式腳本裡會用的版本，會把多個可靠性參數一起疊上：
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
這代表會跟隨重新導向、支援續傳、重試 5 次且每次間隔 3 秒、連線 10 秒逾時、總時間上限 10 分鐘，並且在 HTTP 狀態錯誤時直接失敗——幾乎就是我一路踩坑後學會一定要加進來的全部東西。
cURL 實戰自動化：CI/CD、管線傳輸與腳本安全
將 cURL 輸出直接接給其他工具
curl 不一定要把任何東西存到磁碟；直接管線到另一個指令，是它最被低估的能力之一：
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
一行內就能下載並解壓，或下載並解析。這是我處理一次性資料擷取時最常用的模式。
在 GitHub Actions 與 CI/CD 中使用 cURL
這是一個最簡化的 GitHub Actions 步驟，會下載二進位檔，帶有重試邏輯，並在錯誤時明確失敗：
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
把 token 存成 CI secrets，並以環境變數引用——不要把它們硬寫進腳本。也要使用 --fail（如果你需要看到錯誤內容來除錯，則可用 --fail-with-body），這樣下載壞掉時，建置才會真的失敗，而不是靜悄悄地把垃圾當成功。
curl | sh 的安全疑問
這個問題幾乎每個我看過的開發者論壇都會提到，而且很合理：直接把 curl 管線到 sh，就等於執行你沒審查過的遠端程式碼，完全建立在你相信伺服器沒被入侵、連線也沒被竄改的前提上。真正的風險就是這個——不是危言聳聽，而是很直接的供應鏈安全問題。
更安全的方式是先下載，再檢查腳本，若有提供雜湊值或 GPG 簽章就先驗證，最後才執行：
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # 真的讀一下內容
sha256sum install.sh # 如果有公佈 checksum，就拿來比對
bash install.sh
像 rustup 和 Homebrew 這類知名安裝器仍然會用 curl | sh 這種模式，在這些特定案例裡通常也被接受，因為維護者與發佈管道都很成熟。不過，如果能多花十秒檢查腳本，我寧願這樣做，也不想哪天才發現自己不該那麼信任它。
什麼情況下 cURL 也不夠：JS 渲染頁面、反機器人網站與結構化資料
這是一種很常把人絆倒、而且通常不是你錯的失敗模式：你對著看起來很正常的頁面下 curl -O，結果拿到的不是預期內容，而是一個空空的 HTML 外殼、一個 Cloudflare 驗證頁面，或者一堆像垃圾的內容。cURL 其實只是照著它被設計的方式工作——抓原始 HTTP 回應——只是它不能執行 JavaScript、不能解 CAPTCHA，也無法突破反機器人的指紋辨識系統。這些都不是 cURL 的 bug，而是它本來就不負責的範圍。
為什麼 cURL 會在現代網頁上失手
現代單頁應用程式常常只回傳幾乎空白的 HTML 骨架，真正內容要等頁面載入後由 JavaScript 在客戶端渲染——而這正是 curl 不會執行的部分。除此之外，像 Cloudflare 與 Akamai 這類系統，會對任何不像真實瀏覽器的請求直接丟出驗證頁，而來自同一個 IP 的大量 curl 請求，也很快就會被限速或被當成機器人流量。
下一步：給開發者用的 AI 抓取 API
我會說，curl 大概能處理 80% 的檔案與資料下載需求——靜態資源、API 回應、以及任何以普通 HTTP 資源形式提供的東西。剩下 20%，也就是 JavaScript 很重或有機器人防護的頁面，才是我看過許多開發者花上好幾小時跟標頭與 User-Agent 字串纏鬥，最後還是放棄、轉向另一層工具的地方。
這正是我團隊打造 Thunderbit 想解決的落差，也包含了許多人熟悉的 Chrome 擴充功能。在開發者端，Thunderbit 的 Open API 提供 POST /distill，可從 URL 回傳乾淨、適合 LLM 使用的 Markdown，頁面渲染由服務端處理；也提供 POST /extract，當你需要的是符合 schema 的結構化 JSON，而不是可讀文字時，就能直接取得對應欄位資料。另有 MCP server，讓 Claude 或 Cursor 裡的 agents 在工作途中呼叫 thunderbit_distill 與 thunderbit_extract；還有 CLI（npx @thunderbit/thunderbit-cli distill <url>），在終端機中的使用感跟 curl 很像。例如你可以把 JSON 輸出接到 jq：thunderbit distill <url> --format json | jq -r '.data.markdown'；如果輸出的是 --format markdown，則可以直接丟給文字工具或存成檔案。
並排來看，差異非常明顯。對一個 JS 渲染的產品頁面下 curl，可能只會拿到幾乎空白的 <div id="root"></div>。相對地，thunderbit distill 會回傳已渲染頁面的乾淨 Markdown。Distill 每個 URL 1 點、Extract 每個 URL 20 點。目前各端點限制也不同：Batch Distill 每個工作最多支援 100 個 URL，而 Batch Extract 在共用一個 schema 的情況下最多可接受 50 個 URL。在規劃正式環境佇列規模前，建議先查看最新 API 文件。
如果你對這個概念還比較陌生，我們自己寫的 什麼是網頁爬蟲 是不錯的入門說明，而 無程式碼爬取指南 則是把同一個問題從非技術使用者的角度講清楚，適合團隊中不想碰終端機的人閱讀。若你想先看這個領域更廣的工具比較，我們也整理了一篇 最佳 AI 網頁爬蟲 的總覽。
快速參考：cURL 下載速查表
| 任務 | 指令 |
|---|---|
| 基本下載 | curl -LO <url> |
| 自訂檔名 | curl -L -o myfile.zip <url> |
| 續傳下載 | curl -C - -LO <url> |
| 靜默但顯示錯誤 | curl -sSL -O <url> |
| 並行下載 | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Bearer token 驗證 | curl -H "Authorization: Bearer <token>" -LO <url> |
| 常用腳本化下載 | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| 管線接到擷取工具 | curl -sL <url> | tar xz |
結論與重點整理
用 curl 下載檔案，起步很簡單——curl -O 基本上就能完成大半工作——但真正的技巧藏在背後的那些層次：什麼時候該加 -L、什麼時候要續傳而不是重抓、哪種驗證方式最符合你的流程，以及當 403 或空白 HTML 外殼出現時，應該怎麼處理。這些模式我都親自踩過，通常也都是在真正學會它們有多重要之後。
對我來說，curl 到現在仍然是處理直接檔案下載與可腳本化 HTTP 工作的預設工具——它快、到處都有，而且和 shell 管線搭配起來非常漂亮。但一旦你碰到 JavaScript 渲染頁面或反機器人阻擋，問題就不是再多加幾個參數能解決的，而是代表你需要換一層工具；這正是像 Thunderbit 這樣的 API 能接手處理、讓你不必離開終端機的地方。
把這份速查表收藏起來，下一次遇到不穩定的下載時試試重試與續傳指令；如果你真的撞上 curl 只回傳垃圾內容的那道牆，你也知道下一步該怎麼走——Thunderbit 的定價頁有最新點數說明，如果你想知道升級到下一層工具會花多少，YouTube 頻道 也有操作教學，適合想看影片的人。
關於使用 cURL 下載檔案的常見問題
如何用 cURL 下載檔案並指定檔名？
使用 -o 加上你想要的檔名即可：curl -L -o yourname.ext <url>。記得加上 -L，避免重新導向害下載失敗。
如何續傳失敗的 cURL 下載？
執行 curl -C - -LO <url>。這只有在伺服器支援 range requests 時才有效——先用 curl -I <url> 檢查回應中是否有 Accept-Ranges: bytes。
cURL 可以下載需要登入的檔案嗎？
可以，主要有四種方式：基本驗證（-u user:pass）、Bearer token（-H "Authorization: Bearer <token>"）、基於 Cookie 的 session（-b cookies.txt），或是在腳本環境使用 .netrc 檔案。完整差異與適用情境請看上方驗證章節。
cURL 與 wget 在下載檔案時有什麼不同？
cURL 支援更多協定，通常更適合腳本、管線串接，以及精準的單檔或小批次下載。wget 則是為遞迴抓取與鏡像整個網站目錄而設計，因此更適合大量抓取靜態網站檔案。
為什麼 cURL 下載到的是 HTML 頁面，而不是實際檔案？
最常見的兩個原因：你忘了加 -L，結果伺服器把你導到別的地方；或者該頁面需要 JavaScript 才能渲染出真正內容，而 curl 根本無法執行 JS。第二種情況下，你需要的是能渲染頁面的工具，而不是更多 cURL 參數。
