Servlet 寫到第四節(jié)很多人會(huì)卡在一個(gè)很奇怪的地方業(yè)務(wù)邏輯明明跑通了控制臺(tái)日志也打印得干干凈凈瀏覽器里卻是一片空白或者點(diǎn)了提交之后 URL 變了、頁面數(shù)據(jù)卻全丟了。這兩種癥狀前者多半出在HttpServletResponse的響應(yīng)體輸出上后者基本就是重定向的鍋。它是和 HttpServletRequest 成對(duì)出現(xiàn)的孿生參數(shù)一個(gè)負(fù)責(zé)把數(shù)據(jù)搬進(jìn)來一個(gè)負(fù)責(zé)把結(jié)果送出去。前面幾節(jié)我們把請(qǐng)求對(duì)象拆得比較細(xì)這一節(jié)把響應(yīng)對(duì)象完整過一遍狀態(tài)碼怎么設(shè)、響應(yīng)頭怎么加、字符編碼在哪一步?jīng)Q定中文會(huì)不會(huì)變成問號(hào)、getWriter 和 getOutputStream 為什么不能同時(shí)拿以及 sendRedirect 這個(gè)看起來只有一行的動(dòng)作背后到底發(fā)生了什么、帶走了什么、又留下了什么。如果你正在跟著一套 JavaEE 教程往下走或者已經(jīng)能寫出跑得起來的 Servlet 但對(duì)“為什么這么寫”說不出所以然這篇應(yīng)該能補(bǔ)上那段空白。我按實(shí)際動(dòng)手的順序來先把對(duì)象的結(jié)構(gòu)和容器里的位置講清楚再講編碼這條最容易翻車的鏈路然后重點(diǎn)拆重定向最后給幾個(gè)能直接抄的場(chǎng)景寫法和一張排查表。文中代碼以 Servlet 3.1 及以上、Tomcat 8/9 為運(yùn)行環(huán)境其他容器大同小異。1. 先把響應(yīng)對(duì)象的位置擺正它到底管什么1.1 請(qǐng)求進(jìn)來、響應(yīng)出去一對(duì)孿生參數(shù)的分工service(HttpServletRequest req, HttpServletResponse resp)這個(gè)方法簽名幾乎是每個(gè) Java Web 初學(xué)者看到的第一段“框架代碼”。很多人對(duì) req 的印象很具體——取參數(shù)、取頭、取 session因?yàn)闃I(yè)務(wù)開發(fā)天天要用對(duì) resp 的印象卻很模糊好像除了resp.getWriter().write(hello)就沒別的用處了。這其實(shí)是把響應(yīng)對(duì)象想小了。一次 HTTP 交互本質(zhì)上是“一行請(qǐng)求報(bào)文進(jìn)去一行響應(yīng)報(bào)文出來”。請(qǐng)求報(bào)文里有請(qǐng)求行方法、URI、協(xié)議版本、請(qǐng)求頭、請(qǐng)求體響應(yīng)報(bào)文里同樣有三段狀態(tài)行協(xié)議版本、狀態(tài)碼、原因短語、響應(yīng)頭、響應(yīng)體。HttpServletRequest 負(fù)責(zé)讓你讀取前者的每一部分HttpServletResponse 負(fù)責(zé)讓你寫入后者的每一部分。你寫setStatus(404)是在改狀態(tài)行寫setHeader(Cache-Control, no-store)是在加響應(yīng)頭寫getWriter().write(...)是在填響應(yīng)體。這三件事拼起來才是“一次完整的響應(yīng)”缺一個(gè)都不算完整。把這個(gè)對(duì)應(yīng)關(guān)系記住后面所有的 API 就不再是零散的記憶點(diǎn)而是各歸其位。很多“為什么這個(gè)設(shè)置不生效”的問題本質(zhì)上是你以為自己在改響應(yīng)頭實(shí)際上寫的是請(qǐng)求對(duì)象的 API或者寫在了響應(yīng)已經(jīng)提交之后。1.2 你手里的不是容器本體而是一層門面有個(gè)細(xì)節(jié)值得說清楚你在 Servlet 里拿到的resp類型聲明是HttpServletResponse接口實(shí)際運(yùn)行時(shí)它并不是容器的核心對(duì)象而是一層**門面Facade**包裝。以 Tomcat 為例連接器里真正的響應(yīng)對(duì)象是內(nèi)部的一個(gè)實(shí)現(xiàn)類容器在外面套了一層實(shí)現(xiàn)了HttpServletResponse接口的包裝類再交給你。為什么要多這一層原因很實(shí)際容器的內(nèi)部響應(yīng)對(duì)象上有一大堆方法比如直接操作底層 socket 緩沖區(qū)、強(qiáng)制關(guān)閉連接、修改內(nèi)部狀態(tài)標(biāo)記。這些方法如果暴露給業(yè)務(wù)代碼任何一個(gè)不小心的調(diào)用都可能把容器搞進(jìn)不一致的狀態(tài)排查起來極其痛苦。門面模式的思路就是“只給你該用的那部分”接口上暴露的是規(guī)范定義的標(biāo)準(zhǔn)方法容器私有的東西一律擋住。所以你會(huì)遇到這種情況調(diào)試時(shí)想把 resp 強(qiáng)轉(zhuǎn)成某個(gè)看起來更“強(qiáng)大”的類編譯器或者運(yùn)行時(shí)直接拒絕——這不是你寫錯(cuò)了是設(shè)計(jì)上就不允許。理解這一層包裝還有一個(gè)好處當(dāng)異常棧里出現(xiàn) Facade 相關(guān)的類名時(shí)你不會(huì)一臉茫然。它只是容器在替你做代理異常的真實(shí)位置往往還在你自己的代碼里。1.3 一個(gè)容易忽略的事實(shí)響應(yīng)是有緩沖區(qū)的新手最容易踩的坑幾乎都和“緩沖區(qū)”有關(guān)。Servlet 規(guī)范允許容器為響應(yīng)提供緩沖區(qū)Tomcat 默認(rèn)是 8KB。你調(diào)用getWriter().write(abc)這 3 個(gè)字節(jié)并不會(huì)立刻飛到瀏覽器而是先躺在緩沖區(qū)里等緩沖區(qū)滿了、或者請(qǐng)求處理結(jié)束、或者你主動(dòng)flushBuffer()才真正寫出去。這個(gè)機(jī)制帶來兩個(gè)直接后果。第一性能好——減少系統(tǒng)調(diào)用次數(shù)這點(diǎn)不用多說。第二也是關(guān)鍵的一點(diǎn)響應(yīng)一旦提交committed響應(yīng)頭和狀態(tài)碼就鎖死了。所謂提交指響應(yīng)內(nèi)容已經(jīng)開始發(fā)往客戶端此時(shí)再調(diào)setHeader、setStatus、sendRedirect都不會(huì)有任何效果容器甚至不會(huì)給你報(bào)錯(cuò)就那么靜默地忽略掉然后你對(duì)著瀏覽器抓包發(fā)呆。判斷是否已提交用resp.isCommitted()。想在提交前“反悔”用resp.reset()清空緩沖區(qū) 清空頭 清空狀態(tài)碼或resp.resetBuffer()只清緩沖區(qū)保留頭。這兩個(gè)方法在實(shí)際項(xiàng)目里的典型用途是統(tǒng)一異常處理時(shí)發(fā)現(xiàn)前面已經(jīng)寫了一部分內(nèi)容需要整體推倒重寫一個(gè)錯(cuò)誤頁。注意reset()在響應(yīng)已提交后會(huì)拋IllegalStateException調(diào)用前務(wù)必先判斷isCommitted()。2. 狀態(tài)行、響應(yīng)頭、響應(yīng)體響應(yīng)對(duì)象的三層結(jié)構(gòu)2.1 狀態(tài)碼不只是 200 和 404setStatus(int sc)是最直接的寫法參數(shù)用HttpServletResponse接口上定義的那一堆SC_開頭的常量更不容易寫錯(cuò)。日常開發(fā)里真正高頻的其實(shí)就那么幾個(gè)常量值典型使用場(chǎng)景SC_OK200正常返回內(nèi)容SC_NO_CONTENT204成功但無響應(yīng)體如刪除操作SC_MOVED_TEMPORARILY / SC_FOUND302重定向sendRedirect 內(nèi)部用的就是它SC_NOT_MODIFIED304協(xié)商緩存命中讓瀏覽器用本地副本SC_BAD_REQUEST400參數(shù)校驗(yàn)失敗SC_UNAUTHORIZED401未登錄SC_FORBIDDEN403已登錄但無權(quán)限SC_NOT_FOUND404資源不存在SC_METHOD_NOT_ALLOWED405請(qǐng)求方法不支持SC_INTERNAL_SERVER_ERROR500服務(wù)端未捕獲異常除了setStatus還有一個(gè)容易混淆的sendError(int sc)和sendError(int sc, String msg)。區(qū)別在于setStatus只是設(shè)置狀態(tài)碼響應(yīng)體由你自己寫sendError會(huì)清空緩沖區(qū)、設(shè)置狀態(tài)碼并讓容器去生成一個(gè)標(biāo)準(zhǔn)的錯(cuò)誤頁面或者在 web.xml 里配置的error-page。所以你想自定義錯(cuò)誤內(nèi)容時(shí)別用sendError想交給統(tǒng)一錯(cuò)誤頁處理時(shí)才用它。2.2 響應(yīng)頭setHeader 與 addHeader 的區(qū)別比想象中大響應(yīng)頭的寫入有兩組方法名字只差一個(gè)字母行為完全不同setHeader(name, value)同名頭覆蓋最終只保留一個(gè)值。addHeader(name, value)同名頭追加最終會(huì)有多個(gè)值。大部分頭只允許一個(gè)值比如Content-Type用 setSet-Cookie這類允許多值的頭必須用 add否則后一個(gè) Cookie 會(huì)把前一個(gè)頂?shù)舯憩F(xiàn)為“只種上了最后一個(gè) Cookie”這個(gè) bug 極其隱蔽。此外還有兩個(gè)類型便捷方法setIntHeader和setDateHeader后者接收毫秒時(shí)間戳由容器負(fù)責(zé)格式化成 HTTP 日期格式省得你自己拼字符串拼錯(cuò)格式。幾個(gè)必須掌握的響應(yīng)頭Content-Type內(nèi)容類型 字符集通常用setContentType(text/html;charsetUTF-8)一步設(shè)置。Content-Disposition控制瀏覽器是內(nèi)聯(lián)展示還是下載值形如attachment;filenamexxx。Cache-Control/Pragma/Expires緩存控制三件套見 5.4 節(jié)。Location重定向目標(biāo)地址雖然一般由sendRedirect自動(dòng)寫但手動(dòng)實(shí)現(xiàn) 301 永久重定向時(shí)需要自己設(shè)。2.3 兩種輸出流二選一getWriter 與 getOutputStream響應(yīng)體輸出只有兩條路getWriter()返回字符流PrintWritergetOutputStream()返回字節(jié)流ServletOutputStream。規(guī)則很簡(jiǎn)單也很硬同一個(gè)響應(yīng)里只能用一個(gè)用了其中一個(gè)再拿另一個(gè)會(huì)拋IllegalStateException。怎么選按你要輸出的內(nèi)容類型決定。輸出 HTML、純文本、JSON、XML 這類文本內(nèi)容用 writer它幫你處理字符到字節(jié)的編碼轉(zhuǎn)換輸出圖片、PDF、文件下載、二進(jìn)制協(xié)議數(shù)據(jù)用 outputStream字節(jié)原樣寫出不經(jīng)過編碼轉(zhuǎn)換這一層。這里有個(gè)很多人沒想明白的點(diǎn)writer 的編碼轉(zhuǎn)換用的是哪個(gè)字符集答案是響應(yīng)對(duì)象上設(shè)置的那個(gè)字符集默認(rèn)是 ISO-8859-1。這也是中文亂碼的根源下一節(jié)專門展開。實(shí)操心得選 writer 還是 outputStream最好在方法開頭就定下來別在中間分支里來回?fù)Q。我見過一個(gè)下載接口在異常分支里調(diào)了getWriter()打印錯(cuò)誤信息結(jié)果正常分支的getOutputStream()直接崩掉日志里只有一句 IllegalStateException排查了半天才發(fā)現(xiàn)是異常處理路徑污染了狀態(tài)。3. 中文亂碼的完整鏈路編碼在哪一步被定死3.1 亂碼產(chǎn)生的三個(gè)環(huán)節(jié)中文亂碼是 Java Web 的經(jīng)典老問題但只要把鏈路拆成三段判斷起來其實(shí)很快第一段Java 字符串到字節(jié)。你的String在內(nèi)存里是 UTF-16寫出去必須轉(zhuǎn)成字節(jié)。這一步用的字符集由響應(yīng)對(duì)象的 character encoding 決定默認(rèn) ISO-8859-1。如果你沒設(shè)置中文寫進(jìn)去直接變成?或一串問號(hào)方塊。第二段響應(yīng)頭里的 charset 聲明。瀏覽器收到Content-Type: text/html而沒帶charset時(shí)會(huì)自己猜猜測(cè)策略各瀏覽器不完全一樣結(jié)果就是“我明明設(shè)了編碼還是亂碼”。第三段瀏覽器解碼。它按響應(yīng)頭聲明的字符集把字節(jié)還原成字符。聲明和實(shí)際字節(jié)不一致就是滿屏亂碼。所以正確的做法只有一條讓這三段用同一個(gè)字符集。具體到代碼就是在拿 writer 之前用setContentType(text/html;charsetUTF-8)一次性把“內(nèi)容類型”和“字符集聲明”都設(shè)好同時(shí)這句調(diào)用會(huì)順帶把響應(yīng)對(duì)象的字符編碼也設(shè)成 UTF-8三段自動(dòng)對(duì)齊。3.2 setContentType 與 setCharacterEncoding 的調(diào)用順序setCharacterEncoding(String)只改編碼不改內(nèi)容類型響應(yīng)頭里不會(huì)出現(xiàn) charset 聲明除非你之后又設(shè)了 Content-Type。而setContentType(text/html;charsetUTF-8)會(huì)解析出 charset 部分并調(diào)用前者。這帶來一個(gè)順序陷阱// 錯(cuò)誤寫法先設(shè)編碼再設(shè)帶 charset 的 Content-Type看似沒問題 resp.setCharacterEncoding(GBK); resp.setContentType(text/html;charsetUTF-8); // 最終是 UTF-8前面的 GBK 被覆蓋而反過來// 另一個(gè)容易踩的坑先設(shè)了不帶 charset 的 Content-Type resp.setContentType(text/html); resp.setCharacterEncoding(UTF-8); // 編碼生效了但響應(yīng)頭里沒有 charset瀏覽器仍可能猜錯(cuò)結(jié)論很清楚用一句帶 charset 的 setContentType 搞定不要拆成兩句。拆開寫除了給自己留隱患沒有任何好處。還有一個(gè)更隱蔽的坑這些都必須在getWriter()之前調(diào)用。writer 一旦創(chuàng)建它的編碼就固定了之后再調(diào)setCharacterEncoding不會(huì)有任何效果容器也不會(huì)警告你。所以養(yǎng)成習(xí)慣把編碼設(shè)置放在方法最前面緊跟參數(shù)校驗(yàn)之后。3.3 一組實(shí)測(cè)對(duì)照表下面這張表是我本地用 Tomcat 9 實(shí)測(cè)的結(jié)果輸出內(nèi)容統(tǒng)一是字符串“中文測(cè)試”看瀏覽器最終顯示寫法響應(yīng)頭 Content-Type瀏覽器顯示什么都不設(shè)直接 getWriter().writetext/html無 charset亂碼setCharacterEncoding(UTF-8) 后寫text/html無 charset多數(shù)情況正常部分瀏覽器亂碼setContentType(text/html;charsetUTF-8)text/html;charsetUTF-8正常setContentType 寫在 getWriter() 之后text/html;charsetUTF-8亂碼編碼已固定為 ISO-8859-1setHeader(Content-Type, text/html;charsetUTF-8)同值正常但不推薦不會(huì)同步內(nèi)部編碼狀態(tài)最后一行值得多說一句用setHeader手動(dòng)拼 Content-Type 確實(shí)能讓瀏覽器正常顯示但響應(yīng)對(duì)象內(nèi)部的 character encoding 并沒有跟著變?nèi)绻阒筮€用 writer 寫內(nèi)容字節(jié)層面仍是默認(rèn)編碼只是恰好某些場(chǎng)景下沒暴露問題。這種“能跑但不對(duì)”的寫法是后面出問題的種子。4. sendRedirect 拆解一行代碼背后發(fā)生了什么4.1 報(bào)文層面302 與 Locationresp.sendRedirect(/app/home)這行代碼做的事展開來看是三步清空當(dāng)前響應(yīng)緩沖區(qū)內(nèi)部會(huì)調(diào) resetBuffer 一類的邏輯之前寫的內(nèi)容全部丟棄把狀態(tài)碼設(shè)為 302并在響應(yīng)頭里寫入Location: /app/home結(jié)束本次響應(yīng)的輸出。瀏覽器收到 302 加 Location 之后會(huì)發(fā)起一次全新的請(qǐng)求去訪問 Location 指向的地址。注意“全新”這兩個(gè)字新的請(qǐng)求、新的連接可能復(fù)用 TCP 但那是傳輸層的事、新的 request 對(duì)象、新的線程。地址欄會(huì)變成新地址這是重定向最直觀的外部特征。正因?yàn)槭莾纱为?dú)立請(qǐng)求第一次請(qǐng)求里塞進(jìn) request 域的任何數(shù)據(jù)第二次請(qǐng)求統(tǒng)統(tǒng)看不見。這一點(diǎn)和轉(zhuǎn)發(fā)forward形成鮮明對(duì)比也是初學(xué)者最容易困惑的地方——“我明明 setAttribute 了跳過去怎么就取不到”4.2 重定向與轉(zhuǎn)發(fā)的本質(zhì)區(qū)別這兩個(gè)概念經(jīng)常被放在一起比較我用一張表說清楚對(duì)比項(xiàng)重定向 sendRedirect轉(zhuǎn)發(fā) forward請(qǐng)求次數(shù)2 次瀏覽器發(fā)起第二次1 次服務(wù)器內(nèi)部轉(zhuǎn)交誰在跳轉(zhuǎn)瀏覽器服務(wù)器地址欄變化不變r(jià)equest 域數(shù)據(jù)丟失保留能否跳外部站點(diǎn)可以不可以目標(biāo)資源限制無任意 URL只能是當(dāng)前應(yīng)用內(nèi)部資源性能多一次網(wǎng)絡(luò)往返無額外往返狀態(tài)碼302200內(nèi)部轉(zhuǎn)發(fā)選型上的經(jīng)驗(yàn)原則跳轉(zhuǎn)后如果不需要保留請(qǐng)求數(shù)據(jù)、或者要跳到應(yīng)用外部、或者希望用戶刷新時(shí)不再重復(fù)提交表單用重定向需要在一次請(qǐng)求內(nèi)把數(shù)據(jù)交給下一個(gè)頁面渲染用轉(zhuǎn)發(fā)。典型的重定向場(chǎng)景是“登錄成功后跳到首頁”典型轉(zhuǎn)發(fā)場(chǎng)景是“Controller 處理完把結(jié)果交給 JSP 渲染”。順帶提一句 PRG 模式Post-Redirect-Get表單提交用 POST處理成功后重定向到結(jié)果頁。這樣用戶刷新結(jié)果頁時(shí)發(fā)起的是 GET不會(huì)重復(fù)提交訂單或者重復(fù)扣款。這個(gè)模式在生產(chǎn)環(huán)境里幾乎是標(biāo)配值得養(yǎng)成習(xí)慣。4.3 路徑寫法的坑絕對(duì)路徑、相對(duì)路徑與 contextPathsendRedirect的參數(shù)寫法是最容易出錯(cuò)的地方。規(guī)則大致如下以/開頭相對(duì)于當(dāng)前應(yīng)用的上下文根。注意不是服務(wù)器根。你的應(yīng)用部署在/shop下寫sendRedirect(/home)最終 Location 是/shop/home。不以/開頭相對(duì)于當(dāng)前請(qǐng)求的 URI。比如當(dāng)前請(qǐng)求是/shop/user/login寫sendRedirect(result)最終會(huì)解析成/shop/user/result。這個(gè)相對(duì)規(guī)則很容易算錯(cuò)層級(jí)我不推薦在業(yè)務(wù)代碼里用。以http://或https://開頭完整 URL跳外部站點(diǎn)用?；谶@個(gè)規(guī)則我建議統(tǒng)一寫法永遠(yuǎn)用req.getContextPath() /具體路徑拼出應(yīng)用內(nèi)路徑。String target req.getContextPath() /user/home; resp.sendRedirect(target);這樣無論應(yīng)用部署在根路徑還是子路徑下代碼都不用改。反過來如果你圖省事寫死sendRedirect(/shop/home)哪天部署路徑變了整站跳轉(zhuǎn)全部 404而且這種錯(cuò)誤在開發(fā)環(huán)境往往發(fā)現(xiàn)不了——因?yàn)殚_發(fā)時(shí)應(yīng)用常常就部署在根路徑。注意sendRedirect之后不要再寫return之外的東西。它不會(huì)像forward那樣自動(dòng)終止方法執(zhí)行代碼會(huì)繼續(xù)往下跑。雖然響應(yīng)已提交后續(xù)寫入會(huì)被忽略但如果后面還有數(shù)據(jù)庫操作或者別的副作用代碼那就不只是浪費(fèi)而是可能出錯(cuò)。養(yǎng)成習(xí)慣sendRedirect后面緊跟return;。4.4 重定向會(huì)帶走什么、又留下什么數(shù)據(jù)傳遞是重定向場(chǎng)景下繞不開的問題。既然 request 域失效可選方案有三個(gè)方案一session。把提示信息塞進(jìn) session目標(biāo)頁面取出來之后立刻removeAttribute。這個(gè)“取完就刪”的動(dòng)作必須做否則下次進(jìn)頁面還會(huì)看到上次的舊提示。缺點(diǎn)是依賴會(huì)話用戶禁用 Cookie 時(shí)會(huì)失效雖然現(xiàn)在很少見。方案二URL 參數(shù)。拼接查詢字符串目標(biāo)頁面從req.getParameter取。缺點(diǎn)是中文要URLEncoder.encode(value, UTF-8)編碼而且參數(shù)暴露在地址欄敏感信息不能這么傳。方案三閃存式的臨時(shí)容器。一些框架提供了 FlashMap 之類的機(jī)制本質(zhì)還是 session 加一次性的標(biāo)記自己實(shí)現(xiàn)也不難。三種方案里我做后臺(tái)管理系統(tǒng)時(shí)最常用第一種簡(jiǎn)單直接做對(duì)外的分享鏈接類功能時(shí)才用第二種因?yàn)橐ＷC鏈接可復(fù)制可分享。5. 四個(gè)高頻場(chǎng)景的落地寫法5.1 登錄成功跳轉(zhuǎn)并攜帶提示信息登錄成功后跳首頁并顯示一句“歡迎回來”是重定向最典型的用法。下面是完整寫法protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String username req.getParameter(username); String password req.getParameter(password); // 省略校驗(yàn)邏輯 boolean loginOk checkLogin(username, password); if (loginOk) { req.getSession().setAttribute(loginUser, username); // 提示信息放 session目標(biāo)頁面取完即刪 req.getSession().setAttribute(flashMsg, 登錄成功歡迎回來); resp.sendRedirect(req.getContextPath() /user/home); return; } req.setAttribute(errMsg, 用戶名或密碼不正確); req.getRequestDispatcher(/login.jsp).forward(req, resp); }首頁那邊取值的寫法Object msg session.getAttribute(flashMsg); if (msg ! null) { session.removeAttribute(flashMsg); // 關(guān)鍵取完立刻刪 request.setAttribute(tip, msg); }對(duì)比一下登錄失敗用的是 forward因?yàn)橐彦e(cuò)誤信息和用戶填過的表單數(shù)據(jù)帶回去重新渲染登錄成功用的是 redirect因?yàn)椴恍枰獛Щ財(cái)?shù)據(jù)而且能避免用戶刷新時(shí)重新提交登錄表單。同一次交互里兩種跳轉(zhuǎn)混用這才是真實(shí)項(xiàng)目的常態(tài)。5.2 文件下載文件名不亂碼的寫法文件下載必須用getOutputStream()核心是三件事設(shè)置內(nèi)容類型、設(shè)置 Content-Disposition、把字節(jié)寫出去。中文文件名要額外做 URL 編碼否則瀏覽器拿到的文件名會(huì)變成亂碼或直接截?cái)?。protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String fileName 季度報(bào)表.pdf; byte[] data loadFileBytes(fileName); // 省略具體讀取邏輯 String encoded URLEncoder.encode(fileName, UTF-8).replace(, %20); resp.setContentType(application/octet-stream); resp.setHeader(Content-Disposition, attachment;filename encoded); resp.setContentLength(data.length); try (ServletOutputStream out resp.getOutputStream()) { out.write(data); out.flush(); } }這里的replace(, %20)是個(gè)細(xì)節(jié)URLEncoder是給表單參數(shù)設(shè)計(jì)的會(huì)把空格編成而 HTTP 頭里的文件名要求空格是%20不替換的話文件名里的空格會(huì)變成加號(hào)。這個(gè)坑我踩過一次用戶反饋“下載的文件名多了個(gè)加號(hào)”查了半天才定位到這一行。另一個(gè)建議是設(shè)置Content-Length。帶上長(zhǎng)度瀏覽器就能顯示下載進(jìn)度條不帶的話只能顯示一個(gè)轉(zhuǎn)圈體驗(yàn)差不少。寫流的時(shí)候用 try-with-resources保證異常情況下流被正確關(guān)閉。5.3 返回 JSON 給前端現(xiàn)在大量 Servlet 接口其實(shí)是在給前端頁面或者移動(dòng)端返回 JSON。寫法很簡(jiǎn)單但編碼和內(nèi)容類型必須設(shè)對(duì)否則前端JSON.parse直接報(bào)錯(cuò)。protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { resp.setContentType(application/json;charsetUTF-8); resp.setHeader(Cache-Control, no-store); String json {\code\:0,\msg\:\ok\,\data\:{\total\:128}}; PrintWriter writer resp.getWriter(); writer.write(json); writer.flush(); }兩個(gè)要點(diǎn)。第一application/json;charsetUTF-8里的 charset 是有意義的雖然 JSON 規(guī)范推薦 UTF-8 且不少前端庫能自適應(yīng)但顯式聲明最穩(wěn)。第二寫入后調(diào)一下flush()尤其在接口調(diào)試階段不 flush 時(shí)內(nèi)容可能還在緩沖區(qū)里你用工具抓包看到的是空響應(yīng)體白白懷疑人生。真實(shí)項(xiàng)目里不會(huì)手拼 JSON 字符串通常交給序列化庫處理。但即便用庫編碼設(shè)置這一步仍然要自己做序列化庫只負(fù)責(zé)把對(duì)象變成字符串不負(fù)責(zé)響應(yīng)頭。5.4 禁止緩存的響應(yīng)頭組合后臺(tái)管理系統(tǒng)的接口尤其是返回敏感數(shù)據(jù)的接口被瀏覽器緩存住是很危險(xiǎn)的用戶退出登錄后點(diǎn)后退還能看到上一個(gè)賬號(hào)的數(shù)據(jù)。標(biāo)準(zhǔn)的三件套寫法resp.setHeader(Cache-Control, no-cache, no-store, must-revalidate); resp.setHeader(Pragma, no-cache); // 兼容老版本 HTTP/1.0 代理 resp.setDateHeader(Expires, 0); // 設(shè)為過去時(shí)間立即過期Cache-Control是 HTTP/1.1 的標(biāo)準(zhǔn)Pragma是為了兼容只認(rèn) 1.0 的老中間層Expires: 0是給更老的客戶端兜底。三條一起上基本能覆蓋所有情況。反過來如果某個(gè)靜態(tài)資源接口希望瀏覽器緩存就用setDateHeader(Expires, System.currentTimeMillis() 3600_000)配一個(gè)將來的時(shí)間再加一條Cache-Control: max-age3600。注意max-age的優(yōu)先級(jí)高于Expires兩個(gè)都寫時(shí)以 max-age 為準(zhǔn)這是 HTTP 規(guī)范的約定。6. 踩坑實(shí)錄與排查速查表6.1 流重復(fù)獲取IllegalStateException最經(jīng)典的異常沒有之一java.lang.IllegalStateException: getWriter() has already been called for this response反過來也有 getOutputStream 版本。成因就一個(gè)——同一個(gè)響應(yīng)里兩種流都拿了。真正麻煩的不是直接寫兩行的情況而是被封裝掩蓋的場(chǎng)景基類里統(tǒng)一寫了個(gè)“處理成功”的方法調(diào)了 writer子類業(yè)務(wù)又調(diào)了 outputStream或者過濾器里記日志時(shí)順手resp.getWriter().println(...)把后面的接口全廢掉。過濾器那個(gè)坑尤其隱蔽因?yàn)檫^濾器代碼往往是很久以前寫的平時(shí)不報(bào)錯(cuò)只在特定接口上出問題。排查順序我一般是這三步先在異常棧里找自己項(xiàng)目的包名看第一個(gè)屬于自己代碼的調(diào)用點(diǎn)在哪然后全局搜getWriter(和getOutputStream(看有沒有在公共代碼里被調(diào)用最后確認(rèn)過濾器鏈里有沒有打印響應(yīng)的邏輯。實(shí)操心得在過濾器、攔截器這類公共組件里永遠(yuǎn)不要碰響應(yīng)流。要看響應(yīng)內(nèi)容用包裝類HttpServletResponseWrapper在內(nèi)存里攔截或者干脆只記日志不打響應(yīng)。6.2 提交之后設(shè)置無效癥狀是代碼里明明寫了setHeader、setStatus抓包看響應(yīng)頭里就是沒有。原因九成是響應(yīng)已經(jīng)提交了。觸發(fā)提交的常見動(dòng)作有三個(gè)緩沖區(qū)寫滿、顯式調(diào)了flushBuffer()或flush()、調(diào)了sendRedirect或sendError。排查方法很直接在設(shè)置之前插一句System.out.println(resp.isCommitted())打印 true 就說明前面已經(jīng)提交了。再往前找是哪一步提交的。JSP 頁面里這個(gè)情況特別多因?yàn)?JSP 本身有緩沖區(qū)頁面頂部一大段 HTML 輸出完之后緩沖區(qū)可能就滿了后面的setHeader自然失效。所以需要設(shè)響應(yīng)頭的邏輯一定要放在頁面最前面或者干脆挪到 Servlet 里做。6.3 重定向死循環(huán)與 404 路徑錯(cuò)位重定向死循環(huán)的表現(xiàn)是瀏覽器報(bào)“重定向次數(shù)過多”。典型成因是登錄過濾器寫錯(cuò)了判斷邏輯未登錄就重定向到登錄頁但登錄頁本身也被過濾器攔住了于是無限循環(huán)。解決辦法是給過濾器的攔截路徑加白名單登錄頁、靜態(tài)資源、登錄接口本身都要放行。路徑錯(cuò)位表現(xiàn)為重定向之后 404。多半是 contextPath 沒拼對(duì)或者誤用了相對(duì)路徑。判斷方法很簡(jiǎn)單看響應(yīng)頭里的Location值到底是什么。如果 Location 是/home但你期望/shop/home那就是相對(duì)上下文根解析的問題如果 Location 是/shop/user/result而你期望/shop/result那就是相對(duì)路徑算錯(cuò)了層級(jí)。6.4 響應(yīng)問題排查速查表現(xiàn)象最可能的原因排查動(dòng)作頁面空白無內(nèi)容用了 outputStream 又寫字符或流未 flush檢查流類型補(bǔ) flush中文變問號(hào)未設(shè) charsetwriter 用默認(rèn) ISO-8859-1在 getWriter 前設(shè) Content-Type響應(yīng)頭設(shè)置不生效響應(yīng)已提交打印 isCommitted 定位提交點(diǎn)IllegalStateException兩種流混用全局搜 getWriter / getOutputStream重定向后 request 取不到值兩次請(qǐng)求域失效改用 session 或 URL 參數(shù)重定向 404路徑未拼 contextPath抓包看 Location 實(shí)際值重定向次數(shù)過多過濾器白名單缺失檢查攔截路徑配置下載文件名亂碼未做 URL 編碼用 URLEncoder 并替換加號(hào)退出登錄后仍能看到數(shù)據(jù)未設(shè)禁止緩存頭補(bǔ) Cache-Control 三件套最后分享一個(gè)我一直在用的小習(xí)慣把常用的響應(yīng)操作抽成一個(gè)工具類比如writeJson(resp, obj)、download(resp, fileName, bytes)、redirect(req, resp, path)。工具方法內(nèi)部統(tǒng)一處理編碼、contextPath 拼接、流關(guān)閉這些重復(fù)勞動(dòng)業(yè)務(wù)代碼里就只剩一行調(diào)用。這么做過一段時(shí)間之后編碼類的問題基本就從項(xiàng)目里絕跡了——因?yàn)闆]有任何一個(gè)地方需要單獨(dú)去想 charset 該寫在哪。