1. 從一張日榜截圖說起我為什么要做這個(gè)趨勢(shì)追蹤項(xiàng)目每天刷技術(shù)社區(qū)的時(shí)候我都有個(gè)習(xí)慣——先看當(dāng)天熱榜上冒出來的新項(xiàng)目。這個(gè)習(xí)慣堅(jiān)持了快三年起因很簡(jiǎn)單吃過信息滯后的虧。早些年我做過一個(gè)內(nèi)部工具功能做完才發(fā)現(xiàn)社區(qū)里已經(jīng)有人開源了幾乎一模一樣的東西而且完成度比我高得多。那種感覺就像你辛辛苦苦手搓了一個(gè)輪子結(jié)果發(fā)現(xiàn)隔壁車庫(kù)里停著一輛現(xiàn)成的整車。后來我就開始系統(tǒng)性地追蹤熱榜數(shù)據(jù)最初只是手動(dòng)截圖、記筆記后來慢慢演變成一套自動(dòng)化的采集和分析流程。這個(gè)項(xiàng)目就是這套流程的沉淀——每天抓取一次熱榜日榜數(shù)據(jù)做結(jié)構(gòu)化存儲(chǔ)再?gòu)闹泻Y選出值得深挖的項(xiàng)目做二次分析。它解決的問題很具體把“今天有什么新東西”這件事從隨機(jī)刷到變成可回溯、可對(duì)比、可沉淀的固定動(dòng)作。適合誰(shuí)來參考如果你是獨(dú)立開發(fā)者、技術(shù)選型負(fù)責(zé)人、或者單純想保持技術(shù)敏感度的從業(yè)者這套思路都能直接拿去用。它不依賴任何特定平臺(tái)的高級(jí)權(quán)限核心邏輯就是“定時(shí)抓取 結(jié)構(gòu)化落庫(kù) 人工篩選”門檻低到一臺(tái)能跑腳本的機(jī)器就夠。下面我把整個(gè)項(xiàng)目的設(shè)計(jì)思路、實(shí)現(xiàn)細(xì)節(jié)、踩過的坑以及我實(shí)際用下來覺得最有價(jià)值的幾個(gè)環(huán)節(jié)完整拆一遍。2. 項(xiàng)目整體設(shè)計(jì)與思路拆解2.1 為什么選擇“日榜”而不是“周榜”或“月榜”熱榜的周期選擇直接決定了你能捕捉到什么類型的信息。周榜和月榜反映的是“持續(xù)熱度”適合判斷一個(gè)項(xiàng)目的長(zhǎng)期價(jià)值而日榜反映的是“瞬時(shí)脈沖”適合捕捉新冒頭的項(xiàng)目。我最初只做周榜后來發(fā)現(xiàn)一個(gè)問題很多項(xiàng)目在周榜上出現(xiàn)的時(shí)候已經(jīng)積累了幾千顆星等你再去研究窗口期已經(jīng)過了。日榜的價(jià)值在于時(shí)間差。一個(gè)項(xiàng)目從零到上榜通常只需要一兩天。如果你能在它剛冒頭的時(shí)候就注意到無(wú)論是學(xué)習(xí)它的實(shí)現(xiàn)思路還是判斷它是否值得投入時(shí)間跟進(jìn)都比等到它成為“眾所周知”的項(xiàng)目要主動(dòng)得多。當(dāng)然日榜的噪音也大很多項(xiàng)目只是曇花一現(xiàn)所以我的做法是日榜負(fù)責(zé)發(fā)現(xiàn)周榜負(fù)責(zé)驗(yàn)證。兩個(gè)數(shù)據(jù)源配合使用效果比單看任何一個(gè)都好。2.2 數(shù)據(jù)采集方案為什么不用現(xiàn)成的API很多人第一反應(yīng)是找官方API但我實(shí)測(cè)下來發(fā)現(xiàn)幾個(gè)問題。第一官方API通常有頻率限制日榜數(shù)據(jù)每天只需要抓一次但如果你想補(bǔ)歷史數(shù)據(jù)限制就會(huì)很麻煩。第二API返回的字段往往比頁(yè)面展示的少比如項(xiàng)目的描述、語(yǔ)言標(biāo)簽、當(dāng)日新增星數(shù)這些API里不一定都有。第三也是最關(guān)鍵的——API的穩(wěn)定性不受你控制一旦接口調(diào)整你的整個(gè)流程就斷了。所以我最終選擇的是頁(yè)面解析方案。具體做法是用一個(gè)無(wú)頭瀏覽器加載熱榜頁(yè)面等待內(nèi)容渲染完成后提取DOM節(jié)點(diǎn)再按字段解析成結(jié)構(gòu)化數(shù)據(jù)。這個(gè)方案的好處是所見即所得頁(yè)面上有什么你就能拿到什么壞處是需要處理反爬和頁(yè)面結(jié)構(gòu)變化。為了降低維護(hù)成本我把解析邏輯做成了配置化的——字段用CSS選擇器定義頁(yè)面結(jié)構(gòu)變了只需要改配置不用動(dòng)核心代碼。2.3 存儲(chǔ)設(shè)計(jì)為什么用SQLite而不是CSV一開始我用CSV存數(shù)據(jù)簡(jiǎn)單直接Excel打開就能看。但用了兩個(gè)月就發(fā)現(xiàn)問題了CSV沒有索引查詢效率低字段里如果有逗號(hào)或換行解析就會(huì)出錯(cuò)而且多天數(shù)據(jù)合并分析的時(shí)候要寫一堆腳本去拼接。后來?yè)Q成了SQLite理由很充分。第一它是單文件數(shù)據(jù)庫(kù)不需要額外部署服務(wù)拷貝走就能用。第二支持SQL查詢想按語(yǔ)言篩選、按星數(shù)排序、按日期聚合一句SQL就搞定。第三Python標(biāo)準(zhǔn)庫(kù)自帶sqlite3模塊零依賴。對(duì)于這種單機(jī)、低頻、結(jié)構(gòu)化的數(shù)據(jù)場(chǎng)景SQLite幾乎是最優(yōu)解。表結(jié)構(gòu)我設(shè)計(jì)得很簡(jiǎn)單一張主表存每日快照字段包括日期、項(xiàng)目名、描述、語(yǔ)言、總星數(shù)、當(dāng)日新增星數(shù)、鏈接。主鍵用“日期項(xiàng)目名”的組合避免同一天重復(fù)插入。2.4 篩選策略如何從幾十個(gè)項(xiàng)目里挑出值得看的日榜每天大概有二十到三十個(gè)項(xiàng)目全部細(xì)看是不現(xiàn)實(shí)的。我設(shè)計(jì)了一個(gè)三層篩選漏斗。第一層是硬性過濾排除掉那些明顯是營(yíng)銷性質(zhì)的項(xiàng)目、描述里全是關(guān)鍵詞堆砌的、以及語(yǔ)言標(biāo)簽為空的。第二層是信號(hào)加權(quán)當(dāng)日新增星數(shù)超過某個(gè)閾值的、描述里包含特定技術(shù)關(guān)鍵詞的、以及我關(guān)注的語(yǔ)言生態(tài)里的項(xiàng)目會(huì)獲得更高權(quán)重。第三層是人工復(fù)核經(jīng)過前兩層篩選后通常只剩下五到八個(gè)項(xiàng)目我再逐個(gè)點(diǎn)進(jìn)去看README和issue區(qū)判斷是否值得深入。這個(gè)漏斗的關(guān)鍵在于第二層的權(quán)重配置。我把它做成了一個(gè)獨(dú)立的配置文件閾值和關(guān)鍵詞都可以隨時(shí)調(diào)整。比如最近我在關(guān)注邊緣計(jì)算相關(guān)的項(xiàng)目就把相關(guān)關(guān)鍵詞加進(jìn)去權(quán)重調(diào)高。這樣整個(gè)篩選流程是跟著我的關(guān)注方向走的而不是固定死的。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 頁(yè)面解析的關(guān)鍵等待策略與選擇器穩(wěn)定性頁(yè)面解析最容易出問題的地方是時(shí)機(jī)。熱榜頁(yè)面通常是動(dòng)態(tài)渲染的如果你在內(nèi)容加載完成之前就去提取DOM拿到的就是空節(jié)點(diǎn)。我的做法是設(shè)置一個(gè)顯式等待條件——不是簡(jiǎn)單地等固定秒數(shù)而是等待某個(gè)特定元素出現(xiàn)。比如等待項(xiàng)目列表的容器節(jié)點(diǎn)存在并且其子節(jié)點(diǎn)數(shù)量大于零。這樣即使網(wǎng)絡(luò)慢一點(diǎn)也能保證拿到完整數(shù)據(jù)。選擇器的穩(wěn)定性是另一個(gè)坑。很多頁(yè)面的class名是帶哈希的比如classitem-abc123這種選擇器今天能用明天就失效。我的經(jīng)驗(yàn)是優(yōu)先用語(yǔ)義化的屬性比如>pip install requests beautifulsoup4 lxml playwright playwright install chromium這里有個(gè)細(xì)節(jié)playwright install chromium會(huì)下載一個(gè)Chromium瀏覽器大概一百多兆。如果你在服務(wù)器上跑確保磁盤空間足夠。另外有些精簡(jiǎn)版的操作系統(tǒng)缺少Chromium運(yùn)行所需的系統(tǒng)庫(kù)需要額外安裝。我在一臺(tái)最小化安裝的服務(wù)器上就遇到過這個(gè)問題報(bào)錯(cuò)信息是缺少libnss3等庫(kù)后來用系統(tǒng)包管理器補(bǔ)裝才解決。4.2 抓取腳本的核心邏輯抓取腳本的主流程分四步啟動(dòng)瀏覽器、加載頁(yè)面、等待內(nèi)容、提取數(shù)據(jù)。我用的是異步API因?yàn)閜laywright的同步API在某些環(huán)境下會(huì)有兼容性問題。核心代碼如下from playwright.async_api import async_playwright import asyncio import json async def fetch_trending(date_str): async with async_playwright() as p: browser await p.chromium.launch(headlessTrue) page await browser.new_page() url fhttps://example.com/trending?date{date_str} await page.goto(url, wait_untilnetworkidle) await page.wait_for_selector(.repo-list-item, timeout30000) items await page.query_selector_all(.repo-list-item) results [] for item in items: name await item.query_selector(.repo-name) desc await item.query_selector(.repo-desc) lang await item.query_selector(.repo-lang) stars await item.query_selector(.repo-stars) results.append({ name: await name.inner_text() if name else , desc: await desc.inner_text() if desc else , lang: await lang.inner_text() if lang else , stars: await stars.inner_text() if stars else 0 }) await browser.close() return results這段代碼里有幾個(gè)關(guān)鍵點(diǎn)。wait_untilnetworkidle表示等待網(wǎng)絡(luò)請(qǐng)求基本停止后再繼續(xù)這比單純等load事件更可靠。wait_for_selector設(shè)置了30秒超時(shí)避免頁(yè)面加載失敗時(shí)無(wú)限等待。提取字段時(shí)都做了空值判斷因?yàn)椴皇敲總€(gè)項(xiàng)目都有描述或語(yǔ)言標(biāo)簽。4.3 數(shù)據(jù)入庫(kù)與去重入庫(kù)邏輯我單獨(dú)寫了一個(gè)模塊核心是“先查后插”。對(duì)于每一條抓取到的數(shù)據(jù)先根據(jù)日期和項(xiàng)目名查詢是否已存在如果存在就跳過不存在就插入。SQLite的INSERT OR IGNORE語(yǔ)句可以一步完成這個(gè)邏輯但前提是表上要有唯一約束。我的表結(jié)構(gòu)定義如下CREATE TABLE IF NOT EXISTS trending ( date TEXT NOT NULL, name TEXT NOT NULL, description TEXT, language TEXT, total_stars INTEGER, today_stars INTEGER, url TEXT, PRIMARY KEY (date, name) );主鍵是(date, name)的組合這樣同一天同一個(gè)項(xiàng)目只會(huì)存一條。插入時(shí)用INSERT OR IGNORE INTO trending VALUES (...)如果主鍵沖突就自動(dòng)忽略。這個(gè)設(shè)計(jì)的好處是冪等性——不管你把同一天的數(shù)據(jù)抓多少遍入庫(kù)結(jié)果都是一樣的。4.4 篩選與報(bào)告生成數(shù)據(jù)入庫(kù)后下一步是生成每日?qǐng)?bào)告。報(bào)告的邏輯是從當(dāng)天數(shù)據(jù)中篩選出符合條件的項(xiàng)目按當(dāng)日新增星數(shù)降序排列取前若干條輸出成Markdown格式。篩選條件我放在一個(gè)獨(dú)立的配置文件里格式是JSON方便修改。比如{ min_today_stars: 50, exclude_languages: [HTML, CSS], priority_keywords: [edge, wasm, rust, llm], max_results: 10 }篩選邏輯會(huì)先過濾掉當(dāng)日新增星數(shù)低于閾值的項(xiàng)目再排除掉指定語(yǔ)言的項(xiàng)目然后給包含優(yōu)先關(guān)鍵詞的項(xiàng)目加權(quán)最后按權(quán)重和星數(shù)綜合排序。生成的報(bào)告會(huì)包含項(xiàng)目名、描述、語(yǔ)言、當(dāng)日新增星數(shù)、總星數(shù)、鏈接以及一段我手動(dòng)補(bǔ)充的點(diǎn)評(píng)。這個(gè)點(diǎn)評(píng)是人工寫的因?yàn)闄C(jī)器篩選只能告訴你“什么在漲”不能告訴你“為什么值得看”。4.5 定時(shí)調(diào)度配置定時(shí)任務(wù)我用的是系統(tǒng)自帶的調(diào)度工具。在Linux環(huán)境下編輯crontab文件加一行0 9 * * * /usr/bin/python3 /path/to/fetch_and_report.py /path/to/log/cron.log 21這行配置的意思是每天早上9點(diǎn)執(zhí)行一次腳本標(biāo)準(zhǔn)輸出和錯(cuò)誤輸出都追加到日志文件。這里有個(gè)坑crontab的環(huán)境變量和你在終端里的環(huán)境變量不一樣PATH可能不包含Python的安裝路徑。所以腳本里最好用絕對(duì)路徑或者在crontab里顯式設(shè)置PATH。我一開始就因?yàn)檫@個(gè)原因任務(wù)一直不執(zhí)行排查了半天才發(fā)現(xiàn)是路徑問題。5. 常見問題與排查技巧實(shí)錄5.1 抓取失敗頁(yè)面加載超時(shí)怎么辦這是最常見的問題表現(xiàn)是腳本報(bào)TimeoutError提示等待選擇器超時(shí)。原因通常有三種網(wǎng)絡(luò)問題、頁(yè)面改版、反爬機(jī)制。排查順序是先手動(dòng)打開頁(yè)面看是否能正常訪問如果打不開就是網(wǎng)絡(luò)問題如果能打開但腳本抓不到就用瀏覽器的開發(fā)者工具檢查選擇器是否還有效如果選擇器有效但腳本仍然超時(shí)可能是反爬機(jī)制在起作用比如檢測(cè)到了無(wú)頭瀏覽器的特征。針對(duì)反爬我的應(yīng)對(duì)策略是降低抓取頻率和模擬真實(shí)瀏覽器特征。日榜數(shù)據(jù)一天只需要抓一次頻率本身就很低所以主要是在瀏覽器特征上下功夫。playwright可以設(shè)置user_agent和viewport還可以通過add_init_script注入腳本修改一些瀏覽器指紋。不過說實(shí)話對(duì)于這種公開的熱榜數(shù)據(jù)反爬通常不會(huì)太嚴(yán)格大部分情況下頁(yè)面改版才是罪魁禍?zhǔn)住?.2 數(shù)據(jù)異常星數(shù)突然變成負(fù)數(shù)或零有一次我發(fā)現(xiàn)某天的數(shù)據(jù)里好幾個(gè)項(xiàng)目的當(dāng)日新增星數(shù)是負(fù)數(shù)。這顯然不合理星數(shù)只會(huì)增加不會(huì)減少。排查后發(fā)現(xiàn)是解析邏輯的問題頁(yè)面上有些項(xiàng)目的星數(shù)顯示格式是“123”我的解析函數(shù)沒有處理前面的加號(hào)導(dǎo)致轉(zhuǎn)換失敗默認(rèn)返回了零或負(fù)數(shù)。修復(fù)方法很簡(jiǎn)單在解析前先去掉所有非數(shù)字字符只保留數(shù)字和負(fù)號(hào)然后再轉(zhuǎn)換。提示所有從頁(yè)面提取的數(shù)字字段在轉(zhuǎn)換前都要做一次“清洗”去掉單位、符號(hào)、空格等干擾字符。這個(gè)步驟看起來不起眼但能避免很多莫名其妙的bug。5.3 入庫(kù)沖突同一天同一個(gè)項(xiàng)目出現(xiàn)兩次這個(gè)問題通常是因?yàn)轫?xiàng)目改名或者頁(yè)面展示邏輯變化導(dǎo)致的。比如一個(gè)項(xiàng)目從“foo”改名為“foo-labs”在頁(yè)面上會(huì)顯示為新項(xiàng)目但實(shí)際上是同一個(gè)。我的處理方式是用項(xiàng)目鏈接作為輔助去重依據(jù)。如果兩個(gè)項(xiàng)目的鏈接相同就認(rèn)為是同一個(gè)項(xiàng)目只保留最新的一條。鏈接的穩(wěn)定性比項(xiàng)目名高得多因?yàn)楦拿粫?huì)改鏈接。5.4 報(bào)告生成失敗編碼問題生成Markdown報(bào)告的時(shí)候如果項(xiàng)目描述里包含特殊字符比如中文、emoji、數(shù)學(xué)符號(hào)寫入文件時(shí)可能會(huì)報(bào)編碼錯(cuò)誤。解決方案是在打開文件時(shí)顯式指定encodingutf-8。這個(gè)問題在Windows環(huán)境下尤其常見因?yàn)閃indows的默認(rèn)編碼不是UTF-8。我現(xiàn)在的做法是所有文件讀寫都顯式指定UTF-8不管在什么平臺(tái)上跑行為都一致。5.5 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案腳本超時(shí)網(wǎng)絡(luò)問題或頁(yè)面改版手動(dòng)訪問頁(yè)面檢查選擇器調(diào)整等待策略或更新選擇器星數(shù)為負(fù)解析邏輯未處理符號(hào)檢查原始數(shù)據(jù)格式清洗數(shù)字字段后再轉(zhuǎn)換數(shù)據(jù)重復(fù)項(xiàng)目改名或頁(yè)面邏輯變化對(duì)比項(xiàng)目鏈接用鏈接作為去重依據(jù)編碼錯(cuò)誤文件讀寫未指定編碼檢查報(bào)錯(cuò)信息顯式指定UTF-8定時(shí)任務(wù)不執(zhí)行環(huán)境變量或路徑問題查看cron日志使用絕對(duì)路徑或設(shè)置PATH6. 我實(shí)際用下來覺得最有價(jià)值的幾個(gè)環(huán)節(jié)6.1 歷史數(shù)據(jù)的回溯分析單看一天的日榜信息量有限。但如果你積累了幾個(gè)月的數(shù)據(jù)就能做很多有意思的分析。比如我可以查“過去三個(gè)月里哪些項(xiàng)目連續(xù)上榜超過一周”這類項(xiàng)目通常是有真實(shí)需求的而不是曇花一現(xiàn)的營(yíng)銷項(xiàng)目。我還可以查“某個(gè)語(yǔ)言生態(tài)下最近一個(gè)月新增星數(shù)最多的項(xiàng)目”這能幫我判斷這個(gè)生態(tài)的活躍方向。這些分析用SQL就能完成不需要額外的工具。6.2 關(guān)鍵詞趨勢(shì)的觀察我在篩選配置里維護(hù)了一個(gè)關(guān)鍵詞列表每次生成報(bào)告的時(shí)候會(huì)統(tǒng)計(jì)當(dāng)天上榜項(xiàng)目中包含各個(gè)關(guān)鍵詞的數(shù)量。時(shí)間長(zhǎng)了就能看出趨勢(shì)——比如某個(gè)技術(shù)關(guān)鍵詞從偶爾出現(xiàn)變成頻繁出現(xiàn)說明這個(gè)方向正在升溫。這個(gè)信號(hào)比單看某個(gè)具體項(xiàng)目更有價(jià)值因?yàn)樗从车氖侨后w性的關(guān)注轉(zhuǎn)移。6.3 人工點(diǎn)評(píng)的沉淀機(jī)器篩選只能告訴你“什么在漲”但“為什么漲”需要人工判斷。我每天花十分鐘左右對(duì)篩選出來的項(xiàng)目寫一兩句點(diǎn)評(píng)記錄在報(bào)告里。這些點(diǎn)評(píng)積累下來就成了我自己的技術(shù)觀察筆記。過幾個(gè)月回頭看能清晰地看到自己的關(guān)注點(diǎn)是怎么變化的也能驗(yàn)證當(dāng)時(shí)的判斷是否準(zhǔn)確。這個(gè)習(xí)慣帶來的長(zhǎng)期價(jià)值遠(yuǎn)超項(xiàng)目本身的代碼量。6.4 一個(gè)容易被忽略的細(xì)節(jié)時(shí)區(qū)問題熱榜的“日榜”是按哪個(gè)時(shí)區(qū)算的這個(gè)問題我一開始沒注意后來發(fā)現(xiàn)不同日期抓到的數(shù)據(jù)有重疊才意識(shí)到時(shí)區(qū)的影響。我的做法是統(tǒng)一用UTC時(shí)間做日期標(biāo)識(shí)抓取的時(shí)候把本地時(shí)間轉(zhuǎn)換成UTC入庫(kù)和查詢都用UTC。這樣不管服務(wù)器在哪個(gè)時(shí)區(qū)數(shù)據(jù)都是一致的。如果你只是自己看用本地時(shí)間也無(wú)所謂但如果你想做跨天的對(duì)比分析時(shí)區(qū)不統(tǒng)一就會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)位。6.5 關(guān)于項(xiàng)目維護(hù)的一點(diǎn)體會(huì)這個(gè)項(xiàng)目代碼量不大核心邏輯加起來也就幾百行但它已經(jīng)穩(wěn)定運(yùn)行了很長(zhǎng)時(shí)間。我覺得關(guān)鍵在于把變化的部分和不變的部分分開。抓取邏輯、解析規(guī)則、篩選條件、報(bào)告模板這些都是可能變化的所以我把它們做成了配置或獨(dú)立模塊。而數(shù)據(jù)存儲(chǔ)、去重邏輯、定時(shí)調(diào)度這些相對(duì)穩(wěn)定的部分就保持簡(jiǎn)單直接。這樣每次需要調(diào)整的時(shí)候只需要改配置或改一個(gè)模塊不會(huì)影響到整體流程。另外日志真的很重要。我一開始覺得日志麻煩出了問題全靠猜。后來加了詳細(xì)的日志每次任務(wù)執(zhí)行都記錄關(guān)鍵信息排查問題的時(shí)間從半小時(shí)縮短到幾分鐘?，F(xiàn)在我的原則是寧可多打日志不要少打日志。日志文件定期清理就行存儲(chǔ)成本幾乎可以忽略。最后分享一個(gè)小技巧如果你也想做類似的數(shù)據(jù)追蹤項(xiàng)目不要一開始就追求大而全。先跑通最小閉環(huán)——抓一天的數(shù)據(jù)存下來能查詢就夠了。然后再慢慢加篩選、加報(bào)告、加定時(shí)。我見過太多人一上來就設(shè)計(jì)復(fù)雜的架構(gòu)結(jié)果還沒跑起來就放棄了。這個(gè)項(xiàng)目的價(jià)值不在于代碼多優(yōu)雅而在于它每天都在跑每天都在積累數(shù)據(jù)。數(shù)據(jù)本身才是最有價(jià)值的部分。