前陣子有個(gè)做論文情報(bào)分析的朋友跑來(lái)問我ArXiv的新限流政策到底怎么回事為什么我原來(lái)的腳本一夜之間開始報(bào)403了。這問題其實(shí)最近在好幾個(gè)技術(shù)社區(qū)都被翻來(lái)覆去地討論。ArXiv作為全球最大的預(yù)印本平臺(tái)每天承載著海量的論文檢索和下載請(qǐng)求2024年以來(lái)官方對(duì)API的使用規(guī)則做了一輪明顯收緊的調(diào)整從注冊(cè)認(rèn)證到請(qǐng)求頻率都有了更明確的約束。這篇內(nèi)容就把我實(shí)際踩坑、反復(fù)讀官方文檔之后整理出來(lái)的東西完整說(shuō)一遍看完你應(yīng)該能搞清楚新規(guī)到底改了什么自己的腳本該怎么改以及怎么繼續(xù)合理地用這個(gè)接口做論文檢索、訂閱和批量分析。如果你只是偶爾打開網(wǎng)頁(yè)搜幾篇論文那這次的更新跟你關(guān)系不大但如果你維護(hù)著論文自動(dòng)推送工具、在跑學(xué)術(shù)挖掘的批處理任務(wù)或者寫過爬蟲抓過ArXiv的頁(yè)面和PDF那下面這些內(nèi)容建議認(rèn)真看一遍。我盡量把規(guī)則、操作、排查三類東西都講透讓不同基礎(chǔ)的人都能找到自己需要的部分。1. 這次更新到底改了什么從“君子協(xié)議”到“硬性門檻”1.1 背景ArXiv的接口生態(tài)與濫用現(xiàn)狀A(yù)rXiv的公共API一直是學(xué)術(shù)圈子里公認(rèn)的良心服務(wù)沒必要注冊(cè)、沒有繁瑣的鑒權(quán)拿到http://export.arxiv.org/api/query這個(gè)地址就能直接查論文元數(shù)據(jù)。很多論文推薦系統(tǒng)、機(jī)構(gòu)知識(shí)庫(kù)的自動(dòng)同步腳本、研究者的文獻(xiàn)管理工具都跑在這套接口上。但問題也隨之而來(lái)因?yàn)檫@接口太好用了有人用它做整庫(kù)鏡像有人用高并發(fā)腳本批量拉取全文有人直接把服務(wù)器掛上去搞所謂的“論文搜索引擎”把ArXiv當(dāng)免費(fèi)CDN用。我在維護(hù)自己的論文追蹤工具時(shí)就觀察到過一種典型情況某天起所有請(qǐng)求都開始超時(shí)網(wǎng)頁(yè)端正常但API端像被人打了流量洪水一樣。后來(lái)社區(qū)里有人找到原因某個(gè)開源項(xiàng)目為了給用戶提供“最新論文推送”功能用單IP開幾十個(gè)線程去輪詢把平臺(tái)方的出口帶寬和算力都吃滿了。這類事件多了ArXiv官方自然要?jiǎng)邮?。其?shí)ArXiv早年對(duì)API的約束更像一份“君子協(xié)議”——文檔里用禮貌的語(yǔ)氣寫著“請(qǐng)每次請(qǐng)求間隔至少3秒請(qǐng)使用批量參數(shù)獲取多條記錄”但缺少?gòu)?qiáng)制手段?？梢坏┤鄙?gòu)?qiáng)制手段總有人去試探上限。2024年的政策更新本質(zhì)上是把這層“君子協(xié)議”變成了有認(rèn)證、有標(biāo)識(shí)、有懲罰措施的硬性門檻。1.2 新舊策略的核心差異我們直接看ArXiv官方更新后的幾個(gè)關(guān)鍵變化點(diǎn)我用表格整理一下方便你有直觀印象對(duì)比維度舊策略約2024年前更新后策略認(rèn)證方式匿名請(qǐng)求即可無(wú)需注冊(cè)推薦/要求在注冊(cè)賬號(hào)下獲取API Key匿名訪問受限速率約束文檔建議3秒/次但無(wú)強(qiáng)制校驗(yàn)對(duì)匿名IP有明顯頻率閾值超過即返回403或429批量拉取可用start和max_results循環(huán)翻頁(yè)官方更傾向用id_list一次性取多條翻頁(yè)高頻仍會(huì)被限懲罰措施無(wú)明確說(shuō)明一般靠運(yùn)氣明確說(shuō)明“持續(xù)違規(guī)將封禁IP或永久禁止使用API”大流量下載走API或爬蟲均可被明確引導(dǎo)至data.arxiv.org的批量數(shù)據(jù)文件或聯(lián)系管理員這個(gè)表格里最關(guān)鍵的就是“認(rèn)證”和“懲罰”兩行。以前接口是敞開大門的現(xiàn)在至少在官方建議層面要求開發(fā)者先注冊(cè)賬號(hào)、創(chuàng)建API Key再以攜帶Key的方式訪問。匿名請(qǐng)求并沒有徹底關(guān)閉但被限制在一個(gè)比較保守的頻率區(qū)間一旦觸發(fā)閾值服務(wù)器端會(huì)直接斷開響應(yīng)。1.3 為什么必須更新三個(gè)真實(shí)場(chǎng)景我說(shuō)幾個(gè)真實(shí)場(chǎng)景大家就容易理解官方的苦衷。第一個(gè)場(chǎng)景是爬蟲鏡像。曾有研究者為了做全量論文文本分析直接寫分布式爬蟲爬ArXiv的HTML頁(yè)面和PDF文件單日流量達(dá)到數(shù)TB級(jí)別。ArXiv不是商業(yè)公司它靠大學(xué)、圖書館和捐贈(zèng)維持運(yùn)轉(zhuǎn)這種量級(jí)的流量對(duì)任何公共設(shè)施都是災(zāi)難。官方?jīng)]有直接封殺但后來(lái)確實(shí)對(duì)異常IP做了限制。第二個(gè)場(chǎng)景是劣質(zhì)API代理。有人架設(shè)了免費(fèi)的“ArXiv代理接口”背后就是用普通服務(wù)器反復(fù)請(qǐng)求官方API然后把結(jié)果緩存起來(lái)賣流量或收集用戶畫像。這種中間層不清楚限流規(guī)則也無(wú)視官方的服務(wù)條款導(dǎo)致官方API經(jīng)常被單點(diǎn)打爆。第三個(gè)場(chǎng)景是誤傷了正常用戶。我自己就遇到過一個(gè)定時(shí)任務(wù)因?yàn)榫W(wǎng)絡(luò)抖動(dòng)導(dǎo)致重試邏輯寫得不嚴(yán)謹(jǐn)連續(xù)在幾秒內(nèi)發(fā)出了幾十個(gè)重復(fù)請(qǐng)求然后那個(gè)服務(wù)器IP在接下來(lái)幾個(gè)小時(shí)里訪問ArXiv API全部失敗。其實(shí)不是被針對(duì)而是舊策略下的IP懲罰機(jī)制太粗放觸發(fā)條件不透明正常用戶容易被誤傷。所以新政策的核心導(dǎo)向很明確把訪問行為從“不可控匿名”推向“可控認(rèn)證”讓用得多的人走專門通道讓偶爾用的人保持基本的謙讓。這不是要趕人走而是想讓整個(gè)接口生態(tài)長(zhǎng)期存活。2. 速率限制規(guī)則拆解具體參數(shù)與觸發(fā)機(jī)制2.1 官方API調(diào)用的基本禮節(jié)3秒間隔與單次結(jié)果數(shù)先說(shuō)最核心的一條官方API文檔至今仍然建議“每次請(qǐng)求之間至少間隔3秒”。這個(gè)數(shù)字不是隨便拍的它意味著單IP在理想情況下每分鐘最多約20次請(qǐng)求。如果你的程序要抓取5000條記錄用每頁(yè)20條的標(biāo)準(zhǔn)分頁(yè)來(lái)算需要發(fā)250次請(qǐng)求按3秒間隔算就是750秒大約12.5分鐘。很多急性子受不了這個(gè)速度于是把間隔改成1秒甚至并發(fā)然后就被限流了。這里要給一個(gè)明確建議如果你真的需要一次性拿大量元數(shù)據(jù)不要傻乎乎地一頁(yè)頁(yè)翻。API提供了id_list參數(shù)可以一次傳入多個(gè)論文ID例如id_list2101.00123,2101.00124用一次請(qǐng)求返回多條記錄。官方文檔的態(tài)度非常清楚——能用批量方式解決的需求就不要用高頻分頁(yè)去硬刷。另一個(gè)容易忽略的參數(shù)是max_results。雖然接口允許你拉2000條結(jié)果但我實(shí)測(cè)下來(lái)單次請(qǐng)求返回上千條記錄時(shí)響應(yīng)體非常巨大解析XML容易超時(shí)或內(nèi)存溢出而且一旦中斷就得重新拉。更合理的做法是把max_results控制在20到100之間配合start做小步長(zhǎng)翻頁(yè)或者配合id_list做精確批量獲取。這既是對(duì)ArXiv服務(wù)器的尊重也是保證你自己程序穩(wěn)定性的必要手段。2.2 什么時(shí)候會(huì)觸發(fā)限流狀態(tài)碼與響應(yīng)頭很多人的困惑不是“不知道有3秒規(guī)則”而是“我明明遵守了3秒規(guī)則為什么還是被限”。實(shí)際情況是新政策下觸發(fā)限流的因素不止請(qǐng)求頻率這一個(gè)維度。常見的觸發(fā)條件我整理一下同一IP在很短時(shí)間內(nèi)建立了大量TCP連接即使每個(gè)連接只發(fā)一次請(qǐng)求也會(huì)被判定為異常行為。請(qǐng)求沒有攜帶合理的User-Agent。官方文檔明確要求請(qǐng)求中帶上能識(shí)別應(yīng)用的信息純python-requests或者空白UA的請(qǐng)求會(huì)被優(yōu)先懷疑為腳本。反復(fù)請(qǐng)求不存在的論文ID或者搜索語(yǔ)法錯(cuò)誤導(dǎo)致大量4xx響應(yīng)頻繁的錯(cuò)誤請(qǐng)求同樣會(huì)被計(jì)數(shù)。下載PDF全文頻繁訪問export.arxiv.org以外的資源地址arxiv.org/pdf/...這類路徑在網(wǎng)頁(yè)服務(wù)器層面的限流策略更嚴(yán)格。當(dāng)觸發(fā)限流時(shí)常見的表現(xiàn)有兩種一種是HTTP 403 Forbidden說(shuō)明你在訪問層面被拒絕了另一種是HTTP 429 Too Many Requests說(shuō)明頻率超限服務(wù)器希望你的客戶端慢一點(diǎn)。429響應(yīng)里通常還有Retry-After頭告訴你要等多少秒再試。我在自己代碼里會(huì)專門解析這個(gè)頭程序會(huì)自動(dòng)休眠到指定時(shí)間再繼續(xù)而不是傻傻地重試三次然后崩潰退出。2.3 狀態(tài)碼、重試策略與降級(jí)方案配合限流狀態(tài)處理的完整邏輯我的建議路線是收到200正常解析XML按需休眠后繼續(xù)下一批。 收到403停下來(lái)檢查是否IP被封鎖不要繼續(xù)盲目發(fā)請(qǐng)求至少要冷卻30分鐘以上。 收到429讀取Retry-After頭等待對(duì)應(yīng)秒數(shù)再重新嘗試當(dāng)前請(qǐng)求。 收到5xx說(shuō)明服務(wù)器或網(wǎng)絡(luò)有臨時(shí)問題可以做最多3次指數(shù)退避重試間隔分別設(shè)為3秒、9秒、27秒超過就放棄并記錄日志。這套策略看似簡(jiǎn)單實(shí)際能救很多人。因?yàn)榻^大多數(shù)爬蟲腳本只處理了“成功”和“異?！眱煞N狀態(tài)完全沒有針對(duì)限流狀態(tài)碼做精細(xì)化處理。我見過一個(gè)開源工具在ArXiv新政策上線后繼續(xù)用老邏輯瘋狂重試403請(qǐng)求結(jié)果每個(gè)請(qǐng)求都失敗白白把一個(gè)正常IP跑成了“高危目標(biāo)”。3. 合規(guī)調(diào)用ArXiv API實(shí)操指南3.1 第一步注冊(cè)賬號(hào)并申請(qǐng)API Key雖然ArXiv沒有強(qiáng)迫每個(gè)人必須用Key才能訪問API但從2024年更新后的官方說(shuō)明來(lái)看“認(rèn)證訪問”是明顯的主推方向。我自己是把API Key當(dāng)成必選項(xiàng)來(lái)配置的原因很簡(jiǎn)單帶Key的請(qǐng)求可以獲得更穩(wěn)定的速率表現(xiàn)而且萬(wàn)一IP被誤傷Key還能幫你跟管理員溝通申訴匿名IP基本沒什么辯解空間。注冊(cè)API Key的路徑不復(fù)雜先到arxiv.org注冊(cè)一個(gè)賬號(hào)然后在賬號(hào)設(shè)置或個(gè)人資料頁(yè)面找到API Key管理入口創(chuàng)建一個(gè)Key。創(chuàng)建時(shí)它會(huì)提示你填寫用途說(shuō)明其實(shí)就是一個(gè)告知機(jī)制寫清楚“論文元數(shù)據(jù)定期同步”之類就行。創(chuàng)建完成后會(huì)得到一串字符串類似一個(gè)長(zhǎng)長(zhǎng)的隨機(jī)碼。這個(gè)Key不是放在URL里傳的更合理的做法是放在請(qǐng)求頭里例如Authorization: Bearer your-api-key或者按官方要求以特定參數(shù)攜帶。實(shí)際以ArXiv官方文檔的請(qǐng)求示例為準(zhǔn)不同時(shí)期的推薦攜帶方式略有差異。不過要提醒一點(diǎn)Key是用來(lái)識(shí)別身份的不是用來(lái)買無(wú)限額度的。不要以為帶上Key就能無(wú)限刷官方依然會(huì)監(jiān)測(cè)請(qǐng)求頻率只是認(rèn)證用戶通常能享受到比匿名用戶更寬的閾值同時(shí)也有明確的問責(zé)依據(jù)。把Key泄露到公開倉(cāng)庫(kù)里跟你把數(shù)據(jù)庫(kù)密碼傳到GitHub是一樣的性質(zhì)輕則被人盜用導(dǎo)致你的IP被封重則被官方列入黑名單。3.2 第二步寫一個(gè)標(biāo)準(zhǔn)的Python請(qǐng)求模板我直接給一個(gè)自己長(zhǎng)期在用的Python請(qǐng)求模板按這個(gè)結(jié)構(gòu)來(lái)寫基本穩(wěn)不容易觸雷import time import urllib.parse import urllib.request BASE_URL https://export.arxiv.org/api/query def query_arxiv(search_query: str , start: int 0, max_results: int 20, paper_ids: list None, api_key: str ) - str: params { start: start, max_results: max_results, sortBy: submittedDate, sortOrder: descending, } if search_query: params[search_query] search_query if paper_ids: params[id_list] ,.join(paper_ids) url BASE_URL ? urllib.parse.urlencode(params) headers {User-Agent: my-paper-monitor/1.0 (contact: youexample.com)} if api_key: headers[Authorization] fBearer {api_key} req urllib.request.Request(url, headersheaders) with urllib.request.urlopen(req, timeout30) as resp: if resp.status 200: return resp.read().decode(utf-8) # 使用示例檢索最近提交的 transform er 相關(guān)論文 xml_text query_arxiv(search_queryall:transformer, start0, max_results20) time.sleep(3)這個(gè)模板里有幾個(gè)值得注意的細(xì)節(jié)。一是User-Agent一定要寫清楚最好包含聯(lián)系方式這樣出了問題官方或社區(qū)能聯(lián)系到你而不是把你看作匿名攻擊者。二是一定要設(shè)置timeout避免網(wǎng)絡(luò)異常時(shí)腳本卡死在那里既占用資源又影響后續(xù)任務(wù)。三是在特意的位置加time.sleep(3)不要在一個(gè)函數(shù)里把所有請(qǐng)求都發(fā)完再統(tǒng)一睡覺那種寫法容易在批量執(zhí)行時(shí)暴露出瞬時(shí)峰值。我用這套模板跑了三個(gè)多月每天定時(shí)拉取指定方向的論文元數(shù)據(jù)目前沒有觸發(fā)過一次403或429。相比之下我之前用第三方的arxiv.py庫(kù)如果不對(duì)其內(nèi)部邏輯做調(diào)整偶爾會(huì)在并發(fā)場(chǎng)景下出問題。不是說(shuō)第三方庫(kù)不好而是它們?yōu)榱思嫒莞鞣N場(chǎng)景默認(rèn)的請(qǐng)求策略不一定適合你的節(jié)奏還是親手控制請(qǐng)求間隔更安心。3.3 第三步批量獲取與分頁(yè)的正確姿勢(shì)如果你的需求是“我有500個(gè)論文ID想拿到它們對(duì)應(yīng)的元數(shù)據(jù)和摘要”那正確的打開方式是使用id_list參數(shù)分塊獲取而不是寫個(gè)循環(huán)去逐條請(qǐng)求。def fetch_by_ids(paper_ids: list[str], chunk_size: int 50, api_key: str ) - list[str]: results [] for i in range(0, len(paper_ids), chunk_size): chunk paper_ids[i:i chunk_size] xml_text query_arxiv(paper_idschunk, api_keyapi_key) if xml_text: results.append(xml_text) time.sleep(3) return results這里把chunk_size設(shè)為50是我測(cè)試下來(lái)比較舒服的值。單批50條記錄響應(yīng)體大小適中解析快即使網(wǎng)絡(luò)中斷重試成本也可控。官方允許更大的批但沒必要去碰上限穩(wěn)穩(wěn)地跑完比一次拉滿更實(shí)際。分頁(yè)場(chǎng)景則要特別注意start參數(shù)的語(yǔ)義。ArXiv API的分頁(yè)是全局游標(biāo)式的start0表示從第一條開始start20表示從第21條開始。如果你的查詢結(jié)果集在兩次請(qǐng)求之間發(fā)生了變化比如新的論文正好提交上來(lái)了翻頁(yè)時(shí)可能出現(xiàn)重復(fù)或遺漏。解決方法是盡量縮短分批時(shí)間或者干脆用時(shí)間窗口過濾比如只拉取最近7天的論文然后用submittedDate倒序排列每天跑一次增量同步。3.4 順帶解決“怎么訂閱ArXiv論文”這個(gè)需求很多人其實(shí)不需要API就想每天收到某個(gè)分類的新論文列表。ArXiv官方提供了郵件訂閱和RSS訂閱兩條路。登錄賬號(hào)后在訂閱設(shè)置里可以勾選分類比如cs.AI、cs.LG再設(shè)置推送頻率官方會(huì)用郵件把新增論文的標(biāo)題和摘要發(fā)給你。RSS訂閱更簡(jiǎn)單每個(gè)分類都有一個(gè)專屬RSS地址格式是https://rss.arxiv.org/rss/cs.AI任何支持RSS的閱讀器都能直接用。但如果你想做“自定義關(guān)鍵詞多分類自動(dòng)篩選”的高級(jí)訂閱官方郵件和普通RSS就有點(diǎn)不夠用。這時(shí)候用API自己搭一個(gè)最靈活定時(shí)拉取指定分類的最新論文解析出標(biāo)題和摘要用關(guān)鍵詞匹配篩選再通過郵件或消息機(jī)器人推送給自己。這個(gè)流程在技術(shù)上不復(fù)雜但要注意一個(gè)點(diǎn)定時(shí)任務(wù)的頻率不要超過每小時(shí)一次否則就繞回了“限制”問題。我自己的做法是每天固定早上8點(diǎn)跑一次配合睡眠3秒的間隔一天下來(lái)API開銷極小完全在禮貌范圍內(nèi)。4. 常見問題排查與避坑實(shí)錄4.1 403和429的排查路徑如果你已經(jīng)遇到了訪問失敗先冷靜判斷狀態(tài)碼。403意味著服務(wù)器拒絕了你的請(qǐng)求但不一定是因?yàn)轭l率。排查順序應(yīng)該是這樣的先確認(rèn)IP是否被平臺(tái)防火墻臨時(shí)封禁換個(gè)網(wǎng)絡(luò)試試再檢查請(qǐng)求格式是否有問題比如參數(shù)拼寫錯(cuò)誤、缺少必填參數(shù)、id_list傳了非法字符最后看請(qǐng)求頭里的UA是否合理。如果以上都沒問題那就只能推測(cè)是頻率限制措施是停掉所有任務(wù)冷卻30分鐘以上再重新嘗試。429的處理更明確看響應(yīng)里的Retry-After頭等夠時(shí)間再繼續(xù)。不要用暴力循環(huán)去對(duì)沖429那只會(huì)讓服務(wù)器覺得你“屢教不改”。另外429也經(jīng)常發(fā)生在你“以為自己在遵守3秒間隔”但實(shí)際上是多個(gè)腳本并發(fā)運(yùn)行的情況下。我排查過一個(gè)自己的任務(wù)明明主腳本休眠了3秒可服務(wù)器日志里顯示請(qǐng)求間隔不到1秒后來(lái)才發(fā)現(xiàn)是另一個(gè)歷史遺留腳本還在后臺(tái)跑兩個(gè)進(jìn)程疊加導(dǎo)致總請(qǐng)求數(shù)翻倍。所以做這類工具最好加一個(gè)進(jìn)程鎖確保同時(shí)只有一個(gè)任務(wù)在跑。4.2 大批量下載元數(shù)據(jù)或全文的正確通道如果你的需求已經(jīng)到了“全庫(kù)同步”或“某分類全部論文”的量級(jí)我不建議直接用API硬扛。ArXiv官方提供了批量數(shù)據(jù)文件地址在data.arxiv.org這里面有按月份分塊的元數(shù)據(jù)壓縮包也有全文PDF的批量下載通道。走這條路的好處是不受API速率限制約束適合做離線分析和本地索引構(gòu)建。使用批量數(shù)據(jù)文件需要注意兩個(gè)細(xì)節(jié)。第一這些壓縮包文件非常大動(dòng)輒幾個(gè)GB甚至更大下載前要確認(rèn)磁盤空間和網(wǎng)絡(luò)帶寬足夠最好用支持?jǐn)帱c(diǎn)續(xù)傳的下載工具。第二官方對(duì)批量下載同樣有要求通常需要你先閱讀并同意他們的數(shù)據(jù)使用條款并且“異常高頻的重復(fù)下載”仍然會(huì)被留意所以盡量規(guī)劃好一次到位別反反復(fù)復(fù)拉取同一個(gè)月的數(shù)據(jù)。如果真的需要“定期全量更新”我給的建議是首次用批量文件做全量初始化后續(xù)用API按時(shí)間增量同步。比如每天都用submittedDate:[昨天到今天的日期]去查詢新增論文每次拉幾十條這個(gè)量級(jí)的增量任務(wù)完全不會(huì)觸碰限流紅線。既輕量又及時(shí)是比反復(fù)下載大文件更聰明的方案。4.3 幾個(gè)容易忽視的細(xì)節(jié)UA、解析與增量更新第一User-Agent容易被忽視但相當(dāng)重要。我看到不少人喜歡直接用請(qǐng)求庫(kù)的默認(rèn)UA問題在于同一款庫(kù)的默認(rèn)UA全球幾十萬(wàn)人在用服務(wù)器很難對(duì)這種流量做區(qū)分。最好改成“項(xiàng)目名/版本聯(lián)系方式”的格式既展示了身份也方便維護(hù)者定位問題。如果你用Python的urllib默認(rèn)UA是Python-urllib/3.x這個(gè)在ArXiv的日志里看起來(lái)就像“批量腳本”建議手動(dòng)改成有辨識(shí)度的字符。第二解析API返回的Atom XML時(shí)注意命名空間。ArXiv返回的不是普通XML而是帶xmlns命名空間的Atom格式。用xml.etree.ElementTree直接按標(biāo)簽名查找可能找不到節(jié)點(diǎn)必須先處理命名空間或者用feedparser這個(gè)庫(kù)來(lái)解析。我最初用簡(jiǎn)化的XPath去取title取出來(lái)全是空值排查了半天才發(fā)現(xiàn)是命名空間前綴的問題。用feedparser處理ArXiv響應(yīng)體可以說(shuō)是一勞永逸它把標(biāo)題、作者、摘要、ID、發(fā)布時(shí)間都給整理好了。第三增量更新一定要做去重。ArXiv上的論文狀態(tài)偶爾會(huì)變動(dòng)比如作者修改標(biāo)題、撤回再發(fā)如果你按時(shí)間窗口增量拉取同一篇論文可能出現(xiàn)在兩個(gè)批次里。穩(wěn)妥的做法是在本地存一個(gè)論文ID集合每次入庫(kù)前先去重。不要用標(biāo)題去重因?yàn)闃?biāo)題可能被修改用ArXiv的絕對(duì)ID就是URL末尾那個(gè)數(shù)字串最可靠。另外還有個(gè)防封小技巧如果你的程序要長(zhǎng)時(shí)間運(yùn)行建議把每天的總請(qǐng)求數(shù)控制在一個(gè)低價(jià)范圍內(nèi)比如幾百次以內(nèi)并且均勻分布在一天中不要密集扎堆在半小時(shí)內(nèi)完成。這比偶爾集中跑一次要安全得多。我做論文監(jiān)控時(shí)就把任務(wù)固定為每30分鐘一次小請(qǐng)求一天48次服務(wù)器根本不會(huì)對(duì)你有任何特殊關(guān)注。4.4 一點(diǎn)個(gè)人體會(huì)ArXiv這次更新限流政策初看是給開發(fā)者添堵實(shí)際是在給整個(gè)開源學(xué)術(shù)生態(tài)續(xù)命。免費(fèi)資源永遠(yuǎn)經(jīng)不起無(wú)底線的消耗主動(dòng)幫官方分擔(dān)流量壓力長(zhǎng)期來(lái)看對(duì)自己的工具穩(wěn)定性也有好處。我現(xiàn)在的處理方式是能走批量數(shù)據(jù)文件就走批量文件能走API Key認(rèn)證就走認(rèn)證能用id_list合并請(qǐng)求就不會(huì)逐條刷每發(fā)一個(gè)請(qǐng)求前都默認(rèn)“服務(wù)器不是只為你一個(gè)人服務(wù)”。這套思路堅(jiān)持下來(lái)至少我的工具這半年沒有因?yàn)橄蘖鲾喔^。如果你的項(xiàng)目正好受這次更新影響不妨先從加API Key和請(qǐng)求間隔這兩個(gè)小改動(dòng)入手大多數(shù)情況下問題都能迎刃而解。