早餐外賣這個場景特別適合JSPServlet這套老牌技術(shù)棧來練手業(yè)務(wù)鏈路完整從前臺點餐到后臺出餐都有又不至于復(fù)雜到失控。今天把這個基于JavaWeb和MySQL的JSPServlet早餐外賣店管理系統(tǒng)拆開揉碎講一遍從數(shù)據(jù)庫設(shè)計到前端交互從本機(jī)部署到常見報錯所有流程都是可以照著重現(xiàn)的不是那種飄在PPT上的概念方案。想把這套系統(tǒng)吃透的人我大概分成兩類一類是剛學(xué)完JavaWeb正在找完整項目做課程設(shè)計或畢業(yè)設(shè)計的同學(xué)另一類是工作里被Spring Boot“慣壞了”想回頭補(bǔ)一補(bǔ)原生Servlet、JSP、會話管理這些底層原理的開發(fā)者。這個項目能解決的核心問題就是讓你完全不用框架純靠Servlet控制請求流轉(zhuǎn)、JSP渲染頁面、JDBC操作MySQL自己手工拼出一套能用的外賣管理系統(tǒng)。這么做最大的價值不是“代碼能跑”而是你能真正看清楚一個Web應(yīng)用在瀏覽器和數(shù)據(jù)庫之間到底干了些什么。項目本身的業(yè)務(wù)不復(fù)雜顧客瀏覽早餐分類和菜品加入購物車提交訂單填寫收貨地址和期望送達(dá)時間管理員在后臺維護(hù)菜品、處理訂單狀態(tài)、查看每日營業(yè)額。技術(shù)點覆蓋了JavaWeb幾乎全部核心內(nèi)容Filter過濾器做登錄攔截、Session維護(hù)登錄態(tài)和購物車、JDBC做增刪改查、事務(wù)保證下單扣庫存的一致性、AJAX局部刷新、JSP標(biāo)簽庫遍歷列表。下面按我的實際開發(fā)順序把每個環(huán)節(jié)的關(guān)鍵細(xì)節(jié)和坑都說清楚。1. 整體架構(gòu)與設(shè)計取舍 —— 為什么堅持用 JSPServlet 做外賣系統(tǒng)1.1 技術(shù)選型背后的真實考量有人會問都2025年了誰還用JSPServlet寫新項目這個質(zhì)疑本身沒錯但得分場景。如果是公司里的正式產(chǎn)品我絕對推薦Spring Boot MyBatis / JPA那一套但如果是用來學(xué)習(xí)JavaWeb、理解HTTP請求如何被處理、Session如何維持狀態(tài)、SQL如何被程序調(diào)用那JSPServlet是最直接的地圖。把所有自動化都去掉之后底層的輪廓才會浮出水面。這個早餐外賣系統(tǒng)的業(yè)務(wù)規(guī)模也不大屬于典型的“高并發(fā)需求低、業(yè)務(wù)邏輯直觀、頁面數(shù)量適中”的項目。早餐店高峰時段就是早上七點到九點單量密集但總量有限用Servlet線程池處理完全夠用。反而如果用Spring Boot起步你會發(fā)現(xiàn)大部分精力耗在理解自動配置上而不是業(yè)務(wù)本身。所以我刻意選擇了“裸奔”方案MVC三層全部手寫連接池用簡單的DBCP或者干脆自己封裝JDBC工具類分頁邏輯自己計算事務(wù)邊界自己在Service層控制。寫完之后再回頭看Spring Boot很多概念都是自然而然的對應(yīng)關(guān)系。1.2 系統(tǒng)模塊劃分與角色權(quán)限我把系統(tǒng)拆成前臺門戶和后臺管理兩大塊對應(yīng)兩種角色普通用戶和管理員。前臺給顧客看菜單、下單、查自己的訂單后臺給店員管理菜品類別、上下架早餐、處理訂單狀態(tài)。權(quán)限控制的核心就一句話Session里有沒有登錄用戶以及這個用戶的role字段是不是1。目錄結(jié)構(gòu)我建議這樣組織注意包名要語義清晰com.food ├── controller // Servlet類處理請求轉(zhuǎn)發(fā)和重定向 ├── service // 業(yè)務(wù)邏輯層事務(wù)控制在這里 ├── dao // JDBC數(shù)據(jù)訪問層 ├── entity // 實體類對應(yīng)數(shù)據(jù)庫表 ├── filter // 編碼過濾器、登錄攔截過濾器 ├── util // DBUtil、MD5工具類等 └── listener // 可選啟動時加載分類緩存JSP頁面放在webapp目錄下前臺頁面和后臺頁面用文件夾區(qū)分webapp/front、webapp/admin。這樣的好處是路徑清晰寫Servlet重定向時不會把前臺后臺弄混。1.3 一個Servlet還是多個Servlet這個點是新手最容易糾結(jié)的地方。我見過不少人圖省事寫一個DishServlet里面用if (list.equals(action))、else if (add.equals(action))分別處理不同請求。項目小的時候這么寫沒問題但早餐外賣系統(tǒng)做到后面至少有十幾個功能動作——菜品增刪改查、分類管理、訂單處理、登錄注冊、購物車操作——全塞一個Servlet會讓代碼膨脹到幾百行排查問題非常痛苦。我采用的方案是“一個業(yè)務(wù)實體一個Servlet”。菜品相關(guān)操作放DishServlet訂單相關(guān)放OrderServlet用戶相關(guān)放UserServlet購物車相關(guān)放CartServlet。每個Servlet里用action參數(shù)通過request.getParameter(action)獲取區(qū)分具體方法。這個模式其實已經(jīng)非常接近Spring MVC的RequestMapping思路了理解這種對應(yīng)關(guān)系之后以后學(xué)框架會輕松很多。2. 數(shù)據(jù)庫設(shè)計與核心建模 —— 一份能應(yīng)付答辯的 MySQL 表結(jié)構(gòu)2.1 分類表與菜品表的設(shè)計早餐外賣店的菜單很有特點品類固定、單品價格不高、常有“豆?jié){油條”這種套餐邏輯。所以我的設(shè)計是“分類表菜品表”的主從結(jié)構(gòu)分類表在前臺渲染成導(dǎo)航欄分類菜品表按分類展示。分類表結(jié)構(gòu)簡單重點是狀態(tài)字段和排序字段CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 分類ID, name VARCHAR(50) NOT NULL COMMENT 分類名稱粥品/煎餅/豆?jié){/套餐, sort_order INT DEFAULT 0 COMMENT 排序權(quán)重值小的靠前, status TINYINT DEFAULT 1 COMMENT 1啟用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );菜品表要注意的字段多一些我把關(guān)鍵字段貼出來CREATE TABLE dish ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL COMMENT 所屬分類ID, name VARCHAR(100) NOT NULL COMMENT 菜品名稱, description VARCHAR(500) COMMENT 菜品描述前臺列表展示, price DECIMAL(10,2) NOT NULL COMMENT 現(xiàn)價, original_price DECIMAL(10,2) DEFAULT NULL COMMENT 原價用于劃線價展示, image VARCHAR(200) COMMENT 圖片路徑存相對路徑, stock INT DEFAULT 0 COMMENT 當(dāng)日庫存賣完自動下架, sales_count INT DEFAULT 0 COMMENT 累計銷量用于“熱銷”排序, status TINYINT DEFAULT 1 COMMENT 1在售 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );兩個細(xì)節(jié)必須強(qiáng)調(diào)第一金額字段統(tǒng)一用DECIMAL(10,2)絕對不要用FLOAT或DOUBLE外賣訂單涉及大量金額累加和單價比較浮點誤差會帶來對不上賬的問題第二圖片存的是webapp/upload下的相對路徑比如/upload/youitao.jpg頁面渲染時用request.getContextPath()拼接成完整路徑。千萬別把完整URL寫死進(jìn)數(shù)據(jù)庫換域名、換端口的時候會瘋掉的。2.2 訂單主表與訂單明細(xì)表建模早餐外賣的訂單和正餐外賣有區(qū)別用戶可能是前一天晚上預(yù)訂第二天早上的餐所以“期望送達(dá)時間”是必須的字段而且前臺下單時要限制只能選明天及以后的時間。訂單設(shè)計成主從兩張表主表存一次訂單的整體信息明細(xì)表存這單里每種餐品的數(shù)量、單價、小計。CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 訂單號年月日隨機(jī)數(shù), user_id INT NOT NULL COMMENT 下單用戶ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 訂單總金額, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付備餐中 2配送中 3已完成 4已取消, receiver_name VARCHAR(50) NOT NULL COMMENT 收貨人姓名, receiver_phone VARCHAR(20) NOT NULL COMMENT 聯(lián)系電話, delivery_address VARCHAR(200) NOT NULL COMMENT 配送地址, expected_time DATETIME NOT NULL COMMENT 期望送達(dá)時間, remark VARCHAR(200) COMMENT 訂單備注比如“不要香菜”, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_user_id(user_id), INDEX idx_status(status), INDEX idx_expected_time(expected_time) ); CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL COMMENT 訂單ID, dish_id INT NOT NULL COMMENT 菜品ID, dish_name VARCHAR(100) NOT NULL COMMENT 下單時的菜品名稱快照, price DECIMAL(10,2) NOT NULL COMMENT 下單時的單價快照, quantity INT NOT NULL COMMENT 數(shù)量, subtotal DECIMAL(10,2) NOT NULL COMMENT 小計金額 );這里有一個菜鳥經(jīng)常忽略的設(shè)計為什么訂單明細(xì)表里要冗余dish_name和price這兩個字段因為早餐店的菜品是會改價、甚至?xí)h除的。如果訂單只存dish_id一個月后店長把豆?jié){從兩塊錢漲到三塊錢你再回去看一個月前的訂單報表金額全變了。這叫“歷史數(shù)據(jù)快照”外賣系統(tǒng)的訂單明細(xì)必須保留下單那一刻的商品信息這是行業(yè)通用做法。2.3 外鍵、索引和命名規(guī)范的實操建議外鍵約束在學(xué)術(shù)上很漂亮但在實際項目里我建議盡量不要加物理外鍵尤其是訂單明細(xì)表關(guān)聯(lián)菜品表、訂單表關(guān)聯(lián)用戶表這種高頻查詢鏈路。理由有兩條一是早餐外賣高峰期密集下單物理外鍵在插入和刪除時會有額外的完整性檢查開銷二是做訂單刪除或菜品歸檔時物理外鍵會擋住操作還得先處理關(guān)聯(lián)數(shù)據(jù)。業(yè)務(wù)上的一致性通過Service層事務(wù)來控制數(shù)據(jù)庫只加普通索引。索引方面訂單表里user_id、status、create_time這三個字段是查詢高頻字段前臺用戶查“我的訂單”、后臺管理員按狀態(tài)篩選訂單、按時間范圍統(tǒng)計營業(yè)額都靠這三個索引。但注意不要無腦加索引——訂單狀態(tài)只有幾個固定值區(qū)分度很低單獨加索引收益不大我更推薦建聯(lián)合索引(status, create_time)這樣既能按狀態(tài)篩也能按時間排一個索引覆蓋兩種場景。命名規(guī)范方面我習(xí)慣表名用單數(shù)字段名全部小寫加下劃線user_id不寫成userIdcreate_time不寫成createTime。Java實體類的駝峰命名和數(shù)據(jù)庫下劃線命名之間在DAO層寫映射時手動轉(zhuǎn)換即可項目不大沒必要引入ORM框架但字段命名統(tǒng)一能讓代碼審查不鬧心。主鍵一律叫id邏輯外鍵直接叫xxx_id一看就能明白關(guān)聯(lián)關(guān)系。3. 核心功能模塊實現(xiàn)細(xì)節(jié) —— 從登錄到結(jié)算的完整閉環(huán)3.1 用戶登錄與會話管理登錄是幾乎所有Web系統(tǒng)的入口早餐外賣系統(tǒng)也不例外。我在UserServlet里寫了個login方法流程就是拿到用戶名和密碼先做非空校驗然后調(diào)Service層的login()方法返回用戶對象或null。密碼存儲那邊用了MD5加鹽的方式注冊時把鹽和密碼哈希一起存庫登錄時用同規(guī)則哈希后比對——雖然是老技術(shù)但配合鹽值仍然能擋住大部分“拖庫撞庫”的低級攻擊。加鹽的核心是一人一鹽讓彩虹表失效。登錄成功后做法是request.getSession().setAttribute(loginUser, user)。退出登錄時不僅要session.invalidate()還要記得把Cookie里的JSESSIONID清理掉不然瀏覽器還會在響應(yīng)頭里帶一個無效的會話ID。Session這塊要提醒一個容易踩的坑不要把整個User對象直接塞在Session里當(dāng)JSON用然后在JSP里取${loginUser.password}這種危險操作。正確做法是把密碼字段設(shè)為null再放入Session或者單獨建一個SafeUser對象只保留id、用戶名、手機(jī)號、角色這些安全字段。登錄攔截用Filter來實現(xiàn)最合適。我建了一個LoginFilter在web.xml里配置映射路徑WebFilter(/*) public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; String uri request.getRequestURI(); // 放行登錄頁、注冊頁、靜態(tài)資源、前臺瀏覽接口 if (uri.endsWith(login.jsp) || uri.endsWith(register.jsp) || uri.contains(/static/) || uri.contains(/upload/) || uri.contains(userServlet?actionlogin) || uri.contains(userServlet?actionregister) || uri.contains(dishServlet?actionlist)) { chain.doFilter(request, response); return; } // 其余頁面必須登錄 HttpSession session request.getSession(false); if (session ! null session.getAttribute(loginUser) ! null) { chain.doFilter(request, response); } else { response.sendRedirect(request.getContextPath() /front/login.jsp); } } }注意request.getSession(false)里的false——意思是如果沒有Session就返回null而不是新創(chuàng)建一個。這個細(xì)節(jié)很關(guān)鍵未登錄用戶訪問后臺頁面時不應(yīng)該被“強(qiáng)行創(chuàng)建Session”白白浪費(fèi)服務(wù)器內(nèi)存還讓會話ID有了可乘之機(jī)。3.2 菜單展示、分頁搜索與圖片坐標(biāo)定位前臺的菜單頁是整個系統(tǒng)門面也是JSP標(biāo)簽庫用得最密集的地方。我用JSTL的c:forEach遍歷菜品列表加上c:choose實現(xiàn)“有圖顯示圖、無圖顯示占位圖”的邏輯。分類導(dǎo)航欄用c:if判斷當(dāng)前選中分類高亮。分頁必須自己寫清楚頁面?zhèn)鱬ageNum參數(shù)每頁固定6個菜品因為早餐店數(shù)量不大一頁放太少顯得空曠放太多又太長DAO層先用SELECT COUNT(*)算總量再執(zhí)行帶LIMIT的查詢int pageSize 6; int totalCount dishDao.countByCategory(categoryId); int totalPages (int) Math.ceil(totalCount * 1.0 / pageSize); int offset (pageNum - 1) * pageSize; ListDish dishList dishDao.findByCategory(categoryId, offset, pageSize);頁碼導(dǎo)航怎么做我的方案是直接用c:forEach從1循環(huán)到totalPages生成?pageNum${i}categoryId${categoryId}的鏈接。這里有個細(xì)節(jié)翻頁時一定要把categoryId也帶上并且當(dāng)前頁碼要控制在1和totalPages之間防止用戶直接在地址欄輸入pageNum999導(dǎo)致SQL越界。圖片坐標(biāo)定位這個需求在早餐外賣里有實際應(yīng)用場景——比如菜單頁的一張菜品展示圖上標(biāo)注“豆?jié){ 2元 / 油條 3元 / 茶葉蛋 1.5元”點擊不同坐標(biāo)區(qū)域跳到對應(yīng)菜品分類。原生JSP做這個很簡單不算復(fù)雜給圖片設(shè)置usemap屬性用HTML的map和area標(biāo)簽劃定多個圓形或矩形熱區(qū)每個熱區(qū)的href指向不同查詢鏈接img src${ctx}/upload/breakfast_map.png usemap#breakfastMap alt早餐地圖 map namebreakfastMap area shaperect coords10,10,120,120 href${ctx}/dishServlet?actionlistcategoryId1 alt粥品 area shapecircle coords180,80,40 href${ctx}/dishServlet?actionlistcategoryId2 alt煎餅 /mapcoordinates的四個數(shù)字分別代表矩形左上角和右下角的x、y坐標(biāo)值確定區(qū)域時直接對著圖片坐標(biāo)量就行。如果要求更細(xì)致的交互可以嵌入一小段JavaScript監(jiān)聽圖片的click事件用event.offsetX和event.offsetY判斷點擊位置落入哪個區(qū)域范圍再手動跳轉(zhuǎn)。兩種方式對比HTML map標(biāo)簽簡單可靠但不靈活JS判斷可以加高亮提示、彈窗預(yù)覽體驗更好代價是要自己寫邏輯。3.3 購物車實現(xiàn)——為什么用Session而不用數(shù)據(jù)庫表購物車這環(huán)節(jié)錯誤答案最多。有些人習(xí)慣性地建一張cart_item表用戶加一次購物車就寫一次數(shù)據(jù)庫提交訂單時再逐條讀出來、刪除。這個方案在體驗上有個硬傷用戶逛了半天加了一堆菜中途瀏覽器直接關(guān)掉或者Session超時這些購物車數(shù)據(jù)就成了垃圾數(shù)據(jù)你還得定時清理。而且早餐外賣的場景里購物車生命周期極短從加餐到下單往往不超過幾分鐘根本犯不著落到數(shù)據(jù)庫。我在這個項目里把購物車直接放在Session里結(jié)構(gòu)是MapInteger, CartItem——key是菜品idvalue是包含菜品信息、數(shù)量、小計的購物車項。實現(xiàn)思路是MapInteger, CartItem cart (MapInteger, CartItem) session.getAttribute(cart); if (cart null) { cart new HashMapInteger, CartItem(); session.setAttribute(cart, cart); } // 加購時判斷key存在就數(shù)量1不存在就新建一項這個方案的好處和柜臺點餐的體驗一致加購不需要訪問數(shù)據(jù)庫零延遲購物車數(shù)據(jù)隨Session自然銷毀沒有臟數(shù)據(jù)積壓。缺點你也能想到——用戶在手機(jī)上逛著逛著把瀏覽器關(guān)了購物車就沒了。但在早餐外賣這種低決策成本、即點即走的場景下這是完全可以接受的取舍。購物車頁面的“數(shù)量加減”按鈕要實現(xiàn)一個細(xì)節(jié)數(shù)量減少到0時這一項自動從Map里移除。營業(yè)額統(tǒng)計和庫存扣減都依賴購物車數(shù)據(jù)的準(zhǔn)確性不要在頁面上顯示數(shù)量為0的餐品后還能提交會讓訂單金額算錯。3.4 訂單提交流程與事務(wù)控制下單是整個系統(tǒng)的核心交易環(huán)節(jié)最容易出數(shù)據(jù)不一致的地方。我按下面的步驟設(shè)計Service層的submitOrder方法從Session里拿購物車校驗非空從Session里拿登錄用戶校驗非空遍歷購物車明細(xì)逐項檢查菜品仍在售、庫存夠數(shù)計算訂單總金額循環(huán)累加每個明細(xì)的subtotal生成訂單號形如20250127093000001純數(shù)字避免和字母混淆插入訂單主表拿到自增id遍歷購物車明細(xì)批量插入訂單明細(xì)表扣減庫存UPDATE dish SET stock stock - ? WHERE id ? AND stock ?清空Session里的購物車返回訂單號跳轉(zhuǎn)到支付模擬頁。這十步里第5、6、7、8四步必須處于同一個事務(wù)里。如果只插了主表、明細(xì)表插入失敗主表訂單就是一條“孤兒訂單”如果下單成功但庫存沒扣商品就可能超賣。早餐店雖然單量不大但邏輯上不能有這種漏洞。我用最樸素的方式管理事務(wù)在DBUtil里封裝getConnection()、beginTransaction()、commit()、rollback()然后在Service層手動控制Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 插入訂單主表、明細(xì)表、扣庫存 DBUtil.commit(conn); } catch (Exception e) { DBUtil.rollback(conn); throw new RuntimeException(下單失敗, e); } finally { DBUtil.release(conn); }由于DAO層的每個方法內(nèi)部都會獨立拿連接和釋放連接開事務(wù)時必須用一個外部傳入的連接。方法簽名設(shè)計成insertOrder(Connection conn, Order order)或者在DAO內(nèi)部增加一個重載方法透傳連接。新手在這個地方很容易犯的錯是Service層開啟事務(wù)后調(diào)用DAO方法DAO又自己DriverManager.getConnection()新拿了一個連接導(dǎo)致事務(wù)根本沒作用在同一個數(shù)據(jù)庫會話上。務(wù)必保證整個業(yè)務(wù)鏈路用的是同一個Connection。訂單狀態(tài)流轉(zhuǎn)我設(shè)計為0待支付 → 1已支付/備餐中 → 2配送中 → 3已完成或者0待支付 → 4已取消。后臺管理員操作按鈕根據(jù)當(dāng)前狀態(tài)顯示對應(yīng)的下一步操作。這個狀態(tài)機(jī)的實現(xiàn)原則是狀態(tài)只能往后走不能回退例如不能從“配送中”改成“待支付”否則財務(wù)數(shù)據(jù)就亂了。3.5 后臺訂單管理與營業(yè)額統(tǒng)計后臺管理員的首頁是一個輕量儀表盤今日訂單數(shù)、今日營業(yè)額、待處理訂單數(shù)、菜品銷量Top5。這些數(shù)據(jù)如果用一條SQL硬拼會很痛苦我的做法是拆成多個SQL聚合查詢分別查COUNT(*)、SUM(total_amount)等。營業(yè)額統(tǒng)計有一個大坑訂單金額的累加時機(jī)。如果統(tǒng)計口徑是“訂單創(chuàng)建時間”那就要排除已取消狀態(tài)如果統(tǒng)計口徑是“訂單完成時間”那所有狀態(tài)都得列入“待支付”但未支付的也算異常。我最終采用的口徑是“只統(tǒng)計狀態(tài)為已支付、配送中、已完成的訂單”把待支付和已取消排除掉。SQL寫法類似SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) AS order_count, COALESCE(SUM(total_amount), 0) AS revenue FROM orders WHERE status IN (1, 2, 3) AND create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE_FORMAT(create_time, %Y-%m-%d) ORDER BY day;COALESCE必須加上——某一天沒有任何訂單時SUM返回null頁面直接顯示空白用0填充才合理。統(tǒng)計圖不建議后端生成圖片太重了。我的方案是后臺JSP頁面把統(tǒng)計結(jié)果轉(zhuǎn)換成JSON數(shù)組用原生JavaScript畫簡單的柱狀圖或者引入輕量Chart.js庫。早餐店老板最關(guān)心的是“今天賣了多少單”“哪幾樣賣得好”柱狀圖和排名列表就夠了不需要炫酷的3D圖表。4. 前端交互與JavaScript細(xì)節(jié) —— 讓頁面活起來的小技巧4.1 表單校驗從正則到提交攔截外賣系統(tǒng)的表單主要集中在登錄、注冊、下單這三個場景登錄只需要用戶名密碼非空但注冊和下單必須做格式校驗。我在前端用JavaScript做首道防線在Servlet端做第二道防線絕不信前端的校驗結(jié)果。手機(jī)號校驗是最常見的需求我用一個正則function isValidPhone(phone) { var reg /^1[3-9]\d{9}$/; return reg.test(phone); }這個正則代表第一位是1第二位在3到9之間后面跟著9位數(shù)字總計11位。它基本覆蓋了目前國內(nèi)用戶手機(jī)號的規(guī)律能在用戶輸入錯誤時立刻提示減少無效請求到達(dá)服務(wù)器。但正則只是“格式校驗”不是“真實驗證”——如果項目需要驗證號碼真的存在那就要接短信驗證碼服務(wù)早餐店系統(tǒng)用不上這個級別。下單表單里的“期望送達(dá)時間”必須用JavaScript校驗不能選過去的日期不能選今天之前的時間。我的做法是用new Date()獲取當(dāng)前時間戳然后和輸入框的值做對比時間早于當(dāng)前時間直接彈框攔截。4.2 AJAX局部刷新消息提示和購物車角標(biāo)JSP頁面默認(rèn)是同步刷新但有幾個場景用AJAX體驗?zāi)芴嵘粋€檔次。最典型的是“加入購物車”用戶點一下“加入購物車”按鈕如果整頁刷新頁面滾動位置會重置用戶要重新找到剛才那個菜很煩。我改成用fetch或XMLHttpRequest異步提交返回JSON前端根據(jù)結(jié)果更新頁面上的“購物車商品數(shù)量”角標(biāo)同時彈一個提示條“已加入購物車”。原生JavaScript里可以用這個方式實現(xiàn)AJAX請求function addToCart(dishId) { fetch(ctx /cartServlet?actionadddishId dishId, { method: GET, credentials: same-origin }) .then(function(resp) { return resp.json(); }) .then(function(data) { if (data.success) { document.getElementById(cartCount).textContent data.cartCount; showMsg(已加入購物車); } else { showMsg(data.message || 加入失敗); } }); }這里有個細(xì)節(jié)要注意AJAX請求同樣會被LoginFilter攔截。如果用戶沒登錄就直接點“加購”返回的不是JSON而是一個重定向到登錄頁的HTML頁面前端解析resp.json()會報錯。我的處理方案是在Filter里對AJAX請求做單獨分支判斷通過X-Requested-With請求頭識別未登錄時返回{success:false,message:請先登錄}前端的提示條會展示這個信息。購物車角標(biāo)更新的本質(zhì)是后端addToCart邏輯執(zhí)行完成后計算cart.size()把數(shù)值放進(jìn)JSON返回。前端拿到后直接textContent賦值這樣不用刷新頁面就能看到角標(biāo)變化。4.3 圖片坐標(biāo)交互和旋轉(zhuǎn)的實用技巧前面提到了HTML map做圖片熱區(qū)這里再補(bǔ)充一種方案用JavaScript監(jiān)聽圖片點擊位置實現(xiàn)更復(fù)雜的交互。比如菜品詳情頁有一張“套餐搭配示意圖”用戶點擊圖上的某個位置系統(tǒng)判斷點擊點落在哪個菜品的圓形區(qū)域內(nèi)然后彈出該菜品的詳情卡片再點一次可以加購。核心代碼是這樣的document.getElementById(dishMap).addEventListener(click, function(e) { var rect e.target.getBoundingClientRect(); var x e.clientX - rect.left; var y e.clientY - rect.top; // 判斷坐標(biāo)是否落在某個圓內(nèi)比如圓心(100,80) 半徑40 var dx x - 100; var dy y - 80; if (dx * dx dy * dy 40 * 40) { window.location.href ctx /dishServlet?actiondetailid3; } });判斷一個圓要計算距離平方這是初中幾何——點到圓心的距離小于半徑就在圓內(nèi)。這套邏輯比HTML map靈活在與后端數(shù)據(jù)聯(lián)動菜品坐標(biāo)可以存在數(shù)據(jù)庫里前端循環(huán)讀取后在canvas或div上動態(tài)繪制熱區(qū)而不需要改HTML代碼。另外提一個小技巧有些早餐店會拍豎版圖片但頁面上想展示橫版的效果。傳統(tǒng)做法是后端處理圖片旋轉(zhuǎn)其實前端一行JavaScript就能搞定旋轉(zhuǎn)例如document.getElementById(menuImg).style.rotate -90deg;CSS的rotate屬性可以直接用角度值注意設(shè)置旋轉(zhuǎn)變換后也要配合transform-origin調(diào)整旋轉(zhuǎn)中心不然圖片會繞著左上角轉(zhuǎn)視覺上偏了。這類前端小技巧在處理一些手機(jī)拍攝的早餐實拍圖時特別實用。4.4 跨瀏覽器兼容的幾個注意點現(xiàn)在的瀏覽器都是現(xiàn)代瀏覽器了大部分標(biāo)準(zhǔn)API都能直接用但做JavaWeb課程設(shè)計時要考慮用戶可能用IE或者老內(nèi)核瀏覽器訪問。兼容性風(fēng)險最高的有四個地方fetch、Promise、let/const、Arrow Function。如果項目沒有引入任何框架和庫我建議寫原生JavaScript時采用ES5語法或者用最基礎(chǔ)的XMLHttpRequest封裝。比如上面的addToCart函數(shù)改成原生寫法var xhr new XMLHttpRequest(); xhr.open(GET, ctx /cartServlet?actionadddishId dishId, true); xhr.onreadystatechange function() { if (xhr.readyState 4 xhr.status 200) { var data JSON.parse(xhr.responseText); ... } }; xhr.send();這里不是讓你退回老技術(shù)而是在選型階段就想清楚目標(biāo)用戶是誰。如果這個系統(tǒng)只是校內(nèi)課程設(shè)計運(yùn)行環(huán)境就是Chrome那用fetch完全沒問題。如果是要交付給某個早餐店實際使用店里的電腦可能是十年前的老機(jī)器、瀏覽器從來沒升級過這時候ES5的兼容性優(yōu)勢立刻體現(xiàn)出來。5. 本地環(huán)境部署實操 —— IDEA MySQL 從零跑通項目5.1 MySQL 安裝與版本選擇這個項目用哪個版本的MySQL合適我推薦5.7 LTS版本例如5.7.44原因有三點5.7還是目前大量高校和中小公司的穩(wěn)定主力版本網(wǎng)上教程最多和8.0相比5.7的連接驅(qū)動配置相對簡單不會碰到8.0的caching_sha2_password驗證插件兼容問題早餐外賣項目的SQL語句沒有8.0特有的窗口函數(shù)需求完全不需要硬上8.0。但如果你電腦上已經(jīng)裝了8.0也不用卸掉重裝。只要在JDBC連接串里額外配置兩項useSSLfalse和allowPublicKeyRetrievaltrue。8.0默認(rèn)使用caching_sha2_password認(rèn)證老版本的MySQL驅(qū)動5.1.x系列連接會報“Public Key Retrieval is not allowed”這個錯加上allowPublicKeyRetrievaltrue就能解決。安裝MySQL時有兩個大坑必須提前說。第一個是初始密碼Windows用ZIP壓縮包方式安裝時解壓后執(zhí)行mysqld --initialize-insecure會生成一個root空密碼這樣第一次登錄不用費(fèi)勁找臨時密碼直接打mysql -uroot就能進(jìn)。第二個是my.ini配置文件里的字符集default-character-set要配合MySQL 5.7的寫法服務(wù)端設(shè)置character-set-serverutf8mb4客戶端連接時在連接串里追加useUnicodetruecharacterEncodingutf8否則JSP頁面顯示中文全是問號。Linux服務(wù)器上部署時RPM包安裝有一個常見問題——MySQL 5.7官方倉庫有時只顯示最新小版本比如搜索“mysql 5.7.44”可能找不到對應(yīng)RPM包。我的建議是直接到MySQL官方下載站挑mysql-community-server-5.7.44-1.el7.x86_64.rpm這種完整包安裝不要依賴yum源自動解析版本。5.2 IDEA 配置 Tomcat 與項目結(jié)構(gòu)在IDEA里跑JSPServlet項目新手被卡住的地方新建項目時選錯了類型。正確姿勢是創(chuàng)建一個普通的“Java Enterprise”項目勾選Web Application模板然后配置Tomcat。如果你手里是已經(jīng)寫好的項目代碼導(dǎo)入時要注意三個地方第一項目必須包含webapp目錄且該目錄被正確標(biāo)記為Web資源目錄。IDEA里右鍵webapp→ “Add Framework Support” → 選擇“Web”是可以補(bǔ)救的。第二WEB-INF/web.xml文件必須存在Servlet全注解開發(fā)時代甚至可以沒有web.xml但I(xiàn)DEA的Artifact打包默認(rèn)依賴這個文件。第三Tomcat的Lib目錄要確認(rèn)IDEA里配置Tomcat的“Server”選項時“Libraries”標(biāo)簽頁如果沒有把servlet-api.jar加進(jìn)來所有Servlet類都會編譯報錯找不到HttpServlet。5.3 JDBC 連接與SSL錯誤處理JDBC連接MySQL的代碼是我見過報錯頻率最高的地方。核心連接串如下以MySQL 5.7為例private static final String URL jdbc:mysql://localhost:3306/food_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai; private static final String USER root; private static final String PASSWORD yourpassword; Class.forName(com.mysql.jdbc.Driver); Connection conn DriverManager.getConnection(URL, USER, PASSWORD);useSSLfalse幾乎必寫。如果你裝的是MySQL 8.0卻下載了5.x的驅(qū)動如果不加這個參數(shù)會報“SSL connection error: java.net.SocketException: Connection reset”看起來像網(wǎng)絡(luò)問題實際是SSL握手失敗。serverTimezoneAsia/Shanghai也要寫因為MySQL 5.7之后驅(qū)動要求明確時區(qū)不寫會報The server time zone value ?D1ú±ê×?ê±?? is unrecognized這種亂碼時區(qū)錯誤。驅(qū)動包的jar文件放置位置也是入門常見問題正確的放法是復(fù)制到webapp/WEB-INF/lib目錄下而不是項目根目錄某處。IDEA里雖然可以通過“Add as Library”讓編譯通過但Tomcat部署時如果驅(qū)動只在編譯classpath里、不在WEB-INF/lib運(yùn)行時就會報ClassNotFoundException: com.mysql.jdbc.Driver。保險起見同時放到外部的Tomcat lib目錄也可以但我更推薦跟隨項目打包這樣換一臺電腦拉代碼不會丟依賴。5.4 部署過程中最常見的幾個404/500問題部署跑起來之后如果頁面出現(xiàn)404或500先別慌按以下列表排查大部分情況是低級配置問題現(xiàn)象可能原因解決方案瀏覽器訪問localhost:8080顯示404 Tomcat首頁項目沒有正確部署到Tomcat的webapps目錄IDEA里檢查Artifact輸出或者直接把項目打成war包放到Tomcat/webapps下Servlet訪問時404注解WebServlet的URL路徑寫錯或web.xml里沒有正確配置映射確認(rèn)注解路徑以/開頭比如WebServlet(/dishServlet)訪問時500 ClassNotFoundExceptionJDBC驅(qū)動jar不在WEB-INF/lib下把jar復(fù)制進(jìn)webapp/WEB-INF/lib后Rebuild Artifact中文亂碼頁面編碼、請求編碼、數(shù)據(jù)庫編碼不一致統(tǒng)一設(shè)置JSP頁面pageEncodingUTF-8Servlet里request.setCharacterEncoding(UTF-8)Filter全局接管訪問jsp頁面直接變成源碼下載Tomcat沒有配置JSP支持檢查是否誤把JSP文件放到了webapp/static或直接用瀏覽器訪問了未編譯的源文件報錯端口被占用Tomcat默認(rèn)8080被其他程序占用用netstat -ano還有一個特別隱蔽的問題IDEA重新部署項目時常常報“Address localhost:8080 is already in use”。這是因為之前部署的Tomcat實例沒有正常關(guān)閉殺進(jìn)程時注意看java.exe進(jìn)程直接全殺容易誤傷IDEA自身我建議用netstat -ano查出監(jiān)聽8080端口的PID再taskkill /PID xxx /F。6. 實操過程實錄 —— 跑一遍核心流程看看每一步做了什么6.1 從建庫建表到后臺發(fā)布菜品的完整流程拿一臺全新的Windows機(jī)器舉例整個流程分七個步驟第一步安裝MySQL并啟動服務(wù)。ZIP包解壓后在bin目錄執(zhí)行mysqld --install和net start mysql然后命令行執(zhí)行mysql -uroot -p登錄執(zhí)行建庫語句CREATE DATABASE food_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。選擇utf8mb4而不是utf8的原因是utf8mb4能存emoji和生僻字早餐店鋪名和菜品里可能出現(xiàn)的特殊符號不會變成亂碼。第二步執(zhí)行表結(jié)構(gòu)SQL建表。依次執(zhí)行分類表、菜品表、用戶表、訂單主表、訂單明細(xì)表的建表語句然后插入測試數(shù)據(jù)。比如INSERT INTO category(name, sort_order) VALUES (粥品, 1), (煎餅, 2), (豆?jié){油條, 3); INSERT INTO dish(category_id, name, price, stock, status) VALUES (1, 皮蛋瘦肉粥, 6.00, 50, 1), (2, 加蛋煎餅, 8.00, 30, 1), (3, 豆?jié){, 2.00, 100, 1);第三步在IDEA里創(chuàng)建JavaWeb項目配置好Tomcat第四步編寫實體類。Dish實體類要包含所有表和前端展示需要的字段注意originalPrice和categoryName這類冗余展示字段可以加上——它對應(yīng)分類表的一對一關(guān)聯(lián)通常用JOIN查詢時在DAO層手動組裝。第五步編寫JDBC工具類和DAO層第六步編寫Servlet層和JSP頁面第七步啟動Tomcat訪問http://localhost:8080/food_web/查看菜單頁。后臺發(fā)布菜品的流程管理員登錄后進(jìn)入/admin/dish_list.jsp點“新增菜品”填寫基本信息。這里圖片上傳是個必做的功能我建議先把圖片文件保存到webapp/upload目錄數(shù)據(jù)庫只存“上傳后返回的文件名”。實際上傳用ServletFileUpload解析multipart表單一個隱藏坑是Tomcat的默認(rèn)post體大小限制——maxPostSize默認(rèn)2MB早餐菜品圖片一般不大但也要注意如果上傳超過2MB的圖片會直接拋異常需要到conf/server.xml的Connector標(biāo)簽里設(shè)置maxPostSize-1-1表示不受限。6.2 顧客端模擬下單流程顧客打開首頁看到分類導(dǎo)航欄和菜品列表點“加入購物車”按鈕。這里需要注意的是未登錄用戶點擊加購時Filter會攔住并跳到登錄頁但URL參數(shù)丟失登錄后不會自動回到加購動作。我的改進(jìn)方案是跳轉(zhuǎn)登錄頁前把原始請求URI存入Session登錄成功后sendRedirect回去session.setAttribute(returnUrl, request.getRequestURI() ? request.getQueryString());這樣用戶登錄一次就能回到剛才瀏覽的位置體驗好不少。登錄后繼續(xù)加購右上角購物車角標(biāo)從0變1再點進(jìn)去看到購物車明細(xì)列表修改數(shù)量后頁面底部實時刷新總金額——這一項我用JS計算因為每個菜的小計和總價都能從前端數(shù)據(jù)拿到不用每次改動都請求后端。然后點擊“去結(jié)算”填寫收貨人、手機(jī)號、地址、期望送達(dá)時間。時間組件我用input typedatetime-local好處是瀏覽器自帶原生選擇器后端解析時用SimpleDateFormat按yyyy-MM-ddTHH:mm格式處理。提交訂單后頁面跳轉(zhuǎn)到支付模擬頁顯示訂單號和應(yīng)付金額點擊“模擬支付”按鈕Ajax請求后端把訂單狀態(tài)從0改成1頁面顯示“支付成功店鋪備餐中”。整個流程在后端做了什么提交時事務(wù)里插了主表和明細(xì)表扣了庫存清空購物車支付時只更新訂單狀態(tài)字段一個UPDATE搞定。早餐店場景不需要真實接支付接口這個模擬流程已經(jīng)把業(yè)務(wù)閉環(huán)打通了。6.3 管理員端訂單處理流程管理員登錄后看到待處理訂單列表每個訂單顯示訂單號、用戶、餐品明細(xì)、總金額、期望送達(dá)時間。點擊“確認(rèn)接單”按鈕后端把status 1改成status 2。再點“完成配送”status 2改成status 3。這里有一個實際操作中的體會管理員頁面最好用定時刷新或手動刷新方式更新列表不用做WebSocket實時推送。早餐店高峰時段可能同時來十幾個訂單管理員每接一單刷新一下頁面完全夠用WebSocket的實時性在這個場景里是偽需求還引入一堆復(fù)雜度。如果真想提升體驗可以加一個前端定時器每分鐘自動location.reload()或者用AJAX輪詢刷新訂單數(shù)量角標(biāo)實現(xiàn)簡單效果也尚可。6.4 數(shù)據(jù)統(tǒng)計校驗后臺統(tǒng)計頁要顯示每日營收曲線和熱銷菜品榜。菜品類銷量我依賴訂單明細(xì)表里的quantity字段SELECT dish_name, SUM(quantity) AS total_sales FROM order_item WHERE order_id IN ( SELECT id FROM orders WHERE status IN (1,2,3) ) GROUP BY dish_name ORDER BY total_sales DESC LIMIT 5;這種SQL在數(shù)據(jù)量小的時候性能沒問題。等訂單積累到萬級子查詢的性能瓶頸會出現(xiàn)優(yōu)化方向是把統(tǒng)計邏輯拆到獨立報表表里每天夜里定時匯總。但在課程設(shè)計和創(chuàng)業(yè)初期完全夠用不必過度設(shè)計。7. 常見問題與排查技巧速查表7.1 高頻報錯的一線解決方案列舉一下我實際跑這個項目時遇到、以及幫別人排查過的最典型問題直接按表格查就行癥狀根因處理方式j(luò)ava.sql.SQLException: Access denied for user rootlocalhost密碼錯誤或root賬號授權(quán)問題在命令行用mysql -uroot -p重設(shè)密碼或執(zhí)行ALTER USER rootlocalhost IDENTIFIED BY 新密碼;The server time zone value ... is unrecognized連接串沒指定時區(qū)連接串加serverTimezoneAsia/ShanghaiMySQL 8.0時加useSSLfalseallowPublicKeyRetrievaltrue中文亂碼多層編碼不一致Filter里統(tǒng)一request.setCharacterEncoding(UTF-8)JSP頂部pageEncodingUTF-8MySQL表字段用utf8mb4表單提交后原子性問題沒有開啟事務(wù)Service層包事務(wù)確認(rèn)DAO方法復(fù)用同一個ConnectionTomcat運(yùn)行后無法訪問項目頁面Artifact配置錯誤IDEA里Project Structure → Artifacts → 確保輸出類型為war explodedDeployment里Application context填/MySQL 8.0連不上報Public Key Retrieval is not allowed8.0默認(rèn)認(rèn)證插件連接串加allowPublicKeyRetrievaltrue或創(chuàng)建MySQL用戶時指定mysql_native_password7.2 SQL層面的隱蔽坑早餐外賣系統(tǒng)的SQL并不復(fù)雜但幾個隱蔽問題非常值得記錄。第一個是DELETE FROM orders WHERE id?這種刪除訂單的SQL一旦訂單有明細(xì)表關(guān)聯(lián)刪除主表會產(chǎn)生孤兒明細(xì)數(shù)據(jù)。項目里我的策略是不做物理刪除用status4已取消標(biāo)記后臺列表默認(rèn)過濾掉但數(shù)據(jù)完整保留。第二個是分頁排序混亂問題如果一個頁面上菜品數(shù)據(jù)多次插入沒有明確的ORDER BY idMySQL返回順序可能隨機(jī)且不穩(wěn)定。所以我分頁SQL統(tǒng)一加ORDER BY id ASC避免用戶翻頁時看到菜品順序跳變。第三個是COUNT(*)和COUNT(1)的選擇——在這類小項目里性能差異可忽略但注意COUNT(column)會忽略NULL列統(tǒng)計訂單數(shù)量時如果列有NULL值就容易數(shù)錯直接用COUNT(*)最穩(wěn)妥。7.3 前后端聯(lián)調(diào)時的數(shù)據(jù)格式問題后端Servlet返回數(shù)據(jù)給前端JavaScript時通常用JSON格式。我用的工具是阿里的Fastjson或者Google的Gson在Java里JSON.toJSONString(resultMap)然后通過response.getWriter().write(json)輸出。JSP的script塊里接收時有一個編碼陷阱如果JSP本身contentTypetext/html; charsetUTF-8但Servlet響應(yīng)的Content-Type沒設(shè)置前端JSON.parse可能因為編碼問題解析失敗。穩(wěn)妥做法是Servlet端每次返回JSON都設(shè)置response.setContentType(application/json;charsetUTF-8);前端拿到中文后不用手動轉(zhuǎn)碼JSON標(biāo)準(zhǔn)要求UTF-8。8. 從JSPServlet到框架的思維遷移如果這個系統(tǒng)你已經(jīng)完整寫過一遍我建議你做三個后續(xù)的小實驗用最小的成本感受框架演進(jìn)思路。第一個實驗把DishServlet的一個action方法改成Spring MVC的RequestMapping寫法對比一下URL映射和參數(shù)獲取的異同。你會發(fā)現(xiàn)Spring MVC的RequestParam本質(zhì)就是request.getParameter()的封裝ModelAndView本質(zhì)就是request.setAttribute() forward的封裝。第二個實驗把JDBC手動事務(wù)改成聲明式事務(wù)感受一下Transactional為什么能減少重復(fù)代碼。手寫事務(wù)要每次開連接、提交、回滾聲明式事務(wù)只用加一個注解底層是用AOP動態(tài)代理做的同一件事。第三個實驗把Session購物車改成Redis緩存購物車對比Session方案和獨立緩存方案的差異。Session方案天然綁定單臺服務(wù)器Redis方案可以讓用戶請求打到不同后端節(jié)點而不丟購物車數(shù)據(jù)。這個對比做完后你會對無狀態(tài)設(shè)計和水平擴(kuò)展有切身理解。每次從老技術(shù)遷移到新技術(shù)時試著在代碼注釋里標(biāo)注“這個注解背后做了哪些事如果不用框架我會怎么寫”——堅持這樣一個習(xí)慣技術(shù)底子會打得很扎實。我見過太多只會在Spring Boot里寫RestController、但連HTTP請求是怎么被Servlet容器接住的人。早餐外賣項目這種“裸寫”機(jī)會其實是性價比極高的自我訓(xùn)練。最后分享一點個人看法技術(shù)選型要看場景課程設(shè)計和畢業(yè)設(shè)計寫JSPServlet不是落后而是用最小的復(fù)雜度看清整個Web請求鏈路。你在IDEA里按部就班搭一次這個系統(tǒng)把Session透傳、事務(wù)邊界、Filter攔截這幾塊真正吃透再去學(xué)Spring Boot效率能翻倍。上面這些坑我基本都踩過一遍寫下來算是給后來者省點時間照著做應(yīng)該能少走不少彎路。