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