做開(kāi)發(fā)這些年我發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象很多干了三五年的程序員能隨手寫出復(fù)雜的狀態(tài)管理方案能對(duì)著一堆晦澀的算法滔滔不絕但一碰到 URL 就有點(diǎn)發(fā)怵。尤其是那種帶著自定義協(xié)議前綴、后面還追著一大串百分號(hào)編碼的鏈接比如抖音分享出來(lái)的snssdk1128://webview?urlhttps%3a%2f%2faweme.snssdk.com%2ffalcon%2fdouyi或者淘寶的dps://p?urlhttps%3a%2f%2fmain.m.taobao.com%2f...一看到就頭皮發(fā)麻。這不怪大家URL 這個(gè)知識(shí)點(diǎn)太“碎”了平時(shí)都是遇到哪段查哪段很少有機(jī)會(huì)從底層邏輯上一次理清。這篇文章我打算把這些年跟 URL統(tǒng)一資源定位符打交道攢下的經(jīng)驗(yàn)從最基礎(chǔ)的結(jié)構(gòu)到編碼解碼的底層規(guī)則再到 App Scheme 喚起、抓包改包、接口報(bào)錯(cuò)排查一條線串起來(lái)講透。前端、移動(dòng)端、后端、測(cè)試甚至天天復(fù)制分享鏈接的運(yùn)營(yíng)同學(xué)都能在里面找到自己用得上的東西。讀完你會(huì)理解為什么有些鏈接打不開(kāi)、為什么參數(shù)老丟、為什么解碼總失敗以及這些問(wèn)題的標(biāo)準(zhǔn)解法是什么。1. 先把URL拆開(kāi)五個(gè)組件各管一攤很多人在 URL 上栽跟頭根子在于沒(méi)把 URL 當(dāng)作一個(gè)“有結(jié)構(gòu)”的對(duì)象而是當(dāng)成一長(zhǎng)串不透明的字符來(lái)處理。你一旦把每個(gè)部分拆開(kāi)理解很多報(bào)錯(cuò)和異常行為就有了合理解釋。1.1 URL的骨架每一段都不是白給的一個(gè)標(biāo)準(zhǔn)的絕對(duì) URL長(zhǎng)這樣scheme://userinfohost:port/path?query#fragment拆開(kāi)看就是scheme協(xié)議或應(yīng)用標(biāo)識(shí)http、https、ftp是常見(jiàn)協(xié)議snssdk1128、dps、weixin這種則屬于自定義 Scheme。userinfo用戶名密碼部分現(xiàn)在基本只在特殊內(nèi)網(wǎng)場(chǎng)景用到放在 URL 里其實(shí)有安全隱患因?yàn)槟阒灰堰@種鏈接發(fā)出去賬號(hào)密碼也跟著出去了。host主機(jī)名可以是域名也可以是 IP。port端口HTTP 默認(rèn) 80HTTPS 默認(rèn) 443。只要不是默認(rèn)端口瀏覽器地址欄里一般會(huì)顯示出來(lái)。path路徑對(duì)應(yīng)服務(wù)器上的資源位置比如/video-details/15313。query查詢參數(shù)以?開(kāi)頭多個(gè)參數(shù)用分隔用來(lái)傳業(yè)務(wù)數(shù)據(jù)。fragment片段標(biāo)識(shí)以#開(kāi)頭俗稱錨點(diǎn)。它不會(huì)發(fā)給服務(wù)器純粹是瀏覽器端定位用。給你一個(gè)真實(shí)例子https://user:passexample.com:8080/path/to/page?nametomage18#section-2其中scheme是httpsuserinfo是user:passhost是example.comport是8080path是/path/to/pagequery是nametomage18fragment是section-2。理解 fragment 不發(fā)服務(wù)器這個(gè)特性特別重要。很多對(duì)接第三方登錄的朋友應(yīng)該見(jiàn)過(guò)這樣的鏈接auth://tauth.qq.com/?#access_token1967ab5c237...access_token 被放在#后面也就是 fragment 里。你如果用location.search去取參數(shù)永遠(yuǎn)取不到必須用location.hash再手動(dòng)解析。不少人在這一步卡了幾天最后發(fā)現(xiàn)是壓根取錯(cuò)位置。1.2 URL、URI、URN別在名詞上打架嚴(yán)格來(lái)說(shuō)URL 是 URI統(tǒng)一資源標(biāo)識(shí)符的子集。URI 是個(gè)更大的概念它包含 URL 和 URN 兩種URL 通過(guò)“位置”來(lái)定位資源URN 通過(guò)“名稱”來(lái)標(biāo)識(shí)資源。我們平時(shí)寫的https://example.com/page是 URL而像urn:isbn:0451450523這種則是 URN它只告訴你書(shū)的編號(hào)不關(guān)心資源在哪。實(shí)際工作中你基本可以忽略 URN 的存在但面試時(shí)這個(gè)概念經(jīng)常被拎出來(lái)考所以我建議把“URL 是 URI 的子集URI 包含 URL 和 URN”這句話記清楚。更重要的是在代碼里很多語(yǔ)言的標(biāo)準(zhǔn)庫(kù)命名用的是URI比如 Java 的java.net.URIPython 的urllib.parse你用的時(shí)候別因?yàn)槊侄鴳岩勺约赫义e(cuò)了類。1.3 正斜杠與反斜杠一個(gè)字符引發(fā)的血案熱詞里有條很有意思“在 Linux、macOS 系統(tǒng)以及網(wǎng)址中用作目錄或文件的路徑分隔符”。這里說(shuō)的是正斜杠/。URL 里的路徑分隔符是正斜杠這是有歷史淵源的早期互聯(lián)網(wǎng)基于 Unix 系統(tǒng)Unix 的路徑分隔符就是正斜杠。而 Windows 用的是反斜杠\結(jié)果就是很多人把 Windows 本地路徑直接拼到 URL 后面比如https://example.com/upload\images\logo.png這種 URL 拿到服務(wù)器上解析\根本不是合法路徑分隔符輕則 404重則被 Web 框架當(dāng)成特殊字符處理引發(fā)安全問(wèn)題。我的習(xí)慣是所有進(jìn)入 URL 的路徑一律把反斜杠替換成正斜杠并且代碼里寫死這個(gè)替換邏輯不要指望客戶端傳過(guò)來(lái)的路徑是規(guī)范的。2. 編碼與解碼那些%3a%2f%2f背后的事熱詞里能看到大量%3a%2f%2f這樣的字符串比如com.greenpoint://android.mc10086.activity?urlhttps%3a%2f%2fdev.coc.1008很多人第一眼看到會(huì)覺(jué)得這是加密或者亂碼其實(shí)不是。%3a解碼后是冒號(hào):%2f解碼后是正斜杠/所以https%3a%2f%2f就是https://的編碼形態(tài)。這是 URL 編碼也叫百分號(hào)編碼。2.1 百分號(hào)編碼的本質(zhì)只是轉(zhuǎn)義不是加密URL 最初設(shè)計(jì)時(shí)只允許使用 ASCII 字符集中的一小部分字符。但實(shí)際業(yè)務(wù)里我們經(jīng)常要在鏈接里傳遞中文、空格、emoji甚至、、?這種有特殊意義的字符。為了解決沖突RFC 3986 規(guī)定了一套規(guī)則一個(gè)字符先按某種字符集轉(zhuǎn)成字節(jié)每個(gè)字節(jié)再用%加上兩位十六進(jìn)制數(shù)表示。比如中文“你”在 UTF-8 編碼下是三個(gè)字節(jié)E4 BD A0URL 編碼后就是%E4%BD%A0。空格在 URL 里會(huì)被編碼成%20在 form 表單場(chǎng)景下也可能變成這一點(diǎn)后面講。所以編碼這個(gè)過(guò)程是完全可逆的不是加密只是把原本有特殊含義或超出 ASCII 范圍的字符轉(zhuǎn)成 URL 中安全的形態(tài)。這里要特別強(qiáng)調(diào)一個(gè)認(rèn)知編碼不是為了讓數(shù)據(jù)更安全而是為了讓數(shù)據(jù)在 URL 這個(gè)“傳輸管道”里不產(chǎn)生歧義。如果你以為編碼能防篡改、防窺探那方向就錯(cuò)了。2.2 誰(shuí)必須編碼、誰(shuí)千萬(wàn)別編碼一張表說(shuō)清楚編碼最怕的不是不編而是亂編。很多人一股腦用encodeURIComponent把整個(gè) URL 編一遍結(jié)果冒號(hào)、斜杠全變成%3A%2F%2F服務(wù)端收到后還原不出合法地址直接報(bào) 404。你必須搞清楚 URL 里不同位置對(duì)編碼的要求。位置正確的編碼姿勢(shì)說(shuō)明整個(gè) URL 作為參數(shù)值encodeURIComponent整個(gè) URL因?yàn)榇藭r(shí) URL 是別人的參數(shù)值內(nèi)部所有保留字符都要轉(zhuǎn)義query 鍵值對(duì)的值encodeURIComponent每個(gè)值特別是值里可能含有、、?、#時(shí)path 里的路徑段encodeURI或手動(dòng)轉(zhuǎn)義保留/不編碼但路徑里的中文、空格要編scheme、host、port不編碼這些是 URL 的基礎(chǔ)骨架編碼了直接失效fragment可編碼可不編碼它不發(fā)給服務(wù)器主要是前端自己用前端 JavaScript 里encodeURI和encodeURIComponent的區(qū)別就在這encodeURI會(huì)保留: / ? # 這些字符不編碼適合處理整段 URLencodeURIComponent會(huì)把這些全部編碼適合處理參數(shù)值。我見(jiàn)過(guò)最多的低級(jí)錯(cuò)誤就是用encodeURI去編碼參數(shù)值結(jié)果參數(shù)里只要含個(gè)整個(gè) query 就被拆成了兩個(gè)參數(shù)服務(wù)端解析后參數(shù)直接丟失或者值錯(cuò)亂。后端開(kāi)發(fā)同樣要注意像 Java 的URLEncoder.encode有個(gè)坑它會(huì)把空格編碼成而在 URL path 里應(yīng)該表示加號(hào)本身。所以在不同場(chǎng)景下你可能需要對(duì)和空格做額外處理。2.3 “URL解碼失敗”的真實(shí)場(chǎng)景復(fù)盤熱詞里有“url解碼失敗”這個(gè)詞條。我復(fù)盤幾個(gè)實(shí)際項(xiàng)目里遇到過(guò)的高頻問(wèn)題你對(duì)照看看自己踩過(guò)沒(méi)有。第一類是二次解碼導(dǎo)致語(yǔ)義錯(cuò)亂。流程是前端把%2F當(dāng)成參數(shù)傳給后端后端框架自動(dòng)解碼一次拿到/然后路由匹配時(shí)/被當(dāng)成了路徑分隔符于是路徑就多了一段接口直接返回 404。解決方式通常是前端把%也編碼掉傳%252F后端解一次變成%2F再手動(dòng)解一次才得到/問(wèn)題是你必須約定好到底解幾次。第二類是字符集不統(tǒng)一。同一個(gè)鏈接有的端用 UTF-8 編碼有的端用 GBK 編碼服務(wù)端用 UTF-8 去解碼 GBK 的內(nèi)容出來(lái)的就是亂碼?，F(xiàn)在行業(yè)趨勢(shì)是全面 UTF-8但存量系統(tǒng)里還會(huì)有 GBK 的接口排查思路就是先確認(rèn)編碼是在哪一環(huán)寫入的、在哪一環(huán)讀出來(lái)的兩端對(duì)齊。第三類是鏈接被截?cái)?。用戶把一長(zhǎng)串帶參數(shù)的鏈接貼在聊天工具里聊天工具自己做了 URL 識(shí)別遇到特殊字符就截?cái)嗷蛘咦詣?dòng)折行復(fù)制出來(lái)就是不完整的。這種問(wèn)題沒(méi)法從代碼層面根治只能從產(chǎn)品層面盡量縮短 URL或者用短鏈接包裝。3. 自定義Scheme從com.greenpoint到dps的App喚起鏈路如果說(shuō)標(biāo)準(zhǔn) URL 是瀏覽器和服務(wù)器之間的語(yǔ)言那么自定義 Scheme 就是移動(dòng)端 App 之間、App 和 Web 之間互相喊話的暗號(hào)。熱詞里那些奇奇怪怪的前綴其實(shí)就是各個(gè) App 注冊(cè)的私有協(xié)議。3.1 Scheme是怎么注冊(cè)進(jìn)系統(tǒng)的每次你看到com.greenpoint://或者snssdk1128://這樣的前綴意味著這個(gè) App 在系統(tǒng)里注冊(cè)過(guò)自己的 Scheme。Android 端是在 Manifest 里聲明 intent-filteriOS 端是在 Info.plist 里配置 CFBundleURLTypes。系統(tǒng)層面的工作機(jī)制大概是當(dāng)某個(gè)鏈接要被打開(kāi)時(shí)系統(tǒng)先解析 scheme 部分然后遍歷所有已注冊(cè)的 App找到能處理這個(gè) scheme 的就去喚起它同時(shí)把 scheme 后面的內(nèi)容作為一個(gè)整體傳給該 App。App 拿到這串東西后再自己解析 host、path、query決定要跳轉(zhuǎn)到哪一個(gè)頁(yè)面、執(zhí)行什么動(dòng)作。這就是為什么同一個(gè) scheme 后面跟的內(nèi)容能千奇百怪android.mc10086.activity、webview、p、v1/easybrowse/open這些本質(zhì)上是 App 內(nèi)部定義的“路徑”用來(lái)區(qū)分不同業(yè)務(wù)入口。3.2 拆解幾個(gè)主流App的Scheme寫法我挑幾個(gè)典型例子來(lái)拆。先看中國(guó)移動(dòng)的com.greenpoint://android.mc10086.activity?urlhttps%3a%2f%2fdev.coc.1008scheme 是com.greenpointhost 是android.mc10086.activityquery 里有個(gè)url字段值是https%3a%2f%2fdev.coc.1008解碼后是https://dev.coc.1008再看抖音的snssdk1128://webview?urlhttps%3a%2f%2faweme.snssdk.com%2ffalcon%2fdouyischeme 是snssdk1128host 是webview同樣有一個(gè)url參數(shù)承載真實(shí)的目標(biāo)地址淘寶的dps://p?url...、百度的baiduboxapp://v1/easybrowse/open?url...套路完全一致。你發(fā)現(xiàn)沒(méi)有這些 App 的 Scheme 鏈接幾乎都遵循同一種設(shè)計(jì)外層是 App 內(nèi)部導(dǎo)航協(xié)議內(nèi)層用一個(gè)編碼過(guò)的 url 字段給 WebView 或內(nèi)置瀏覽器提供最終目標(biāo)地址。為什么要編碼內(nèi)層 URL因?yàn)槿绻痪幋a你會(huì)在 URL 里看到這樣的結(jié)構(gòu)dps://p?urlhttps://main.m.taobao.com/detail/index.html?id123utm_sourcex外層的 query 會(huì)從第一個(gè)開(kāi)始被截?cái)嘁驗(yàn)榻馕銎鳠o(wú)法區(qū)分這個(gè)是屬于外層還是內(nèi)層。編碼之后內(nèi)層 URL 變成一個(gè)沒(méi)有歧義的參數(shù)值外層解析完再單獨(dú)解碼一次就能還原完整內(nèi)層地址。我在很多項(xiàng)目里都是這么約定參數(shù)的這也應(yīng)該是你設(shè)計(jì) Scheme 鏈接時(shí)的默認(rèn)標(biāo)準(zhǔn)。3.3 工程里寫Scheme的5個(gè)硬性規(guī)范這些規(guī)范是踩坑踩出來(lái)的建議直接抄進(jìn)你的開(kāi)發(fā)規(guī)范文檔參數(shù)鍵名統(tǒng)一固定用url、from、type這樣的統(tǒng)一鍵名避免同一個(gè) App 各端各寫一套。你實(shí)際維護(hù)過(guò)的項(xiàng)目越大越能體會(huì)統(tǒng)一參數(shù)名的價(jià)值。嵌 URL 必須編碼凡是參數(shù)值里要放 URL 的一律encodeURIComponent后再拼進(jìn)去。解碼時(shí)統(tǒng)一解碼一次不準(zhǔn)多處解。預(yù)留版本字段好的 Scheme 設(shè)計(jì)會(huì)在開(kāi)頭帶版本信息比如myapp://v2/page。因?yàn)?App 版本不可能全部同時(shí)升級(jí)老版本拿到新格式鏈接可能直接崩潰有版本號(hào)可以寫兼容邏輯。處理未安裝場(chǎng)景Scheme 喚起有一個(gè)天然缺陷——如果用戶沒(méi)裝這個(gè) App鏈接點(diǎn)了沒(méi)反應(yīng)。常規(guī)做法是先嘗試喚 Scheme捕獲超時(shí)或失敗后再跳轉(zhuǎn)應(yīng)用市場(chǎng)或下載頁(yè)。有條件的話用 Universal LinkiOS和 App LinksAndroid做兜底他們走 HTTPS 域名驗(yàn)證未安裝時(shí)可以優(yōu)雅降級(jí)到網(wǎng)頁(yè)。日志脫敏很多 Scheme 鏈接里會(huì)帶用戶標(biāo)識(shí)、token 這類敏感信息。打日志時(shí)別整條鏈接打出來(lái)只打印 scheme 和 host 部分防止日志泄密。4. 盤一盤日常開(kāi)發(fā)里的URL高頻坑這一章我挑幾個(gè)出現(xiàn)頻率極高、幾乎每個(gè)團(tuán)隊(duì)都會(huì)遇到的實(shí)際問(wèn)題展開(kāi)講每個(gè)都附帶可以落地的解法。4.1 驗(yàn)證URL有效性別拿正則硬剛“js驗(yàn)證url有效性”是我看到的熱詞之一。很多同事一開(kāi)口就是“寫個(gè)正則校驗(yàn)一下鏈接合不合法”然后貼出這種/^https?:\/\//.test(str)這個(gè)正則只能說(shuō)明字符串以 http 或 https 開(kāi)頭完全校驗(yàn)不了“這是個(gè)有效 URL”。更尷尬的是它直接排除了你上面看到的那些自定義 Scheme。在瀏覽器環(huán)境里判斷一個(gè)字符串是不是合法絕對(duì) URL最穩(wěn)的方式是直接讓瀏覽器解析它function isValidUrl(str) { try { const u new URL(str); return !!u.protocol !!u.host; } catch (e) { return false; } }new URL()內(nèi)部會(huì)做完整語(yǔ)法解析解析不過(guò)就拋異常。但要注意兩點(diǎn)第一它不校驗(yàn)域名是否真實(shí)存在第二它會(huì)對(duì)解析作自動(dòng)糾偏比如你傳example.com/path它解析出來(lái)是example.com/path沒(méi)有 scheme這種需要單獨(dú)判斷。后端 Python 的寫法更直白from urllib.parse import urlparse def is_valid_url(url): try: result urlparse(url) return result.scheme in (http, https) and bool(result.netloc) except ValueError: return False這種驗(yàn)證只能證明“格式上像個(gè) URL”如果你要驗(yàn)證“這個(gè) URL 真的能訪問(wèn)”那就得發(fā)請(qǐng)求比如用requests.head(url, allow_redirectsTrue, timeout3)看返回狀態(tài)碼是不是 2xx 或 3xx。我個(gè)人的分層策略是前端做格式校驗(yàn)防止用戶輸錯(cuò)后端做可達(dá)性校驗(yàn)防止業(yè)務(wù)數(shù)據(jù)出錯(cuò)。4.2 用Fiddler改URL抓包調(diào)參與重定向的正確姿勢(shì)熱詞里有“fiddler更改url”。Fiddler 不只是抓包工具它還能當(dāng)“中間人”幫你改請(qǐng)求這個(gè)功能在調(diào)試時(shí)特別有用。我常用的是 FiddlerScript在OnBeforeRequest里加規(guī)則把所有指向舊域名的請(qǐng)求重寫到新域名if (oSession.HostnameIs(api.old.com)) { oSession.fullUrl oSession.fullUrl.Replace(api.old.com, api.new.com); }另一個(gè)場(chǎng)景是后端返回了某個(gè) URL你想在前端驗(yàn)證不同參數(shù)的效果直接在 Fiddler 里把響應(yīng)體中的 URL 替換掉不用動(dòng)代碼。改 URL 有個(gè)隱藏坑你把域名改掉了請(qǐng)求頭里的 Host、Referer、Origin 可能還是原來(lái)的值?，F(xiàn)在很多后端接口會(huì)校驗(yàn)這些頭改裝完報(bào) 403 或 401 往往就是這個(gè)原因。我一般會(huì)順手把請(qǐng)求頭也改了至少確保 Host 和 URL 里的域名一致。手機(jī)抓包調(diào)試時(shí)還要注意代理裝好之后要確認(rèn)系統(tǒng)沒(méi)有開(kāi)啟“僅信任用戶證書(shū)”之類的選項(xiàng)不然 HTTPS 解密會(huì)失敗導(dǎo)致你看到的全是加密亂碼。4.3 短鏈還原、日歷訂閱、音樂(lè)直鏈URL的經(jīng)典衍生玩法短鏈每天隨處可見(jiàn)但“expand short url”這個(gè)需求經(jīng)常被忽略。短鏈接的原理就是 HTTP 302 重定向你請(qǐng)求短鏈地址服務(wù)器在響應(yīng)頭里的 Location 字段給出真實(shí)地址瀏覽器再跳到那里。所以在代碼里還原短鏈正確姿勢(shì)不是直接 GET而是發(fā) HEAD 請(qǐng)求或者帶allow_redirectsFalse的 GET拿到 Location 就讀出來(lái)了import requests resp requests.head(https://短鏈地址, allow_redirectsFalse) if resp.status_code 302: print(resp.headers.get(Location))為什么不直接 GET因?yàn)橥暾?GET 會(huì)跟著重定向鏈一路執(zhí)行下去白白消耗響應(yīng)體流量和時(shí)間而且你只想看跳轉(zhuǎn)目標(biāo)并不想下載目標(biāo)頁(yè)內(nèi)容。日歷訂閱 URL 也很有意思。webcal://是日歷訂閱的常用協(xié)議很多平臺(tái)的分享按鈕看起來(lái)是webcal://example.com/calendar.ics。你直接放在瀏覽器里打開(kāi)大概率無(wú)效所以代碼處理時(shí)一般會(huì)把webcal://替換成https://去下載.ics文件再讓系統(tǒng)日歷識(shí)別。很多“訂閱日歷 URL 鏈接大全”網(wǎng)站干的就是這個(gè)轉(zhuǎn)換工作。至于“音樂(lè) URL 地址在線生成”這類工具本質(zhì)上是把一首歌的 CDN 地址拼接出來(lái)加上合適的簽名參數(shù)。拆解一個(gè)這類 URL你通常會(huì)看到https://cdn.example.com/music/12345.mp3?signabcdefexpire1699999999sign是簽名expire是過(guò)期時(shí)間防止鏈接被盜用。遇到 403十有八九是簽名過(guò)期或者請(qǐng)求頭里的 Referer 不對(duì)加一個(gè)正確的 Referer 通常能解決。4.4 token接口報(bào)“URL請(qǐng)求失敗”怎么定位熱詞里有一條 JSON 風(fēng)格的消息“token exchange failed: error sending request for url (https://...)”。這種報(bào)錯(cuò)一般出現(xiàn)在 OAuth 2.0 的 token 換取環(huán)節(jié)也就是你的后端拿 code 去換 access_token 時(shí)向授權(quán)服務(wù)器發(fā)請(qǐng)求失敗。我梳理了幾個(gè)高頻根因按概率排序redirect_uri不一致。授權(quán)服務(wù)器要求回調(diào)地址必須和注冊(cè)時(shí)完全一致包括協(xié)議、域名、端口、路徑任何一處差一個(gè)字符都會(huì)拒絕。很多人改過(guò)域名忘了改授權(quán)配置。請(qǐng)求體拼接錯(cuò)誤。用拼接參數(shù)時(shí)某個(gè)參數(shù)值里自帶或?qū)е聟?shù)錯(cuò)亂。統(tǒng)一用urlencode處理鍵值對(duì)別手拼。網(wǎng)絡(luò)出口問(wèn)題。服務(wù)器所在環(huán)境訪問(wèn)不了授權(quán)服務(wù)器可能是防火墻、DNS 解析錯(cuò)誤或路由不通。先curl -I試一下。證書(shū)問(wèn)題。環(huán)境里少了根證書(shū)或者用了自簽名證書(shū)導(dǎo)致 TLS 校驗(yàn)失敗。必要時(shí)把SSL_CERT_FILE指到正確的證書(shū)鏈。超時(shí)。授權(quán)服務(wù)器響應(yīng)慢默認(rèn)超時(shí)時(shí)間太短連續(xù)重試又觸發(fā)限流。排查順序建議是先看異常堆棧確認(rèn)卡在哪一步再用curl -v手工模擬同一個(gè)請(qǐng)求對(duì)比結(jié)果最后抓包看實(shí)際發(fā)出的請(qǐng)求和返回內(nèi)容。這種問(wèn)題絕大多數(shù)是配置錯(cuò)而非代碼邏輯錯(cuò)所以別急著改代碼先對(duì)配置。5. URL問(wèn)題速查表癥狀、根因、處置一頁(yè)紙我把前面講的內(nèi)容整理成一張速查表方便你遇到問(wèn)題時(shí)直接對(duì)著查。這些都是真實(shí)項(xiàng)目中出現(xiàn)率最高的場(chǎng)景。癥狀根因處置方式解碼后中文顯示亂碼編碼字符集不一致UTF-8 vs GBK統(tǒng)一使用 UTF-8解碼時(shí)明確指定字符集參數(shù)里的導(dǎo)致參數(shù)被拆分參數(shù)值未編碼對(duì)每個(gè)參數(shù)值用encodeURIComponentURL 中的%2F導(dǎo)致路徑多出一段服務(wù)端自動(dòng)解碼后按路徑解析傳參時(shí)用%252F并在代碼中約定解碼次數(shù)第三方登錄后拿不到 tokentoken 放在 fragment 中前端用location.hash讀取而非search短鏈接還原后地址不正確請(qǐng)求方式導(dǎo)致未讀到 Location用 HEAD 請(qǐng)求或關(guān)閉自動(dòng)重定向讀響應(yīng)頭scheme 鏈接在微信里打不開(kāi)微信內(nèi)置瀏覽器限制使用白名單 scheme 或 Universal Link 兜底接口報(bào) token exchange failedredirect_uri / 網(wǎng)絡(luò) / 證書(shū)問(wèn)題優(yōu)先核對(duì)授權(quán)配置再用curl -v手動(dòng)復(fù)現(xiàn)Fiddler 改域名后請(qǐng)求報(bào) 403Host、Referer 與目標(biāo)不一致同步修改請(qǐng)求頭保持與目標(biāo)一致順手再補(bǔ)幾條我個(gè)人的長(zhǎng)期習(xí)慣都是教訓(xùn)換來(lái)的一是所有 URL 拼接不做手拼字符串統(tǒng)一用各語(yǔ)言自帶的 URI 構(gòu)建類比如 Java 的UriComponentsBuilder、Python 的urljoin、JavaScript 的URL對(duì)象。手拼字符串很容易漏加/或者多編碼一層。二是每次對(duì)接外部系統(tǒng)先把對(duì)方回調(diào)鏈接、參數(shù)列表、編碼要求整理成文檔放進(jìn)項(xiàng)目倉(cāng)庫(kù)。等項(xiàng)目大了你會(huì)發(fā)現(xiàn)“當(dāng)時(shí)誰(shuí)定的這個(gè)參數(shù)名”這類問(wèn)題有多讓人頭疼。三是線上日志里記錄 URL 時(shí)做截?cái)嗪兔撁粲绕涫菐?token、授權(quán)碼的鏈接。出于安全考慮這也是審計(jì)總會(huì)盯的地方。四是本地開(kāi)發(fā)環(huán)境統(tǒng)一掛一個(gè)抓包工具不管前端后端報(bào)錯(cuò)先看真實(shí)請(qǐng)求長(zhǎng)什么樣再去猜代碼里發(fā)生了什么。省下的時(shí)間絕對(duì)值得。這個(gè)內(nèi)容最后再分享一個(gè)實(shí)際項(xiàng)目里摸出來(lái)的小技巧當(dāng)你處理那種復(fù)雜嵌套的 URL比如 Scheme 里套 Web URL、Web URL 里再套重定向參數(shù)最穩(wěn)妥的調(diào)試方法是先手工把每一層解碼敲出來(lái)確認(rèn)意圖再在代碼里逐步還原。把“人腦解析”和“代碼解析”的結(jié)果對(duì)齊再?gòu)?fù)雜的鏈接也能在幾分鐘內(nèi)理清。制維護(hù)一個(gè)“URL 規(guī)范檢查單”把今天聊到的這些點(diǎn)都列進(jìn)去每次改動(dòng)照著過(guò)一遍很多坑根本不會(huì)發(fā)生。