簡(jiǎn)介這是一份面向計(jì)算機(jī)專業(yè)學(xué)生與Qt初學(xué)者、可用于畢業(yè)設(shè)計(jì)參考的局域網(wǎng)聊天室完整工程源碼。項(xiàng)目基于Qt框架開(kāi)發(fā)實(shí)現(xiàn)私聊、文件傳輸與管理員權(quán)限管理三大核心功能通過(guò)定時(shí)器輪詢數(shù)據(jù)庫(kù)標(biāo)志位實(shí)時(shí)判斷用戶在線狀態(tài)私聊普通消息走UDP協(xié)議文件傳輸走TCP協(xié)議通信雙方按需切換服務(wù)端與客戶端身份無(wú)需中轉(zhuǎn)服務(wù)器。資源包共87個(gè)文件以cpp與h源碼、o編譯產(chǎn)物、ui界面文件為主另含jpg與png圖片素材、xml配置及qrc資源文件壓縮包約6.54MB工程結(jié)構(gòu)完整可直接導(dǎo)入Qt Creator。使用前需在本地或服務(wù)器安裝MySQL數(shù)據(jù)庫(kù)推薦32位5.7.31版本并務(wù)必閱讀隨包幫助文檔且僅限局域網(wǎng)內(nèi)使用、不可跨網(wǎng)段。目前已有4111人學(xué)習(xí)下載適合需要理解Qt網(wǎng)絡(luò)編程、數(shù)據(jù)庫(kù)交互與多線程定時(shí)器機(jī)制、并希望獲得可運(yùn)行畢設(shè)項(xiàng)目的讀者參考借鑒。1. 需求先立住為什么局域網(wǎng)聊天室值得做成一份完整畢設(shè)局域網(wǎng)聊天室這個(gè)題目每年都有人做也每年都有人做得四不像。問(wèn)題不在題目本身而在于很多人一上來(lái)就打開(kāi) Qt Designer 拖控件拖完發(fā)現(xiàn)不知道服務(wù)端該干什么最后交上去的是一個(gè)只能單機(jī)自說(shuō)自話的殼子。我見(jiàn)過(guò)最典型的翻車現(xiàn)場(chǎng)是客戶端能發(fā)消息但兩臺(tái)機(jī)器連不上答辯時(shí)導(dǎo)師問(wèn)“你的連接是怎么建立的、斷線了怎么辦”答不上來(lái)。這份畢設(shè)要解決的核心需求其實(shí)很明確在一個(gè)沒(méi)有外網(wǎng)的教室或?qū)嶒?yàn)室局域網(wǎng)內(nèi)多臺(tái)機(jī)器能互相發(fā)現(xiàn)、建立連接、收發(fā)文本消息并且服務(wù)端能對(duì)在線用戶做基本管理。它適合兩類人一是正在做網(wǎng)絡(luò)編程方向畢設(shè)、需要一份結(jié)構(gòu)完整可交付方案的學(xué)生二是想拿 Qt 練一遍 C/S 架構(gòu)完整鏈路的開(kāi)發(fā)者。技術(shù)棧鎖定 QtC用 QTcpSocket 和 QTcpServer 打通傳輸層用 Qt Widgets 做界面不引入第三方網(wǎng)絡(luò)庫(kù)保證在常見(jiàn)開(kāi)發(fā)環(huán)境里能直接編譯跑起來(lái)。下面這套結(jié)構(gòu)從需求到設(shè)計(jì)到驗(yàn)收一路鋪開(kāi)你可以照著改。2. 總體架構(gòu)設(shè)計(jì)C/S 結(jié)構(gòu)與四個(gè)模塊的職責(zé)劃分局域網(wǎng)聊天室看著簡(jiǎn)單但真要做成能答辯的東西架構(gòu)必須先想清楚。我一般會(huì)把整個(gè)系統(tǒng)切成服務(wù)端和客戶端兩側(cè)每側(cè)再拆成若干職責(zé)單一的模塊避免所有邏輯堆在一個(gè) MainWindow 里。這樣做的好處是答辯時(shí)你能指著模塊說(shuō)“這塊負(fù)責(zé)什么、那塊負(fù)責(zé)什么”而不是一句“都在主窗口里”。2.1 服務(wù)端與客戶端的職責(zé)邊界服務(wù)端是整個(gè)聊天室的中樞它持有所有在線客戶端的 socket 連接負(fù)責(zé)消息的接收、轉(zhuǎn)發(fā)和用戶列表維護(hù)。客戶端則負(fù)責(zé)界面交互、消息的發(fā)送與展示以及和服務(wù)端之間的協(xié)議解析。兩者之間通過(guò)一條自定義的文本協(xié)議通信協(xié)議格式在下一節(jié)展開(kāi)。這里有個(gè)設(shè)計(jì)取舍值得說(shuō)清楚為什么不做純 P2P因?yàn)榫钟蚓W(wǎng)里客戶端之間互相發(fā)現(xiàn)需要廣播或組播NAT 和防火墻策略在不同機(jī)器上表現(xiàn)不一致調(diào)試成本高而且畢設(shè)答辯時(shí)導(dǎo)師更看重你對(duì) C/S 模型的理解。用中心服務(wù)端轉(zhuǎn)發(fā)邏輯清晰、可控性強(qiáng)出問(wèn)題也好定位。通常的做法是服務(wù)端只做轉(zhuǎn)發(fā)和狀態(tài)管理不存歷史消息這樣服務(wù)端邏輯足夠輕客戶端斷線重連也不會(huì)牽扯太多狀態(tài)同步。服務(wù)端內(nèi)部我一般拆成三個(gè)類ChatServer負(fù)責(zé)監(jiān)聽(tīng)和接受連接ClientSession封裝單個(gè)客戶端連接及其狀態(tài)MessageRouter負(fù)責(zé)解析消息并決定轉(zhuǎn)發(fā)給誰(shuí)。客戶端拆成ChatWindow界面、NetworkClient連接與收發(fā)、ProtocolCodec協(xié)議編解碼。四個(gè)模塊的職責(zé)劃分如下表模塊所在側(cè)核心職責(zé)關(guān)鍵類連接管理服務(wù)端監(jiān)聽(tīng)端口、接受新連接、維護(hù)在線列表ChatServer會(huì)話封裝服務(wù)端單客戶端讀寫、心跳檢測(cè)、斷線清理ClientSession消息路由服務(wù)端解析協(xié)議、廣播或定向轉(zhuǎn)發(fā)MessageRouter網(wǎng)絡(luò)客戶端客戶端建立連接、收發(fā)數(shù)據(jù)、重連NetworkClient2.2 通信協(xié)議設(shè)計(jì)一行一條消息的文本協(xié)議協(xié)議是這套方案里最容易被忽視、又最容易在答辯時(shí)被追問(wèn)的部分。我建議用最簡(jiǎn)單的行文本協(xié)議每條消息以換行符\n結(jié)尾字段之間用固定分隔符隔開(kāi)。這樣用QTcpSocket的canReadLine()和readLine()就能天然處理粘包問(wèn)題不需要自己寫緩沖區(qū)拼包邏輯。協(xié)議定義四類消息登錄LOGIN、聊天CHAT、用戶列表USERLIST、系統(tǒng)通知SYS。格式統(tǒng)一為類型|字段1|字段2。例如登錄消息是LOGIN|張三聊天消息是CHAT|張三|大家好。服務(wù)端收到后按|切分根據(jù)類型走不同分支。// 協(xié)議解析按行讀取按豎線切分字段 void ClientSession::onReadyRead() { while (socket-canReadLine()) { QByteArray line socket-readLine().trimmed(); if (line.isEmpty()) continue; // 按 | 拆分第一段是消息類型 QListQByteArray parts line.split(|); QString type QString::fromUtf8(parts.value(0)); if (type LOGIN parts.size() 2) { username QString::fromUtf8(parts.at(1)); router-handleLogin(this); // 注冊(cè)用戶并廣播列表 } else if (type CHAT parts.size() 3) { router-handleChat(this, QString::fromUtf8(parts.at(2))); } } }這段代碼的關(guān)鍵點(diǎn)在于canReadLine()循環(huán)TCP 是流式協(xié)議一次readyRead可能收到半條消息也可能收到兩條半用行緩沖讀取能保證每次處理的都是完整消息。trimmed()去掉行尾的\r\n兼容不同平臺(tái)的換行。字段用value()取值而不是直接下標(biāo)是為了防止畸形消息導(dǎo)致越界崩潰——這一點(diǎn)在答辯演示時(shí)特別重要導(dǎo)師很可能故意發(fā)一條格式錯(cuò)誤的消息看你程序崩不崩。提示協(xié)議里不要用中文做分隔符也不要用空格因?yàn)橛脩裘锟赡軒Э崭?。豎線|在用戶名里出現(xiàn)的概率極低夠用。2.3 線程模型為什么單線程事件循環(huán)就夠很多同學(xué)一上來(lái)就想給每個(gè)連接開(kāi)一個(gè)線程覺(jué)得這樣“性能好”。在局域網(wǎng)聊天室這個(gè)場(chǎng)景里這是過(guò)度設(shè)計(jì)。Qt 的QTcpServer和QTcpSocket本身就是異步非阻塞的基于事件循環(huán)工作幾十個(gè)客戶端的消息轉(zhuǎn)發(fā)在單線程里完全跑得動(dòng)。開(kāi)多線程反而引入跨線程信號(hào)槽連接、鎖競(jìng)爭(zhēng)、對(duì)象歸屬Q(mào)Object 的線程親和性這些坑調(diào)試起來(lái)是血淚經(jīng)驗(yàn)。我一般會(huì)明確告訴做這個(gè)題的人服務(wù)端主線程跑事件循環(huán)所有 socket 操作都在主線程完成消息處理邏輯輕量不做耗時(shí)計(jì)算。如果將來(lái)要加文件傳輸這種大塊數(shù)據(jù)再考慮把文件 IO 放到工作線程通過(guò)信號(hào)槽把結(jié)果回傳主線程。這個(gè)取舍在答辯時(shí)講出來(lái)反而是加分項(xiàng)——說(shuō)明你懂什么時(shí)候不該用多線程。3. 核心模塊實(shí)現(xiàn)連接管理、消息轉(zhuǎn)發(fā)與界面聯(lián)動(dòng)架構(gòu)定下來(lái)之后落到代碼就是三件事服務(wù)端怎么接住連接、消息怎么轉(zhuǎn)發(fā)出去、客戶端界面怎么和網(wǎng)絡(luò)層聯(lián)動(dòng)。這一章把這三塊拆開(kāi)講每塊都給可復(fù)現(xiàn)的實(shí)現(xiàn)片段和參數(shù)說(shuō)明。3.1 服務(wù)端監(jiān)聽(tīng)與在線用戶管理服務(wù)端啟動(dòng)時(shí)綁定端口并開(kāi)始監(jiān)聽(tīng)。端口號(hào)建議放在配置文件或命令行參數(shù)里不要硬編碼答辯時(shí)換臺(tái)機(jī)器端口被占用就尷尬了。在線用戶用一個(gè)QHashQString, ClientSession*維護(hù)鍵是用戶名值是會(huì)話對(duì)象指針。用戶名重復(fù)時(shí)拒絕登錄并回一條系統(tǒng)通知這是最基本的健壯性。// ChatServer 啟動(dòng)監(jiān)聽(tīng) bool ChatServer::start(quint16 port) { if (!server-listen(QHostAddress::Any, port)) { qWarning() 監(jiān)聽(tīng)失敗: server-errorString(); return false; } qInfo() 服務(wù)端已啟動(dòng)端口: port; return true; } // 新連接到來(lái)創(chuàng)建會(huì)話對(duì)象 void ChatServer::onNewConnection() { while (server-hasPendingConnections()) { QTcpSocket *socket server-nextPendingConnection(); auto *session new ClientSession(socket, router, this); // 連接斷開(kāi)時(shí)清理會(huì)話避免野指針 connect(socket, QTcpSocket::disconnected, session, ClientSession::onDisconnected); } }QHostAddress::Any表示監(jiān)聽(tīng)所有網(wǎng)卡地址局域網(wǎng)內(nèi)其他機(jī)器才能連進(jìn)來(lái)如果只寫LocalHost那就只有本機(jī)能連這是新手最常見(jiàn)的“為什么別人連不上”的原因。hasPendingConnections()配合while循環(huán)是為了處理同一時(shí)刻多個(gè)連接排隊(duì)的情況。會(huì)話對(duì)象用new創(chuàng)建后掛到父對(duì)象this上Qt 的對(duì)象樹(shù)會(huì)在父對(duì)象銷毀時(shí)自動(dòng)釋放子對(duì)象省去手動(dòng) delete 的麻煩但斷線時(shí)的邏輯清理從在線列表移除、廣播用戶列表仍要顯式做。3.2 消息路由與廣播邏輯消息路由的核心是“收到一條聊天消息轉(zhuǎn)發(fā)給除發(fā)送者外的所有在線用戶”。這里有個(gè)細(xì)節(jié)廣播時(shí)如果某個(gè) socket 已經(jīng)處于斷開(kāi)狀態(tài)但還沒(méi)被清理直接write會(huì)失敗甚至觸發(fā)異常。穩(wěn)妥的做法是寫之前判斷state() QAbstractSocket::ConnectedState寫失敗則標(biāo)記該會(huì)話待清理。// 廣播聊天消息給所有在線用戶可排除發(fā)送者 void MessageRouter::broadcast(const QString payload, ClientSession *exclude) { QByteArray data payload.toUtf8() \n; // 統(tǒng)一補(bǔ)換行對(duì)應(yīng)行協(xié)議 for (ClientSession *s : sessions) { if (s exclude) continue; if (s-socketState() ! QAbstractSocket::ConnectedState) { pendingCleanup.append(s); // 延遲清理避免遍歷中刪除 continue; } s-send(data); } cleanupPending(); // 遍歷結(jié)束后統(tǒng)一清理 }這段代碼里有兩個(gè)工程習(xí)慣值得學(xué)一是發(fā)送數(shù)據(jù)統(tǒng)一補(bǔ)\n保證接收端canReadLine()能正確切分二是遍歷過(guò)程中不直接刪除元素而是先記到pendingCleanup遍歷完再統(tǒng)一清理。這是容器遍歷刪除的經(jīng)典避坑寫法答辯時(shí)被問(wèn)到“你廣播時(shí)有人掉線怎么辦”這就是標(biāo)準(zhǔn)答案。exclude參數(shù)讓發(fā)送者不回顯自己的消息客戶端本地已經(jīng)顯示過(guò)了避免界面重復(fù)。3.3 客戶端界面與網(wǎng)絡(luò)層的信號(hào)槽聯(lián)動(dòng)客戶端最容易寫亂的地方是把網(wǎng)絡(luò)收發(fā)邏輯直接塞進(jìn)按鈕的槽函數(shù)里。正確做法是網(wǎng)絡(luò)層NetworkClient只負(fù)責(zé)連接、發(fā)送、接收收到完整消息后發(fā)一個(gè)自定義信號(hào)界面層ChatWindow連這個(gè)信號(hào)去更新列表和聊天框。這樣界面和網(wǎng)絡(luò)解耦換界面不用動(dòng)網(wǎng)絡(luò)代碼。// NetworkClient收到一行完整消息后發(fā)出信號(hào) void NetworkClient::onReadyRead() { while (socket-canReadLine()) { QString line QString::fromUtf8(socket-readLine()).trimmed(); QListQString parts line.split(|); QString type parts.value(0); if (type CHAT) { emit chatReceived(parts.value(1), parts.value(2)); // 發(fā)送者, 內(nèi)容 } else if (type USERLIST) { emit userListUpdated(parts.mid(1)); // 剩余字段是用戶名 } else if (type SYS) { emit systemNotice(parts.value(1)); } } }emit chatReceived(...)之后ChatWindow里用connect把信號(hào)接到槽函數(shù)槽函數(shù)里往QListWidget追加一條“發(fā)送者內(nèi)容”。userListUpdated攜帶的是QStringList界面直接clear()再addItems()刷新在線列表。這種“網(wǎng)絡(luò)層發(fā)信號(hào)、界面層收信號(hào)”的模式是 Qt 里做 C/S 客戶端的標(biāo)準(zhǔn)姿勢(shì)也是答辯時(shí)能講清楚“你的界面和網(wǎng)絡(luò)怎么通信”的關(guān)鍵。注意信號(hào)參數(shù)類型要在頭文件里用Q_OBJECT宏配合signals:聲明跨線程連接時(shí)還要注冊(cè)元類型單線程場(chǎng)景下不用管但要知道有這么回事。4. 避坑與排查局域網(wǎng)聊天室最容易翻車的五個(gè)點(diǎn)這個(gè)項(xiàng)目代碼量不大但坑很集中。下面五條是我?guī)ы?xiàng)目時(shí)反復(fù)見(jiàn)到的翻車點(diǎn)每條按“現(xiàn)象、原因、解決”寫清楚你照著排查能省下大量調(diào)試時(shí)間。4.1 現(xiàn)象本機(jī)能連別的機(jī)器連不上原因幾乎總是監(jiān)聽(tīng)地址寫成了QHostAddress::LocalHost或者客戶端連接時(shí)填了127.0.0.1。127.0.0.1永遠(yuǎn)指向本機(jī)回環(huán)別的機(jī)器連過(guò)來(lái)當(dāng)然失敗。解決辦法是服務(wù)端用QHostAddress::Any監(jiān)聽(tīng)客戶端填服務(wù)端的局域網(wǎng) IP用ipconfig或ifconfig查。另外要確認(rèn)兩臺(tái)機(jī)器在同一網(wǎng)段防火墻沒(méi)有攔截該端口。排查時(shí)先在服務(wù)端機(jī)器上用telnet 服務(wù)端IP 端口測(cè)一下端口通不通通不了就是網(wǎng)絡(luò)或防火墻問(wèn)題不是代碼問(wèn)題。4.2 現(xiàn)象中文消息顯示亂碼原因是編碼不統(tǒng)一。Qt5 默認(rèn)源碼是 UTF-8但QString::toUtf8()和fromUtf8()必須成對(duì)使用。如果一端用toLocal8Bit()發(fā)、另一端用fromUtf8()收中文必亂。統(tǒng)一規(guī)定協(xié)議傳輸一律 UTF-8發(fā)送端toUtf8()接收端fromUtf8()界面顯示用QString天然支持 Unicode。還有個(gè)小坑是readLine()返回的QByteArray里帶\r\n不trimmed()的話字段末尾會(huì)多出空白解析時(shí)對(duì)不上。4.3 現(xiàn)象客戶端異常關(guān)閉后服務(wù)端用戶列表還掛著這個(gè)人原因是只處理了正常斷開(kāi)沒(méi)處理異常斷開(kāi)。TCP 連接異常斷開(kāi)時(shí)disconnected信號(hào)通常會(huì)觸發(fā)但如果客戶端進(jìn)程被強(qiáng)殺服務(wù)端可能過(guò)一會(huì)兒才感知到。解決辦法是在disconnected槽里做統(tǒng)一清理從在線列表移除、關(guān)閉 socket、廣播更新后的用戶列表。更穩(wěn)妥的做法是加心跳機(jī)制服務(wù)端定時(shí)給每個(gè)會(huì)話發(fā)心跳超時(shí)未響應(yīng)就主動(dòng)斷開(kāi)清理。畢設(shè)層面disconnected信號(hào)加清理邏輯已經(jīng)夠用心跳可以作為加分項(xiàng)提一句。4.4 現(xiàn)象程序運(yùn)行一段時(shí)間后崩潰報(bào)野指針或重復(fù)釋放多半是會(huì)話對(duì)象的生命周期沒(méi)管好。ClientSession用new創(chuàng)建后如果既掛了父對(duì)象、又在斷線時(shí)手動(dòng)delete就會(huì)重復(fù)釋放。統(tǒng)一原則對(duì)象掛父對(duì)象托管斷線時(shí)只做邏輯清理從列表移除、置空指針不手動(dòng) delete或者不掛父對(duì)象、斷線時(shí)deleteLater()延遲刪除。兩種方式選一種不要混用。deleteLater()比delete安全因?yàn)樗褎h除排到事件循環(huán)下一輪避免在信號(hào)槽回調(diào)里刪掉正在使用的對(duì)象。4.5 現(xiàn)象發(fā)送大段文字時(shí)對(duì)方只收到一半這是粘包/半包問(wèn)題的典型表現(xiàn)。TCP 不保證一次write對(duì)應(yīng)一次read大消息會(huì)被拆成多個(gè) TCP 段。解決辦法就是前面說(shuō)的行協(xié)議接收端用canReadLine()循環(huán)讀直到?jīng)]有完整行發(fā)送端保證每條消息以\n結(jié)尾。千萬(wàn)不要在接收端假設(shè)“一次 readyRead 就是一條完整消息”那是新手最常犯的錯(cuò)。如果消息體本身可能包含換行比如多行聊天內(nèi)容就要在協(xié)議里加長(zhǎng)度字段但畢設(shè)場(chǎng)景下單行文本夠用不必復(fù)雜化。5. 驗(yàn)收與答辯怎么證明這套聊天室真的跑通了驗(yàn)收這件事很多人栽在“功能都有但說(shuō)不清楚怎么驗(yàn)證”。我一般會(huì)讓學(xué)生準(zhǔn)備一份可復(fù)現(xiàn)的驗(yàn)收清單答辯時(shí)按清單逐條演示比空口說(shuō)“實(shí)現(xiàn)了聊天功能”有說(shuō)服力得多。下面這套流程你可以直接拿去用。第一步是環(huán)境準(zhǔn)備兩臺(tái)及以上機(jī)器接入同一局域網(wǎng)服務(wù)端機(jī)器啟動(dòng)服務(wù)并記錄 IP 和端口客戶端機(jī)器分別啟動(dòng)并登錄不同用戶名。驗(yàn)收時(shí)先展示服務(wù)端日志里打印的監(jiān)聽(tīng)成功和連接建立記錄證明連接鏈路是通的。第二步是功能演示A 發(fā)消息B 和 C 都能收到且 A 自己不重復(fù)顯示B 下線A 和 C 的用戶列表實(shí)時(shí)減少新用戶 D 登錄所有人列表增加 D。第三步是異常演示這是拉開(kāi)差距的地方強(qiáng)殺一個(gè)客戶端進(jìn)程觀察服務(wù)端是否在合理時(shí)間內(nèi)清理該用戶并廣播列表發(fā)送一條格式錯(cuò)誤的消息比如手動(dòng)用網(wǎng)絡(luò)調(diào)試工具發(fā)CHAT|觀察程序是否崩潰。第四步是邊界演示用戶名重復(fù)登錄被拒絕、空消息不發(fā)送、超長(zhǎng)消息能完整送達(dá)。答辯時(shí)導(dǎo)師最愛(ài)問(wèn)的三個(gè)問(wèn)題提前準(zhǔn)備好答案一是“你的協(xié)議怎么設(shè)計(jì)的為什么這么設(shè)計(jì)”答行文本協(xié)議加豎線分隔利用canReadLine天然處理粘包簡(jiǎn)單可控二是“多個(gè)客戶端同時(shí)發(fā)消息會(huì)不會(huì)亂”答單線程事件循環(huán)串行處理消息按到達(dá)順序轉(zhuǎn)發(fā)不會(huì)交錯(cuò)三是“斷線重連怎么做的”如果做了就講重連邏輯沒(méi)做就誠(chéng)實(shí)說(shuō)當(dāng)前版本依賴手動(dòng)重連并說(shuō)明擴(kuò)展思路。誠(chéng)實(shí)比硬編強(qiáng)導(dǎo)師一眼能看出來(lái)。驗(yàn)收項(xiàng)操作預(yù)期結(jié)果連接建立客戶端填服務(wù)端 IP 登錄服務(wù)端日志顯示新連接客戶端進(jìn)入聊天界面消息廣播A 發(fā)送文本B、C 收到A 不重復(fù)顯示用戶列表同步B 下線、D 上線所有在線客戶端列表實(shí)時(shí)更新異常斷開(kāi)強(qiáng)殺客戶端進(jìn)程服務(wù)端清理該用戶并廣播畸形消息發(fā)送 CHAT最后說(shuō)個(gè)我自己的習(xí)慣每次答辯前我都會(huì)把整套流程在兩臺(tái)干凈機(jī)器上從零走一遍包括重新編譯、重新配置 IP、重新登錄而不是在自己開(kāi)發(fā)機(jī)上點(diǎn)兩下了事。因?yàn)殚_(kāi)發(fā)機(jī)上跑通不代表?yè)Q臺(tái)機(jī)器能跑通環(huán)境差異帶來(lái)的翻車我見(jiàn)過(guò)太多次。從那以后我每次交付前都強(qiáng)制走一遍“干凈環(huán)境全流程”這個(gè)習(xí)慣幫我擋掉了至少一半的現(xiàn)場(chǎng)事故。希望這套結(jié)構(gòu)和驗(yàn)收清單能幫到你照著改改就能變成你自己的畢設(shè)方案。本文還有配套的精品資源點(diǎn)擊獲取