1. 從一次線上故障說起為什么GET請求會“丟”數(shù)據(jù)去年我負責的一個用戶中心服務出了個挺有意思的線上問題。前端同學在修改用戶昵稱時為了圖方便直接用了GET請求把新的昵稱拼在URL后面類似/api/user/updateNickname?nickname新名字。上線后風平浪靜直到有一天一個運營同學反饋他給一個VIP用戶設置的包含特殊符號和長文本的昵稱提交后總是失敗但用短一點的英文名就沒事。排查過程一波三折。一開始懷疑是后端字符編碼問題又或者是接口限流查了半天日志和代碼都沒發(fā)現(xiàn)異常。最后還是運維同學在Nginx的訪問日志里發(fā)現(xiàn)了端倪那條失敗的請求其URL長度在日志里被截斷了后面的參數(shù)根本沒傳到后端應用。這才恍然大悟問題出在GET請求本身某些代理服務器或瀏覽器對URL長度有隱性的限制超長的參數(shù)會被直接截斷或丟棄。而POST請求的請求體Body則沒有這個硬性限制。這個看似簡單的“GET和POST區(qū)別”問題實際上牽扯出的是HTTP協(xié)議設計哲學、瀏覽器實現(xiàn)、服務器配置以及安全規(guī)范等一系列深層知識。很多人包括一些工作幾年的開發(fā)者對它們的理解可能還停留在“GET取數(shù)據(jù)POST改數(shù)據(jù)”的層面。今天我們就拋開那些教科書式的簡單對比從一個一線開發(fā)者的視角深入聊聊GET和POST那些你必須知道的、真正影響編碼和設計的區(qū)別。2. 協(xié)議層面的本質(zhì)差異語義、冪等性與安全性要真正理解GET和POST必須回到HTTP/1.1協(xié)議規(guī)范RFC 7231的定義。這不是死記硬背概念而是理解后續(xù)所有衍生現(xiàn)象和最佳實踐的基石。2.1 核心語義你究竟想干什么HTTP方法Method的核心是表達意圖而不僅僅是技術實現(xiàn)。GET的語義是“獲取”Fetch。它向服務器請求一個指定資源的表示。關鍵在于GET請求不應該改變服務器的狀態(tài)。你可以把它想象成去圖書館查一本書你告訴管理員書名URL管理員把書資源表示給你。無論你查多少次圖書館書架上的書服務器狀態(tài)本身沒有變化。因此GET請求應該是安全Safe的。POST的語義是“提交”Submit。它請求服務器處理請求中包含的實體通常放在請求體Body中這通常會導致服務器狀態(tài)的改變和/或副作用的產(chǎn)生。比如你在圖書館的借閱單請求體上填好信息并提交管理員處理后你的借閱記錄服務器狀態(tài)就改變了一本書的狀態(tài)也可能從“在館”變?yōu)椤敖璩觥?。所以POST是非安全的。注意這里的“安全”是協(xié)議術語特指“是否會產(chǎn)生副作用”。一個設計良好的GET接口確實不應該修改數(shù)據(jù)庫但一個胡亂實現(xiàn)的GET接口完全可以在后端做刪除操作——這違背了協(xié)議約定會帶來嚴重后果比如網(wǎng)絡爬蟲可能無意中觸發(fā)刪除。2.2 冪等性操作一次和操作N次結(jié)果一樣嗎這是面試?？键c也是設計可靠API的關鍵。GET是冪等的Idempotent。冪等意味著多次執(zhí)行相同的操作產(chǎn)生的效果與執(zhí)行一次的效果相同。你刷新一個網(wǎng)頁GET請求10次服務器返回的內(nèi)容在資源未更新的情況下和你訪問1次是一樣的服務器狀態(tài)也不會因為你的多次刷新而改變10次。這個特性對網(wǎng)絡通信至關重要它允許客戶端在請求失敗如超時時安全地重試而不用擔心重復提交。POST是非冪等的。提交一份訂單POST請求一次創(chuàng)建一條訂單記錄。如果因為網(wǎng)絡超時客戶端沒收到響應而自動重試了這個POST請求服務器就可能創(chuàng)建出兩條一模一樣的訂單。這就是著名的“重復提交”問題。因此對于POST操作服務端必須設計防重機制如Token、冪等鍵。2.3 可緩存性如何利用這一點提升性能緩存是Web性能優(yōu)化的利器而GET和POST在緩存行為上截然不同。GET請求是可緩存的。因為它是冪等且安全的瀏覽器、CDN、代理服務器等中間節(jié)點可以大膽地緩存GET請求的響應。當你再次訪問同一個URL時可能直接從本地緩存或就近的CDN節(jié)點獲取數(shù)據(jù)速度極快且減輕了源站壓力。這也是為什么靜態(tài)資源、API查詢接口強烈建議使用GET的原因。POST請求默認是不可緩存的。由于它會導致狀態(tài)變化緩存其響應是沒有意義的甚至是有害的想象一下緩存了一個“支付成功”的頁面結(jié)果。雖然RFC沒有完全禁止緩存POST響應但所有主流瀏覽器和緩存中間件默認都不會緩存它。如果你試圖對POST接口做緩存優(yōu)化需要非常小心地通過Cache-Control等頭部顯式控制但這通常不是個好主意。為了更直觀地對比我將這些協(xié)議層面的核心區(qū)別整理成了下表特性維度GETPOST對開發(fā)者的實際影響語義獲取Fetch資源提交Submit數(shù)據(jù)進行處理定義了接口的“用途”是API設計的首要依據(jù)。安全性安全不應有副作用非安全通常有副作用違反安全性約定如用GET刪除數(shù)據(jù)會破壞Web基礎設施如爬蟲、預取的假設導致災難。冪等性冪等非冪等GET請求失敗可自動重試POST請求必須由業(yè)務邏輯處理防重?？删彺嫘钥删彺鏋g覽器、CDN默認會緩存默認不可緩存GET接口天然適合做緩存優(yōu)化POST接口的緩存需極其謹慎。請求參數(shù)位置URL的查詢字符串Query String請求體Body決定了參數(shù)是否可見、長度限制、數(shù)據(jù)類型支持等。數(shù)據(jù)長度限制受URL長度限制瀏覽器、服務器各有不同理論上無限制受服務器配置約束GET不適合傳輸大量數(shù)據(jù)如表單提交、文件上傳。數(shù)據(jù)可見性參數(shù)明文顯示在URL、瀏覽器歷史、服務器日志中參數(shù)在Body中相對隱蔽但仍為明文GET參數(shù)不適合傳遞敏感信息如密碼、令牌。書簽/分享可被收藏為書簽URL包含完整參數(shù)不可被收藏Body信息不保存在URL中分享一個搜索結(jié)果GET的鏈接是可行的分享一個表單提交結(jié)果POST的鏈接則不行。后退/刷新無害瀏覽器通常會提示重新提交表單瀏覽器會提示“確認重新提交表單”用戶體驗不同POST操作后退刷新需額外處理。3. 實踐中的關鍵分野參數(shù)、長度、安全與瀏覽器行為理解了協(xié)議本質(zhì)我們再看它們在具體編碼和運行時的表現(xiàn)。這些是日常開發(fā)中最常碰到的“坑點”。3.1 參數(shù)位置與編碼不僅僅是“放哪兒”那么簡單GET的參數(shù)通過URL的**查詢字符串Query String傳遞即?key1value1key2value2的形式。POST的參數(shù)則放在請求體Request Body**中。這個根本性的區(qū)別導致了連鎖反應URL編碼Percent-Encoding由于URL本身是一串特定字符集的文本GET參數(shù)中的特殊字符如空格、中文、、必須進行百分號編碼。例如空格變成%20。如果你在代碼中手動拼接GET參數(shù)忘記編碼很可能導致解析錯誤。而POST的Body內(nèi)容類型Content-Type為application/x-www-form-urlencoded時雖然也對特殊字符進行編碼但它是整個Body作為一個整體進行傳輸編碼邏輯更清晰如果是multipart/form-data或application/json編碼方式又完全不同。數(shù)據(jù)類型支持GET參數(shù)本質(zhì)是文本鍵值對難以直接傳輸復雜結(jié)構如嵌套JSON或二進制數(shù)據(jù)如圖片。雖然可以通過序列化如JSON序列化成字符串再URL編碼來傳遞但非常笨拙且受長度限制。POST的Body則可以輕松支持多種格式表單、JSON、XML甚至二進制流這是它成為數(shù)據(jù)提交首選的重要原因。3.2 長度限制那個讓我踩坑的“隱形天花板”這是我開篇故障的根本原因。雖然HTTP協(xié)議本身沒有規(guī)定URL的長度上限但現(xiàn)實世界中的各個環(huán)節(jié)都給自己加了限制瀏覽器不同瀏覽器有不同限制。IE早期版本限制約2048字符Chrome、Firefox等現(xiàn)代瀏覽器限制在幾萬字符級別但這只是理論值。服務器Web服務器如Nginx、Apache和應用程序服務器如Tomcat都有各自的配置項來限制請求行包含URL的長度。例如Nginx的client_header_buffer_size和large_client_header_buffers配置就直接影響能接收的URL長度。超過限制服務器會直接返回414 URI Too Long或400 Bad Request錯誤。代理與CDN中間代理、負載均衡器、CDN節(jié)點也可能有自身的URL長度限制并且這個限制往往不透明最容易在測試環(huán)境被忽略直到上線后流量經(jīng)過復雜網(wǎng)絡路徑時才暴露。實操心得一個簡單的經(jīng)驗法則是永遠不要用GET傳遞超過2000字符的數(shù)據(jù)。對于需要傳遞大量數(shù)據(jù)的場景如復雜的查詢條件、長文本內(nèi)容毫不猶豫地使用POST。在設計查詢API時如果過濾條件非常復雜也應該考慮使用POST將條件以JSON格式放在Body中這比構建一個超長的、難以閱讀和維護的GET URL要優(yōu)雅和可靠得多。3.3 安全與可見性GET參數(shù)是“明信片”GET參數(shù)附在URL上這意味著瀏覽器地址欄可見用戶一眼就能看到不適合傳遞密碼、令牌等敏感信息。瀏覽器歷史記錄URL會被保存在瀏覽器歷史中別人查看歷史就能看到參數(shù)。服務器訪問日志W(wǎng)eb服務器通常會記錄完整的請求URL到訪問日志文件中。如果日志管理不當敏感參數(shù)可能被泄露。Referer頭部當從A頁面跳轉(zhuǎn)到B頁面時B頁面收到的請求中Referer頭部會包含A頁面的完整URL。如果A頁面的URL中含有敏感GET參數(shù)這個參數(shù)就會泄露給B頁面所在的域名。因此任何敏感信息絕對不要通過GET傳遞。即使使用HTTPS加密了整個通信過程URL中的參數(shù)在客戶端和服務器端的日志系統(tǒng)中仍然是明文。POST的Body內(nèi)容在HTTPS下是加密的且通常不會完整記錄到服務器訪問日志中日志一般只記錄路徑不記錄Body相對安全。但請注意這并不意味著POST可以隨意傳遞密碼密碼等核心機密在任何情況下都應進行哈希加鹽處理后再傳輸。3.4 瀏覽器與用戶的交互行為瀏覽器基于GET和POST的語義差異對用戶行為有不同的處理刷新與后退刷新一個GET請求的頁面瀏覽器會直接重新發(fā)起請求。刷新或后退到一個由POST請求產(chǎn)生的頁面時幾乎所有瀏覽器都會彈出提示框詢問用戶“確認重新提交表單”。這是因為瀏覽器知道POST可能改變服務器狀態(tài)重復提交可能造成不良后果如重復扣款。這個提示是瀏覽器對用戶的保護。書簽與鏈接分享GET請求的URL包含了所有參數(shù)因此整個請求狀態(tài)可以被保存為書簽或通過鏈接分享。而POST請求的狀態(tài)Body內(nèi)容無法通過URL保存因此不能直接書簽或分享。預取與預渲染一些瀏覽器或插件會進行預取Prefetch來加速瀏覽它們通常只預取GET請求的鏈接因為GET是安全且冪等的。它們絕不會去預取一個POST鏈接那可能導致未知的副作用。4. 深入技術細節(jié)Body、URL與協(xié)議歷史要徹底搞懂我們還得再往下鉆一層看看數(shù)據(jù)到底是怎么“上車”和“下車”的。4.1 GET真的不能有Body嗎這是一個經(jīng)典的誤解。從HTTP/1.1協(xié)議語法上講GET請求是可以包含消息體Body的。RFC 7231并沒有禁止這一點。然而協(xié)議語義明確指出GET的Body沒有定義任何含義。也就是說服務器可以忽略GET請求中的Body。在實踐中99.99%的服務器端框架、庫、代理和緩存中間件都會忽略甚至拒絕處理GET請求的Body。例如如果你用curl給一個Spring Boot的GET接口發(fā)送帶Body的請求Spring默認的解析器很可能根本不會去讀取這個Body。如果你強行讓服務端去讀那么你會破壞所有中間件如緩存服務器、網(wǎng)關對GET請求的假設導致不可預知的行為。結(jié)論在工程實踐上必須視“GET請求沒有Body”為鐵律。任何需要傳遞到服務端的數(shù)據(jù)都必須通過URL的路徑Path或查詢字符串Query String來傳遞。4.2 POST的參數(shù)可以放在URL里嗎反過來POST請求當然可以把參數(shù)放在URL的查詢字符串中。這在一些特定場景下是合理的例如分頁或過濾參數(shù)POST /api/users/search?page1size20將分頁、排序等控制參數(shù)放在URL中而將復雜的查詢條件如一個多字段的過濾對象放在Body的JSON里。這樣設計URL部分代表了“查詢的視圖”Body部分代表了“查詢的具體內(nèi)容”語義清晰。API版本號或訪問令牌有時會將API版本/v1/或認證令牌?access_tokenxxx放在URL中而將業(yè)務數(shù)據(jù)放在Body里。但需要注意的是放在URL中的參數(shù)同樣會受到長度限制和可見性問題的約束。4.3 一個歷史“包袱”POST的兩種編碼早期Web以表單提交為主POST請求體主要有兩種編碼方式理解它們有助于處理一些遺留系統(tǒng)或特定場景application/x-www-form-urlencoded這是默認的表單編碼方式。它會將Body中的鍵值對如name張三age20進行URL編碼空格變號特殊字符百分號編碼格式和GET的查詢字符串非常像但位置在Body里。這種格式簡單但不適合傳輸二進制文件。multipart/form-data當表單需要上傳文件時必須使用這種編碼。它會將整個Body分割成多個部分Part每個部分對應一個表單字段并包含自己的頭部信息如Content-Type。這種方式可以高效地混合傳輸文本和二進制數(shù)據(jù)但格式復雜解析起來也比上一種麻煩。現(xiàn)代前端開發(fā)中使用fetch或axios等庫我們更常用application/json格式來傳遞復雜的結(jié)構化數(shù)據(jù)后端框架也能很好地支持解析。這已經(jīng)成為RESTful API設計的事實標準。5. 設計抉擇與最佳實踐什么時候該用誰理論說了一大堆最終要落到代碼和設計上。下面是我總結(jié)的一些核心原則和場景分析。5.1 首要原則遵從語義Semantic這是最高原則。選擇GET還是POST首先取決于你的操作意圖而不是技術實現(xiàn)的難易。意圖是查詢、獲取數(shù)據(jù)且操作不應改變服務器狀態(tài) -用GET。例子搜索商品、獲取用戶信息、查詢訂單列表、下載文件。意圖是創(chuàng)建、更新、刪除數(shù)據(jù)或觸發(fā)一個有副作用的操作 -用POST或PUT、DELETE但POST是通用性最強的。例子用戶注冊創(chuàng)建、修改密碼更新、提交訂單創(chuàng)建并觸發(fā)庫存變更等副作用。違反語義的后果很嚴重。用GET來刪除資源可能導致搜索引擎爬蟲、瀏覽器預加載、鏈路監(jiān)控系統(tǒng)等無意中觸發(fā)刪除操作。用POST來做一個純查詢你就放棄了緩存帶來的巨大性能優(yōu)勢并且讓用戶無法收藏或分享這個查詢結(jié)果的鏈接。5.2 場景化決策指南場景推薦方法理由與注意事項簡單數(shù)據(jù)查詢?nèi)绺鶕?jù)ID查詳情GET冪等、安全、可緩存。URL簡潔易于分享和書簽。復雜條件查詢?nèi)绨鄠€過濾、排序字段POST查詢條件可能很長或結(jié)構復雜放在JSON Body中更靈活不受URL長度限制也便于前端構造和后端解析。創(chuàng)建新資源如發(fā)表文章POST非冪等操作必須用POST或PUT if you have the full URI。更新資源如修改文章標題PUT/PATCH更符合RESTful語義。如果只用POST也務必在Body中指明操作類型。刪除資源DELETE語義最清晰。用POST包裹刪除動作也是常見做法尤其是前端表單限制時。提交表單數(shù)據(jù)含文件上傳POST數(shù)據(jù)量大可能含二進制必須用POST。編碼用multipart/form-data。觸發(fā)一個無返回值的動作如“發(fā)送驗證碼”、“清理緩存”POST這是一個有副作用的操作非冪等應用POST。需要被收藏或分享的頁面如一個特定的搜索結(jié)果頁GET狀態(tài)參數(shù)保存在URL中才能實現(xiàn)鏈接分享。如果參數(shù)復雜可考慮生成一個唯一短鏈通過GET短鏈映射到服務器端存儲的復雜查詢條件。涉及敏感信息密碼、支付令牌POST(且必須HTTPS)絕對不要出現(xiàn)在URL、日志中。POST Body在HTTPS下加密傳輸。服務端日志不應記錄Body。5.3 關于RESTful API設計的特別說明在RESTful架構風格中HTTP方法被賦予了更精確的語義GET獲取資源。POST創(chuàng)建資源服務端決定URI。PUT更新資源客戶端提供完整資源及URI。PATCH部分更新資源。DELETE刪除資源。在這種情況下POST和GET的界限更加清晰。但即使在RESTful API中對于復雜的、只讀的查詢操作例如一個包含多重聚合、過濾的報表查詢使用POST來傳遞查詢條件也是被廣泛接受的這被稱為“Query by POST”它避免了構造一個極其冗長且可能超出限制的GET URL。5.4 一個真實的架構案例搜索API的演進我經(jīng)歷過一個電商搜索系統(tǒng)的重構。最初搜索接口是GET參數(shù)全部堆在URL里/search?kw手機category123price_min1000price_max5000sortsalespage1...。隨著業(yè)務復雜篩選條件增加到幾十個品牌、屬性、服務承諾等URL經(jīng)常超長前端拼接麻煩后端解析也容易出錯。重構后我們將其改為POST /search。請求體是一個結(jié)構清晰的JSON{ keyword: 手機, filters: { categoryId: 123, priceRange: {min: 1000, max: 5000}, brandIds: [101, 102], attributes: [{key: color, value: black}] }, sort: {field: sales, order: desc}, page: 1, size: 20 }這樣做帶來了幾個好處徹底擺脫長度限制無論條件多復雜JSON結(jié)構都能輕松容納。前后端協(xié)作更高效JSON Schema可以明確定義接口格式前后端調(diào)試方便。易于擴展新增篩選條件只需在JSON中添加字段無需改動URL結(jié)構。緩存策略調(diào)整由于改為POST默認不可緩存。我們針對這個高頻接口在網(wǎng)關層設計了基于請求體摘要如MD5的緩存機制將計算出的摘要值作為緩存鍵同樣獲得了緩存性能提升只是實現(xiàn)上比GET復雜一些。這個案例說明規(guī)則是死的人是活的。在深刻理解GET和POST本質(zhì)區(qū)別的基礎上結(jié)合具體業(yè)務場景和約束如性能、復雜度做出最合理的設計選擇這才是資深工程師的價值所在。