簡介來自吉林大學(xué)軟件學(xué)院的C課程設(shè)計(jì)優(yōu)秀作品圍繞“模擬即時(shí)通信系統(tǒng)”展開以面向?qū)ο蟪绦蛟O(shè)計(jì)方法實(shí)現(xiàn)類QQ/微信整合平臺的用戶基本信息、好友管理、群管理三大核心模塊。支持好友增刪改查、共同好友推薦以及群加入、退出、成員查詢、臨時(shí)討論組等差異化策略貼近真實(shí)社交軟件業(yè)務(wù)邏輯適合C課程設(shè)計(jì)選題參考或進(jìn)階練習(xí)。資源包共153個(gè)文件以cpp/h源碼、sln/vcxproj工程配置、exe可執(zhí)行程序及SQLite數(shù)據(jù)庫為主體附帶調(diào)試記錄與編譯中間文件整體約354MB結(jié)構(gòu)完整便于直接研讀與運(yùn)行驗(yàn)證。已有1317人瀏覽學(xué)習(xí)。這份作品的價(jià)值在于呈現(xiàn)了一個(gè)可運(yùn)行、可擴(kuò)展的完整課設(shè)方案源碼模塊劃分清晰如Tencent_information、Chat_function、judgment等并附有可直接運(yùn)行的exe和數(shù)據(jù)庫文件能幫助讀者快速理解面向?qū)ο蠼Ｅc文件/數(shù)據(jù)庫操作的綜合應(yīng)用也可作為答辯展示和功能擴(kuò)展的起點(diǎn)。1. 一份C課程設(shè)計(jì)資源包即時(shí)通信系統(tǒng)恰好踩中了課程設(shè)計(jì)的核心考點(diǎn)如果說C面向?qū)ο蟪绦蛟O(shè)計(jì)課程設(shè)計(jì)里有一個(gè)既能拿高分又不會(huì)爛大街的選題即時(shí)通信系統(tǒng)一定是排在前三的那個(gè)。我這次拆的這個(gè)源碼包功能閉環(huán)很完整注冊登錄、好友管理、單聊與群聊、離線消息附帶設(shè)計(jì)文檔和答辯參考。它最大的價(jià)值不是“能跑通”而是把網(wǎng)絡(luò)收發(fā)、界面渲染、業(yè)務(wù)狀態(tài)拆成了顆粒清晰的類真正對得起面向?qū)ο筮@四個(gè)字。適合正在找課程設(shè)計(jì)素材、準(zhǔn)備答辯、或者想補(bǔ)一下“從demo變成可演示系統(tǒng)”這一課的人。模塊拆得好后面驗(yàn)收、答辯、二次開發(fā)都省事。2. 整體架構(gòu)與類設(shè)計(jì)七張類圖把網(wǎng)絡(luò)、界面、數(shù)據(jù)徹底切開2.1 為什么一個(gè)課程設(shè)計(jì)值得用C/S架構(gòu)和分層來做很多同學(xué)的課程設(shè)計(jì)喜歡做單機(jī)通訊錄代碼量不大但答辯時(shí)老師問一句“你這個(gè)核心業(yè)務(wù)流程怎么擴(kuò)展”基本就卡住了。即時(shí)通信系統(tǒng)天然是C/S架構(gòu)客戶端負(fù)責(zé)交互服務(wù)器負(fù)責(zé)轉(zhuǎn)發(fā)與狀態(tài)維護(hù)這個(gè)拆分本身就逼著你做模塊化設(shè)計(jì)。我在這個(gè)資源包里看到的做法是三層結(jié)構(gòu)表現(xiàn)層登錄窗口、主窗口、聊天窗口只做界面渲染與用戶操作響應(yīng)。業(yè)務(wù)層好友管理、消息路由、登錄態(tài)校驗(yàn)不依賴具體socket代碼。數(shù)據(jù)層賬號存儲(chǔ)、會(huì)話記錄接口與實(shí)現(xiàn)分離。這個(gè)選型的好處很直接網(wǎng)絡(luò)模塊掛了界面不應(yīng)該跟著卡死數(shù)據(jù)庫換了業(yè)務(wù)層不需要改。課程設(shè)計(jì)答辯時(shí)老師問到“為什么這么設(shè)計(jì)”三層分離是最容易講清楚的答案。我一般會(huì)建議照著這個(gè)結(jié)構(gòu)做因?yàn)樗墙?jīng)過大量項(xiàng)目驗(yàn)證過的不是課程設(shè)計(jì)特有的產(chǎn)物。2.2 核心類與對象關(guān)系從基類抽象到接口回調(diào)類設(shè)計(jì)是整個(gè)資源包的重頭戲。它的核心類可以概括成六個(gè)CNetCore負(fù)責(zé)socket收發(fā)CMsgProtocol負(fù)責(zé)協(xié)議編解碼CUser封裝用戶信息CRoom管群聊成員CAccountStore管賬號數(shù)據(jù)CMsgEvent作為事件載體在業(yè)務(wù)層流轉(zhuǎn)。// netcore.h #pragma once #include winsock2.h #include QString class CNetCore { public: bool Startup(); // 初始化 Winsock 并創(chuàng)建 socket bool ConnectTo(const QString host, quint16 port); bool SendPacket(const char* data, int len); int RecvPacket(char* buffer, int capacity); void Close(); private: SOCKET sock_; bool isConnected_; };這個(gè)類的設(shè)計(jì)有一點(diǎn)很關(guān)鍵把SOCKET封裝成成員變量外部代碼不直接碰句柄所有對socket的操作都收口到CNetCore的方法里。ConnectTo接收主機(jī)名和端口內(nèi)部完成域名解析與connect調(diào)用SendPacket只負(fù)責(zé)把字節(jié)流發(fā)出去不關(guān)心它是什么協(xié)議這樣協(xié)議層與傳輸層就解耦了。你可能會(huì)問為什么不把協(xié)議解析也放進(jìn)CNetCore因?yàn)槁氊?zé)不同。CNetCore解決“怎么把數(shù)據(jù)發(fā)出去”CMsgProtocol解決“發(fā)出去的數(shù)據(jù)長什么樣”。混在一起后改動(dòng)協(xié)議會(huì)導(dǎo)致網(wǎng)絡(luò)模塊全部重編沒必要。2.3 數(shù)據(jù)層實(shí)現(xiàn)賬號存儲(chǔ)與登錄態(tài)分離賬號數(shù)據(jù)在這個(gè)項(xiàng)目里用的是SQLite表結(jié)構(gòu)就兩張一張存賬號信息一張存好友關(guān)系。CAccountStore對外暴露Register、Verify、GetFriendList三個(gè)方法內(nèi)部是參數(shù)化SQL語句避免拼字符串帶來的注入問題。bool CAccountStore::Register(const QString name, const QString pwd) { QSqlQuery query(db_); query.prepare(INSERT INTO t_account(name, pwd_hash) VALUES(?, ?)); query.addBindValue(name); query.addBindValue(EncryptPwd(pwd)); return query.exec(); } bool CAccountStore::Verify(const QString name, const QString pwd) { QSqlQuery query(db_); query.prepare(SELECT pwd_hash FROM t_account WHERE name ?); query.addBindValue(name); if (!query.exec() || !query.next()) return false; return query.value(0).toString() EncryptPwd(pwd); }EncryptPwd這里用的是簡單哈希加鹽不是明文存密碼。課程設(shè)計(jì)階段不需要上多復(fù)雜的加密但至少要有這個(gè)意識。你仔細(xì)看這個(gè)設(shè)計(jì)CAccountStore沒有任何網(wǎng)絡(luò)相關(guān)代碼它不知道消息從哪來這保證了數(shù)據(jù)層可以被單獨(dú)測試。我之前看到過不少課程設(shè)計(jì)把SQL語句直接寫進(jìn)窗口類里窗口關(guān)閉時(shí)數(shù)據(jù)庫連接還開著邏輯全攪在一起Debug時(shí)全是玄學(xué)問題。這個(gè)資源包的做法才是能落地的。3. 網(wǎng)絡(luò)模塊與消息協(xié)議從socket到可靠收發(fā)要走完的三步3.1 客戶端socket封裝初始化、連接、非阻塞模式網(wǎng)絡(luò)模塊是即時(shí)通信系統(tǒng)里最容易翻車的地方原因不是socket本身難而是隱藏狀態(tài)太多。資源包里CNetCore::Startup()的實(shí)現(xiàn)很有代表性。bool CNetCore::Startup() { WSADATA wsaData; int rc WSAStartup(MAKEWORD(2, 2), wsaData); if (rc ! 0) { qDebug() WSAStartup failed: rc; return false; } sock_ socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (sock_ INVALID_SOCKET) { qDebug() socket create failed: WSAGetLastError(); WSACleanup(); return false; } u_long mode 1; ioctlsocket(sock_, FIONBIO, mode); // 切換非阻塞模式 return true; }注意兩個(gè)細(xì)節(jié)。第一WSAStartup必須檢查返回值它失敗時(shí)后續(xù)所有socket調(diào)用都會(huì)報(bào)10107之類的“套接字版本協(xié)商失敗”錯(cuò)誤很多人第一次跑Windows網(wǎng)絡(luò)程序都會(huì)栽在這。第二ioctlsocket把socket切成非阻塞后recv在沒有數(shù)據(jù)到來時(shí)會(huì)立即返回SOCKET_ERROR錯(cuò)誤碼是WSAEWOULDBLOCK。這個(gè)錯(cuò)誤不是異常是正?，F(xiàn)象邏輯里必須把它和真正的網(wǎng)絡(luò)錯(cuò)誤區(qū)分開。3.2 協(xié)議頭設(shè)計(jì)長度頭、類型頭與負(fù)載分離消息協(xié)議是這個(gè)項(xiàng)目最值得抄作業(yè)的部分。它的格式是“4字節(jié)消息總長度 2字節(jié)消息類型 負(fù)載”負(fù)載是utf8編碼的JSON字符串。這樣設(shè)計(jì)的好處是黏包和半包都能處理。QByteArray BuildPacket(quint16 msgType, const QByteArray payload) { QByteArray packet; quint32 len payload.size(); packet.append(char((len 24) 0xFF)); packet.append(char((len 16) 0xFF)); packet.append(char((len 8) 0xFF)); packet.append(char(len 0xFF)); packet.append(char((msgType 8) 0xFF)); packet.append(char(msgType 0xFF)); packet.append(payload); return packet; }大端序存儲(chǔ)有一個(gè)實(shí)際好處調(diào)試時(shí)用十六進(jìn)制查看數(shù)據(jù)包長度字段一眼就能讀出來不用考慮小端序的字節(jié)交換。msgType占2字節(jié)預(yù)留了從0到65535的消息類型空間對課程設(shè)計(jì)來說綽綽有余。接收端的解析不是一次性能做完的。TCP是字節(jié)流它不保證每次recv拿到的正好是一個(gè)完整的數(shù)據(jù)包。資源包里的做法是維護(hù)一個(gè)接收緩沖區(qū)和TryDecode函數(shù)bool CMsgProtocol::TryDecode(QByteArray buffer, CMessage out) { while (buffer.size() HEADER_LEN) { quint32 len (quint8(buffer[0]) 24) | (quint8(buffer[1]) 16) | (quint8(buffer[2]) 8) | (quint8(buffer[3])); if (len MAX_PAYLOAD) { buffer.clear(); return false; // 數(shù)據(jù)異常防止惡意包撐爆內(nèi)存 } if (buffer.size() HEADER_LEN len) { return false; // 半包等更多數(shù)據(jù) } quint16 type (quint8(buffer[4]) 8) | quint8(buffer[5]); out.SetType(type); out.SetPayload(buffer.mid(HEADER_LEN, len)); buffer.remove(0, HEADER_LEN len); return true; // 取出一條完整消息 } return false; }每次recv到新數(shù)據(jù)后把數(shù)據(jù)追加到緩沖區(qū)末尾再調(diào)用TryDecode循環(huán)解析。如果返回值是半包說明數(shù)據(jù)還沒收全等下一輪再試。這個(gè)邏輯一旦寫成粘包、拆包問題基本一次解決不會(huì)再出現(xiàn)“消息錯(cuò)位”的詭異問題。3.3 服務(wù)器并發(fā)select復(fù)用與請求處理邊界服務(wù)器端這個(gè)項(xiàng)目用的是select模型線程數(shù)固定一個(gè)監(jiān)聽socket加若干個(gè)客戶端socket。select的好處是單線程處理多路IO比開一堆線程更可控對課程設(shè)計(jì)的并發(fā)量完全夠用。fd_set readSet; FD_ZERO(readSet); FD_SET(listenSock, readSet); for (SOCKET s : clients) FD_SET(s, readSet); timeval tv {1, 0}; int ret select(0, readSet, nullptr, nullptr, tv); if (ret 0) { if (FD_ISSET(listenSock, readSet)) { // accept 新連接加入 clients 容器 } for (SOCKET s : clients) { if (FD_ISSET(s, readSet)) { // recv數(shù)據(jù)交給 CMsgProtocol 解析 } } }select的超時(shí)時(shí)間設(shè)成1秒還有一個(gè)隱藏作用即使沒有網(wǎng)絡(luò)事件主循環(huán)每秒都會(huì)醒一次趁機(jī)做心跳超時(shí)檢測把長時(shí)間沒發(fā)心跳的客戶端踢下線。課程設(shè)計(jì)如果要演示“客戶端崩潰后服務(wù)器能感知”這個(gè)機(jī)制是必要的。服務(wù)器每次recv都盡量把緩沖區(qū)讀完但不要把耗時(shí)操作放在網(wǎng)絡(luò)循環(huán)里比如寫數(shù)據(jù)庫可以丟到任務(wù)隊(duì)列里否則一個(gè)客戶端的大量消息會(huì)把整個(gè)服務(wù)器的響應(yīng)拖慢。4. 界面邏輯與線程模型UI和網(wǎng)絡(luò)分離消息隊(duì)列不卡窗口4.1 跨線程通信把網(wǎng)絡(luò)線程的數(shù)據(jù)安全地送到界面線程很多課程設(shè)計(jì)在第一次演示時(shí)都會(huì)出現(xiàn)一個(gè)尷尬場景聊天窗口拖動(dòng)時(shí)卡頓或者干脆“窗口未響應(yīng)”。原因幾乎都是網(wǎng)絡(luò)數(shù)據(jù)處理在UI線程里執(zhí)行了。這個(gè)資源包給的做法是網(wǎng)絡(luò)線程負(fù)責(zé)收包解析界面線程只負(fù)責(zé)渲染。// worker.h class NetWorker : public QObject { Q_OBJECT public slots: void OnReadyRead(); // 網(wǎng)絡(luò)線程收到數(shù)據(jù) signals: void MessageReceived(const CMessage msg); void ParseError(const QString desc); };在工作線程里發(fā)信號信號攜帶的是自定義類型CMessage所以必須先調(diào)用qRegisterMetaTypeCMessage()注冊否則連接時(shí)會(huì)直接報(bào)錯(cuò)。// mainwindow.cpp connect(netWorker_, NetWorker::MessageReceived, this, MainWindow::OnMessageReceived, Qt::QueuedConnection);Qt::QueuedConnection是這里最關(guān)鍵的一個(gè)參數(shù)。它保證信號投遞到接收者的事件循環(huán)中而不是立即執(zhí)行。這樣即使網(wǎng)絡(luò)線程短時(shí)間內(nèi)收到大量消息界面線程也只是每條都排隊(duì)處理窗口不會(huì)因?yàn)榉磸?fù)重繪而卡死。如果你用的是非Qt框架對應(yīng)方案是封裝一個(gè)線程安全消息隊(duì)列UI線程定時(shí)取同樣能達(dá)到這個(gè)效果。4.2 登錄到主界面的狀態(tài)切換別用if堆邏輯登錄、注冊、主界面之間的跳轉(zhuǎn)這個(gè)項(xiàng)目用一個(gè)簡單的狀態(tài)機(jī)來管理。登錄成功后把用戶信息和好友列表寫進(jìn)內(nèi)存再切換主窗口登錄失敗留在當(dāng)前窗口并給出提示。void LoginWindow::OnLoginResult(bool ok, const QString reason) { if (ok) { MainWindow* w new MainWindow(user_, friendList_); w-show(); this-close(); } else { QMessageBox::warning(this, 登錄失敗, reason); } }注意這里不是直接new一個(gè)窗口就好而是要把登錄結(jié)果里拿到的好友列表指針傳給主窗口。如果不傳主窗口還得再查一遍數(shù)據(jù)庫相當(dāng)于繞了一圈。有些實(shí)現(xiàn)會(huì)在兩個(gè)窗口之間維護(hù)一堆全局變量一旦處理“賬號被踢下線”就會(huì)漏狀態(tài)。4.3 好友列表與聊天窗口增量刷新比全量重建可靠主窗口的好友列表這個(gè)版本用的是QListWidget但它不是每次都clear()再重新插入。每次只對有狀態(tài)變化的條目做更新這樣有兩個(gè)好處一是列表不會(huì)閃爍二是不會(huì)丟焦點(diǎn)。聊天窗口的消息列表同理新消息到達(dá)時(shí)只追加一條QListWidgetItem并且自動(dòng)滾動(dòng)到底部。void ChatWindow::AppendMessage(const QString sender, const QString content) { QListWidgetItem* item new QListWidgetItem( QString(%1: %2).arg(sender, content)); listWidget_-addItem(item); listWidget_-scrollToBottom(); }這里我見過最常見的翻車姿勢是直接在聊天窗口構(gòu)造函數(shù)里創(chuàng)建一個(gè)新的QListWidgetItem給每條歷史消息然后還手動(dòng)控制setCurrentRow結(jié)果窗口加載幾十條消息后就開始閃爍。資源包的做法是歷史消息和實(shí)時(shí)消息走同一個(gè)AppendMessage入口統(tǒng)一行為就可預(yù)期。5. 排障與常見問題五個(gè)把分?jǐn)?shù)拉低的踩坑記錄5.1 粘包與半包導(dǎo)致消息錯(cuò)位現(xiàn)象A發(fā)送“你好”和“再見”兩條消息B收到的卻是“你”和“好再見”。原因TCP把兩條消息放進(jìn)同一個(gè)TCP段發(fā)出接收端一次recv讀到了兩條完整數(shù)據(jù)但程序只按一條來處理第二條多出來的字節(jié)留在了緩沖區(qū)里下一次再來數(shù)據(jù)時(shí)就錯(cuò)位了。解決緩沖區(qū)加協(xié)議長度頭處理上一章講的TryDecode就是完整的解決方案。從那以后我寫網(wǎng)絡(luò)程序第一時(shí)間先定協(xié)議長度頭不是先寫收發(fā)邏輯。5.2 服務(wù)器select返回后立即空轉(zhuǎn)現(xiàn)象服務(wù)器CPU占用接近100%但客戶端沒有發(fā)任何數(shù)據(jù)。原因socket被設(shè)置成非阻塞后accept返回INVALID_SOCKET有些代碼沒有檢查這個(gè)值就把無效socket加入fd_setselect每次都因?yàn)闊o效句柄觸發(fā)異常返回業(yè)務(wù)循環(huán)就變成了死循環(huán)。解決accept和recv必須要判定失敗分支。accept返回INVALID_SOCKET且WSAGetLastError為WSAEWOULDBLOCK時(shí)直接跳過本輪。順帶檢查clients容器里是否有已關(guān)閉連接發(fā)現(xiàn)有FD_CLOSE事件就移出集合并closesocket。5.3 界面線程被網(wǎng)絡(luò)阻塞假死現(xiàn)象拖動(dòng)聊天窗口時(shí)整個(gè)程序沒反應(yīng)Windows提示“未響應(yīng)”。原因recv被設(shè)計(jì)成行代碼直接寫在按鈕點(diǎn)擊事件里網(wǎng)絡(luò)沒數(shù)據(jù)時(shí)就會(huì)一直阻塞在那里UI線程完全被卡住。解決網(wǎng)絡(luò)收發(fā)全部移到獨(dú)立線程界面通過隊(duì)列接收消息。只要做到“UI線程不碰socket”這類問題基本不會(huì)出現(xiàn)。5.4 中文用戶名亂碼現(xiàn)象用UTF-8編碼的用戶名注冊成功后服務(wù)器端讀出來是一串亂碼。原因Windows默認(rèn)的本地代碼頁是GBK客戶端界面輸入的QString在本地代碼頁模式下被轉(zhuǎn)換成GBK字節(jié)流而服務(wù)器端解析時(shí)仍按UTF-8處理字節(jié)解釋不一致就亂碼了。解決統(tǒng)一編碼在協(xié)議層明確是UTF-8。寫入socket前用QString::toUtf8()讀出后QString::fromUtf8()。不要信“Windows控制臺能顯示中文就是對的”socket沒有編碼概念只有字節(jié)流誰定義編碼誰負(fù)責(zé)。5.5 服務(wù)器退出時(shí)崩潰現(xiàn)象關(guān)閉服務(wù)器控制臺程序有時(shí)直接報(bào)錯(cuò)或者卡住無法退出。原因客戶端連接還掛在clients容器里服務(wù)器直接退出時(shí)每個(gè)socket都還持有對象引用部分晚到的recv回調(diào)還在工作析構(gòu)順序錯(cuò)亂導(dǎo)致重復(fù)釋放。解決退出前統(tǒng)一關(guān)閉所有socket先斷開有連接的客戶端再清理監(jiān)聽socket。而且查找所有delete處確保每個(gè)網(wǎng)絡(luò)對象只有一個(gè)擁有者。最好在服務(wù)器退出流程里加一個(gè)標(biāo)志位讓循環(huán)正常跳出而不是強(qiáng)殺線程。6. 把優(yōu)秀成績拉開差距可靠性驗(yàn)證與可擴(kuò)展接口6.1 用腳本把協(xié)議回歸測試做成自動(dòng)化課程設(shè)計(jì)說出來不算數(shù)要有驗(yàn)證。我在這個(gè)資源包里最欣賞的部分是一組測試腳本起服務(wù)器后腳本啟動(dòng)兩個(gè)客戶端進(jìn)程預(yù)設(shè)好賬號、好友關(guān)系讓A給B連續(xù)發(fā)100條消息然后腳本檢查B收到的消息條數(shù)、順序和內(nèi)容是否一致。這個(gè)腳本不是UI自動(dòng)化而是走socket層面直接打協(xié)議包所以能非?？彀l(fā)現(xiàn)問題。# stress_test.py import socket import struct import time def build_packet(msg_type, payload): return struct.pack(IH, len(payload), msg_type) payload.encode(utf-8) client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 9999)) client.send(build_packet(1, {action:login,name:A,pwd:123456})) time.sleep(0.2) for i in range(100): client.send(build_packet(3, {to:B,content:msg-%d} % i)) client.close()這個(gè)協(xié)議格式剛好和C端一致IH對應(yīng)大端2字節(jié)類型加4字節(jié)長度。為什么用腳本而不是在C里再寫一個(gè)測試客戶端因?yàn)槟_本改起來快壓測時(shí)不用重新編譯而且可以結(jié)合串行、并發(fā)多場景跑。我在之前做模擬項(xiàng)目X時(shí)就是靠這套腳本在答辯前抓到一個(gè)只在壓力下才出現(xiàn)的隱性半包問題。從那以后我每次做網(wǎng)絡(luò)課程設(shè)計(jì)都會(huì)先寫一套回歸腳本再開始寫業(yè)務(wù)代碼。6.2 預(yù)留擴(kuò)展點(diǎn)離線消息與文件傳輸如果你想讓成績再上一個(gè)臺階可以重點(diǎn)看這個(gè)資源包的擴(kuò)展接口設(shè)計(jì)。服務(wù)器維護(hù)一個(gè)離線消息隊(duì)列客戶端登錄成功后服務(wù)器把隊(duì)列里的消息逐條推送過來客戶端按會(huì)話分組展示。這個(gè)邏輯本質(zhì)上是對消息路由層做一個(gè)小擴(kuò)展不需要改動(dòng)網(wǎng)絡(luò)核心。文件傳輸也做了預(yù)留文件分片后復(fù)用同一套協(xié)議格式只是類型字段變成了FILE_CHUNK負(fù)載里放了文件ID、分片序號和二進(jìn)制數(shù)據(jù)。底層收發(fā)不變只是負(fù)載大了些。這也是這個(gè)資源包的價(jià)值它不是一套只夠演示的基礎(chǔ)代碼而是留好了后續(xù)功能擴(kuò)展的空間。我記得某導(dǎo)師在答辯時(shí)說了一句話課程設(shè)計(jì)不是看你會(huì)不會(huì)寫代碼是看你有沒有想過這個(gè)系統(tǒng)明天怎么加功能。這話很扎心但確實(shí)是驗(yàn)收時(shí)拉開分差的關(guān)鍵點(diǎn)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取