在一組經過標註、以文章為主的測試樣本中，newspaper4k 對 全部 22 個樣本 都成功產生輸出，找回了 98.65% 的評分文章單元，且沒有帶入任何標註過的樣板文字。就這三項指標來看，它非常符合本測試的優先目標；但這並不代表它是放諸四海皆準的最佳選擇。
在這組樣本裡，沒有其他工具能同時達到這三個觀察結果。Mozilla Readability 找回了所有評分內容單元，但夾帶了更多標註樣板；goose3 雖然沒有混入標註樣板，卻有兩次回傳空字串。不同的判斷標準，仍可能會偏好其他函式庫。
有一個抓取預設值，在正式部署前特別值得注意。
newspaper4k 是什麼
newspaper4k 是 newspaper3k 的維護分支，而 newspaper3k 本身又是原始 newspaper 的 Python 3 延續版。這段血統很重要，因為你在網路上搜尋協助時，多半會看到前一代的資料，而它的部分 API 已經變動。
官方參考：newspaper4k 官方倉庫。
這個函式庫最容易用錯的一點之一，就是直接去呼叫 set_html()。這個方法根本不存在。HTML 需要透過 download() 載入：
from newspaper import Article
a = Article(url="https://example.com/story")
a.download(input_html=html) # 不是 set_html()
a.parse()
text = a.text
我第一次執行時也犯了這個錯，還在確認是不是我自己的問題之前，先把函式庫評成 22 個樣本中只有 0 個正確。後來證實是我弄錯了。
它回傳的不只是文字而已。Article 物件還會暴露 text、title、authors、publish_date、top_image、images、movies、meta_description、meta_lang、tags 和 article_html 等欄位。keywords 與 summary 則需要下面會提到的可選 NLP 安裝與語料設定。本次有盤點欄位，但沒有評分中繼資料的準確度。
測試版本：0.9.6、MIT 授權、1,135 個 GitHub stars，倉庫最後一次推送日期為 2026-07-31。這個日期只是快照，不能代表整體維護健康度。Python 3.14.2。
測試結果
| 函式庫 | 文章召回率（共 22 個） | 樣板文字滲出 | 內容詞精準率 | 污染詞數量 | 是否產生輸出 |
|---|---|---|---|---|---|
| Readability | 1.0000 | 0.2353 | 0.9109 | 35 | 22/22 |
| trafilatura | 0.9865 | 0.0588 | 0.9411 | 4 | 22/22 |
| newspaper4k | 0.9865 | 0.0000 | 0.9452 | 0 | 22/22 |
| resiliparse | 0.9054 | 0.0588 | 0.9381 | 7 | 22/22 |
| jusText | 0.8378 | 0.4706 | 0.8760 | 74 | 19/22 |
| goose3 | 0.8243 | 0.0000 | 1.0000 | 0 | 20/22 |
sixway-scores.json。每個樣本中的每個單元都帶有獨特的識別標記，因此「找回」與「滲出」都是精確的子字串包含判定，而不是相似度分數。召回率是針對全部 22 個樣本計算；滲出率與精準率則是針對同時含有文章與樣板的 11 個樣本計算。
有三個欄位值得分開看。
它把每個頁面都輸出了。 goose3 和 jusText 沒做到——分別是 22 個裡面 20 個與 19 個。這點比表面看起來更重要，因為像這樣的精準率與 F1，都取決於有沒有產生輸出：如果某個函式庫回傳空字串，它就不會進入分子也不會進入分母，等於放棄的代價很低。goose3 的 1.0000 精準率，是在 11 個樣本中的 10 個上算出來的；newspaper4k 的 0.9452 則是在 11 個中的 11 個上算出來的。這兩者並不是完全相同的衡量方式。
它完全沒有滲出樣板。 這些樣本裡刻意加入了對抗性樣板——例如與文章並列的中性促銷區塊、看似無害 class 名稱的留言串、以及不直接寫著「ad」的廣告區塊。Readability 的 sibling-append 啟發式吞進去了其中幾個；newspaper4k 一個都沒有帶進來。
它只漏掉 74 個單元中的 1 個，而且這個漏失是共通的。
漏掉的是那個非純文字樣本——也就是由表格、程式碼區塊、短項目與圖片說明組成，而不是以段落為主的頁面——它漏掉的是 caption。而且它不是唯一會在這裡漏掉的工具：
| 函式庫 | 非純文字頁面的召回率 | 漏掉的單元 |
|---|---|---|
| Readability | 1.000 | — |
| jusText | 1.000 | — |
| trafilatura | 0.875 | caption |
| resiliparse | 0.875 | caption |
| newspaper4k | 0.875 | caption |
| goose3 | 0.250 | 兩個表格、程式碼區塊、兩個短項目、caption |
有三個函式庫都漏掉了同一個 caption，而且沒有漏掉其他單元，這看起來不像三個獨立 bug，反而像是對 caption 這種內容價值的共通繼承假設。如果你的內容是文件、食譜，或任何 caption 承載了段落沒有的資訊，正式採用前一定要測；而 Readability 和 jusText 都把它保留了下來。
同一個樣本也是 goose3 失控的地方，它幾乎丟掉了整頁內容，所以「非純文字內容」這個維度，遠比總表看起來更能拉開這六個工具的差距。
在速度方面，newspaper4k 對這 22 個樣本的中位抽取時間是 2.69 ms，是六者中最慢的，最差情況達到 199.81 ms。相較於 resiliparse 的 0.06 ms 中位數，在這次受控測試中差了 45 倍。單頁流程裡，中位數也許不算大，但在高負載下的吞吐量與尾延遲，這裡並沒有測試。冷啟動匯入的成本會在後面另外說明。
我會先改掉的第一個預設值
官方參考：newspaper4k 文件。
檢視隨附的 Configuration 物件，可以看到 22 個設定，其中之一是：
_honor_robotstxt = False
除非你明確告訴它，newspaper4k 不會理會 robots.txt。如果你讓它自己抓取——也就是使用 Article(url).download()，而沒有提供 input_html——它就會直接抓你指定的網址，不管網站的 robots 檔案怎麼寫。
對於一個主要用途是解析你手上已經有的 HTML 的函式庫來說，這樣的工程預設其實說得通；但如果你把它丟到正式環境後，才發現它會這樣抓取，那就很危險。若你要讓它抓取，請在 Configuration 裡把 honor_robotstxt=True 打開；或者像我在本次測試中一樣，直接傳入 input_html，由你自己負責抓取。
另外兩個也值得知道：
number_threads = 10。 多文章工具的預設平行度是 10。平行不等於每秒請求數，但如果你沒有另外設定每個主機的限制與排程，它確實可能造成一波同步請求。
fetch_images = True。 圖片抓取預設開啟，這會讓離線使用成為一個問題。在阻擋 socket.connect 的情況下，本次測試的 newspaper4k 0.9.6 路徑——也就是對一個已持有的 HTML 呼叫 download(input_html=…) 再接 parse()——能順利完成、回傳 1,292 個字元，且嘗試 0 次 網路連線。這只證明了這條特定路徑，不代表所有設定、外掛、內容型別或未來版本都一樣。
其餘預設值都算合理：min_word_count 300、min_sent_count 7、max_text 100,000、http_success_only True、memorize_articles True、follow_meta_refresh False、allow_binary_content False。
安裝與啟動現實面
pip install newspaper4k 會拉下 22 個套件 和 47.5 MiB，大約花 6 秒。全新子程序的冷匯入時間是 2.812 s——在這份比較裡是最慢的。
| 函式庫 | 套件數 | site-packages | 冷匯入時間 | 抽取 p50 |
|---|---|---|---|---|
| resiliparse | 5 | 21.0 MiB | 0.015 s | 0.06 ms |
| jusText | 3 | 22.4 MiB | 0.777 s | 0.56 ms |
| goose3 | 16 | 44.3 MiB | 2.181 s | 1.85 ms |
| newspaper4k | 22 | 47.5 MiB | 2.812 s | 2.69 ms |
| trafilatura | 17 | 69.9 MiB | 1.584 s | 0.51 ms |
install-and-import.json。每個函式庫都在各自全新的虛擬環境中安裝，因此不會繼承其他函式庫的相依項。
2.812 秒的匯入時間，是 resiliparse 15 毫秒的 187 倍。在長時間運作的工作程序裡，這只付一次，幾乎可以忽略；但在無伺服器函式裡，每次冷啟動都要付一次，而那種情況下，不管抽取表現多好，newspaper4k 都不是理想選擇。
安裝上還有一個小瑕疵：匯入時會印出警告：
UserWarning: nltk is not installed. Some NLP features will be unavailable. Install it with: pip install 'newspaper4k[nlp]'
本次測試完全不需要這些功能，而且在沒有它們的情況下，抽取也正常運作；但基礎安裝並不是完整安裝，newspaper4k[nlp] 會帶來更重的依賴樹與語料下載。只有在你真的需要關鍵字與摘要時，才應該把這部分成本算進去。
記憶體，以及破損 HTML 會怎麼影響它
這批評測中先前被列為未測的兩件事，現在都有量化了。
更大的壓力測試背景可參考十個函式庫的記憶體與錯誤 HTML 比較。
峰值常駐記憶體 使用 /usr/bin/time -l 測得，每個格子都跑一個全新程序——匯入底線代表函式庫載入後閒置時的成本，峰值則包含文件本身。
| 函式庫 | 執行環境 | 匯入底線（MiB） | 226 KB HTML 峰值（MiB） | 10 MB HTML 峰值（MiB） |
|---|---|---|---|---|
| html2text | python3.14 | 18.7 | 19.9 | 71.2 |
| pyquery | python3.14 | 30.3 | 33.9 | 172.5 |
| resiliparse | python3.14 | 20.5 | 25.1 | 225.1 |
| markdownify | python3.14 | 23.9 | 28.9 | 278.5 |
| goose3 | python3.14 | 44.1 | 52.4 | 398.5 |
| cheerio | node22 | 66.8 | 76.5 | 398.5 |
| justext | python3.14 | 30.3 | 36.6 | 431.2 |
| newspaper4k | python3.14 | 52.6 | 61.8 | 668.5 |
| trafilatura | python3.14 | 52.5 | 64.8 | 927.1 |
| turndown | node22 | 47.8 | 68.4 | 2947.1 |
memory-results.json。Python 與 Node 的基準彼此不能直接比較；兩者內部都包含了直譯器本身。
newspaper4k 的底線是 52.6 MiB，而 10 MB HTML 的峰值是 668.5 MiB——在 Python 函式庫裡是第二重的。對一般頁面來說，這兩個數字都不算問題；但如果你是在記憶體受限的 worker 裡批次處理大型文件，這就很重要了。
破損 HTML。 這裡有 12 份文件，每份只壞一個地方——例如未關閉標籤、錯誤巢狀的 inline 元素、帶空格但未加引號的屬性、多餘的關閉標籤、完全沒有 <html>、重複屬性、在標籤中間截斷的文件、錯誤實體、未關閉的 <script>、故意說謊的字元編碼宣告、包含標記的註解，以及 600 層巢狀結構——另外再加上 兩份結構完整且大小相符的控制組，因為「它什麼都沒回傳」只有在函式庫對乾淨文件也同樣沉默時，才能說明它對破損的反應。
控制組與破損案例在原始結果中可以清楚分開：
| 群組 | 文件數 | 是否拋錯 | 空輸出 | 找回的評分 sentinel |
|---|---|---|---|---|
| 結構完整且大小匹配的控制組 | 2 | 0 | 0 | 不納入破損評分 |
| 破損樣本 | 12 | 0 | 10 | 5/33，不含未關閉的<script> 案例 |
兩個控制組分別輸出了 70 與 1,351 個字元，而 12 個破損輸入中有 10 個回傳空字串。這表示，在這個樣本設計裡，空白輸出確實可歸因於 HTML 破損，而不是單純因為輸入太短。評分方式會在 11 份可計分的破損文件上檢查標題、段落與連結 sentinel。未關閉的 <script> 樣本則被排除，因為在 HTML5 解析規則下，後續標記仍屬於 script 內容。請參考malformed-results.json。這代表的是一項重要的恢復限制，選型時不能只看「沒有拋錯」。
優缺點整理
優勢。 在這次比較中沒有任何標註樣板 token，22 個受控文章樣本全部都有輸出，文章單元評分召回率達 0.9865。它能輸出文章文字與中繼資料欄位，不過中繼資料的準確性沒有測試。已持有 HTML 的測試路徑在 socket.connect 被封鎖時沒有任何網路嘗試。檢查當下倉庫有最近的日期型推送；更廣泛的維護健康度沒有評估。
劣勢。 本組中冷匯入最重，達 2.812 s，且實測 site-packages 為 22 個套件 / 47.5 MiB。honor_robotstxt 預設為 False，而多文章工具預設十個執行緒。基礎安裝會警告缺少 NLTK，所以關鍵字與摘要需要更重的可選安裝。最重要的是，12 個破損樣本中有 10 個回傳空輸出，即使兩個結構完整的控制組都能正常產生文字。
適合誰用，不適合誰用
如果你的優先順序是：在文章導向的受控資料集上產生非空文字、盡量避免標註樣板，並且可以接受較慢的冷啟動，那麼可以考慮 newspaper4k。依照這個明確規則，它在這次樣本比較中表現最好。若你的規則不同，也可以選 Readability，因為它保留了最多評分內容；或者選 resiliparse，因為它在啟動與中位抽取速度上更快。
如果你的情境是：冷啟動最重要、47.5 MiB 的實測 site-packages 不能接受，或者你很在意破損 HTML 的恢復能力，那就應該跳過它，或至少先做充分的 bake test。這裡 resiliparse 的匯入速度快了 187 倍，但它在所有品質欄位上也沒有與 trafilatura 完全打平：trafilatura 的文章召回率更高，而兩者在滲出與精準率上的輪廓也不同。newspaper4k 是以文章為中心設計的；商品列表與儀表板沒有測試，因此不能對那些場景做任何保證。
不管怎樣，只要它會自己抓取，就把 honor_robotstxt 打開。 這不是效能建議。
託管 API 何時適合
newspaper4k 可以解析呼叫端提供的 HTML，也有抓取路徑。託管式抽取服務則把取得內容、渲染與 schema 工作都交給供應商邊界處理。我們有在做 Thunderbit，但它沒有套用到這組樣本，因此這篇評測不包含任何品質、渲染、反機器人、延遲或成本比較。就已持有的文章 HTML 而言，這裡的證據只說明 newspaper4k 本身；非文章類目標還需要各自評估。
如果你想看同樣六個抽取器在同一組樣本上的比較，請參考六個函式庫的抽取比較。
若你關注的是雲端服務，我們的網頁爬蟲 API 總整理會是更廣的視角；若想看自架替代方案，可參考開源爬蟲總論。如果文字最後要送進模型，用 Python 將 HTML 轉成 Markdown 會說明資訊保真在哪裡流失。
要不要使用 newspaper4k？
如果 HTML 已經在手上，newspaper4k 可以先視為文章文字抽取的強力候選，再拿你的真實網站資料做一次 bake-off 後決定是否採用。受控樣本顯示它有很高的文章召回率、沒有標註樣板，而且在 22 個文章導向樣本上都能輸出非空內容。但這不涵蓋真實網頁或中繼資料準確性，而且 12 個破損樣本中有 10 個回傳空輸出。
如果你會用它的抓取路徑，請明確檢查 honor_robotstxt=False、十執行緒平行度，以及每個主機的限速控制。若冷啟動或依賴體積很重要，請在你的部署環境中實測 2.812 秒的本機匯入時間與 47.5 MiB 的 site-packages，而不要把它們當成通用容器成本。
試用 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
為什麼 set_html() 不能用？
因為 newspaper4k 裡根本沒有這個方法。HTML 要透過 download(input_html=html) 傳入，然後再呼叫 parse()。搜尋結果常會出現 newspaper3k 的範例，所以很容易搞混；我第一次跑的時候也踩到了這個坑，後來在評分前先把測試框架修正了。
newspaper4k 會尊重 robots.txt 嗎？
預設不會。honor_robotstxt 的出廠值是 False。如果你讓函式庫自己抓取，請在 Configuration 裡設成 True；或者直接傳入 input_html，自行負責抓取。多文章工作預設也會使用十個執行緒。這是未經你明確指定的平行度，不是固定請求速率；抓取時請自己設定每個主機的限制。
parse() 會發出網路請求嗎？
在 newspaper4k 0.9.6 中，本次測試的 download(input_html=…) 加上 parse() 路徑，當 socket.connect 被封鎖時，對一份已持有的 HTML 完全沒有任何連線嘗試。這並不代表所有解析設定、外掛、內容型別或未來版本都不會碰網路。
匯入時出現的 NLTK 警告是什麼？
基礎安裝不包含 NLTK，所以關鍵字抽取與摘要功能不可用，函式庫在匯入時也會提示這件事。抽取本身不受影響——這裡量測的所有項目都只用了基礎安裝。pip install 'newspaper4k[nlp]' 會把這些功能加上去，但也會帶來更重的依賴樹與語料下載。
這篇評測沒有測什麼？ 真實世界的網頁——這些都是經過標註的受控樣本。中繼資料欄位有盤點，但沒有針對標題、作者、日期或圖片準確度打分。多語言抽取、NLP 額外功能、多執行緒來源抓取，以及高負載下的吞吐量也都沒有測。程序峰值記憶體只是在一個 226 KB 與一個 10 MB 的 HTML 輸入上測得，沒有並行或持續負載情境。
