React開發(fā)者有個共同的噩夢：用戶刷新頁面，篩選條件全丟。有人選擇localStorage，有人上Redux Persist，但Pierre de Poulpiquet走了條更野的路——他把URL本身變成了狀態(tài)容器。

state-in-url這個庫只有7KB，卻能讓URL像useState一樣工作。刷新不丟、分享即同步、還能直接塞進(jìn)瀏覽器歷史棧。

聽起來像魔法？原理其實粗暴得很。Pierre發(fā)現(xiàn)URL的query string（查詢字符串）是個被嚴(yán)重低估的存儲空間：它天然持久、自帶序列化、用戶還能直接編輯。唯一的問題是React生態(tài)里沒人把它當(dāng)成一等公民。

從"這需求做不了"到"地址欄就是數(shù)據(jù)庫"

故事始于2023年初。Pierre當(dāng)時在做一個數(shù)據(jù)儀表盤，產(chǎn)品經(jīng)理提了個"簡單"需求：篩選條件要能分享鏈接。他算了算工作量：改路由、加序列化、處理嵌套對象、兼容舊鏈接……至少兩天。

「我當(dāng)時就想，為什么URL不能像state一樣用？」Pierre在博客回憶，「每次setState的時候自動同步到地址欄，讀取的時候自動解析回來，這不應(yīng)該是框架該干的事嗎？」

他調(diào)研了一圈。Next.js的useSearchParams只能存字符串，要自己手寫JSON序列化。React Router的search params API更底層，處理數(shù)組和對象時代碼量爆炸。一些第三方庫要么體積太大，要么類型支持稀爛。

最離譜的是，很多團(tuán)隊的解決方案是：把狀態(tài)存進(jìn)localStorage，URL只放一個token。用戶分享鏈接？對不起，對方看不到你的篩選條件。

Pierre的解法是把雙向綁定做到極致。他設(shè)計了一個useUrlState鉤子，用法和useState幾乎一模一樣：

const [filters, setFilters] = useUrlState('filters', defaultValue);

背后干了三件事：寫入時自動把對象壓縮成URL-safe的字符串，讀取時反向解析，還能處理深度合并防止舊鏈接崩潰。整個序列化層用了superjson，支持Date、Map、Set這些JSON搞不定的類型。

7KB的體積，怎么做到的？

體積控制是Pierre的執(zhí)念。他拒絕引入zod做運行時校驗——「類型安全交給TypeScript編譯時，運行時少一層開銷」。壓縮算法選了lz-string而不是gzip，因為瀏覽器原生支持，不需要wasm。

關(guān)鍵取舍在功能邊界。state-in-url不做路由管理，不碰history API的pushState/replaceState細(xì)節(jié)，只專注query string的讀寫。這意味著它和任何路由方案都能共存：Next.js、Remix、甚至純React Router。

「很多人問我為什么不支持hash路由」，Pierre說，「但2024年了，還有誰在用hash模式？我不為1%的場景讓99%的人多掏字節(jié)?！?/p>

這種克制帶來了意外收益。庫的核心邏輯不到200行，測試覆蓋率卻拉到97%。Pierre在CI里加了size-limit，每次PR如果體積增長超過100字節(jié)就自動阻斷。

GitHub上的star曲線很說明問題：發(fā)布前三個月只有零星關(guān)注，直到有人用它做了個"URL即配置"的代碼沙盒，一周漲了800星。

生產(chǎn)環(huán)境的真實戰(zhàn)績

最硬核的測試來自Pierre自己的項目。一個金融數(shù)據(jù)平臺，篩選條件包含20多個維度，包括日期范圍、多選標(biāo)簽、排序方式。之前用Redux + persistence，代碼量1200行，還有三個邊緣case處理不干凈。

遷移到state-in-url后，狀態(tài)管理代碼壓縮到80行。更關(guān)鍵的是，用戶開始自發(fā)分享帶參數(shù)的鏈接——以前他們得截圖圈選條件，現(xiàn)在直接復(fù)制地址欄。

有個細(xì)節(jié)Pierre沒料到：SEO團(tuán)隊跑來感謝他。因為篩選條件進(jìn)了URL，爬蟲能抓到更多長尾組合，索引量漲了40%。

當(dāng)然有限制。URL長度有天花板，Chrome大概能扛8000字符，但超過2000字符就開始影響可讀性。Pierre的建議是：把高頻篩選放URL，復(fù)雜配置扔給服務(wù)器生成短鏈。state-in-url留了hook，可以自定義序列化策略。

「也有人吐槽query string太丑」，Pierre承認(rèn)，「但比起功能可用性，美觀是廉價需求。況且用戶根本不會盯著地址欄看。」

生態(tài)位上的微妙博弈

state-in-url不是第一個做這件事的。2022年的next-usequerystate、更早的nuqs都是同類方案。Pierre的差異化在于極簡主義：nuqs支持Next.js的App Router和Pages Router雙模式，代碼復(fù)雜度翻倍；next-usequerystate綁定Zod，體積多15KB。

「我選擇只服務(wù)React 18+，只支持現(xiàn)代瀏覽器」，Pierre說，「這不是傲慢，是算過賬的。我的目標(biāo)用戶是愿意為了體驗犧牲兼容性的團(tuán)隊，他們通常也是付費意愿最強(qiáng)的?！?/p>

這個判斷似乎對了。庫發(fā)布一年后，被三家YC公司采用，其中一家做了定制付費支持。Pierre現(xiàn)在每周花5小時維護(hù)，收入剛好覆蓋服務(wù)器成本——「不指望發(fā)財，但證明這條路能走通」。

最近他在實驗一個激進(jìn)功能：把URL狀態(tài)和服務(wù)端實時同步。思路是用BroadcastChannel API，讓同一個URL在多個標(biāo)簽頁之間自動保持一致。草稿代碼已經(jīng)推到dev分支，但Pierre很謹(jǐn)慎——「這可能會打破用戶對URL的直覺，需要更多真實場景驗證」。

GitHub上有個issue開了四個月沒人回：用戶問能不能支持React Native。Pierre的回復(fù)很直接：「URL是瀏覽器概念，移動端用Deep Link有完全不同的心智模型。這個庫不會跨平臺，專注本身就是功能。」

如果你現(xiàn)在打開state-in-url的文檔首頁，會看到一行加粗的警告：「本庫假設(shè)你相信URL應(yīng)該暴露應(yīng)用狀態(tài)」。Pierre說這是唯一的準(zhǔn)入門檻——比技術(shù)約束更硬的，是產(chǎn)品哲學(xué)的對齊。

你的項目里，有多少狀態(tài)其實本該住在地址欄里？