簡介基于Java的網(wǎng)上訂餐系統(tǒng)畢業(yè)設計文檔面向計算機相關專業(yè)學生及Java Web開發(fā)者完整呈現(xiàn)從需求分析到系統(tǒng)測試的閉環(huán)設計過程。文檔采用JSP技術、MYSQL數(shù)據(jù)庫與Java編程語言基于B/S架構實現(xiàn)用戶通過瀏覽器即可完成訂餐管理員則能對系統(tǒng)進行全面管理內(nèi)容還涉及SSL安全加密、數(shù)據(jù)庫規(guī)范化設計以及用戶、訂單、菜單三大核心模塊的實現(xiàn)方案可幫助讀者快速理解在線訂餐系統(tǒng)的業(yè)務邏輯與開發(fā)要點。資源為單個docx文件約3.3MB包含摘要、目錄、系統(tǒng)架構、數(shù)據(jù)庫設計、核心模塊、應用程序設計、系統(tǒng)實現(xiàn)與測試、應用前景等章節(jié)結構清晰便于按需查閱。目前已有163人學習適合作為畢業(yè)設計參考、課程項目模板或Java Web入門實踐資料對提升實際項目開發(fā)與文檔撰寫能力有直接幫助。 剛剛拿到這份《基于Java網(wǎng)上訂餐系統(tǒng)設計與實現(xiàn)》時我的第一反應是——終于遇到一份不靠Spring Boot Vue撐門面的Java畢業(yè)設計了。整套資源走的是 JSP MySQL Java 的老牌技術棧B/S結構把訂餐系統(tǒng)拆成用戶、商家、管理員三個角色覆蓋菜品展示、購物車、下單、訂單處理、評價的完整閉環(huán)。它能解決的痛點很具體畢設選題缺一個業(yè)務完整、能寫清楚設計過程的作品或者想花最小成本把Java Web的請求響應鏈路跑通。適合兩類人一個是時間緊需要論文與源碼同步交付的在校生另一個是想拿真實業(yè)務練手、搞清楚JSP頁面和Servlet到底怎么配合的初學者。值不值得下看完后面的復現(xiàn)細節(jié)你心里自然有數(shù)。2. JSP MySQL B/S這份Java網(wǎng)上訂餐系統(tǒng)為什么走穩(wěn)健老路線2.1 JSP的動態(tài)頁面原理HTML里嵌Java代碼段怎么工作JSP說到底是一個以Servlet為中心的模板機制。瀏覽器訪問一個.jsp文件時Web服務器先執(zhí)行里面的Java程序段再把運行結果和HTML源碼一起拼裝后返回給瀏覽器。文檔里那個描述很準確JSP可以分離網(wǎng)頁邏輯與網(wǎng)頁設計支持可重用的組件式開發(fā)。對畢業(yè)設計這類中小型管理系統(tǒng)這種模式最大的好處是不需要單獨搭前端工程頁面結構、數(shù)據(jù)渲染、請求處理可以集中在一個文件里快速迭代。一個最小的JSP頁面運行邏輯是這樣的% page languagejava contentTypetext/html; charsetutf-8 pageEncodingutf-8 % % page importjava.util.Date, java.text.SimpleDateFormat % html body !-- 服務端先執(zhí)行這段Java代碼 -- % SimpleDateFormat sdf new SimpleDateFormat(yyyy-MM-dd HH:mm:ss); String now sdf.format(new Date()); % p當前服務器時間% now %/p !-- 頁面里也有純靜態(tài)HTML會被原樣返回 -- /body /html這段代碼里服務器收到請求后先執(zhí)行% %內(nèi)的Java代碼把格式化后的時間存進now變量% %再把變量輸出到HTML流中。往這個模板里疊加數(shù)據(jù)庫查詢就變成了一個動態(tài)菜品列表頁面。兩個參數(shù)要留意contentType的charset和pageEncoding務必保持utf-8不然中文會亂碼這個坑在第5章會專門展開。2.2 B/S三層調(diào)用鏈一次下單請求經(jīng)過了哪幾層B/S結構的核心是瀏覽器向服務器發(fā)請求文檔里把系統(tǒng)拆成表示邏輯層、控制邏輯層、數(shù)據(jù)展現(xiàn)層三個相對獨立又相互關聯(lián)的部分。拿用戶提交訂單這個動作走一遍整條鏈路就很清楚了用戶瀏覽器點擊下單 → 表單提交成HTTP請求 → Tomcat里的Servlet接收參數(shù) → Servlet調(diào)用業(yè)務邏輯 → DAO層通過JDBC訪問MySQL → 查詢結果逐層返回 → 頁面重新渲染訂單列表。這里有一個容易被忽略的點B/S結構下客戶機上只需要裝瀏覽器所有數(shù)據(jù)庫訪問和應用程序執(zhí)行都在服務器端完成。所以部署時真正要操心的是Tomcat、MySQL和代碼包三者之間的配合而不是用戶機器上的環(huán)境。開發(fā)成本低、升級維護集中在服務器端這正是這套系統(tǒng)選B/S而不是C/S的理由。2.3 運行環(huán)境與部署第一步先讓項目在自己電腦上轉起來文檔給出的運行環(huán)境很親民酷睿i3處理器、2G以上內(nèi)存、320GB硬盤操作系統(tǒng)Windows XP或Win7都能帶得動。實際開發(fā)環(huán)境一般這樣配項目推薦配置操作系統(tǒng)Windows 10 / Windows 11 均可JDKJDK 1.8Web服務器Tomcat 7 或 8.5數(shù)據(jù)庫MySQL 5.7 或 8.0開發(fā)工具MyEclipse 或 Eclipse EE瀏覽器Chrome / Edge部署第一步先把數(shù)據(jù)庫連接工具類改好。JSP項目里最常寫的JDBC連接工具長這樣// DBUtil.java — JDBC連接MySQL的工具類 package com.order.util; import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DBUtil { // MySQL 5.x 用 com.mysql.jdbc.DriverMySQL 8.x 用 com.mysql.cj.jdbc.Driver private static final String DRIVER com.mysql.jdbc.Driver; private static final String URL jdbc:mysql://localhost:3306/order_db ?useUnicodetruecharacterEncodingutf-8useSSLfalse; private static final String USER root; private static final String PASSWORD 123456; static { try { Class.forName(DRIVER); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(AutoCloseable... closables) { for (AutoCloseable c : closables) { if (c ! null) { try { c.close(); } catch (Exception e) { e.printStackTrace(); } } } } }這段代碼是整個系統(tǒng)能跑起來的地基。邏輯說明靜態(tài)代碼塊負責加載驅動getConnection()返回一個真實連接close()用可變參數(shù)一次關掉多個資源避免每個DAO里重復寫try-catch。參數(shù)說明localhost:3306是MySQL默認地址和端口order_db是數(shù)據(jù)庫名要和你本地建的庫一致useSSLfalse在本地開發(fā)時加上能省掉一堆證書警告USER和PASSWORD按自己MySQL的實際賬號改。我第一次跑這類項目時就是漏了characterEncodingutf-8結果后臺上架菜品全是問號這屬于必踩的坑。3. 需求分析用戶、商家、管理員三角色的權限與流程怎么落成代碼3.1 用戶、商家、管理員各管哪攤事先畫清楚邊界需求分析階段最容易犯的錯是一上來就建表寫代碼。文檔里的做法是對照著用例圖把三個角色的功能邊界先劃清楚后面的權限控制和模塊拆分才有依據(jù)。三個角色的功能劃分如下角色核心功能關鍵動作用戶瀏覽首頁、全部菜品、資訊注冊登錄管理購物車和訂單評價維護收貨地址提交訂單、發(fā)表評價商家個人中心、菜品管理、售后維權管理上架/下架菜品、處理售后管理員輪播管理、資訊管理、客戶管理、菜品管理、帖子管理、發(fā)送消息、商家審核、售后維權、統(tǒng)計中心審核商家、查看統(tǒng)計數(shù)據(jù)從這張表能看出一個設計思路用戶管的是吃這條線商家管的是賣這條線管理員管的是全場這條線。三個角色在頁面入口上就要分開登錄后菜單按角色動態(tài)渲染而不是把所有功能堆在一個頁面里。文檔里商家用例圖里還有一個個人中心實際開發(fā)中這通常是商家修改店鋪信息、查看經(jīng)營數(shù)據(jù)的入口和用戶的個人中心是兩個不同的頁面。3.2 注冊、登錄、添加信息三條流程判斷邏輯怎么寫文檔的流程圖畫了三張注冊、登錄、添加信息。這三張圖對應的代碼判斷邏輯是相通的。以注冊為例完整的Servlet簡化實現(xiàn)是這樣的// RegisterServlet.java — 用戶注冊邏輯的簡化實現(xiàn) protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException { String username req.getParameter(username); String password req.getParameter(password); // 第一步用戶名查重存在就直接打回 if (userDao.findByUsername(username) ! null) { resp.sendRedirect(register.jsp?error用戶名已存在); return; } // 第二步基本信息校驗空值或格式不對也打回 if (username null || username.length() 3 || password null || password.length() 6) { resp.sendRedirect(register.jsp?error注冊信息不正確); return; } // 第三步寫庫并跳轉到登錄頁 userDao.insert(username, password); resp.sendRedirect(login.jsp?success注冊成功); }這段代碼和注冊流程圖是一一對應的先判斷用戶名是否存在存在提示已存在再判斷注冊信息是否正確不對提示不正確最后寫庫。參數(shù)說明register.jsp?error用戶名已存在這種URL傳參方式可以直接在頁面上回顯錯誤信息省事且無狀態(tài)密碼最少6位是我一般項目里的硬性約束。登錄邏輯類似只是把查重換成先判斷用戶名是否為空再判斷密碼是否為空最后比對用戶名密碼三步。添加信息流程里文檔特意提到信息編號系統(tǒng)采用自動增號的模式對應到數(shù)據(jù)庫就是主鍵AUTO_INCREMENT頁面表單里不需要也不應該出現(xiàn)編號輸入框。3.3 非功能需求權限隔離、數(shù)據(jù)完整性和界面干凈一樣重要功能需求之外文檔花了不少篇幅講性能需求和數(shù)據(jù)完整性這些點寫論文時是湊字數(shù)的好素材寫代碼時就是實打實的約束。系統(tǒng)安全性要求可以歸納成三條管理員憑用戶名密碼登錄才能進后臺用戶必須注冊登錄才能下單不同權限不能越級操作。落到代碼上就是登錄成功后往session里放當前用戶對象后臺管理頁面前置一個過濾器判斷session里有沒有管理員身份沒有就重定向回登錄頁。數(shù)據(jù)完整性方面文檔明確要求商品信息不可為空、數(shù)據(jù)間聯(lián)系正確、相同數(shù)據(jù)在不同記錄中保持一致。這些靠數(shù)據(jù)庫約束和事務來兜底菜品表的name字段加NOT NULL訂單金額用DECIMAL而不用FLOAT下單過程包在事務里執(zhí)行。界面需求分析里的輸入設計原則——輸入量盡量少、用下拉框代替文本框、盡早檢查輸入數(shù)據(jù)——對應到實現(xiàn)上就是注冊表單盡量精簡、分類選擇用下拉框、前端做基礎格式校驗。摘要里提到的SSL加密在本地開發(fā)階段通常體現(xiàn)為HTTPS部署和JDBC連接URL里的useSSL參數(shù)畢業(yè)設計演示環(huán)境不用深究。4. 數(shù)據(jù)庫設計從E-R圖到核心建表SQL一次說清主外鍵怎么掛4.1 E-R圖里有哪些實體和關系文檔里數(shù)據(jù)庫設計章節(jié)先畫系統(tǒng)E-R圖再轉成數(shù)據(jù)表。這套系統(tǒng)里能數(shù)出來的實體有用戶、商家、菜品、菜品分類、訂單、訂單明細、購物車、評價、資訊、帖子、收貨地址、售后維權。實體關系梳理下來是這幾條分類和菜品是一對多一個分類下掛多個菜品用戶和訂單是一對多一個用戶可以下多個訂單用戶和購物車是一對多一個用戶購物車里有多個條目用戶和收貨地址是一對多用戶和菜品是多對多靠訂單明細這個中間實體拆開商家和菜品是一對多商家審核通過后維護自己的菜品。搞清這些關系建表時外鍵往哪掛就不會猶豫。4.2 核心建表SQL用戶、菜品、訂單三張表怎么建文檔里數(shù)據(jù)庫表設計給的字段比較簡略但是設計思路很明確。用戶、菜品、訂單三張表是系統(tǒng)的骨架按常規(guī)做法建表如下-- 用戶表 CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用戶ID自動增號, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登錄用戶名, password VARCHAR(100) NOT NULL COMMENT 登錄密碼, role TINYINT DEFAULT 0 COMMENT 角色0普通用戶 1商家 2管理員, nickname VARCHAR(50) DEFAULT NULL COMMENT 顯示昵稱, phone VARCHAR(20) DEFAULT NULL COMMENT 手機號, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注冊時間, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表; -- 菜品表 CREATE TABLE dish ( id INT NOT NULL AUTO_INCREMENT COMMENT 菜品ID, category_id INT NOT NULL COMMENT 所屬分類ID關聯(lián)category表, shop_id INT NOT NULL COMMENT 所屬商家ID關聯(lián)用戶表, name VARCHAR(100) NOT NULL COMMENT 菜品名稱不能為空, price DECIMAL(10,2) NOT NULL COMMENT 單價, image VARCHAR(255) DEFAULT NULL COMMENT 圖片路徑, status TINYINT DEFAULT 1 COMMENT 狀態(tài)1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), CONSTRAINT fk_dish_category FOREIGN KEY (category_id) REFERENCES category(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT菜品表; -- 訂單表 CREATE TABLE orders ( id INT NOT NULL AUTO_INCREMENT COMMENT 訂單ID自動增號, order_no VARCHAR(32) NOT NULL COMMENT 訂單編號下單時生成, user_id INT NOT NULL COMMENT 下單用戶ID, shop_id INT NOT NULL COMMENT 承接訂單的商家ID, total_amount DECIMAL(10,2) NOT NULL COMMENT 訂單總金額, status TINYINT DEFAULT 0 COMMENT 訂單狀態(tài)0待處理 1已接單 2配送中 3已完成 4已取消, address VARCHAR(255) NOT NULL COMMENT 收貨地址快照, remark VARCHAR(255) DEFAULT NULL COMMENT 備注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 下單時間, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user (user_id), CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES user(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單表;這三張表有幾個設計點值得抄。存儲引擎用InnoDB支持外鍵和事務下單時的事務控制靠它字符集統(tǒng)一utf8mb4比utf8多支持表情字符中文存儲也更穩(wěn)妥金額字段用DECIMAL(10,2)而不是FLOAT——浮點數(shù)算金額會出現(xiàn)0.10.2不等于0.3的尷尬這在訂單金額計算里就是翻車現(xiàn)場。orders表里冗余了shop_id配合order_no唯一索引一個用戶一次加購多個商家的菜品時在代碼里按shop_id拆分成多張訂單這就是文檔里管理員可對系統(tǒng)進行全面管理數(shù)據(jù)層面的基礎。商家審核這條線簡單做法是在user表加一個status字段標記商家是否通過審核管理員在商家審核管理里改這個狀態(tài)就夠用。4.3 購物車與訂單明細多對多關系靠中間表拆開用戶和菜品是多對多關系關系型數(shù)據(jù)庫里必須用中間表拆。購物車和訂單明細是這套系統(tǒng)里兩個角色不同的中間表——購物車是臨時數(shù)據(jù)訂單明細是業(yè)務數(shù)據(jù)二者不能混用。-- 購物車表臨時數(shù)據(jù) CREATE TABLE cart ( id INT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL COMMENT 哪個用戶的購物車, dish_id INT NOT NULL COMMENT 放進購物車的菜品ID, quantity INT DEFAULT 1 COMMENT 數(shù)量, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_dish (user_id, dish_id), CONSTRAINT fk_cart_user FOREIGN KEY (user_id) REFERENCES user(id), CONSTRAINT fk_cart_dish FOREIGN KEY (dish_id) REFERENCES dish(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT購物車表; -- 訂單明細表業(yè)務數(shù)據(jù) CREATE TABLE order_item ( id INT NOT NULL 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 小計, PRIMARY KEY (id), KEY idx_order (order_id), CONSTRAINT fk_order_item_order FOREIGN KEY (order_id) REFERENCES orders(id), CONSTRAINT fk_order_item_dish FOREIGN KEY (dish_id) REFERENCES dish(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單明細表;購物車表的uk_user_dish聯(lián)合唯一索引挺關鍵同一個用戶重復加同一道菜時代碼里可以做數(shù)量加1而不是再插一行購物車界面就不會出現(xiàn)兩行一模一樣的菜品。訂單明細表里我特意寫了dish_name和price兩個快照字段——下單那一刻把菜名和單價拷貝進來之后商家改價、下架都不影響歷史訂單的展示和統(tǒng)計。這個細節(jié)在文檔里沒明說但做訂單系統(tǒng)的常規(guī)做法都是這樣不然訂單列表里菜名跟著菜品表變動對賬會對到懷疑人生。5. 避坑復現(xiàn)這套Java訂餐系統(tǒng)最容易翻車的五個地方這套資源技術棧不新但恰恰是這種老組合坑都藏在環(huán)境匹配和細節(jié)處理上。下面這些是我復現(xiàn)同類項目時踩過或看別人踩過的按現(xiàn)象→原因→解決寫清楚。5.1 部署啟動類端口、驅動、編碼三板斧坑一Tomcat啟動報Address already in use頁面打不開?，F(xiàn)象啟動Tomcat時控制臺直接報端口占用錯誤localhost:8080訪問無響應。原因本機裝了其他服務占用8080端口或者之前啟動的Tomcat進程沒關干凈端口沒釋放。解決Windows下執(zhí)行netstat -ano | findstr 8080找到占用端口的進程PID到任務管理器里結束它更省事的辦法是直接改Tomcatconf/server.xml里的Connector port8080改成8081。改完記得用新端口訪問別拿舊地址反復測這種低級錯誤最容易讓人懷疑人生。坑二運行時報ClassNotFoundException: com.mysql.jdbc.Driver或Communications link failure?，F(xiàn)象第一次點登錄按鈕頁面直接白屏報錯控制臺提示找不到驅動類或者連接失敗。原因MySQL 5.x 和 8.x 的JDBC驅動類名不一樣——5.x是com.mysql.jdbc.Driver8.x是com.mysql.cj.jdbc.Driver而且mysql-connector-java的jar版本要和數(shù)據(jù)庫大版本匹配。驅動jar放錯位置也會報這個錯。解決先確認本地MySQL是哪個大版本再選擇對應版本的mysql-connector-javajar包放進WEB-INF/lib目錄同時把DBUtil里的DRIVER常量改成對應類名。MySQL 8.0以上還要在連接URL里帶上serverTimezoneAsia/Shanghai否則時區(qū)報錯能卡你一下午。5.2 數(shù)據(jù)讀寫類亂碼和事務丟失坑三菜品名稱等中文寫入MySQL后變成???或徹底亂碼?，F(xiàn)象管理端后臺上架菜品提交時頁面顯示正常刷新列表查出來全是問號。原因建庫字符集、JDBC連接URL、JSP頁面編碼三個地方不一致。最常見的是建庫時用了默認的latin1或者連接URL沒帶characterEncodingutf-8。解決建庫時執(zhí)行CREATE DATABASE order_db DEFAULT CHARSET utf8mb4連接URL加useUnicodetruecharacterEncodingutf-8JSP頁面頂部contentType和pageEncoding統(tǒng)一utf-8。這三個地方對齊后亂碼問題基本絕跡。這是最玄學也最好解決的坑排查順序永遠是從數(shù)據(jù)庫到連接再到頁面。坑四購物車加購數(shù)量對提交訂單后金額和明細對不上?，F(xiàn)象購物車里3件商品合計89元提交訂單后庫里只有2件金額停在59元。原因加購、改數(shù)量、提交訂單分了好幾個請求提交訂單的操作沒有放在一個事務里讀取購物車→生成訂單→寫入訂單明細→清空購物車這四步有一步失敗數(shù)據(jù)就殘缺了。解決把下單流程封裝進一個Service方法用Connection.setAutoCommit(false)開啟手動事務四步全部執(zhí)行成功再commit()任一步拋異常就rollback()。事務代碼別寫在JSP頁面里那是JSP項目最常見的反面教材——頁面里一段一段拼SQL出錯連回滾的機會都沒有。5.3 登錄與頁面顯示類坑五登錄成功后一刷新就回到登錄頁或者直接提示session失效。現(xiàn)象用戶名密碼輸入正確頁面跳轉到了首頁按F5刷新立刻被踢回登錄頁。原因過濾器攔截了所有頁面請求但沒有放行l(wèi)ogin.jsp和登錄接口更常見的是登錄成功后沒把用戶對象寫進session。解決在過濾器代碼里把登錄頁、登錄接口、注冊頁加進白名單路徑匹配用startsWith判斷登錄成功執(zhí)行session.setAttribute(user, user)后續(xù)頁面從session取當前用戶取不到再重定向到登錄頁。這個坑排查起來不難但正好對應文檔里不同權限的用戶不能越級操作這條安全需求寫論文時還能順帶講成權限控制的實現(xiàn)細節(jié)。6. 測試用例與驗收清單把能跑變成能答辯代碼能跑只是第一步能演示、能講清設計過程才是畢業(yè)設計的驗收標準。測試章節(jié)在文檔里篇幅不大但測試意義、測試策略、測試安排這三點在答辯時經(jīng)常被追問。我一般會按業(yè)務順序準備一份測試用例清單演示時照著走既不會亂也不會漏。編號測試項操作預期結果01注冊填寫用戶名密碼提交用戶名不存在則注冊成功并跳轉登錄頁02登錄分別輸入正確/錯誤密碼正確則進首頁錯誤給出提示03菜品瀏覽打開全部菜品列表菜品名稱、價格、圖片正常顯示04加購把兩個菜品加入購物車購物車數(shù)量和金額累加正確05下單從購物車提交訂單訂單生成明細正確總金額匹配06接單商家或管理員處理訂單訂單狀態(tài)從待處理變?yōu)橐呀訂?7評價對已完成訂單發(fā)表評價評價展示在對應菜品下08商家審核管理員審核商家審核通過后商家才可上架菜品演示前還要過一遍答辯檢查點講B/S三層時能說清一次下單請求從瀏覽器到MySQL再返回的完整鏈路展示數(shù)據(jù)庫設計時拿出第4章的E-R關系和建表語句說明訂單明細為什么做價格快照權限控制要現(xiàn)場演示——普通用戶登錄后看不到后臺管理菜單測試記錄要能對應上面表格給出真實操作結果而不是只念測試通過四個字。這套Java網(wǎng)上訂餐系統(tǒng)的文檔、SQL腳本和源碼可以整套拿回去對照跑建議先按第4章把表建出來再按第2章的步驟部署。從那以后我每次做完一個畢設項目都強制自己先按這個清單跑一遍再談演示表格里最后兩行是很多人忽略的但評審老師最愛問。希望幫到你。本文還有配套的精品資源點擊獲取