簡介這是一套基于JavaWeb實現(xiàn)的必勝客在線訂餐系統(tǒng)項目包面向正在學習JavaWeb、準備課程設(shè)計或畢業(yè)設(shè)計的學生與初級開發(fā)者圍繞用戶注冊登錄、菜單瀏覽、購物車、下單支付及后臺菜品與訂單管理等典型餐飲業(yè)務(wù)場景展開可幫助讀者打通從需求分析、數(shù)據(jù)庫設(shè)計到前后端交互的完整鏈路。壓縮包共1307個文件約66.88MB以png、jpg等頁面圖片素材java源碼、class編譯文件、jsp與html視圖、css與js腳本以及jar依賴、xml與properties配置和sql建表腳本為主基本覆蓋開發(fā)、部署與數(shù)據(jù)初始化所需內(nèi)容。目前已有2518人學習。項目采用MVC思路組織Servlet、JSP與JavaBean配合數(shù)據(jù)庫訪問層完成業(yè)務(wù)邏輯讀者可重點研讀請求處理、數(shù)據(jù)校驗、訂單狀態(tài)流轉(zhuǎn)與頁面異步交互也能從配置和目錄結(jié)構(gòu)中理解Tomcat部署方式適合作為課程設(shè)計模板或JavaWeb綜合實踐參考。1. 拿到一個 JavaWeb 訂餐系統(tǒng)源碼包先分清它是 JSPServlet 還是 SSM把壓縮包解開之后第一件事不是打開 IDE 新建工程而是先ls一遍目錄。JavaWeb 這個詞在課程設(shè)計資源里覆蓋的跨度極大一種是最經(jīng)典的 JSP Servlet JDBC 直連 MySQL 的三層結(jié)構(gòu)另一種是 Spring SpringMVC MyBatis 的整合工程兩者的啟動方式、依賴管理甚至配置文件的后綴都不一樣。這個在線訂餐系統(tǒng)屬于哪一類決定了你接下來半小時是順風順水還是連續(xù)翻車。它真正值錢的地方在于提供了一條完整的點餐鏈路菜單瀏覽、加入購物車、提交訂單、后臺改單四段都能跑通而不是一堆互不相干的 CRUD 頁面拼起來的樣子貨。適合兩類人趕課程設(shè)計需要一套能演示、能講清邏輯的骨架以及剛學完 Servlet 想找一個有業(yè)務(wù)味道的練手項目而不是繼續(xù)在圖書管理系統(tǒng)的增刪改查里打轉(zhuǎn)。下面按「先判斷、再跑通、后拆解、最后避坑」的順序走每一步都落到你能直接抄的命令和參數(shù)上。2. 環(huán)境對齊JDK、Tomcat、MySQL 三件套版本核對這類包最容易出問題的地方不在代碼而在版本。課程設(shè)計資源普遍有年份包里的mysql-connector-java-5.1.x.jar配 MySQL 8 會直接報驅(qū)動類找不到j(luò)avax.servlet與jakarta.servlet混用則會在 Tomcat 10 上整站 404。我一般會先把版本關(guān)系釘死再談別的。2.1 看目錄判斷技術(shù)棧用一次 find 摸清家底傳統(tǒng)工程和 Maven 工程的區(qū)分非常明顯看有沒有pom.xml就夠了。但光看這個還不夠得順手把 jar 包、SQL 腳本、配置文件全撈出來心里有張地圖后面排錯才不會靠猜。你看到的目錄/文件大概率是什么后續(xù)動作WEB-INF/web.xmlWEB-INF/lib/*.jarsrc傳統(tǒng) JSPServlet 工程按普通 Web 工程導入jar 手動掛到 classpathpom.xmlsrc/main/javasrc/main/webappMaven 工程多為 SSM先mvn dependency:tree看依賴有沒有沖突applicationContext.xml/spring-mvc.xmlSpring 系整合檢查包掃描路徑和數(shù)據(jù)源 Bean*.sql常見名order_db.sql、db.sql建庫建表腳本先導庫再改連接參數(shù)jdbc.properties/db.properties連接參數(shù)外置優(yōu)先改這里別動 Java 源碼里的硬編碼# 解壓后先做一次結(jié)構(gòu)掃描別急著導 IDE unzip -q online-order.zip -d order-src cd order-src # 1. 看清目錄層級判斷是 webapp 結(jié)構(gòu)還是標準 Maven 結(jié)構(gòu) find . -maxdepth 3 -type d | sort # 2. 把所有 jar 列出來重點看 mysql 驅(qū)動和 servlet-api 的版本 find . -name *.jar -exec basename {} \; | sort -u # 3. 定位三個關(guān)鍵文件web.xml、pom.xml、建庫腳本 find . \( -name web.xml -o -name pom.xml -o -name *.sql -o -name jdbc.properties \) -print這三條命令里第一條決定導入方式第二條決定版本兼容性第三條決定你改配置時該打開哪個文件。第二條尤其關(guān)鍵如果看到mysql-connector-java-5.1.47.jar而你本機是 MySQL 8就要么換成mysql-connector-java-8.0.x要么把驅(qū)動的類名從com.mysql.jdbc.Driver改成com.mysql.cj.jdbc.Driver兩者只能選一個混著來必報ClassNotFoundException。servlet-api 的 jar 如果出現(xiàn)在WEB-INF/lib里部署前記得刪掉容器自己會提供重復了會引發(fā)類加載沖突。2.2 數(shù)據(jù)庫先跑通建表、導數(shù)據(jù)、改四個連接參數(shù)代碼可以慢慢看數(shù)據(jù)庫必須先活。絕大多數(shù)「頁面空白、后臺報 500」的根因都是連接串里缺參數(shù)或者庫名對不上。-- 建庫時字符集一次到位別用默認的 latin1 再回頭改 CREATE DATABASE IF NOT EXISTS order_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE order_db; -- 菜品表status 控制上下架stock 用于下單時扣減 CREATE TABLE dish ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, img VARCHAR(255) DEFAULT NULL, -- 只存相對路徑如 /upload/dish/1.jpg status TINYINT NOT NULL DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 訂單主表total 是下單瞬間的金額快照 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT NOT NULL, total DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待支付 1已支付 2配送中 3已完成 4已取消 create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;連接參數(shù)建議單獨放一個 properties 文件改的時候不用重新編譯# src/main/resources/jdbc.properties jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/order_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue jdbc.usernameroot jdbc.password改成你自己的密碼連接串里的四個參數(shù)各自管一件事缺一個就會以很奇怪的方式失敗characterEncodingutf8決定中文能不能正常入庫serverTimezoneAsia/Shanghai不加MySQL 8 會報時區(qū)異常訂單時間直接是 nulluseSSLfalse是為了本地開發(fā)省掉證書握手allowPublicKeyRetrievaltrue是 MySQL 8 默認認證插件下必須開的否則第一次連接就被拒絕。密碼不要留在代碼里也不要提交到任何倉庫這是血淚經(jīng)驗。// 讀取配置并統(tǒng)一管理連接避免每個 DAO 里都寫一遍 DriverManager public class DBUtil { private static final Properties PROPS new Properties(); static { try (InputStream in DBUtil.class.getClassLoader() .getResourceAsStream(jdbc.properties)) { PROPS.load(in); Class.forName(PROPS.getProperty(jdbc.driver)); // 老驅(qū)動這里會拋異常 } catch (Exception e) { throw new ExceptionInInitializerError(數(shù)據(jù)源初始化失敗: e.getMessage()); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection( PROPS.getProperty(jdbc.url), PROPS.getProperty(jdbc.username), PROPS.getProperty(jdbc.password)); } }這段代碼的關(guān)鍵在靜態(tài)塊Class.forName一旦失敗整個類初始化就崩報錯會非常明確地指向驅(qū)動問題比運行時在某個 DAO 里拋NullPointerException好排查得多。getResourceAsStream用的是 classloader 路徑所以jdbc.properties必須放在src/main/resources或者WEB-INF/classes下放錯位置讀出來就是 null。2.3 編譯、打包、部署war 包怎么放context path 怎么定Maven 工程一條命令解決傳統(tǒng)工程走 IDEA 的 Artifacts 配置兩條路都要清楚。# Maven 工程跳過測試直接打包 mvn -DskipTests clean package # 產(chǎn)物一般在 target 下確認 war 包名字 ls -lh target/*.war # 丟進 Tomcat 的 webappswar 名就是 context path cp target/order.war $CATALINA_HOME/webapps/ # 啟動并觀察日志重點看有沒有 SEVERE 和數(shù)據(jù)庫連接異常 $CATALINA_HOME/bin/startup.sh tail -f $CATALINA_HOME/logs/catalina.out如果 war 包叫order.war訪問地址就是http://localhost:8080/order/末尾的斜杠不能省省了在部分容器版本上會 404。非 Maven 工程則要把WEB-INF/lib下所有 jar 一起打進 artifact 的WEB-INF/lib漏一個就是NoClassDefFoundError。啟動日志里如果出現(xiàn)Communications link failure說明 MySQL 沒起來或端口不通出現(xiàn)Unknown database order_db說明建庫腳本沒執(zhí)行或者庫名改了沒同步這兩類錯誤占首次部署失敗的八成以上先看日志再改代碼。3. 訂單主鏈路從加購物車到落庫的四個關(guān)鍵節(jié)點點餐系統(tǒng)的業(yè)務(wù)復雜度幾乎全壓在訂單上。菜單和用戶是靜態(tài)數(shù)據(jù)訂單是有狀態(tài)、有并發(fā)、有金額的寫得好不好在這里拉開差距。這一段拆的是包里最值得看的部分也是二次改造時最容易改出 bug 的地方。3.1 購物車放 Session 還是放數(shù)據(jù)庫課程設(shè)計級項目基本都是 Session簡單直接但也埋著坑。// 購物車結(jié)構(gòu)dishId - {數(shù)量, 下單時的單價快照} // 不直接緩存 Dish 實體避免菜品改價后購物車金額跟著漂 public class CartItem implements Serializable { private Integer dishId; private String name; private BigDecimal price; // 加入購物車時鎖定的價格 private int qty; // getter / setter 省略 } // 加購已存在就累加數(shù)量不存在就新建 WebServlet(/cart/add) public class CartAddServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { int dishId Integer.parseInt(req.getParameter(dishId)); int qty Integer.parseInt(req.getParameter(qty)); HttpSession session req.getSession(); MapInteger, CartItem cart (MapInteger, CartItem) session.getAttribute(cart); if (cart null) { cart new LinkedHashMap(); // 保持加入順序頁面顯示更穩(wěn)定 session.setAttribute(cart, cart); } CartItem item cart.get(dishId); if (item null) { Dish dish dishService.findById(dishId); // 查一次庫拿名稱和價格 item new CartItem(dishId, dish.getName(), dish.getPrice(), 0); cart.put(dishId, item); } item.setQty(item.getQty() qty); resp.sendRedirect(req.getContextPath() /cart/list); } }用LinkedHashMap而不是HashMap是為了讓購物車列表按用戶加購順序展示HashMap的遍歷順序在不同 JDK 版本上并不一致偶爾會出現(xiàn)「加了兩道菜順序亂跳」的玄學現(xiàn)象。價格在加購時鎖進CartItem是為了給下面的事務(wù)做鋪墊——下單時必須用鎖定的價而不是下單瞬間重新查庫的價。Session 方案的天花板也很清楚換瀏覽器購物車就沒了多實例部署時不共享。要往生產(chǎn)方向走就得把購物車落到cart表用user_id dish_id做唯一鍵INSERT ... ON DUPLICATE KEY UPDATE qty qty ?一條 SQL 搞定累加。這一步改造量不大但講清楚為什么改比直接堆一個 Redis 更有說服力。3.2 下單事務(wù)金額快照、明細落庫、庫存扣減必須在一個事務(wù)里這是整個項目最該逐行讀的方法。寫錯的話線上表現(xiàn)就是「訂單成功了但庫存沒動」或者「扣了庫存訂單沒生成」。public String submitOrder(int userId, MapInteger, CartItem cart) throws SQLException { Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 關(guān)閉自動提交事務(wù)從這里開始 // 1. 先算總額并生成訂單號簡化版生產(chǎn)建議用雪花或號段 String orderNo OD System.currentTimeMillis(); BigDecimal total BigDecimal.ZERO; for (CartItem it : cart.values()) { total total.add(it.getPrice().multiply(BigDecimal.valueOf(it.getQty()))); } // 2. 主表落庫status0 待支付 long orderId orderDao.insert(conn, orderNo, userId, total, 0); for (CartItem it : cart.values()) { // 3. 明細表存價格快照歷史訂單不受后續(xù)改價影響 orderItemDao.insert(conn, orderId, it.getDishId(), it.getPrice(), it.getQty()); // 4. 帶條件的庫存扣減影響行數(shù)為 0 說明庫存不夠 int affected dishDao.reduceStock(conn, it.getDishId(), it.getQty()); if (affected 0) { throw new SQLException(庫存不足, dishId it.getDishId()); } } conn.commit(); return orderNo; } catch (SQLException e) { if (conn ! null) conn.rollback(); // 任何一步失敗整體回滾 throw e; } finally { if (conn ! null) { conn.setAutoCommit(true); conn.close(); } } }配套的扣減 SQL 必須是帶條件的更新不能先 select 再 update-- 用一條語句完成「判斷 扣減」把并發(fā)判斷交給數(shù)據(jù)庫 UPDATE dish SET stock stock - #{qty} WHERE id #{dishId} AND stock #{qty};AND stock qty這個條件就是并發(fā)防線。兩個用戶同時搶最后一份MySQL 的行鎖會讓第二條更新看到扣減后的值條件不成立返回影響行數(shù) 0Java 層據(jù)此拋異?；貪L。如果改成先SELECT stock判斷夠不夠、再UPDATE中間那段窗口期足夠插進另一個事務(wù)超賣就發(fā)生了。同一個Connection貫穿所有 DAO 也是必須的很多人圖省事在每個 DAO 里各自getConnection()那種寫法下setAutoCommit(false)完全失效回滾只回滾了個寂寞。3.3 訂單狀態(tài)機別讓后臺能隨便改狀態(tài)狀態(tài)字段用數(shù)字沒問題問題在于沒有約束。后臺管理頁面上一個「修改狀態(tài)」的下拉框如果直接UPDATE orders SET status ?運營手一抖就能把已完成的訂單改回待支付。-- 只允許合法躍遷待支付(0) - 已支付(1) - 配送中(2) - 已完成(3) -- 取消只允許從 0 或 1 發(fā)起 UPDATE orders SET status #{to} WHERE id #{orderId} AND status #{from};執(zhí)行后檢查影響行數(shù)為 0 就提示「訂單狀態(tài)已變化請刷新后重試」。這一招順帶解決了重復提交用戶連點兩次「確認收貨」第二次的from已經(jīng)不是 2 了更新自然失敗不會重復觸發(fā)積分或通知邏輯。狀態(tài)躍遷表建議直接寫死在 Service 里用一個MapInteger, SetInteger存允許的下一狀態(tài)比散落在各個 if 里安全得多。這里不需要上狀態(tài)機框架但要有一張明確的表至少自己排錯時能一眼看出哪條路徑是非法的。3.4 分頁與菜品圖片兩個小功能兩個大坑分頁別用LIMIT offset, size配全表COUNT(*)就完事菜品表數(shù)據(jù)量小的時候看不出問題做二次開發(fā)一造幾萬條數(shù)據(jù)就慢了。常規(guī)寫法是兩條 SQL一條SELECT ... ORDER BY id DESC LIMIT ?, ?一條SELECT COUNT(*) FROM dish WHERE status 1兩條共用同一套 where 條件條件拼錯就會導致「總數(shù) 100 條但翻到第 3 頁就空了」。// 分頁參數(shù)做邊界收斂防止 page0 或 size10000 這類臟輸入 int page Math.max(1, Integer.parseInt(req.getParameter(page) null ? 1 : req.getParameter(page))); int size 8; // 每頁固定 8 道菜前端三列布局剛好 int offset (page - 1) * size; ListDish list dishDao.findByPage(offset, size); int total dishDao.countOnSale(); int pages (total size - 1) / size; // 向上取整別用整除圖片上傳這塊包里常見的做法是把文件存到webapp/upload/下數(shù)據(jù)庫里存相對路徑/upload/dish/xxx.jpg。存相對路徑而不是D:/tomcat/webapps/...這種絕對路徑是能不能換機器部署的分水嶺。文件名一定要重命名成 UUID 或時間戳別用原始文件名中文名加特殊字符在部分容器上會導致 404上傳目錄也別放在WEB-INF里面那個目錄瀏覽器根本訪問不到。4. 登錄、權(quán)限與后臺管理過濾器與參數(shù)綁定后臺管理是這類項目里最容易被忽略的部分因為它「能跑就行」。但恰恰是后臺頁面越權(quán)訪問、SQL 拼接、明文密碼三個問題經(jīng)常同時出現(xiàn)。4.1 編碼過濾器與登錄攔截兩個 Filter 各管一件事編碼問題統(tǒng)一在入口解決別在每個 Servlet 里寫setCharacterEncoding。WebFilter(/*) // 攔截所有請求順序上要排在登錄過濾器之前 public class EncodingFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { req.setCharacterEncoding(UTF-8); // 只管 POST 體 resp.setCharacterEncoding(UTF-8); resp.setContentType(text/html;charsetUTF-8); chain.doFilter(req, resp); } } WebFilter(urlPatterns {/order/*, /cart/*, /admin/*}) public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest r (HttpServletRequest) req; HttpSession session r.getSession(false); // 注意false別順手創(chuàng)建新會話 if (session null || session.getAttribute(loginUser) null) { ((HttpServletResponse) resp).sendRedirect(r.getContextPath() /login.jsp); return; // 不往下走請求到此為止 } chain.doFilter(req, resp); } }getSession(false)這個參數(shù)是重點。寫成getSession()或getSession(true)每個未登錄請求都會創(chuàng)建一個空會話內(nèi)存里堆一堆無用的 Session 對象壓測時看著內(nèi)存曲線往上走還找不到原因。兩個過濾器的執(zhí)行順序由web.xml里的filter-mapping聲明順序決定或者在注解場景下靠過濾器名字母序所以正式項目里建議統(tǒng)一寫在web.xml里順序看得見。4.2 后臺越權(quán)前端隱藏菜單不叫權(quán)限控制后臺頁面常見做法是登錄后按角色渲染菜單管理員看得到「菜品管理」普通用戶看不到。但菜單只是a標簽地址欄直接敲/admin/dish/list照樣能進。真正的攔截必須在服務(wù)端做。// 后臺攔截角色不匹配直接打回首頁別只靠隱藏鏈接 WebFilter(/admin/*) public class AdminFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest r (HttpServletRequest) req; User user (User) r.getSession().getAttribute(loginUser); if (user null || user.getRole() ! 1) { // 1 管理員 ((HttpServletResponse) resp).sendError(403); return; } chain.doFilter(req, resp); } }sendError(403)比sendRedirect更合適越權(quán)訪問不該被靜默重定向成「正?！沽鞒倘罩纠镆哺菀锥ㄎ弧＝巧侄斡谜麛?shù)沒錯但要定義成常量或者枚舉別在十個地方散寫role 1后期加一個「店長」角色就得全局搜索替換。4.3 密碼存儲與 SQL 注入兩道必須自己守的線用戶表里存明文密碼是這類課程設(shè)計包里最常見的減分項。改造成本其實很低。// 注冊與登錄都用占位符字符串拼接一律不許出現(xiàn) public User login(String username, String rawPwd) throws SQLException { String sql SELECT id, username, pwd_hash, salt, role FROM user WHERE username ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); try (ResultSet rs ps.executeQuery()) { if (!rs.next()) return null; String salt rs.getString(salt); String expect rs.getString(pwd_hash); // 加鹽摘要同一密碼在不同用戶下哈希值不同彩虹表失效 String actual DigestUtils.sha256Hex(salt rawPwd); return expect.equalsIgnoreCase(actual) ? mapRow(rs) : null; } } }PreparedStatement的占位符不只是防注入還能讓數(shù)據(jù)庫復用執(zhí)行計劃username a OR 11這種輸入會被當成普通字符串處理。至于密碼最低要求是加鹽哈希別用 MD5 裸哈希要更穩(wěn)一點就換 BCrypt自帶鹽值和計算強度代價是登錄時多花幾十毫秒。這里還有一個細節(jié)登錄失敗時不要區(qū)分「用戶不存在」和「密碼錯誤」統(tǒng)一提示「用戶名或密碼錯誤」否則等于免費提供賬號枚舉接口。5. 避坑與排查五條踩過的記錄按現(xiàn)象對號入座以下五條是我拆這類包時按出現(xiàn)頻率排的基本覆蓋了從解壓到跑通的全過程。遇到問題先按「現(xiàn)象」對照比漫無目的地翻代碼快得多。5.1 啟動與部署類問題記錄一訪問首頁 404日志里沒有任何異?，F(xiàn)象Tomcat 啟動成功localhost:8080能出貓頁但訪問項目路徑就是 404catalina.out干干凈凈。原因war 包沒有真正解壓或者 context path 和你想的不一樣。常見于 war 包名帶版本號如order-1.0.war實際路徑是/order-1.0/也可能是web.xml里url-pattern寫成了/index而首頁文件叫index.jsp容器沒配歡迎頁。解決先ls $CATALINA_HOME/webapps/確認解壓出來的目錄名訪問地址嚴格按目錄名來檢查web.xml里有沒有welcome-file-list沒有就手動訪問/index.jsp驗證最后看server.xml里 Connector 的端口是不是被改過。記錄二啟動報 ClassNotFoundException: com.mysql.cj.jdbc.Driver現(xiàn)象應(yīng)用能起來但一碰數(shù)據(jù)庫就拋異常堆棧里明確寫著驅(qū)動類找不到。原因三種可能——jar 沒打進WEB-INF/lib打進去了但是 5.1.x 版本類名應(yīng)該是com.mysql.jdbc.Driver或者容器本身帶了一個老版本驅(qū)動類加載時先命中了它。解決find . -name mysql-connector*.jar確認驅(qū)動文件存在MySQL 8 用com.mysql.cj.jdbc.Driver5.7 用com.mysql.jdbc.Driver兩者不能混如果容器lib目錄下也有同名驅(qū)動刪掉容器里的那份讓應(yīng)用自帶的生效。5.2 數(shù)據(jù)與編碼類問題記錄三菜品名稱入庫變成問號頁面顯示亂碼現(xiàn)象后臺新增一道菜數(shù)據(jù)庫里查出來是???或者頁面標題上出現(xiàn)一串菱形方塊。原因鏈路上有三處字符集任何一處是 latin1 都會斷。數(shù)據(jù)庫/表沒設(shè)utf8mb4連接串缺characterEncodingutf8JSP 頁面沒寫% page contentTypetext/html;charsetUTF-8 %。解決先SHOW CREATE TABLE dish;看表字符集不對就ALTER TABLE dish CONVERT TO CHARACTER SET utf8mb4;再核對連接串的編碼參數(shù)最后統(tǒng)一在過濾器和 JSP 頭部各設(shè)一次三處齊了才不會漏。已經(jīng)寫成問號的數(shù)據(jù)改不回來只能重錄所以建庫那一步別偷懶。5.3 業(yè)務(wù)邏輯類問題記錄四下單提示成功但庫存數(shù)字紋絲不動現(xiàn)象訂單列表里有新訂單明細也對可菜品表里stock一直是原值。原因庫存扣減的 SQL 放在了事務(wù)之外或者 DAO 各自開了連接主事務(wù)回滾了它也不知道還有一種情況是扣減語句寫成了SET stock ?直接賦值而不是stock stock - ?看著執(zhí)行成功其實把庫存改成了固定值。解決確認所有 DAO 方法接收同一個Connection參數(shù)并且沒有內(nèi)部getConnection()確認扣減用的是stock stock - #{qty}并且?guī)ND stock #{qty}最后在commit()之前打斷點看每一步的影響行數(shù)是不是都在預期內(nèi)。這類問題最典型的特征是「部分成功」一旦見到部分成功先懷疑事務(wù)邊界。5.4 靜態(tài)資源類問題記錄五菜品圖片上傳成功頁面上一片裂圖現(xiàn)象上傳接口返回成功數(shù)據(jù)庫里img字段也有值但img src...顯示不出來瀏覽器控制臺 404。原因存的是絕對路徑如D:\upload\1.jpg瀏覽器沒法訪問或者文件寫到了WEB-INF/upload下這個目錄對外不可見再或者img字段存的是upload/1.jpg而頁面在/dish/list這種二級路徑下相對路徑解析錯了。解決統(tǒng)一存以/開頭的應(yīng)用內(nèi)相對路徑頁面渲染時拼上${pageContext.request.contextPath}上傳目錄放在webapp下而非WEB-INF下如果用到 SpringMVC檢查mvc:resources有沒有把/upload/**映射到實際目錄漏了配置就算文件真實存在也是 404。6. 二次改造讓這套骨架從「能演示」變成「能講清楚」跑通只是及格線。這套代碼真正的價值在于它的結(jié)構(gòu)足夠干凈改起來不牽一發(fā)動全身。我一般的改造順序是先補數(shù)據(jù)一致性再補交互最后才是加功能因為前兩步?jīng)Q定了你改動之后還敢不敢繼續(xù)動。改造點具體做法驗證方式購物車持久化新建cart表user_iddish_id唯一鍵用ON DUPLICATE KEY UPDATE做累加換瀏覽器登錄購物車內(nèi)容還在訂單號生成時間戳換成「日期 庫自增序列」或雪花算法并發(fā)壓 50 單order_no 無重復重復提交防護訂單表加token字段頁面渲染時下發(fā)提交時校驗并刪除連點提交按鈕只生成一單后臺權(quán)限細化角色常量抽成枚舉AdminFilter按 URI 前綴分級普通賬號直敲后臺地址返回 403慢查詢治理給orders(user_id, create_time)加聯(lián)合索引EXPLAIN看 type 從 ALL 變 ref改造完怎么確認沒改壞我的習慣是準備一份最小回歸清單每次動完代碼照著走一遍比憑記憶點頁面靠譜得多# 用 curl 做一輪冒煙比手點快也方便比對返回 BASEhttp://localhost:8080/order # 1. 登錄拿會話把 cookie 存下來后續(xù)請求帶上 curl -s -c /tmp/ck.txt -d usernametestpassword123456 $BASE/login -o /dev/null -w login:%{http_code}\n # 2. 加購兩道菜看是否 302 到購物車 curl -s -b /tmp/ck.txt -d dishId1qty2 $BASE/cart/add -o /dev/null -w add:%{http_code}\n # 3. 提交訂單返回體里應(yīng)帶訂單號 curl -s -b /tmp/ck.txt -X POST $BASE/order/submit | grep -o OD[0-9]* # 4. 直接查庫核對庫存是否真的減了 2 mysql -uroot -p -e SELECT id,name,stock FROM order_db.dish WHERE id1;這套腳本的意義在于把「頁面看起來正常」換成「數(shù)據(jù)確實對上了」。第 3 步拿到的訂單號要和第 4 步的庫存變化對得上才算真的通過只看到跳轉(zhuǎn)到成功頁就收工很容易漏掉事務(wù)沒生效的情況。還有一個容易被忽略的點改完之后記得把web.xml里的歡迎頁、過濾器順序、jdbc.properties三者再對一遍。我吃過一次虧把數(shù)據(jù)庫從本地換到另一臺機器只改了 properties 忘了改連接池的初始化參數(shù)結(jié)果應(yīng)用啟動正常第一次下單才報錯排查了半天才想起是兩個配置源。從那以后我每次動配置都強制先把「啟動 → 登錄 → 加購 → 下單 → 后臺改狀態(tài)」這條鏈路空跑一遍再改代碼雖然多花五分鐘但省下的往往是半個下午。這套訂餐系統(tǒng)的包就放在那里按上面的順序拆一遍比自己從零搭一個骨架要快得多希望幫到你。本文還有配套的精品資源點擊獲取