絡(luò)層開發(fā)：NSHTTPURLResponse響應(yīng)頭解析實(shí)戰(zhàn)與踩坑指南)
寫網(wǎng)絡(luò)層代碼的時(shí)候很多 iOS 開發(fā)者都會(huì)遇到同一個(gè)困惑request 發(fā)出去了data 也回來了但響應(yīng)頭里到底藏了什么信息、怎么才能優(yōu)雅地拿到這些信息、以及拿回來之后能做什么腦子里經(jīng)常是一團(tuán)漿糊。NSHTTPURLResponse 這個(gè)類名聽起來很基礎(chǔ)但真正用起來坑卻不少尤其是在處理緩存、斷點(diǎn)續(xù)傳、Cookie 服務(wù)等場(chǎng)景時(shí)對(duì)響應(yīng)數(shù)據(jù)的解析能力直接決定了功能能否穩(wěn)定落地。這篇內(nèi)容就圍繞 NSHTTPURLResponse 的數(shù)據(jù)解析展開從類的關(guān)系、屬性語義、實(shí)際使用場(chǎng)景到踩坑記錄完整梳理一遍適合正在做網(wǎng)絡(luò)層封裝、或者準(zhǔn)備處理下載任務(wù)和緩存邏輯的 iOS 開發(fā)者作為參考。1. 先搞清楚 NSHTTPURLResponse 到底是什么1.1 它和 NSURLResponse 的關(guān)系很多新人會(huì)把 NSURLResponse 和 NSHTTPURLResponse 混為一談拿出來就用等到想讀 statusCode 的時(shí)候發(fā)現(xiàn)沒這個(gè)屬性才開始懷疑人生。實(shí)際上 NSURLResponse 是 Foundation 框架里對(duì)“一次網(wǎng)絡(luò)請(qǐng)求返回的響應(yīng)元數(shù)據(jù)”的抽象基類它只包含 URL、MIMEType、期望內(nèi)容長度 expectedContentLength、文本編碼名 textEncodingName 這四樣?xùn)|西。而 NSHTTPURLResponse 是它的子類專門針對(duì) HTTP/HTTPS 協(xié)議擴(kuò)展了兩個(gè)關(guān)鍵字段一個(gè)是 HTTP 狀態(tài)碼 statusCode另一個(gè)是響應(yīng)頭字典 allHeaderFields。也就是說如果你發(fā)起的是 http:// 或 https:// 請(qǐng)求URLSession 實(shí)際返回給你的響應(yīng)對(duì)象就是 NSHTTPURLResponse 的實(shí)例可以直接做類型轉(zhuǎn)換。這里要特別注意一個(gè)細(xì)節(jié)并不是所有網(wǎng)絡(luò)請(qǐng)求都會(huì)返回 NSHTTPURLResponse。比如加載本地文件、或者自定義協(xié)議的時(shí)候返回的可能是 NSURLResponse 本身。所以在代碼里做類型判斷是必要的不要盲目強(qiáng)轉(zhuǎn)。實(shí)際項(xiàng)目中我習(xí)慣用if let httpResponse response as? HTTPURLResponse這種安全轉(zhuǎn)換的寫法既避免崩潰也方便后面統(tǒng)一處理。1.2 一個(gè)典型的響應(yīng)生命周期要理解 NSHTTPURLResponse最好從一次完整的 HTTP 請(qǐng)求去反推它的位置?？蛻舳送ㄟ^ URLSession 發(fā)起請(qǐng)求經(jīng)過 DNS 解析、TCP 連接、TLS 握手HTTPS然后發(fā)送請(qǐng)求行和請(qǐng)求頭。服務(wù)器處理完之后返回狀態(tài)行比如 HTTP/1.1 200 OK、響應(yīng)頭一堆 key-value和響應(yīng)體實(shí)際數(shù)據(jù)。NSHTTPURLResponse 承載的就是“狀態(tài)行 響應(yīng)頭”這兩個(gè)部分的信息響應(yīng)體則是通過 URLSession 的 dataTask 或者 downloadTask 的另一個(gè)回調(diào)參數(shù)拿到的。換句話說它是請(qǐng)求結(jié)果的第一道閘門——在讀取 data 之前你應(yīng)該先通過它判斷這次請(qǐng)求到底成沒成功、返回的是什么類型的數(shù)據(jù)、是否需要走下一步邏輯。在實(shí)際開發(fā)中看到很多項(xiàng)目直接在 completion handler 里判斷 data 是否為空不檢查狀態(tài)碼也不讀響應(yīng)頭。這樣做一旦遇到服務(wù)器返回 4xx、5xx 且?guī)уe(cuò)誤頁面 HTML 的情況很容易把錯(cuò)誤數(shù)據(jù)當(dāng)成正常業(yè)務(wù)數(shù)據(jù)處理產(chǎn)生很難排查的線上問題。養(yǎng)成先解析 NSHTTPURLResponse、再處理 data 的習(xí)慣能規(guī)避掉相當(dāng)一部分低級(jí) bug。2. 響應(yīng)頭信息的獲取與解析2.1 如何拿到 NSHTTPURLResponse 對(duì)象在 URLSession 體系的回調(diào)里獲取 NSHTTPURLResponse 非常簡單。比如使用 dataTask 的 completion handlerlet task URLSession.shared.dataTask(with: url) { data, response, error in guard let httpResponse response as? HTTPURLResponse else { // 不是 HTTP 協(xié)議或者請(qǐng)求失敗 return } print(狀態(tài)碼: \(httpResponse.statusCode)) print(響應(yīng)頭: \(httpResponse.allHeaderFields)) } task.resume()如果你用的是代理模式URLSessionDelegate響應(yīng)信息會(huì)出現(xiàn)在urlSession(_:dataTask:didReceive:completionHandler:)這個(gè)方法里同樣是先轉(zhuǎn)類型再使用。注意用URLSessionConfiguration做自定義 Session 時(shí)委托回調(diào)里的 response 參數(shù)也需要做同樣的類型轉(zhuǎn)換。func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive response: URLResponse, completionHandler: escaping (URLSession.ResponseDisposition) - Void) { if let httpResponse response as? HTTPURLResponse { // 這里就可以讀取狀態(tài)碼和響應(yīng)頭了 print(status: \(httpResponse.statusCode)) } completionHandler(.allow) }這里有個(gè)經(jīng)驗(yàn)點(diǎn)很多人在 completion handler 里喜歡直接打印整個(gè) response比如print(response)。這會(huì)輸出一堆調(diào)試信息但真正要拿字段的時(shí)候反而容易對(duì)不上號(hào)。建議第一步永遠(yuǎn)是 safe cast第二步才是取數(shù)據(jù)。2.2 allHeaderFields 的讀取與大小寫陷阱allHeaderFields 是 NSHTTPURLResponse 里最常用的屬性它返回一個(gè)[AnyHashable : Any]類型的字典里面裝的是服務(wù)器返回的原始響應(yīng)頭字段。但這個(gè)字典有一個(gè)特別容易踩坑的地方key 的大小寫并不穩(wěn)定。HTTP 協(xié)議本身規(guī)定頭字段名是不區(qū)分大小寫的比如 Content-Type、content-type、CONTENT-TYPE 在語義上是同一個(gè)。但 iOS 系統(tǒng)在把這些字段塞進(jìn)字典時(shí)并沒有保證統(tǒng)一格式。實(shí)測(cè)下來絕大多數(shù)服務(wù)器返回的響應(yīng)頭會(huì)保留原始大小寫但有些代理服務(wù)器或者 CDN 節(jié)點(diǎn)會(huì)對(duì)頭字段做規(guī)范化處理原本是小寫的 key 可能會(huì)變成首字母大寫也可能保持小寫。如果你用allHeaderFields[content-type]去取服務(wù)器回的是Content-Type那拿到就是 nil而且這種問題在真機(jī)上偶發(fā)、模擬器上正常非常難排查。所以穩(wěn)妥的做法是不直接通過下標(biāo)訪問而是寫一個(gè)大小寫不敏感的查找方法。我自己項(xiàng)目里常用的是一個(gè)擴(kuò)展extension HTTPURLResponse { func headerValue(for key: String) - String? { guard let fields allHeaderFields as? [String: Any] else { return nil } for (k, v) in fields { if k.caseInsensitiveCompare(key) .orderedSame { return v as? String } } return nil } }這個(gè)擴(kuò)展在團(tuán)隊(duì)內(nèi)部流轉(zhuǎn)了好幾個(gè)項(xiàng)目遇到不同后端返回風(fēng)格不同的頭字段時(shí)從來不出幺蛾子。用caseInsensitiveCompare去遍歷匹配雖然效率上不如直接取鍵但響應(yīng)頭一般也就十幾個(gè)字段這點(diǎn)遍歷開銷完全可以忽略換來的是接入各種后端服務(wù)時(shí)的從容。2.3 關(guān)鍵響應(yīng)頭字段的業(yè)務(wù)價(jià)值響應(yīng)頭里不是每個(gè)字段在業(yè)務(wù)層都有用但有幾個(gè)非常關(guān)鍵值得專門寫工具方法去解析。Content-Type 是最重要的一個(gè)它告訴你響應(yīng)體到底是什么格式。這里需要注意的是完整的 Content-Type 可能帶 charset 參數(shù)比如text/html; charsetutf-8。解析的時(shí)候要先把分號(hào)后面的東西去掉取到真正的 MIME 類型再單獨(dú)提取字符集。很多講網(wǎng)絡(luò)庫的文章會(huì)忽略這一步直接拿整串去匹配text/html結(jié)果帶著; charsetutf-8就永遠(yuǎn)匹配不上了。Content-Length 在 iOS 的 NSHTTPURLResponse 里對(duì)應(yīng)的是 expectedContentLength這個(gè)屬性的類型是 Int64表示服務(wù)器聲明的內(nèi)容長度。它有兩個(gè)坑一個(gè)是沒有這個(gè)字段時(shí)值為 NSURLResponseUnknownLength實(shí)際是 -1做進(jìn)度條時(shí)必須對(duì) -1 做特殊處理另一個(gè)是服務(wù)器返回了不確定長度的內(nèi)容比如 chunked 傳輸時(shí)這個(gè)值也是 -1。所以下載進(jìn)度計(jì)算不能只靠這個(gè)字段更可靠的方式是拿已接收數(shù)據(jù)量除以總數(shù)據(jù)量時(shí)對(duì) -1 兜底成不確定進(jìn)度。Cache-Control 和 ETag 是做緩存時(shí)要重點(diǎn)解析的字段。Cache-Control 里可能有 no-cache、no-store、max-age 等指令每個(gè)指令都對(duì)應(yīng)不同的緩存策略。ETag 則用于條件請(qǐng)求做增量更新時(shí)配合 If-None-Match 使用。Set-Cookie 字段在某些需要手動(dòng)管理 Cookie 的場(chǎng)景下也得解析。雖然 URLSession 默認(rèn)的 Cookie 存儲(chǔ)機(jī)制會(huì)自動(dòng)處理大部分情況但在 WebView 和原生網(wǎng)絡(luò)棧共存、或者需要跨進(jìn)程共享登錄態(tài)的 App 里手動(dòng)讀取 Set-Cookie 依然有不可替代的作用。所有這些字段的解析都不要在主線程做字符串處理。雖然響應(yīng)頭解析本身量不大但當(dāng)下載任務(wù)多、請(qǐng)求頻繁時(shí)堆在主線程上的字符串操作會(huì)讓列表滑動(dòng)掉幀。放到后臺(tái)隊(duì)列統(tǒng)一解析完把結(jié)果整理成模型再拋給主線程比較穩(wěn)妥。3. 狀態(tài)碼、編碼與內(nèi)容協(xié)商的細(xì)節(jié)3.1 statusCode 的正確打開方式statusCode 反映的是 HTTP 服務(wù)器對(duì)這次請(qǐng)求的最終處理結(jié)果。常見的有 200 OK、201 Created、204 No Content、301/302 重定向、304 Not Modified、400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、500 Internal Server Error 等。很多項(xiàng)目拿到任何一個(gè)非 200 狀態(tài)碼就直接拋錯(cuò)誤這種一刀切的做法在業(yè)務(wù)上是有隱患的。比如 204 表示“服務(wù)端處理成功但沒返回內(nèi)容”如果接口設(shè)計(jì)成刪除類操作返回 204你把 204 當(dāng)錯(cuò)誤處理就出大問題了。再比如 304 Not Modified在緩存場(chǎng)景里是一個(gè)正常的“命中緩存”信號(hào)返回它恰恰意味著之前的緩存還能用這時(shí)應(yīng)該直接用本地緩存而不是報(bào)錯(cuò)。所以一個(gè)成熟的網(wǎng)絡(luò)層判斷邏輯不是簡單地statusCode 200或者statusCode 400而是要分業(yè)務(wù)場(chǎng)景if 200...299 ~ httpResponse.statusCode { // 成功繼續(xù)處理 data } else if httpResponse.statusCode 304 { // 使用緩存 } else if 300...399 ~ httpResponse.statusCode { // 重定向但不建議在這里處理交給 URLSession } else { // 4xx / 5xx統(tǒng)一走錯(cuò)誤邏輯 }這里額外提一個(gè)細(xì)節(jié)URLSession 默認(rèn)對(duì)重定向的處理規(guī)則是自動(dòng)跟隨的它內(nèi)部會(huì)重新發(fā)起請(qǐng)求最終你拿到的 response 更像是最后一次重定向的結(jié)果。如果你要手動(dòng)控制重定向比如跨域跳轉(zhuǎn)時(shí)做 cookie 校驗(yàn)得把 session 的 delegate 實(shí)現(xiàn)urlSession(_:task:willPerformHTTPRedirection:newRequest:completionHandler:)而這個(gè)方法里拿到的原始 HTTPURLResponse恰恰就是重定向發(fā)生之前的那個(gè)響應(yīng)。3.2 textEncodingName 與字符集轉(zhuǎn)換NSURLResponse 的 textEncodingName 返回的是服務(wù)器在 Content-Type 里聲明使用的字符編碼名比如 utf-8、gbk 等。處理網(wǎng)絡(luò)數(shù)據(jù)的時(shí)候這個(gè)字段直接關(guān)系到 data 能不能被正確轉(zhuǎn)成字符串。iOS 原生 API 里把 data 轉(zhuǎn)成 String 一般用String(data:encoding:)但這個(gè)構(gòu)造函數(shù)要求傳入一個(gè)String.Encoding值而 textEncodingName 返回的是 IANA 字符集名比如 “utf-8”。這兩個(gè)體系并不完全一致需要做映射。Foundation 提供了一個(gè)String.Encoding的轉(zhuǎn)換入口let encodingRaw CFStringConvertIANACharSetNameToEncoding(textEncodingName as CFString) let encoding String.Encoding(rawValue: CFStringConvertEncodingToNSStringEncoding(encodingRaw))做這個(gè)轉(zhuǎn)換的時(shí)候會(huì)遇到一大類中文網(wǎng)站返回 gb2312 或 gbk 編碼的情況。這兩個(gè)字符集在 iOS 上轉(zhuǎn)換出來的String.Encoding是存在的但不少開發(fā)者習(xí)慣硬編碼.utf8導(dǎo)致中文亂碼。寫一個(gè)根據(jù) textEncodingName 動(dòng)態(tài)決定 encoding 的工具方法是中文網(wǎng)絡(luò)環(huán)境下做內(nèi)容解析的基本功。還需要注意一種情況有些服務(wù)器返回的 Content-Type 里沒寫 charset此時(shí) textEncodingName 是 nil。如果你硬要按某個(gè)編碼解碼就可能出現(xiàn)半亂碼。這種情況下需要自己從業(yè)務(wù)角度做個(gè)兜底比如優(yōu)先嘗試 UTF-8再退回 GBK 嘗試能解出合法字符就用哪個(gè)。3.3 內(nèi)容協(xié)商Content-Type、Accept、Content-Encoding內(nèi)容協(xié)商這個(gè)概念在 iOS 里接觸的人不多但在做多端接口設(shè)計(jì)時(shí)非常重要。簡單說客戶端通過請(qǐng)求頭里的 Accept 告訴服務(wù)器自己能接收什么類型服務(wù)器通過響應(yīng)頭里的 Content-Type 告訴客戶端實(shí)際返回了什么類型。NSHTTPURLResponse 的 MIMEType 屬性其實(shí)就是從 Content-Type 里解析出來的純類型部分比如 application/json、image/png、text/html。判斷一個(gè)響應(yīng)體怎么解析時(shí)應(yīng)該優(yōu)先看 MIMEType 而不是隨便猜switch httpResponse.mimeType?.lowercased() { case application/json: // JSON 解析邏輯 case image/png, image/jpeg: // 圖片處理邏輯 case text/html: // HTML 解析邏輯 default: // 通用二進(jìn)制處理 }Content-Encoding 則是另一個(gè)容易被忽略的字段它表示響應(yīng)體在傳輸過程中是否經(jīng)過壓縮常見的值是 gzip。URLSession 在大多數(shù)情況下會(huì)自動(dòng)解壓 gzip但如果你拿到的是原始 NSData 且感覺解壓邏輯不對(duì)勁就要回頭看看 Content-Encoding 是不是寫了 gzip 而你用的接口層沒做任何解壓處理。自定義協(xié)議棧或者某些第三方緩存庫在手動(dòng)處理數(shù)據(jù)時(shí)這個(gè)字段必須檢查否則會(huì)出現(xiàn)數(shù)據(jù)解密后亂碼、文件校驗(yàn)失敗這類詭異問題。4. 實(shí)際項(xiàng)目中的幾種典型用法4.1 下載場(chǎng)景下的斷點(diǎn)續(xù)傳下載任務(wù)是 NSHTTPURLResponse 數(shù)據(jù)解析最有價(jià)值的應(yīng)用場(chǎng)景之一。實(shí)現(xiàn)斷點(diǎn)續(xù)傳時(shí)客戶端會(huì)在請(qǐng)求頭里帶上 Range 字段服務(wù)器如果支持范圍請(qǐng)求會(huì)返回 206 Partial Content同時(shí)響應(yīng)頭里會(huì)帶 Content-Range告訴你本次返回的是文件的哪一段。這一步的解析直接決定了你本地文件碎片能不能正確拼接。Content-Range 的格式通常是bytes 0-1023/2048表示這次返回的是第 0 到第 1023 字節(jié)文件總大小是 2048 字節(jié)。解析時(shí)要把這三個(gè)數(shù)字完整提取出來我自己封裝時(shí)會(huì)從 allHeaderFields 里取出 Content-Range 后做一次正則匹配專門提取區(qū)間和總長度。同時(shí)判斷 statusCode 是不是 206只有 206 的時(shí)候才走斷點(diǎn)續(xù)傳邏輯如果服務(wù)器不支持 Range會(huì)返回 200 并附帶整個(gè)文件這時(shí)需要把本地已下載的部分丟棄重新全量下載。判斷這個(gè)邏輯不能只依賴 Content-Range 是否存在因?yàn)橛行┓?wù)器的實(shí)現(xiàn)比較怪會(huì)同時(shí)返回 200 和 Content-Range這種情況下以 statusCode 為準(zhǔn)更穩(wěn)妥。另外這里有一個(gè)實(shí)際開發(fā)中遇到過的問題響應(yīng)頭里的 Content-Length 在 Range 請(qǐng)求里代表的是本次返回片段的大小而不是整個(gè)文件的大小。很多做文件下載的人在這里栽過跟頭——拿著 206 的 expectedContentLength 直接當(dāng)文件總大小去做進(jìn)度百分比進(jìn)度算到一半就超 100% 了?？偞笮?yīng)該從 Content-Range 的第三段取這一點(diǎn)要特別注意寫進(jìn)注釋。4.2 緩存驗(yàn)證與 ETagHTTP 緩存里有一個(gè)很重要的機(jī)制叫條件請(qǐng)求?？蛻舳耸状握?qǐng)求某個(gè)資源時(shí)服務(wù)器返回的響應(yīng)頭里會(huì)帶 ETag實(shí)體標(biāo)簽或者 Last-Modified最后修改時(shí)間。下次客戶端再請(qǐng)求同樣的資源時(shí)帶上 If-None-Match值為之前的 ETag或 If-Modified-Since值為之前的 Last-Modified去問服務(wù)器資源變了嗎沒變就返回 304 Not Modified變了就返回 200 和新數(shù)據(jù)。在這個(gè)過程中解析 NSHTTPURLResponse 的作用體現(xiàn)在首次響應(yīng)時(shí)把 ETag 和 Last-Modified 存下來以及收到 304 時(shí)判斷走不走緩存。在一個(gè)緩存庫或者網(wǎng)絡(luò)框架里這兩行解析代碼往往就是整個(gè)緩存體系的關(guān)鍵支點(diǎn)。存儲(chǔ)時(shí)要注意一個(gè)細(xì)節(jié)ETag 本身是帶引號(hào)的字符串比如abc123。存儲(chǔ)的時(shí)候保持原樣請(qǐng)求時(shí)原樣放到 If-None-Match 里不要手動(dòng)去引號(hào)。有些服務(wù)器比較嚴(yán)格引號(hào)去掉了一對(duì)不上就判斷失敗緩存就永遠(yuǎn)命中不了。4.3 Cookie 與會(huì)話保持URLSession 默認(rèn)會(huì)自動(dòng)處理服務(wù)器下發(fā)的 Set-Cookie把 Cookie 存進(jìn)存儲(chǔ)層后續(xù)請(qǐng)求自動(dòng)帶上。但在混合開發(fā)場(chǎng)景App 內(nèi)嵌 WebView、原生網(wǎng)絡(luò)棧又同時(shí)在跑時(shí)經(jīng)常發(fā)現(xiàn) WebView 里登錄的會(huì)話原生請(qǐng)求里拿不到反過來也一樣。這時(shí)候就需要手動(dòng)解析 Set-Cookie然后在原生和 WebView 之間同步 Cookie。拿到 Set-Cookie 之后主要做的事是提取 name、value、domain、path、expires 這幾個(gè)字段生成一個(gè)新的 Cookie 對(duì)象再通過 HTTPCookieStorage 寫入共享存儲(chǔ)。這里關(guān)鍵詞是HTTPCookieStorage.shared。解析 Set-Cookie 時(shí)不要試圖用正則全局匹配因?yàn)?Set-Cookie 可能出現(xiàn)在 allHeaderFields 里也可能有多個(gè)值。建議先把所有 Set-Cookie 值提取出來再一行一行解析避免多個(gè) Cookie 擠在同一個(gè)字符串里時(shí)互相干擾。在 iOS 11 之后URLSession 對(duì) Cookie 的處理更加智能但 HTTPCookieStorage 和 WKWebsiteDataStore 之間的同步仍然需要手動(dòng)橋接這部分的響應(yīng)頭解析在未來很長一段時(shí)間內(nèi)都不會(huì)過時(shí)。5. 常見問題與排查技巧實(shí)錄5.1 allHeaderFields 取不到值的坑之前提到過響應(yīng)頭 key 的大小寫問題實(shí)際上還有另一個(gè)坑某些字段在 allHeaderFields 里會(huì)出現(xiàn)在這個(gè)字典里但在某些 iOS 版本上從 HTTPURLResponse 的專用屬性如textEncodingName里取值卻是 nil。原因是系統(tǒng)解析的時(shí)候沒有把 Content-Type 里的 charset 提取出來導(dǎo)致 textEncodingName 落空。這種情況在服務(wù)器沒按規(guī)范把 charset 放在 Content-Type 最前面時(shí)最容易發(fā)生。比如服務(wù)器返回Content-Type: text/html;charsetutf-8注意中文字符集名通常有小寫系統(tǒng)能解析出 utf-8但如果返回Content-Type: text/html; charsetUTF-8有些版本也能正常。真正出問題的是那種把 charset 放中間或拼寫奇怪的響應(yīng)頭。排查時(shí)如果發(fā)現(xiàn) textEncodingName 為 nil就去 allHeaderFields 里撈原始 Content-Type 自己解析不要依賴系統(tǒng)給的結(jié)果。5.2 重定向后響應(yīng)信息的丟失有一類需求是在登錄后跟蹤重定向鏈路最終拿到真正的落地頁地址。默認(rèn)情況下URLSession 會(huì)自動(dòng)跟隨重定向你在 completion handler 中拿到的 HTTPURLResponse 是最后一次請(qǐng)求的結(jié)果中間那些 302 響應(yīng)頭和 Location 跳轉(zhuǎn)地址會(huì)被系統(tǒng)消化掉不會(huì)暴露給你。如果業(yè)務(wù)上必須要拿到重定向中間信息唯一的辦法是實(shí)現(xiàn) session delegate 里的willPerformHTTPRedirection方法。在那里面可以拿到將要被重定向的響應(yīng)對(duì)象讀取它的 statusCode 和 Location 字段做自定義處理后再?zèng)Q定允許還是取消重定向。這個(gè)環(huán)節(jié)容易犯的錯(cuò)誤是在 delegate 方法里修改了 NSURLRequest 的 header 或者 URL但沒有調(diào)用 completionHandler請(qǐng)求會(huì)一直掛著直到超時(shí)。真機(jī)上表現(xiàn)就是轉(zhuǎn)圈圈很久然后報(bào)超時(shí)錯(cuò)誤排查了老半天才發(fā)現(xiàn)是完成回調(diào)沒觸發(fā)。5.3 線程與線程安全UI 上讀取響應(yīng)頭字段沒問題但如果要做字符串解析、正則匹配、編碼轉(zhuǎn)換這類計(jì)算就要注意線程問題。URLSession 的 completion handler 默認(rèn)在一個(gè)后臺(tái)串行隊(duì)列執(zhí)行在這個(gè)回調(diào)里直接做 JSON 序列化和字符串轉(zhuǎn)換是可以的但一旦涉及 UI 更新或者訪問跨線程共享的可變字典就必須小心。我見過最典型的崩潰場(chǎng)景是多個(gè)下載任務(wù)并發(fā)完成各自的 completion handler 同時(shí)去操作同一個(gè)進(jìn)度數(shù)組沒有加鎖結(jié)果數(shù)組越界或者數(shù)據(jù)錯(cuò)亂。正確的做法是讓解析邏輯保持純凈——輸入 HTTPURLResponse 和 data輸出模型對(duì)象不碰全局可變狀態(tài)。所有的狀態(tài)更新統(tǒng)一回主線程或者用隊(duì)列串行執(zhí)行。5.4 不同 iOS 版本的兼容差異NSHTTPURLResponse 的核心 API 從很多年前就比較穩(wěn)定但細(xì)節(jié)上有過變化。比如在 iOS 13 及之后HTTPURLResponse 多了一個(gè)初始化方法允許你在模擬響應(yīng)時(shí)自定義 statusCode 和 headerFields這對(duì)單元測(cè)試非常有用。寫測(cè)試用例時(shí)可以用這個(gè)初始化方法構(gòu)造各種響應(yīng)測(cè)試網(wǎng)絡(luò)層的解析邏輯而不必真的搭一個(gè) HTTP 服務(wù)器。let url URL(string: https://example.com)! let response HTTPURLResponse(url: url, statusCode: 206, httpVersion: HTTP/1.1, headerFields: [Content-Range: bytes 0-100/200])!另外iOS 15 之后 URLSession 新增了 async/await 接口NSHTTPURLResponse 的獲取方式變成了let (data, response) try await session.data(from: url)用法上依然是 safe cast底層原理沒有本質(zhì)變化。做新項(xiàng)目時(shí)直接用 async/await 更簡潔但老項(xiàng)目維護(hù)時(shí)把兩套寫法都吃透才能應(yīng)對(duì)不同代碼庫。5.5 排查思路小結(jié)如果哪天發(fā)現(xiàn)自己寫的網(wǎng)絡(luò)解析邏輯在某些請(qǐng)求上拿不到想要的頭字段我建議按這個(gè)順序排查第一先確認(rèn)請(qǐng)求真的是 HTTP(S) 協(xié)議不是自定義 scheme第二打印整個(gè) allHeaderFields 字典肉眼看看 key 的實(shí)際大小寫和拼寫第三確認(rèn)服務(wù)器那頭是真的返回了這個(gè)字段還是被網(wǎng)關(guān)或反向代理過濾掉了第四看響應(yīng)頭的編碼是不是非 ASCII因?yàn)槟承?CDN 節(jié)點(diǎn)會(huì)對(duì)中文頭字段做轉(zhuǎn)義處理導(dǎo)致解析結(jié)果和預(yù)期不符第五做一次真機(jī)和模擬器的對(duì)照測(cè)試排除系統(tǒng)版本差異。很多響應(yīng)頭解析的“靈異事件”最后查下來都是大小寫、拼接符號(hào)或者被中間層改寫這三個(gè)原因很少是系統(tǒng) SDK 本身的 bug。所以寫代碼時(shí)多留一個(gè) debug 開關(guān)常打日志能少走很多彎路。其實(shí)相應(yīng)當(dāng)響應(yīng)數(shù)據(jù)處理得多了你會(huì)發(fā)現(xiàn) NSHTTPURLResponse 就像一面鏡子把服務(wù)器端的配置、網(wǎng)關(guān)策略和協(xié)議遵循情況都照了出來。把它的每一項(xiàng)字段都搞明白再遇到網(wǎng)絡(luò)相關(guān)的疑難雜癥至少能快速定位到是傳輸層的問題還是業(yè)務(wù)層的問題而不是對(duì)著 data 干瞪眼。這篇內(nèi)容里所有的解析代碼都是我在日常開發(fā)現(xiàn)場(chǎng)反復(fù)用過的方案遇到類似需求可以直接抄改一改字段名就能嵌入到自己的網(wǎng)絡(luò)層里。 iOS網(wǎng)絡(luò)層開發(fā)：NSHTTPURLResponse響應(yīng)頭解析實(shí)戰(zhàn)與踩坑指南
寫網(wǎng)絡(luò)層代碼的時(shí)候很多 iOS 開發(fā)者都會(huì)遇到同一個(gè)困惑request 發(fā)出去了data 也回來了但響應(yīng)頭里到底藏了什么信息、怎么才能優(yōu)雅地拿到這些信息、以及拿回來之后能做什么腦子里經(jīng)常是一團(tuán)漿糊。NSHTTPURLResponse 這個(gè)類名聽起來很基礎(chǔ)但真正用起來坑卻不少尤其是在處理緩存、斷點(diǎn)續(xù)傳、Cookie 服務(wù)等場(chǎng)景時(shí)對(duì)響應(yīng)數(shù)據(jù)的解析能力直接決定了功能能否穩(wěn)定落地。這篇內(nèi)容就圍繞 NSHTTPURLResponse 的數(shù)據(jù)解析展開從類的關(guān)系、屬性語義、實(shí)際使用場(chǎng)景到踩坑記錄完整梳理一遍適合正在做網(wǎng)絡(luò)層封裝、或者準(zhǔn)備處理下載任務(wù)和緩存邏輯的 iOS 開發(fā)者作為參考。1. 先搞清楚 NSHTTPURLResponse 到底是什么1.1 它和 NSURLResponse 的關(guān)系很多新人會(huì)把 NSURLResponse 和 NSHTTPURLResponse 混為一談拿出來就用等到想讀 statusCode 的時(shí)候發(fā)現(xiàn)沒這個(gè)屬性才開始懷疑人生。實(shí)際上 NSURLResponse 是 Foundation 框架里對(duì)“一次網(wǎng)絡(luò)請(qǐng)求返回的響應(yīng)元數(shù)據(jù)”的抽象基類它只包含 URL、MIMEType、期望內(nèi)容長度 expectedContentLength、文本編碼名 textEncodingName 這四樣?xùn)|西。而 NSHTTPURLResponse 是它的子類專門針對(duì) HTTP/HTTPS 協(xié)議擴(kuò)展了兩個(gè)關(guān)鍵字段一個(gè)是 HTTP 狀態(tài)碼 statusCode另一個(gè)是響應(yīng)頭字典 allHeaderFields。也就是說如果你發(fā)起的是 http:// 或 https:// 請(qǐng)求URLSession 實(shí)際返回給你的響應(yīng)對(duì)象就是 NSHTTPURLResponse 的實(shí)例可以直接做類型轉(zhuǎn)換。這里要特別注意一個(gè)細(xì)節(jié)并不是所有網(wǎng)絡(luò)請(qǐng)求都會(huì)返回 NSHTTPURLResponse。比如加載本地文件、或者自定義協(xié)議的時(shí)候返回的可能是 NSURLResponse 本身。所以在代碼里做類型判斷是必要的不要盲目強(qiáng)轉(zhuǎn)。實(shí)際項(xiàng)目中我習(xí)慣用if let httpResponse response as? HTTPURLResponse這種安全轉(zhuǎn)換的寫法既避免崩潰也方便后面統(tǒng)一處理。1.2 一個(gè)典型的響應(yīng)生命周期要理解 NSHTTPURLResponse最好從一次完整的 HTTP 請(qǐng)求去反推它的位置?？蛻舳送ㄟ^ URLSession 發(fā)起請(qǐng)求經(jīng)過 DNS 解析、TCP 連接、TLS 握手HTTPS然后發(fā)送請(qǐng)求行和請(qǐng)求頭。服務(wù)器處理完之后返回狀態(tài)行比如 HTTP/1.1 200 OK、響應(yīng)頭一堆 key-value和響應(yīng)體實(shí)際數(shù)據(jù)。NSHTTPURLResponse 承載的就是“狀態(tài)行 響應(yīng)頭”這兩個(gè)部分的信息響應(yīng)體則是通過 URLSession 的 dataTask 或者 downloadTask 的另一個(gè)回調(diào)參數(shù)拿到的。換句話說它是請(qǐng)求結(jié)果的第一道閘門——在讀取 data 之前你應(yīng)該先通過它判斷這次請(qǐng)求到底成沒成功、返回的是什么類型的數(shù)據(jù)、是否需要走下一步邏輯。在實(shí)際開發(fā)中看到很多項(xiàng)目直接在 completion handler 里判斷 data 是否為空不檢查狀態(tài)碼也不讀響應(yīng)頭。這樣做一旦遇到服務(wù)器返回 4xx、5xx 且?guī)уe(cuò)誤頁面 HTML 的情況很容易把錯(cuò)誤數(shù)據(jù)當(dāng)成正常業(yè)務(wù)數(shù)據(jù)處理產(chǎn)生很難排查的線上問題。養(yǎng)成先解析 NSHTTPURLResponse、再處理 data 的習(xí)慣能規(guī)避掉相當(dāng)一部分低級(jí) bug。2. 響應(yīng)頭信息的獲取與解析2.1 如何拿到 NSHTTPURLResponse 對(duì)象在 URLSession 體系的回調(diào)里獲取 NSHTTPURLResponse 非常簡單。比如使用 dataTask 的 completion handlerlet task URLSession.shared.dataTask(with: url) { data, response, error in guard let httpResponse response as? HTTPURLResponse else { // 不是 HTTP 協(xié)議或者請(qǐng)求失敗 return } print(狀態(tài)碼: \(httpResponse.statusCode)) print(響應(yīng)頭: \(httpResponse.allHeaderFields)) } task.resume()如果你用的是代理模式URLSessionDelegate響應(yīng)信息會(huì)出現(xiàn)在urlSession(_:dataTask:didReceive:completionHandler:)這個(gè)方法里同樣是先轉(zhuǎn)類型再使用。注意用URLSessionConfiguration做自定義 Session 時(shí)委托回調(diào)里的 response 參數(shù)也需要做同樣的類型轉(zhuǎn)換。func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive response: URLResponse, completionHandler: escaping (URLSession.ResponseDisposition) - Void) { if let httpResponse response as? HTTPURLResponse { // 這里就可以讀取狀態(tài)碼和響應(yīng)頭了 print(status: \(httpResponse.statusCode)) } completionHandler(.allow) }這里有個(gè)經(jīng)驗(yàn)點(diǎn)很多人在 completion handler 里喜歡直接打印整個(gè) response比如print(response)。這會(huì)輸出一堆調(diào)試信息但真正要拿字段的時(shí)候反而容易對(duì)不上號(hào)。建議第一步永遠(yuǎn)是 safe cast第二步才是取數(shù)據(jù)。2.2 allHeaderFields 的讀取與大小寫陷阱allHeaderFields 是 NSHTTPURLResponse 里最常用的屬性它返回一個(gè)[AnyHashable : Any]類型的字典里面裝的是服務(wù)器返回的原始響應(yīng)頭字段。但這個(gè)字典有一個(gè)特別容易踩坑的地方key 的大小寫并不穩(wěn)定。HTTP 協(xié)議本身規(guī)定頭字段名是不區(qū)分大小寫的比如 Content-Type、content-type、CONTENT-TYPE 在語義上是同一個(gè)。但 iOS 系統(tǒng)在把這些字段塞進(jìn)字典時(shí)并沒有保證統(tǒng)一格式。實(shí)測(cè)下來絕大多數(shù)服務(wù)器返回的響應(yīng)頭會(huì)保留原始大小寫但有些代理服務(wù)器或者 CDN 節(jié)點(diǎn)會(huì)對(duì)頭字段做規(guī)范化處理原本是小寫的 key 可能會(huì)變成首字母大寫也可能保持小寫。如果你用allHeaderFields[content-type]去取服務(wù)器回的是Content-Type那拿到就是 nil而且這種問題在真機(jī)上偶發(fā)、模擬器上正常非常難排查。所以穩(wěn)妥的做法是不直接通過下標(biāo)訪問而是寫一個(gè)大小寫不敏感的查找方法。我自己項(xiàng)目里常用的是一個(gè)擴(kuò)展extension HTTPURLResponse { func headerValue(for key: String) - String? { guard let fields allHeaderFields as? [String: Any] else { return nil } for (k, v) in fields { if k.caseInsensitiveCompare(key) .orderedSame { return v as? String } } return nil } }這個(gè)擴(kuò)展在團(tuán)隊(duì)內(nèi)部流轉(zhuǎn)了好幾個(gè)項(xiàng)目遇到不同后端返回風(fēng)格不同的頭字段時(shí)從來不出幺蛾子。用caseInsensitiveCompare去遍歷匹配雖然效率上不如直接取鍵但響應(yīng)頭一般也就十幾個(gè)字段這點(diǎn)遍歷開銷完全可以忽略換來的是接入各種后端服務(wù)時(shí)的從容。2.3 關(guān)鍵響應(yīng)頭字段的業(yè)務(wù)價(jià)值響應(yīng)頭里不是每個(gè)字段在業(yè)務(wù)層都有用但有幾個(gè)非常關(guān)鍵值得專門寫工具方法去解析。Content-Type 是最重要的一個(gè)它告訴你響應(yīng)體到底是什么格式。這里需要注意的是完整的 Content-Type 可能帶 charset 參數(shù)比如text/html; charsetutf-8。解析的時(shí)候要先把分號(hào)后面的東西去掉取到真正的 MIME 類型再單獨(dú)提取字符集。很多講網(wǎng)絡(luò)庫的文章會(huì)忽略這一步直接拿整串去匹配text/html結(jié)果帶著; charsetutf-8就永遠(yuǎn)匹配不上了。Content-Length 在 iOS 的 NSHTTPURLResponse 里對(duì)應(yīng)的是 expectedContentLength這個(gè)屬性的類型是 Int64表示服務(wù)器聲明的內(nèi)容長度。它有兩個(gè)坑一個(gè)是沒有這個(gè)字段時(shí)值為 NSURLResponseUnknownLength實(shí)際是 -1做進(jìn)度條時(shí)必須對(duì) -1 做特殊處理另一個(gè)是服務(wù)器返回了不確定長度的內(nèi)容比如 chunked 傳輸時(shí)這個(gè)值也是 -1。所以下載進(jìn)度計(jì)算不能只靠這個(gè)字段更可靠的方式是拿已接收數(shù)據(jù)量除以總數(shù)據(jù)量時(shí)對(duì) -1 兜底成不確定進(jìn)度。Cache-Control 和 ETag 是做緩存時(shí)要重點(diǎn)解析的字段。Cache-Control 里可能有 no-cache、no-store、max-age 等指令每個(gè)指令都對(duì)應(yīng)不同的緩存策略。ETag 則用于條件請(qǐng)求做增量更新時(shí)配合 If-None-Match 使用。Set-Cookie 字段在某些需要手動(dòng)管理 Cookie 的場(chǎng)景下也得解析。雖然 URLSession 默認(rèn)的 Cookie 存儲(chǔ)機(jī)制會(huì)自動(dòng)處理大部分情況但在 WebView 和原生網(wǎng)絡(luò)棧共存、或者需要跨進(jìn)程共享登錄態(tài)的 App 里手動(dòng)讀取 Set-Cookie 依然有不可替代的作用。所有這些字段的解析都不要在主線程做字符串處理。雖然響應(yīng)頭解析本身量不大但當(dāng)下載任務(wù)多、請(qǐng)求頻繁時(shí)堆在主線程上的字符串操作會(huì)讓列表滑動(dòng)掉幀。放到后臺(tái)隊(duì)列統(tǒng)一解析完把結(jié)果整理成模型再拋給主線程比較穩(wěn)妥。3. 狀態(tài)碼、編碼與內(nèi)容協(xié)商的細(xì)節(jié)3.1 statusCode 的正確打開方式statusCode 反映的是 HTTP 服務(wù)器對(duì)這次請(qǐng)求的最終處理結(jié)果。常見的有 200 OK、201 Created、204 No Content、301/302 重定向、304 Not Modified、400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、500 Internal Server Error 等。很多項(xiàng)目拿到任何一個(gè)非 200 狀態(tài)碼就直接拋錯(cuò)誤這種一刀切的做法在業(yè)務(wù)上是有隱患的。比如 204 表示“服務(wù)端處理成功但沒返回內(nèi)容”如果接口設(shè)計(jì)成刪除類操作返回 204你把 204 當(dāng)錯(cuò)誤處理就出大問題了。再比如 304 Not Modified在緩存場(chǎng)景里是一個(gè)正常的“命中緩存”信號(hào)返回它恰恰意味著之前的緩存還能用這時(shí)應(yīng)該直接用本地緩存而不是報(bào)錯(cuò)。所以一個(gè)成熟的網(wǎng)絡(luò)層判斷邏輯不是簡單地statusCode 200或者statusCode 400而是要分業(yè)務(wù)場(chǎng)景if 200...299 ~ httpResponse.statusCode { // 成功繼續(xù)處理 data } else if httpResponse.statusCode 304 { // 使用緩存 } else if 300...399 ~ httpResponse.statusCode { // 重定向但不建議在這里處理交給 URLSession } else { // 4xx / 5xx統(tǒng)一走錯(cuò)誤邏輯 }這里額外提一個(gè)細(xì)節(jié)URLSession 默認(rèn)對(duì)重定向的處理規(guī)則是自動(dòng)跟隨的它內(nèi)部會(huì)重新發(fā)起請(qǐng)求最終你拿到的 response 更像是最后一次重定向的結(jié)果。如果你要手動(dòng)控制重定向比如跨域跳轉(zhuǎn)時(shí)做 cookie 校驗(yàn)得把 session 的 delegate 實(shí)現(xiàn)urlSession(_:task:willPerformHTTPRedirection:newRequest:completionHandler:)而這個(gè)方法里拿到的原始 HTTPURLResponse恰恰就是重定向發(fā)生之前的那個(gè)響應(yīng)。3.2 textEncodingName 與字符集轉(zhuǎn)換NSURLResponse 的 textEncodingName 返回的是服務(wù)器在 Content-Type 里聲明使用的字符編碼名比如 utf-8、gbk 等。處理網(wǎng)絡(luò)數(shù)據(jù)的時(shí)候這個(gè)字段直接關(guān)系到 data 能不能被正確轉(zhuǎn)成字符串。iOS 原生 API 里把 data 轉(zhuǎn)成 String 一般用String(data:encoding:)但這個(gè)構(gòu)造函數(shù)要求傳入一個(gè)String.Encoding值而 textEncodingName 返回的是 IANA 字符集名比如 “utf-8”。這兩個(gè)體系并不完全一致需要做映射。Foundation 提供了一個(gè)String.Encoding的轉(zhuǎn)換入口let encodingRaw CFStringConvertIANACharSetNameToEncoding(textEncodingName as CFString) let encoding String.Encoding(rawValue: CFStringConvertEncodingToNSStringEncoding(encodingRaw))做這個(gè)轉(zhuǎn)換的時(shí)候會(huì)遇到一大類中文網(wǎng)站返回 gb2312 或 gbk 編碼的情況。這兩個(gè)字符集在 iOS 上轉(zhuǎn)換出來的String.Encoding是存在的但不少開發(fā)者習(xí)慣硬編碼.utf8導(dǎo)致中文亂碼。寫一個(gè)根據(jù) textEncodingName 動(dòng)態(tài)決定 encoding 的工具方法是中文網(wǎng)絡(luò)環(huán)境下做內(nèi)容解析的基本功。還需要注意一種情況有些服務(wù)器返回的 Content-Type 里沒寫 charset此時(shí) textEncodingName 是 nil。如果你硬要按某個(gè)編碼解碼就可能出現(xiàn)半亂碼。這種情況下需要自己從業(yè)務(wù)角度做個(gè)兜底比如優(yōu)先嘗試 UTF-8再退回 GBK 嘗試能解出合法字符就用哪個(gè)。3.3 內(nèi)容協(xié)商Content-Type、Accept、Content-Encoding內(nèi)容協(xié)商這個(gè)概念在 iOS 里接觸的人不多但在做多端接口設(shè)計(jì)時(shí)非常重要。簡單說客戶端通過請(qǐng)求頭里的 Accept 告訴服務(wù)器自己能接收什么類型服務(wù)器通過響應(yīng)頭里的 Content-Type 告訴客戶端實(shí)際返回了什么類型。NSHTTPURLResponse 的 MIMEType 屬性其實(shí)就是從 Content-Type 里解析出來的純類型部分比如 application/json、image/png、text/html。判斷一個(gè)響應(yīng)體怎么解析時(shí)應(yīng)該優(yōu)先看 MIMEType 而不是隨便猜switch httpResponse.mimeType?.lowercased() { case application/json: // JSON 解析邏輯 case image/png, image/jpeg: // 圖片處理邏輯 case text/html: // HTML 解析邏輯 default: // 通用二進(jìn)制處理 }Content-Encoding 則是另一個(gè)容易被忽略的字段它表示響應(yīng)體在傳輸過程中是否經(jīng)過壓縮常見的值是 gzip。URLSession 在大多數(shù)情況下會(huì)自動(dòng)解壓 gzip但如果你拿到的是原始 NSData 且感覺解壓邏輯不對(duì)勁就要回頭看看 Content-Encoding 是不是寫了 gzip 而你用的接口層沒做任何解壓處理。自定義協(xié)議棧或者某些第三方緩存庫在手動(dòng)處理數(shù)據(jù)時(shí)這個(gè)字段必須檢查否則會(huì)出現(xiàn)數(shù)據(jù)解密后亂碼、文件校驗(yàn)失敗這類詭異問題。4. 實(shí)際項(xiàng)目中的幾種典型用法4.1 下載場(chǎng)景下的斷點(diǎn)續(xù)傳下載任務(wù)是 NSHTTPURLResponse 數(shù)據(jù)解析最有價(jià)值的應(yīng)用場(chǎng)景之一。實(shí)現(xiàn)斷點(diǎn)續(xù)傳時(shí)客戶端會(huì)在請(qǐng)求頭里帶上 Range 字段服務(wù)器如果支持范圍請(qǐng)求會(huì)返回 206 Partial Content同時(shí)響應(yīng)頭里會(huì)帶 Content-Range告訴你本次返回的是文件的哪一段。這一步的解析直接決定了你本地文件碎片能不能正確拼接。Content-Range 的格式通常是bytes 0-1023/2048表示這次返回的是第 0 到第 1023 字節(jié)文件總大小是 2048 字節(jié)。解析時(shí)要把這三個(gè)數(shù)字完整提取出來我自己封裝時(shí)會(huì)從 allHeaderFields 里取出 Content-Range 后做一次正則匹配專門提取區(qū)間和總長度。同時(shí)判斷 statusCode 是不是 206只有 206 的時(shí)候才走斷點(diǎn)續(xù)傳邏輯如果服務(wù)器不支持 Range會(huì)返回 200 并附帶整個(gè)文件這時(shí)需要把本地已下載的部分丟棄重新全量下載。判斷這個(gè)邏輯不能只依賴 Content-Range 是否存在因?yàn)橛行┓?wù)器的實(shí)現(xiàn)比較怪會(huì)同時(shí)返回 200 和 Content-Range這種情況下以 statusCode 為準(zhǔn)更穩(wěn)妥。另外這里有一個(gè)實(shí)際開發(fā)中遇到過的問題響應(yīng)頭里的 Content-Length 在 Range 請(qǐng)求里代表的是本次返回片段的大小而不是整個(gè)文件的大小。很多做文件下載的人在這里栽過跟頭——拿著 206 的 expectedContentLength 直接當(dāng)文件總大小去做進(jìn)度百分比進(jìn)度算到一半就超 100% 了?？偞笮?yīng)該從 Content-Range 的第三段取這一點(diǎn)要特別注意寫進(jìn)注釋。4.2 緩存驗(yàn)證與 ETagHTTP 緩存里有一個(gè)很重要的機(jī)制叫條件請(qǐng)求?？蛻舳耸状握?qǐng)求某個(gè)資源時(shí)服務(wù)器返回的響應(yīng)頭里會(huì)帶 ETag實(shí)體標(biāo)簽或者 Last-Modified最后修改時(shí)間。下次客戶端再請(qǐng)求同樣的資源時(shí)帶上 If-None-Match值為之前的 ETag或 If-Modified-Since值為之前的 Last-Modified去問服務(wù)器資源變了嗎沒變就返回 304 Not Modified變了就返回 200 和新數(shù)據(jù)。在這個(gè)過程中解析 NSHTTPURLResponse 的作用體現(xiàn)在首次響應(yīng)時(shí)把 ETag 和 Last-Modified 存下來以及收到 304 時(shí)判斷走不走緩存。在一個(gè)緩存庫或者網(wǎng)絡(luò)框架里這兩行解析代碼往往就是整個(gè)緩存體系的關(guān)鍵支點(diǎn)。存儲(chǔ)時(shí)要注意一個(gè)細(xì)節(jié)ETag 本身是帶引號(hào)的字符串比如abc123。存儲(chǔ)的時(shí)候保持原樣請(qǐng)求時(shí)原樣放到 If-None-Match 里不要手動(dòng)去引號(hào)。有些服務(wù)器比較嚴(yán)格引號(hào)去掉了一對(duì)不上就判斷失敗緩存就永遠(yuǎn)命中不了。4.3 Cookie 與會(huì)話保持URLSession 默認(rèn)會(huì)自動(dòng)處理服務(wù)器下發(fā)的 Set-Cookie把 Cookie 存進(jìn)存儲(chǔ)層后續(xù)請(qǐng)求自動(dòng)帶上。但在混合開發(fā)場(chǎng)景App 內(nèi)嵌 WebView、原生網(wǎng)絡(luò)棧又同時(shí)在跑時(shí)經(jīng)常發(fā)現(xiàn) WebView 里登錄的會(huì)話原生請(qǐng)求里拿不到反過來也一樣。這時(shí)候就需要手動(dòng)解析 Set-Cookie然后在原生和 WebView 之間同步 Cookie。拿到 Set-Cookie 之后主要做的事是提取 name、value、domain、path、expires 這幾個(gè)字段生成一個(gè)新的 Cookie 對(duì)象再通過 HTTPCookieStorage 寫入共享存儲(chǔ)。這里關(guān)鍵詞是HTTPCookieStorage.shared。解析 Set-Cookie 時(shí)不要試圖用正則全局匹配因?yàn)?Set-Cookie 可能出現(xiàn)在 allHeaderFields 里也可能有多個(gè)值。建議先把所有 Set-Cookie 值提取出來再一行一行解析避免多個(gè) Cookie 擠在同一個(gè)字符串里時(shí)互相干擾。在 iOS 11 之后URLSession 對(duì) Cookie 的處理更加智能但 HTTPCookieStorage 和 WKWebsiteDataStore 之間的同步仍然需要手動(dòng)橋接這部分的響應(yīng)頭解析在未來很長一段時(shí)間內(nèi)都不會(huì)過時(shí)。5. 常見問題與排查技巧實(shí)錄5.1 allHeaderFields 取不到值的坑之前提到過響應(yīng)頭 key 的大小寫問題實(shí)際上還有另一個(gè)坑某些字段在 allHeaderFields 里會(huì)出現(xiàn)在這個(gè)字典里但在某些 iOS 版本上從 HTTPURLResponse 的專用屬性如textEncodingName里取值卻是 nil。原因是系統(tǒng)解析的時(shí)候沒有把 Content-Type 里的 charset 提取出來導(dǎo)致 textEncodingName 落空。這種情況在服務(wù)器沒按規(guī)范把 charset 放在 Content-Type 最前面時(shí)最容易發(fā)生。比如服務(wù)器返回Content-Type: text/html;charsetutf-8注意中文字符集名通常有小寫系統(tǒng)能解析出 utf-8但如果返回Content-Type: text/html; charsetUTF-8有些版本也能正常。真正出問題的是那種把 charset 放中間或拼寫奇怪的響應(yīng)頭。排查時(shí)如果發(fā)現(xiàn) textEncodingName 為 nil就去 allHeaderFields 里撈原始 Content-Type 自己解析不要依賴系統(tǒng)給的結(jié)果。5.2 重定向后響應(yīng)信息的丟失有一類需求是在登錄后跟蹤重定向鏈路最終拿到真正的落地頁地址。默認(rèn)情況下URLSession 會(huì)自動(dòng)跟隨重定向你在 completion handler 中拿到的 HTTPURLResponse 是最后一次請(qǐng)求的結(jié)果中間那些 302 響應(yīng)頭和 Location 跳轉(zhuǎn)地址會(huì)被系統(tǒng)消化掉不會(huì)暴露給你。如果業(yè)務(wù)上必須要拿到重定向中間信息唯一的辦法是實(shí)現(xiàn) session delegate 里的willPerformHTTPRedirection方法。在那里面可以拿到將要被重定向的響應(yīng)對(duì)象讀取它的 statusCode 和 Location 字段做自定義處理后再?zèng)Q定允許還是取消重定向。這個(gè)環(huán)節(jié)容易犯的錯(cuò)誤是在 delegate 方法里修改了 NSURLRequest 的 header 或者 URL但沒有調(diào)用 completionHandler請(qǐng)求會(huì)一直掛著直到超時(shí)。真機(jī)上表現(xiàn)就是轉(zhuǎn)圈圈很久然后報(bào)超時(shí)錯(cuò)誤排查了老半天才發(fā)現(xiàn)是完成回調(diào)沒觸發(fā)。5.3 線程與線程安全UI 上讀取響應(yīng)頭字段沒問題但如果要做字符串解析、正則匹配、編碼轉(zhuǎn)換這類計(jì)算就要注意線程問題。URLSession 的 completion handler 默認(rèn)在一個(gè)后臺(tái)串行隊(duì)列執(zhí)行在這個(gè)回調(diào)里直接做 JSON 序列化和字符串轉(zhuǎn)換是可以的但一旦涉及 UI 更新或者訪問跨線程共享的可變字典就必須小心。我見過最典型的崩潰場(chǎng)景是多個(gè)下載任務(wù)并發(fā)完成各自的 completion handler 同時(shí)去操作同一個(gè)進(jìn)度數(shù)組沒有加鎖結(jié)果數(shù)組越界或者數(shù)據(jù)錯(cuò)亂。正確的做法是讓解析邏輯保持純凈——輸入 HTTPURLResponse 和 data輸出模型對(duì)象不碰全局可變狀態(tài)。所有的狀態(tài)更新統(tǒng)一回主線程或者用隊(duì)列串行執(zhí)行。5.4 不同 iOS 版本的兼容差異NSHTTPURLResponse 的核心 API 從很多年前就比較穩(wěn)定但細(xì)節(jié)上有過變化。比如在 iOS 13 及之后HTTPURLResponse 多了一個(gè)初始化方法允許你在模擬響應(yīng)時(shí)自定義 statusCode 和 headerFields這對(duì)單元測(cè)試非常有用。寫測(cè)試用例時(shí)可以用這個(gè)初始化方法構(gòu)造各種響應(yīng)測(cè)試網(wǎng)絡(luò)層的解析邏輯而不必真的搭一個(gè) HTTP 服務(wù)器。let url URL(string: https://example.com)! let response HTTPURLResponse(url: url, statusCode: 206, httpVersion: HTTP/1.1, headerFields: [Content-Range: bytes 0-100/200])!另外iOS 15 之后 URLSession 新增了 async/await 接口NSHTTPURLResponse 的獲取方式變成了let (data, response) try await session.data(from: url)用法上依然是 safe cast底層原理沒有本質(zhì)變化。做新項(xiàng)目時(shí)直接用 async/await 更簡潔但老項(xiàng)目維護(hù)時(shí)把兩套寫法都吃透才能應(yīng)對(duì)不同代碼庫。5.5 排查思路小結(jié)如果哪天發(fā)現(xiàn)自己寫的網(wǎng)絡(luò)解析邏輯在某些請(qǐng)求上拿不到想要的頭字段我建議按這個(gè)順序排查第一先確認(rèn)請(qǐng)求真的是 HTTP(S) 協(xié)議不是自定義 scheme第二打印整個(gè) allHeaderFields 字典肉眼看看 key 的實(shí)際大小寫和拼寫第三確認(rèn)服務(wù)器那頭是真的返回了這個(gè)字段還是被網(wǎng)關(guān)或反向代理過濾掉了第四看響應(yīng)頭的編碼是不是非 ASCII因?yàn)槟承?CDN 節(jié)點(diǎn)會(huì)對(duì)中文頭字段做轉(zhuǎn)義處理導(dǎo)致解析結(jié)果和預(yù)期不符第五做一次真機(jī)和模擬器的對(duì)照測(cè)試排除系統(tǒng)版本差異。很多響應(yīng)頭解析的“靈異事件”最后查下來都是大小寫、拼接符號(hào)或者被中間層改寫這三個(gè)原因很少是系統(tǒng) SDK 本身的 bug。所以寫代碼時(shí)多留一個(gè) debug 開關(guān)常打日志能少走很多彎路。其實(shí)相應(yīng)當(dāng)響應(yīng)數(shù)據(jù)處理得多了你會(huì)發(fā)現(xiàn) NSHTTPURLResponse 就像一面鏡子把服務(wù)器端的配置、網(wǎng)關(guān)策略和協(xié)議遵循情況都照了出來。把它的每一項(xiàng)字段都搞明白再遇到網(wǎng)絡(luò)相關(guān)的疑難雜癥至少能快速定位到是傳輸層的問題還是業(yè)務(wù)層的問題而不是對(duì)著 data 干瞪眼。這篇內(nèi)容里所有的解析代碼都是我在日常開發(fā)現(xiàn)場(chǎng)反復(fù)用過的方案遇到類似需求可以直接抄改一改字段名就能嵌入到自己的網(wǎng)絡(luò)層里。