做Web開發(fā)這幾年301和302這兩個(gè)狀態(tài)碼算是遇到頻率最高的重定向方式但我發(fā)現(xiàn)不少同學(xué)到現(xiàn)在都沒把兩者的區(qū)別完全搞明白。之前接到一個(gè)模擬項(xiàng)目網(wǎng)站要從HTTP整體遷到HTTPS前端同事圖省事配了一堆302跳轉(zhuǎn)結(jié)果線上訪問是沒問題搜索引擎卻不認(rèn)賬舊頁面權(quán)重遲遲不轉(zhuǎn)移新關(guān)鍵詞排名一直上不來。最后定位到根因就是臨時(shí)和永久這兩個(gè)詞的語義用反了。這篇文章不寫概念教科書直接從實(shí)際工作出發(fā)把兩個(gè)狀態(tài)碼的職責(zé)邊界、服務(wù)器配置方法、踩過的坑和排查套路全部揉在一起聊。適合正在搭站的后端開發(fā)、維護(hù)線上環(huán)境的運(yùn)維還有天天被SEO指標(biāo)追著跑的運(yùn)營(yíng)同學(xué)。我會(huì)先用生活化的類比把301和302的本質(zhì)講透再給可抄作業(yè)的配置示例最后整理一份常見問題速查表。看完這篇文章你應(yīng)該能在五分鐘內(nèi)判斷某個(gè)場(chǎng)景到底該用301還是302。1. 重定向狀態(tài)碼的本質(zhì)301和302到底在告訴客戶端什么1.1 狀態(tài)碼是服務(wù)器給客戶端的一句明確旁白HTTP請(qǐng)求是一個(gè)問答過程瀏覽器問服務(wù)器我要訪問這個(gè)地址服務(wù)器用狀態(tài)碼回答請(qǐng)求收到了處理結(jié)果是這樣。狀態(tài)碼不是給用戶看的文案而是給瀏覽器、爬蟲、客戶端程序看的結(jié)構(gòu)化信息。3開頭的狀態(tài)碼統(tǒng)一表示重定向意思是你要的東西我已經(jīng)看到了但它現(xiàn)在不在這個(gè)地址我給你一個(gè)Location響應(yīng)頭里面寫著新地址你自己再跑一趟。你可以把301和302想象成導(dǎo)航App里的兩種提示。301是這個(gè)目的地已經(jīng)永久搬家了以后都用新地址來找我302是這個(gè)目的地暫時(shí)不對(duì)外開放你先去臨時(shí)地址湊合一下過段時(shí)間再回原地址試試。兩種說法看似相似但客戶端和搜索引擎處理它們的邏輯完全不同這也是很多事故的源頭。1.2 301與302的官方語義差異先看定義301 Moved Permanently請(qǐng)求的資源已經(jīng)被永久移動(dòng)以后任何對(duì)原始URL的請(qǐng)求都應(yīng)該直接使用新的URL。302 Found請(qǐng)求的資源暫時(shí)被移到了另一個(gè)URL以后對(duì)原始URL的請(qǐng)求仍然應(yīng)該繼續(xù)使用原始URL。這里有個(gè)歷史彩蛋302最初的名字叫Found語義非常模糊后來HTTP/1.1規(guī)范也沒改干凈導(dǎo)致很多瀏覽器實(shí)現(xiàn)是不管301還是302只要我用GET請(qǐng)求跳轉(zhuǎn)后一律變成GET。所以官方規(guī)范后來補(bǔ)充了303 See Other和307 Temporary Redirect來解決語義混亂的問題。咱們后文會(huì)提到但工程上現(xiàn)在依然大量用到301和302所以理解其根本差異仍然是基本功。從實(shí)際影響看主要差異體現(xiàn)在三方面對(duì)比維度301 永久重定向302 臨時(shí)重定向?yàn)g覽器緩存行為會(huì)默認(rèn)緩存跳轉(zhuǎn)結(jié)果一般不會(huì)主動(dòng)緩存除非響應(yīng)頭顯式允許搜索引擎處理將舊URL權(quán)重繼承到新URL索引更新為新地址繼續(xù)把舊URL視為可訪問地址不轉(zhuǎn)移權(quán)重典型觸發(fā)結(jié)果用戶再次輸入舊地址時(shí)可能直接被跳轉(zhuǎn)用戶每次都會(huì)先訪問舊地址再收到跳轉(zhuǎn)指令適用階段域名更換、結(jié)構(gòu)改版、協(xié)議升級(jí)臨時(shí)活動(dòng)頁、登錄、A/B測(cè)試對(duì)普通用戶來說301和302在瀏覽器里看到的差異不大甚至感知不到。但對(duì)爬蟲和客戶端程序來說差別巨大。如果配置錯(cuò)誤輕則增加無謂的請(qǐng)求次數(shù)重則讓網(wǎng)站整整數(shù)個(gè)月的SEO工作白干。2. 場(chǎng)景選型什么時(shí)候用301什么時(shí)候用3022.1 用301的典型場(chǎng)景凡是舊地址以后再也不打算用了的情況都該用301。我實(shí)際經(jīng)手過的場(chǎng)景主要有四類第一域名更換。從一個(gè)已經(jīng)運(yùn)營(yíng)多年的域名遷移到新域名必須把所有頁面、圖片、靜態(tài)資源的地址都通過301指到新域名。這時(shí)候如果用了302老用戶在搜索引擎里點(diǎn)擊舊鏈接后雖然也能到達(dá)新頁面但搜索引擎會(huì)一直覺得舊域名還有效就不會(huì)把流量和權(quán)重放下。第二HTTP協(xié)議升級(jí)到HTTPS。這是當(dāng)前最普遍的場(chǎng)景。配置時(shí)在服務(wù)器層面把80端口的請(qǐng)求全部301跳轉(zhuǎn)到443端口返回帶新鏈接的Location頭。我見過有人為了圖省事直接把所有HTTP請(qǐng)求都用302轉(zhuǎn)發(fā)短期內(nèi)確實(shí)能跳到HTTPS頁面但搜索引擎對(duì)舊鏈接的信任度會(huì)下降而且多次臨時(shí)跳轉(zhuǎn)會(huì)讓抓取效率變差。第三URL規(guī)范化。比如一個(gè)網(wǎng)站的頁面既可以通過http://old.example.com訪問也可以通過https://old.example.com訪問搜索引擎會(huì)認(rèn)為是兩個(gè)不同站點(diǎn)。通常選擇其中一個(gè)版本作為主版本把另一個(gè)版本通過301指過去。常見的做法是把裸域名統(tǒng)一帶www或者反過來總之要用301不能兩個(gè)域名都聲稱自己是正版。第四舊內(nèi)容永久下線但希望用戶去新的替代頁面。比如原本的/article/123改成了/posts/123舊編號(hào)以后不再復(fù)用直接301到新地址。搜索引擎會(huì)把舊頁面的外鏈聲望轉(zhuǎn)給新頁面這也是SEO遷移中最值錢的環(huán)節(jié)。我自己的經(jīng)驗(yàn)是只要在需求里看到永久、以后不恢復(fù)、域名換了這些字眼第一反應(yīng)就應(yīng)該上301。猶豫不決時(shí)寧可保守一點(diǎn)也不要讓一個(gè)永久變更用臨時(shí)狀態(tài)碼撐半年。2.2 用302的典型場(chǎng)景302適合原地址仍然有效只是這次請(qǐng)求你要去別的地方處理的場(chǎng)景。最常見的有三類。登錄跳轉(zhuǎn)算一個(gè)。用戶訪問一個(gè)需要登錄的頁面系統(tǒng)會(huì)先把他帶到登錄頁登錄成功后帶著回跳參數(shù)再回到原始地址。在這個(gè)暫時(shí)走開一下的過程中原始URL本身沒有任何變化用戶下次再來還是走同樣的流程所以用302非常合適。臨時(shí)活動(dòng)頁也算一個(gè)。比如節(jié)日大促原頁面欄位內(nèi)容不變只是臨時(shí)把流量引到一個(gè)活動(dòng)頁活動(dòng)結(jié)束后再回到原來的頁面邏輯。這里如果有緩存可能會(huì)把用戶永遠(yuǎn)留在活動(dòng)頁所以要非常注意響應(yīng)頭的緩存控制。實(shí)在拿不準(zhǔn)時(shí)301一定不要用302配合Cache-Control: no-store是更穩(wěn)的方案。A/B測(cè)試同樣依賴302。當(dāng)一個(gè)功能有兩個(gè)版本在分流實(shí)驗(yàn)后臺(tái)要按用戶群體或參數(shù)決定跳到哪一版。這個(gè)跳轉(zhuǎn)對(duì)每個(gè)用戶來說可能都不一樣絕不能讓瀏覽器永久緩存某個(gè)跳轉(zhuǎn)目標(biāo)否則實(shí)驗(yàn)就廢了。用302的好處就在于此每次請(qǐng)求都老老實(shí)實(shí)到服務(wù)器問一句我這次該去哪。順帶提一句302還可以用于均衡負(fù)載。一些老舊的系統(tǒng)用302把請(qǐng)求輪流指到不同機(jī)房的服務(wù)節(jié)點(diǎn)但現(xiàn)代架構(gòu)基本都用DNS或網(wǎng)關(guān)層負(fù)載均衡了302這種方案只適合少數(shù)限制嚴(yán)格的場(chǎng)景。2.3 容易被忽略的303、307和308既然聊到選型就得把另外三個(gè)兄弟狀態(tài)碼拿出來說說。HTTP/1.1時(shí)代補(bǔ)充了303 See Other和307 Temporary Redirect后來又有了308 Permanent Redirect。303無論原請(qǐng)求是POST還是PUT跳轉(zhuǎn)后都讓客戶端改用GET去訪問新地址。常用于表單提交成功后跳轉(zhuǎn)到結(jié)果頁防止用戶刷新頁面導(dǎo)致重復(fù)提交。307語義和302幾乎一樣都是臨時(shí)重定向但不對(duì)請(qǐng)求方法做任何強(qiáng)制轉(zhuǎn)換。如果用POST發(fā)起請(qǐng)求服務(wù)器返回307瀏覽器會(huì)再用POST請(qǐng)求新地址。這點(diǎn)很重要因?yàn)楹芏嗯f實(shí)現(xiàn)的302會(huì)把POST變?yōu)镚ET導(dǎo)致請(qǐng)求體丟失。308語義和301一樣是永久重定向但同樣不會(huì)更改請(qǐng)求方法。處理非GET請(qǐng)求的永久遷移時(shí)用它比301更安全。工程上普通頁面的GET跳轉(zhuǎn)用301/302足夠但涉及API接口和表單回跳時(shí)要多留個(gè)心眼。我見過不少團(tuán)隊(duì)把POST接口的301跳轉(zhuǎn)當(dāng)GET處理導(dǎo)致客戶端拿到響應(yīng)后丟失了請(qǐng)求體查了半天才發(fā)現(xiàn)是狀態(tài)碼語義在作怪。3. Web服務(wù)器上的301/302配置實(shí)操3.1 主流服務(wù)器配置示例真正動(dòng)手配的時(shí)候第一件事就是確定自己用的是哪種Web服務(wù)器。下面給幾份可以直接抄的例子。NginxNginx里設(shè)置重定向一般用return或rewrite。return更簡(jiǎn)潔高效適合明確的目標(biāo)地址# 整個(gè)站點(diǎn)的HTTP強(qiáng)制跳轉(zhuǎn)到HTTPS用301永久跳轉(zhuǎn) server { listen 80; server_name old.example.com; return 301 https://new.example.com$request_uri; } # 某個(gè)舊路徑永久跳轉(zhuǎn)到新路徑用301 location /old/ { return 301 https://new.example.com/new/$request_uri; } # 臨時(shí)活動(dòng)頁跳轉(zhuǎn)用302 location /promo { return 302 https://new.example.com/event/spring-sale; }rewrite也能實(shí)現(xiàn)但一般在需要基于路徑正則改寫時(shí)才更值得用rewrite ^/old/(.*)$ /new/$1 permanent; # 301 rewrite ^/old/(.*)$ /new/$1 redirect; # 302ApacheApache的配置更接近人類語言可以用Redirect或RedirectMatch指令# 單個(gè)路徑的301永久重定向 Redirect 301 /old https://new.example.com/new # 基于正則匹配的302臨時(shí)重定向 RedirectMatch 302 ^/old/(.*)$ https://new.example.com/new/$1Apache配置文件改動(dòng)后用apachectl graceful平滑生效Nginx用nginx -s reload不要用restart否則會(huì)有短暫中斷。Node.js / Express后端代碼里控制重定向狀態(tài)碼也很常見Express框架只需要一行const express require(express); const app express(); // 永久跳轉(zhuǎn) app.get(/old, (req, res) { res.redirect(301, /new); }); // 臨時(shí)跳轉(zhuǎn)默認(rèn)就是302 app.get(/temporary, (req, res) { res.redirect(/temp); });Java Servlet / Spring BootGetMapping(/old) public void redirectOld(HttpServletResponse response) throws IOException { response.setStatus(301); response.setHeader(Location, https://new.example.com/new); response.flushBuffer(); } // 或者用Spring Boot更簡(jiǎn)潔的方式 GetMapping(/old2) public RedirectView redirectOld2() { RedirectView view new RedirectView(/new); view.setStatusCode(HttpStatus.MOVED_PERMANENTLY); return view; }配置本身的語法不難難的是弄清楚目標(biāo)地址怎么拼。3.2 配置時(shí)最容易踩的路徑坑我在代碼審查里最?？吹降腻e(cuò)誤有三個(gè)。第一個(gè)是丟掉查詢參數(shù)。Nginx里如果寫死return 301 https://new.example.com/new;那么用戶訪問/old?fromad時(shí)fromad就丟了。正確寫法是保留$request_uri或用對(duì)應(yīng)變量拼上return 301 https://new.example.com/new$request_uri;這里的$request_uri包含原來的URI和查詢字符串能把/old?fromad原樣帶到https://new.example.com/new?fromad。第二個(gè)是域名帶的路徑重復(fù)。假設(shè)源站是https://new.example.com/blog如果配置里不小心寫成return 301 https://new.example.com/blog$request_uri而$request_uri又包含/old結(jié)果就變成/blog/old了。正確做法是明確我要把舊路徑映射到新頁面的哪個(gè)根位置最好先寫一個(gè)測(cè)試文件驗(yàn)證再上線。第三個(gè)是特殊字符和中文路徑。重定向目標(biāo)URL只支持ASCII字符如果舊路徑里有中文或空格服務(wù)器端最好對(duì)Location頭做URL編碼否則部分瀏覽器會(huì)直接報(bào)地址無效。Nginx和Apache通常會(huì)自動(dòng)處理一部分但后端代碼里自己拼接時(shí)一定要用encodeURI、URLEncoder.encode這類工具。修改完配置后我習(xí)慣用兩三步自檢先看是否保留參數(shù)再看目標(biāo)URL是否可達(dá)最后用命令行工具確認(rèn)響應(yīng)頭。別小看這三步能擋掉一大半線上事故。3.3 如何驗(yàn)證重定向配置生效驗(yàn)證重定向不是用瀏覽器點(diǎn)一下看看能不能跳這么簡(jiǎn)單瀏覽器會(huì)默認(rèn)跟隨跳轉(zhuǎn)你根本看不到中間過程。最直接的方式是用curl查看響應(yīng)頭限制不跟隨跳轉(zhuǎn)curl -I http://old.example.com/old輸出里會(huì)看到HTTP/1.1 301 Moved Permanently Location: https://new.example.com/newHTTP/1.1 301就是要的重點(diǎn)。如果看到的是302 Found說明你配錯(cuò)了。如果想去掉緩存因素的干擾可以加-H Cache-Control: no-cache再看一遍。要查看完整跳轉(zhuǎn)鏈用curl -L并設(shè)置最大跳轉(zhuǎn)次數(shù)curl -L --max-redirs 5 http://old.example.com/old這個(gè)方法能快速發(fā)現(xiàn)跳轉(zhuǎn)鏈太長(zhǎng)和循環(huán)重定向問題。瀏覽器開發(fā)者工具里的Network面板也能看到每次請(qǐng)求的狀態(tài)碼記得勾選Disable cache再測(cè)試否則瀏覽器緩存的301結(jié)果會(huì)干擾判斷。4. 重定向配置常見問題與排查方法4.1 問題重定向循環(huán)典型的報(bào)錯(cuò)是瀏覽器顯示此網(wǎng)頁造成了太多重定向或ERR_TOO_MANY_REDIRECTS。原因通常是A跳B、B再跳A形成死循環(huán)。常見場(chǎng)景是HTTP與HTTPS兩個(gè)配置互相指舊域名指向新域名新域名又因?yàn)槟硞€(gè)規(guī)則指回舊域名。排查思路很簡(jiǎn)單第一步先看服務(wù)器配置確認(rèn)有沒有兩個(gè)return規(guī)則同時(shí)命中同一個(gè)URL。第二步用curl逐步查看curl -I -L --max-redirs 3 http://old.example.com/如果輸出里反復(fù)出現(xiàn)HTTP/1.1 301且Location一直變不回http://基本就是循環(huán)。我踩過一次很隱蔽的坑Nginx里server塊的listen 80和listen 443 ssl都寫了return 301 https://new.example.com$request_uri看起來沒錯(cuò)但其中一個(gè)證書配置失效導(dǎo)致HTTPS端口響應(yīng)失敗瀏覽器在兩次跳轉(zhuǎn)后反而報(bào)循環(huán)。后來把監(jiān)聽規(guī)則放全局變量里統(tǒng)一管理才解決。4.2 問題302跳轉(zhuǎn)后權(quán)重丟失這個(gè)問題的表現(xiàn)是頁面能訪問但搜索引擎收錄一直不更新舊關(guān)鍵詞排名波動(dòng)。原因幾乎都是永久性遷移卻用了302。搜索引擎對(duì)302的處理是舊地址仍然存活先抓取舊地址臨時(shí)跳轉(zhuǎn)不完全信任所以權(quán)重不會(huì)真正轉(zhuǎn)移。我的建議是凡是判斷為永久變更立刻改成301。如果業(yè)務(wù)方說暫時(shí)不確定以后恢復(fù)不恢復(fù)怎么辦那就給出時(shí)間底線——超過兩周到一個(gè)月還沒恢復(fù)的就默認(rèn)按永久遷移處理改成301。不要為了以后方便恢復(fù)而長(zhǎng)期使用302這個(gè)舒適區(qū)會(huì)讓SEO團(tuán)隊(duì)很痛苦。另外還有一層容易被忽略CDN或中間代理可能會(huì)緩存302響應(yīng)。有些緩存系統(tǒng)對(duì)于帶Set-Cookie或特定路徑的302不會(huì)緩存但純靜態(tài)路徑就說不準(zhǔn)。如果發(fā)現(xiàn)改完配置用戶還在走舊地址優(yōu)先檢查CDN節(jié)點(diǎn)節(jié)點(diǎn)緩存和瀏覽器緩存。4.3 問題瀏覽器或CDN緩存了舊的跳轉(zhuǎn)結(jié)果301的一個(gè)副作用是瀏覽器會(huì)記住這個(gè)跳轉(zhuǎn)下次訪問舊地址直接跳到新地址。這本來是性能優(yōu)化但在調(diào)試階段非常煩人你把301改成302或改成另一個(gè)地址后瀏覽器還在用舊結(jié)果。清理辦法分三檔第一檔是開發(fā)者工具Network面板里勾選Disable cache然后強(qiáng)制刷新第二檔是用curl -H Cache-Control: no-cache驗(yàn)證服務(wù)器實(shí)際響應(yīng)第三檔是換一個(gè)無痕窗口或換瀏覽器測(cè)試。如果是CDN緩存需要在CDN控制臺(tái)刷新對(duì)應(yīng)路徑的緩存或者在響應(yīng)頭里加Cache-Control: no-store來控制。尤其是臨時(shí)活動(dòng)頁如果CDN把302結(jié)果緩存一小時(shí)活動(dòng)結(jié)束后的時(shí)間窗口里用戶還是會(huì)跳到活動(dòng)頁等于白加班。4.4 問題重定向后請(qǐng)求方法丟失這里要回到之前提過的307/308。一個(gè)典型場(chǎng)景是客戶端向服務(wù)端提交一個(gè)POST請(qǐng)求服務(wù)端返回302并指向另一個(gè)地址瀏覽器按規(guī)范可能把這個(gè)POST請(qǐng)求變成GET請(qǐng)求導(dǎo)致新地址收到的請(qǐng)求沒有請(qǐng)求體業(yè)務(wù)報(bào)錯(cuò)。最直接的解決辦法是如果后端需要保持原請(qǐng)求方法就用307或308如果希望把POST轉(zhuǎn)成GET例如表單提交成功后跳轉(zhuǎn)結(jié)果頁就用303或302并告知客戶端必須用GET。這里沒有一刀切的答案完全取決于業(yè)務(wù)是否需要保留請(qǐng)求方法。排查這類問題時(shí)建議在服務(wù)端打印請(qǐng)求方法、請(qǐng)求頭和請(qǐng)求體對(duì)比跳轉(zhuǎn)前后的差異。很多框架默認(rèn)會(huì)把302包裝成GET請(qǐng)求這是框架行為不是服務(wù)器底層錯(cuò)誤。5. 我在實(shí)際項(xiàng)目中掌握的幾條避坑經(jīng)驗(yàn)5.1 優(yōu)先用簡(jiǎn)潔規(guī)則替代復(fù)雜正則Nginx里return指令比rewrite更容易理解也更省性能。rewrite適合需要從URL中提取一段并重新拼接的場(chǎng)景但正則寫復(fù)雜后非常難維護(hù)。我曾經(jīng)維護(hù)過一個(gè)老站點(diǎn)一條rewrite規(guī)則寫了半年沒人敢碰后來直接改用兩三條return規(guī)則把所有舊路徑顯式列出來反而便于排查。我的建議是能用精確路徑就不寫正則能寫正則就別嵌套多層判斷盡量讓每一條跳轉(zhuǎn)規(guī)則一眼就能看懂。5.2 重定向目標(biāo)必須做可達(dá)性自檢跳轉(zhuǎn)是否成功不只取決于狀態(tài)碼還取決于Location指向的地址是否真的能返回200。如果配了301到新地址但新地址本身是404那用戶只會(huì)看到一記重定向失效搜索引擎也把新頁面當(dāng)成死鏈。我在驗(yàn)收時(shí)會(huì)寫一個(gè)簡(jiǎn)單腳本把所有要配置的舊URL和新URL成對(duì)測(cè)試確保舊URL返回3XX、新URL返回2XX并且在跳轉(zhuǎn)鏈上不出現(xiàn)404。5.3 重定向鏈越短越好從舊URL到最終頁面中間經(jīng)歷多次3XX跳轉(zhuǎn)會(huì)拖慢頁面加載速度也會(huì)讓搜索引擎的抓取預(yù)算浪費(fèi)在非內(nèi)容頁上。理想狀態(tài)是舊URL只跳轉(zhuǎn)一次直達(dá)最終URL。如果有歷史原因造成中間層比如舊域名跳中間域名再跳新域名一定要盡快收斂成一次跳轉(zhuǎn)。我曾經(jīng)處理過一個(gè)項(xiàng)目跳轉(zhuǎn)鏈?zhǔn)?跳最后用curl -L看到響應(yīng)耗時(shí)翻了四倍優(yōu)化成單跳后用戶體感快了很多。5.4 留好日志和監(jiān)控重定向不是配完就結(jié)束的事。建議在Nginx或應(yīng)用層為3XX響應(yīng)單獨(dú)打日志記錄來源URL、目標(biāo)URL、跳轉(zhuǎn)類型。這樣當(dāng)運(yùn)營(yíng)反饋某個(gè)入口流量異常下降時(shí)你可以快速拉出日志看是哪個(gè)環(huán)節(jié)把流量截?cái)嗔?。我?xí)慣每季度做一次重定向?qū)徲?jì)把所有3XX響應(yīng)按狀態(tài)碼、跳轉(zhuǎn)目標(biāo)、命中次數(shù)排序一次性清理掉那些已經(jīng)沒人訪問但還在消耗爬蟲預(yù)算的舊規(guī)則。最后再分享一個(gè)個(gè)人體會(huì)處理301和302最重要的不是記住代碼怎么寫而是建立一張這個(gè)變更到底是不是永久的判斷表。每次收到跳轉(zhuǎn)需求先問業(yè)務(wù)方三句話舊地址以后還需要正常訪問嗎這個(gè)跳轉(zhuǎn)預(yù)計(jì)持續(xù)多久目標(biāo)地址是同一個(gè)站內(nèi)的內(nèi)容還是另一個(gè)系統(tǒng)的頁面答案如果是舊地址以后不用了且持續(xù)超過一個(gè)月基本都是301跑不掉如果只是暫時(shí)引導(dǎo)且需要頻繁變化302是更合適的選擇。這套判斷邏輯一旦養(yǎng)成你寫出的跳轉(zhuǎn)規(guī)則會(huì)比很多人穩(wěn)得多。