簡(jiǎn)介kok1服務(wù)端源碼是一套面向經(jīng)典網(wǎng)絡(luò)游戲“萬(wàn)王之王1”的后端系統(tǒng)實(shí)現(xiàn)使用C編寫(xiě)適合游戲服務(wù)端開(kāi)發(fā)者、網(wǎng)絡(luò)編程學(xué)習(xí)者以及希望研究大型多人在線游戲架構(gòu)的讀者參考。整個(gè)壓縮包共219個(gè)文件體積約18.52MB除了核心的C源碼與頭文件還配有可執(zhí)行程序、動(dòng)態(tài)鏈接庫(kù)、中間目標(biāo)文件、配置文件、工程文件等覆蓋從編譯構(gòu)建到運(yùn)行配置的完整環(huán)節(jié)方便按模塊理解工程組織方式。目前已有1046人學(xué)習(xí)下載。源碼中可系統(tǒng)梳理C服務(wù)端的網(wǎng)絡(luò)通信、多線程并發(fā)、內(nèi)存管理、數(shù)據(jù)庫(kù)交互、狀態(tài)機(jī)設(shè)計(jì)、日志與安全防護(hù)等關(guān)鍵知識(shí)點(diǎn)配合不同進(jìn)程的配置和項(xiàng)目目錄結(jié)構(gòu)能進(jìn)一步理解多模塊服務(wù)端的進(jìn)程劃分、啟動(dòng)流程與配置加載關(guān)系。閱讀時(shí)可結(jié)合業(yè)務(wù)邏輯拆解登錄、角色、地圖、戰(zhàn)斗等模塊觀察服務(wù)端如何管理連接、同步狀態(tài)與處理數(shù)據(jù)對(duì)想深入經(jīng)典網(wǎng)游服務(wù)端實(shí)現(xiàn)原理、積累實(shí)戰(zhàn)經(jīng)驗(yàn)的開(kāi)發(fā)者來(lái)說(shuō)是一份可對(duì)照學(xué)習(xí)的完整參考資料。 最近不少朋友在后臺(tái)問(wèn)我關(guān)于“kok1服務(wù)端源碼”這類(lèi)項(xiàng)目的事說(shuō)實(shí)話單從標(biāo)題看它更像是一個(gè)游戲私服或者某種業(yè)務(wù)系統(tǒng)的服務(wù)端代碼包。但把周邊熱搜詞拉出來(lái)一看情況就明朗了——冒險(xiǎn)島079服務(wù)端、DNF服務(wù)端、嵌入式內(nèi)核源碼、mybatis源碼、PHP源碼這些詞全混在一起說(shuō)明問(wèn)這個(gè)問(wèn)題的人真正想要的東西其實(shí)是一套通用的服務(wù)端源碼閱讀方法論。不管kok1是某個(gè)游戲的模擬器端還是一個(gè)業(yè)務(wù)后臺(tái)拿到手之后的第一步永遠(yuǎn)不是急著跑起來(lái)而是先搞清楚這坨代碼是怎么組織、怎么通信、怎么存數(shù)據(jù)的。這篇文章我就拿這類(lèi)“服務(wù)端源碼”項(xiàng)目當(dāng)靶子把我這些年讀源碼、改源碼、給源碼擦屁股的經(jīng)驗(yàn)完整過(guò)一遍。全文不綁定某個(gè)具體游戲或框架但方法論可以直接套到你手頭那份源碼上。1. 拿到一份陌生服務(wù)端源碼先別急著編譯先做這三件事很多人拿到源碼包第一反應(yīng)是雙擊README、裝依賴(lài)、敲啟動(dòng)命令然后盯著控制臺(tái)日志發(fā)呆。這個(gè)順序是錯(cuò)的。服務(wù)端源碼和普通業(yè)務(wù)代碼最大的區(qū)別在于它不是一個(gè)線性執(zhí)行的程序而是一組常駐進(jìn)程 一堆異步回調(diào) 一套持久化策略的組合體。如果你不知道進(jìn)程之間怎么協(xié)作跑起來(lái)也看不懂日志在說(shuō)什么。我拿到任何一份服務(wù)端源碼第一步永遠(yuǎn)是“三看”看目錄結(jié)構(gòu)把頂層目錄樹(shù)打出來(lái)按功能模塊畫(huà)一張腦圖。通常一個(gè)服務(wù)端項(xiàng)目會(huì)分成網(wǎng)關(guān)層、邏輯層、數(shù)據(jù)層、公共庫(kù)這幾個(gè)大塊。如果頂層目錄里有g(shù)ame、login、db、common這類(lèi)名詞那基本就是游戲服務(wù)端的經(jīng)典布局如果是controller、service、dao那就是Web后臺(tái)的MVC布局。kok1這類(lèi)標(biāo)題如果帶游戲?qū)傩源蟾怕首叩氖乔罢??？磫?dòng)入口找到main函數(shù)所在的工程或模塊順著啟動(dòng)流程讀一遍。重點(diǎn)看它啟動(dòng)了哪些線程、監(jiān)聽(tīng)了哪些端口、初始化了哪些管理器。這一步能讓你知道“這程序一開(kāi)機(jī)到底在干什么”?？磁渲梦募湍_本config目錄、.ini、.json、.lua或SQL初始化腳本這些文件揭示了程序的運(yùn)行參數(shù)和依賴(lài)環(huán)境。比如端口號(hào)、數(shù)據(jù)庫(kù)連接串、Redis地址、日志級(jí)別。把這些信息記下來(lái)后面調(diào)試時(shí)能省一半時(shí)間。這三件事做完你手里就有了一張“地圖”。不需要記住每一行代碼只需要知道“我想找某功能時(shí)應(yīng)該去哪一層翻”。這套方法不區(qū)分項(xiàng)目是C寫(xiě)的、Java寫(xiě)的、Go寫(xiě)的還是Python寫(xiě)的。語(yǔ)言只是語(yǔ)法外殼服務(wù)端源碼的骨架邏輯高度一致接收請(qǐng)求、處理業(yè)務(wù)、讀寫(xiě)數(shù)據(jù)、返回結(jié)果。先認(rèn)骨架再摳血肉這是讀源碼的第一性原則。2. 網(wǎng)絡(luò)層與消息分發(fā)讀服務(wù)端源碼首先要啃的硬骨頭服務(wù)端源碼里最勸退新手的就是網(wǎng)絡(luò)層。一堆Socket、epoll、IOCP、Netty相關(guān)的代碼看著頭大。但我可以負(fù)責(zé)任地告訴你服務(wù)端源碼的網(wǎng)絡(luò)層是整份代碼里最不需要逐行精讀的部分你只需要搞清楚三件事即可2.1 消息是怎么進(jìn)來(lái)的不管是TCP長(zhǎng)連接還是HTTP短連接服務(wù)端一定有一個(gè)監(jiān)聽(tīng)的端口注冊(cè)了一堆回調(diào)函數(shù)。你要找的是“收到一條數(shù)據(jù)后第一個(gè)被調(diào)用的函數(shù)是哪個(gè)”。在C項(xiàng)目里這通常是某個(gè)OnMessage或OnRecv回調(diào)在Java項(xiàng)目里這通常是某個(gè)ChannelInboundHandler的channelRead方法。找到這個(gè)入口你就找到了整個(gè)服務(wù)端的數(shù)據(jù)入口。2.2 消息是怎么分發(fā)的服務(wù)端收到一條原始字節(jié)流之后首先要做的事情是“拆包”。因?yàn)門(mén)CP是流式協(xié)議一次recv可能收到半條消息也可能收到好幾條消息。所以網(wǎng)絡(luò)層一定有一個(gè)粘包拆包器負(fù)責(zé)從字節(jié)流里切出完整的一條條消息——通常是以包頭包含消息長(zhǎng)度 包體包含消息ID 序列化數(shù)據(jù)的格式來(lái)實(shí)現(xiàn)的。拆出一條完整消息后框架會(huì)根據(jù)消息ID查表找到對(duì)應(yīng)的處理函數(shù)Handler。這個(gè)過(guò)程叫”消息分發(fā)“。在C代碼里常見(jiàn)實(shí)現(xiàn)是一個(gè)大Switch或一個(gè)消息ID到函數(shù)指針的映射表Java里則通常用注解或者抽象工廠來(lái)做。讀這部分代碼時(shí)我建議你重點(diǎn)畫(huà)一張表消息ID范圍所屬模塊回調(diào)函數(shù)線程模型10001~10010登錄認(rèn)證AuthHandlerIO線程20001~20050玩家戰(zhàn)斗BattleHandler邏輯線程30001~30099背包物品BagHandler邏輯線程有了這張表你后續(xù)想找“某個(gè)特定功能怎么實(shí)現(xiàn)的”直接按消息ID查表定位就行根本不用通讀全工程。2.3 消息處理在哪個(gè)線程這是最容易被忽略也最容易踩坑的地方。服務(wù)端源碼通常有“IO線程”和“邏輯線程”的區(qū)分。IO線程只負(fù)責(zé)收發(fā)數(shù)據(jù)邏輯線程負(fù)責(zé)跑業(yè)務(wù)。如果你在一個(gè)IO線程里直接執(zhí)行耗時(shí)操作比如寫(xiě)數(shù)據(jù)庫(kù)、調(diào)外部API輕則阻塞收包重則導(dǎo)致服務(wù)端雪崩?？炊€程模型之后你就理解了為什么很多服務(wù)端源碼里會(huì)有postToLogicThread、scheduleTask這類(lèi)看似多余的封裝。它們不是為了裝逼是為了保證業(yè)務(wù)邏輯線程安全。我在實(shí)際調(diào)試中至少有三分之一的Bug最終都定位到“線程用錯(cuò)”上。3. 邏輯層怎么讀從一段任務(wù)流程代碼搞懂游戲服務(wù)端的核心設(shè)計(jì)網(wǎng)絡(luò)層搞明白之后最重的活兒就是邏輯層。邏輯層是服務(wù)端源碼的主體承載了所有業(yè)務(wù)規(guī)則。游戲服務(wù)端的邏輯層以“玩家在線”為核心Web后臺(tái)以“請(qǐng)求處理”為核心。不同的領(lǐng)域邏輯組織方式有所區(qū)別但核心套路是一樣的狀態(tài)機(jī) 數(shù)據(jù)變更 事件通知。以游戲服務(wù)端里最常見(jiàn)的“接任務(wù)”流程為例整條鏈路是這樣的玩家點(diǎn)擊NPC客戶(hù)端發(fā)送“請(qǐng)求接任務(wù)”消息。服務(wù)端收到消息進(jìn)入任務(wù)模塊的Handle函數(shù)。處理函數(shù)先做合法性校驗(yàn)角色是否在線、任務(wù)是否已接取、前置任務(wù)是否完成、等級(jí)是否達(dá)標(biāo)。校驗(yàn)通過(guò)后修改玩家的任務(wù)狀態(tài)從“未接取”改為“進(jìn)行中”。把變更后的數(shù)據(jù)寫(xiě)回緩存或數(shù)據(jù)庫(kù)。返回消息給客戶(hù)端告訴它“任務(wù)接取成功”并附帶最新的任務(wù)列表。觸發(fā)后續(xù)事件比如給玩家發(fā)一條跑馬燈提示、更新UI面板、推送統(tǒng)計(jì)日志。讀這七個(gè)步驟對(duì)應(yīng)的代碼不需要從上往下逐行念而是要回答以下幾個(gè)問(wèn)題校驗(yàn)邏輯集中在哪個(gè)函數(shù)——這個(gè)函數(shù)就是你改規(guī)則時(shí)的“門(mén)衛(wèi)”。狀態(tài)字段存在哪——是存在玩家對(duì)象的內(nèi)存結(jié)構(gòu)里還是直接落庫(kù)這決定了你在做并發(fā)控制時(shí)要不要加鎖。消息返回是同步的還是異步的——有的框架是收到請(qǐng)求直接返回有的則是處理完異步推送。理解這一點(diǎn)你才不會(huì)在調(diào)試時(shí)對(duì)著“明明請(qǐng)求成功了但客戶(hù)端沒(méi)反應(yīng)”發(fā)呆。事件通知是怎么觸發(fā)的——很多邏輯模塊比如成就系統(tǒng)、每日任務(wù)會(huì)監(jiān)聽(tīng)其他模塊的事件。你要找的是事件總線或者觀察者模式的注冊(cè)點(diǎn)。把這幾個(gè)問(wèn)題弄明白之后你就具備“改邏輯”的能力了。改邏輯不是改一處而是要改一整套數(shù)據(jù)流轉(zhuǎn)路徑。我見(jiàn)過(guò)太多人在服務(wù)端源碼里只改了一個(gè)內(nèi)存字段的值忘了同步改存檔結(jié)果玩家一重啟就回檔。這類(lèi)低級(jí)錯(cuò)誤都是因?yàn)闆](méi)建立“數(shù)據(jù)一次修改全鏈路同步”的意識(shí)。邏輯層里還會(huì)有很多聽(tīng)起來(lái)很高大上的詞比如AOI感興趣區(qū)域管理、尋路、戰(zhàn)斗結(jié)算、掉落表、技能編輯器。這些本質(zhì)上都是特定領(lǐng)域的算法不影響你理解整體架構(gòu)。我建議你把它們當(dāng)黑盒先搞清楚輸入輸出再去精讀核心算法。千萬(wàn)不要一上來(lái)就鉆進(jìn)尋路算法里出不來(lái)了。4. 數(shù)據(jù)層存檔、緩存與代碼解耦一份服務(wù)端源碼的含金量看這里服務(wù)端源碼和普通腳本最大的區(qū)別就是數(shù)據(jù)是持久的。玩家下線了數(shù)據(jù)要存下來(lái)服務(wù)器重啟了數(shù)據(jù)不能丟玩家在線期間讀寫(xiě)不能太慢。所以數(shù)據(jù)層設(shè)計(jì)直接決定了這個(gè)服務(wù)端的穩(wěn)定上限。讀數(shù)據(jù)層代碼我建議按這四步來(lái)4.1 先看持久化方式游戲服務(wù)端常見(jiàn)的存檔方式有四種純文件存檔數(shù)據(jù)寫(xiě)到一個(gè)自定義格式的文件里。優(yōu)點(diǎn)是簡(jiǎn)單缺點(diǎn)是并發(fā)差、容易壞。多見(jiàn)于老牌模擬器或小規(guī)模游戲。關(guān)系型數(shù)據(jù)庫(kù)MySQL等優(yōu)點(diǎn)是查詢(xún)方便、事務(wù)完整缺點(diǎn)是高頻寫(xiě)庫(kù)有性能瓶頸通常需要配合緩存。NoSQLRedis/MongoDB適合高頻讀寫(xiě)和緩存但事務(wù)性弱。混合方案Redis做在線緩存MySQL做定期落盤(pán)玩家下線時(shí)從緩存同步回?cái)?shù)據(jù)庫(kù)。這是目前大型服務(wù)端的主流方案。kok1這類(lèi)服務(wù)端源碼具體用哪種方案你要去配置文件和數(shù)據(jù)訪問(wèn)層看?？吹絙igworld、redis、mysql、leveldb這些關(guān)鍵詞基本就能判斷了。4.2 再看數(shù)據(jù)訪問(wèn)接口正常工程里數(shù)據(jù)訪問(wèn)不會(huì)散落在邏輯代碼里而是統(tǒng)一封裝在一層。可能是PlayerDataManager可能是Dao層也可能是Repository。你讀這部分代碼時(shí)重點(diǎn)看三件事玩家數(shù)據(jù)是何時(shí)加載的——上線時(shí)一次性load全量還是按模塊懶加載玩家數(shù)據(jù)是何時(shí)寫(xiě)庫(kù)的——每次修改立即寫(xiě)還是定時(shí)批量寫(xiě)玩家下線時(shí)發(fā)生了什么——有沒(méi)有觸發(fā)一次完整的存檔流程這一塊搞清楚了你就能回答“改漏數(shù)據(jù)文件導(dǎo)致回檔”這類(lèi)問(wèn)題的根因了。4.3 再談緩存一致性問(wèn)題如果一份源碼里同時(shí)有Redis和MySQL那就一定會(huì)涉及到緩存與數(shù)據(jù)庫(kù)的一致性。常見(jiàn)套路是“先更新數(shù)據(jù)庫(kù)再刪除緩存”或者“先更新緩存再異步寫(xiě)庫(kù)”。讀代碼時(shí)你心里要有一個(gè)數(shù)據(jù)流轉(zhuǎn)流程圖修改請(qǐng)求從哪進(jìn)、先碰哪層存儲(chǔ)、后碰哪層存儲(chǔ)、哪個(gè)節(jié)點(diǎn)是最終一致性的權(quán)威源。這一段不需要太深但你要知道如果你在邏輯層改了一個(gè)字段卻忘了走數(shù)據(jù)層封裝那么這份數(shù)據(jù)很可能“只能活一個(gè)進(jìn)程周期”。這個(gè)問(wèn)題在調(diào)試“重啟服務(wù)器后玩家數(shù)據(jù)丟失”時(shí)幾乎每次都能遇到。4.4 看數(shù)據(jù)庫(kù)表結(jié)構(gòu)如果源碼附帶SQL腳本不要急著跑先把表結(jié)構(gòu)全部過(guò)一遍。重點(diǎn)看玩家表、背包表、任務(wù)表、郵件表之間是怎么通過(guò)ID關(guān)聯(lián)的。表結(jié)構(gòu)的設(shè)計(jì)直接體現(xiàn)了業(yè)務(wù)模型的邊界。我經(jīng)常說(shuō)一句話看表結(jié)構(gòu)的速度比通讀代碼快十倍。表設(shè)計(jì)合理代碼大概率也亂不到哪去表結(jié)構(gòu)亂七八糟代碼里必定藏著成堆的臨時(shí)補(bǔ)丁。數(shù)據(jù)層是整個(gè)服務(wù)端源碼里“含金量”最高的部分。因?yàn)榫W(wǎng)絡(luò)層是上帝造好的輪子邏輯層是業(yè)務(wù)流水賬只有數(shù)據(jù)層是架構(gòu)師真正花心思設(shè)計(jì)的東西。你讀數(shù)據(jù)層時(shí)得到的收益遠(yuǎn)大于讀其他層。5. 把源碼跑起來(lái)環(huán)境準(zhǔn)備、啟動(dòng)順序和實(shí)測(cè)中容易踩的坑理論讀得再多不跑起來(lái)等于零。服務(wù)端源碼跑起來(lái)的過(guò)程本身就是一個(gè)“平滑校驗(yàn)”的過(guò)程——它逼著你把前面幾張地圖拼成一張立體圖。5.1 環(huán)境準(zhǔn)備階段先確認(rèn)幾個(gè)硬性依賴(lài)編譯環(huán)境C項(xiàng)目需要對(duì)應(yīng)的編譯器版本老項(xiàng)目經(jīng)常卡在“新編譯器編譯不過(guò)老代碼”上。我的建議是看源碼里有沒(méi)有CMakeLists.txt或Makefile如果有說(shuō)明它支持從源碼構(gòu)建如果只有.sln那大概率只考慮Windows平臺(tái)。運(yùn)行依賴(lài)很多服務(wù)端源碼依賴(lài)特定的庫(kù)比如libevent、openssl、boost、zookeeper、protobuf。裝的時(shí)候注意版本一定要和源碼要求的一致差了哪怕一個(gè)小版本都可能編不過(guò)。數(shù)據(jù)庫(kù)確定用它內(nèi)置的SQL腳本建庫(kù)還是需要手動(dòng)創(chuàng)建。跑之前先把數(shù)據(jù)庫(kù)啟動(dòng)起來(lái)把初始化腳本執(zhí)行一遍。5.2 啟動(dòng)順序服務(wù)端通常不是單進(jìn)程而是多進(jìn)程協(xié)作。常見(jiàn)的啟動(dòng)順序是啟動(dòng)數(shù)據(jù)庫(kù)MySQL/Redis/MongoDB。啟動(dòng)公共基礎(chǔ)服務(wù)比如日志服務(wù)、消息隊(duì)列。啟動(dòng)中心服或登錄服。啟動(dòng)各個(gè)場(chǎng)景服或業(yè)務(wù)服。啟動(dòng)網(wǎng)關(guān)服讓客戶(hù)端能連進(jìn)來(lái)。很多源碼自帶一鍵啟動(dòng)腳本但建議你別依賴(lài)它。手動(dòng)按順序啟動(dòng)的好處是你能清楚看到每個(gè)進(jìn)程在干嘛哪個(gè)起不來(lái)、報(bào)什么錯(cuò)一目了然。出了問(wèn)題排查速度比無(wú)腦跑腳本快得多。5.3 實(shí)測(cè)中的四個(gè)經(jīng)典坑端口占用老的模擬器很喜歡用固定端口比如8877、8888、10086這些。本機(jī)別的服務(wù)占用了端口服務(wù)端起不來(lái)日志還模棱兩可。排查時(shí)用netstat -ano看端口占用秒懂。數(shù)據(jù)庫(kù)連接失敗初始化腳本跑完了但源碼里配置的數(shù)據(jù)庫(kù)賬號(hào)/密碼和本地不一致導(dǎo)致進(jìn)程起了又退。這時(shí)候去配置文件夾里改連接字符串。編譯期deprecated錯(cuò)誤老代碼用了新編譯器已經(jīng)不支持的寫(xiě)法。這時(shí)不要硬改業(yè)務(wù)代碼優(yōu)先在編譯選項(xiàng)里降級(jí)標(biāo)準(zhǔn)比如C11換成C98或者把報(bào)錯(cuò)的地方改成新語(yǔ)法。數(shù)據(jù)沖突導(dǎo)致啟動(dòng)崩潰如果源碼自帶了測(cè)試存檔數(shù)據(jù)而數(shù)據(jù)庫(kù)里沒(méi)有對(duì)應(yīng)的表記錄啟動(dòng)時(shí)加載存檔可能直接崩。這種情況清空存檔目錄或重建庫(kù)表就能解決。把服務(wù)端跑起來(lái)之后別急著關(guān)先觀察日志輸出格式看它正常時(shí)每秒打印什么、報(bào)錯(cuò)時(shí)打印什么。日志是服務(wù)端源碼的“病歷本”養(yǎng)成看日志的習(xí)慣你以后排查問(wèn)題會(huì)快十倍。6. 進(jìn)階想真正吃透一份服務(wù)端源碼光看源碼本身還不夠最后說(shuō)點(diǎn)扎心的實(shí)話。源碼只是“結(jié)果”真正的“原因”藏在你看不見(jiàn)的地方。想徹底吃透一份服務(wù)端源碼你至少還要具備三個(gè)底層能力協(xié)議分析能力服務(wù)端和客戶(hù)端通信的協(xié)議格式一般在源碼里有定義文件.proto、.xml、.json、.h。你要能自己解析一條消息的構(gòu)成消息頭多長(zhǎng)、校驗(yàn)位怎么算、加密有沒(méi)有、壓縮有沒(méi)有。沒(méi)有這個(gè)能力你看到報(bào)錯(cuò)“消息解析失敗”就只能干瞪眼。性能分析能力服務(wù)端源碼跑起來(lái)之后你要學(xué)會(huì)看CPU、內(nèi)存、句柄數(shù)、線程數(shù)。老服務(wù)端最容易出現(xiàn)的是內(nèi)存泄漏——每次處理完一條消息new出來(lái)的對(duì)象沒(méi)delete。把valgrind或perf用起來(lái)找泄漏點(diǎn)比肉眼盯代碼高效得多。鏈路追蹤能力一條消息從客戶(hù)端發(fā)來(lái)到服務(wù)端存庫(kù)中間經(jīng)過(guò)了哪幾個(gè)模塊每層做了什么這個(gè)“全鏈路圖”要能自己畫(huà)出來(lái)。沒(méi)有這個(gè)全局視圖改一處邏輯必然引出一處新Bug。這三個(gè)能力不是靠讀源碼本身能獲得的而是在反復(fù)調(diào)試、反復(fù)看日志、反復(fù)背鍋過(guò)程中練出來(lái)的。這也是為什么我說(shuō)“服務(wù)端源碼這份東西拆開(kāi)來(lái)看都是套路合起來(lái)看全是細(xì)節(jié)”。所以我的建議是找一份結(jié)構(gòu)清晰、社區(qū)活躍度高的服務(wù)端源碼比如熱度高、issue多的知名開(kāi)源項(xiàng)目先把網(wǎng)絡(luò)層讀通再挑一個(gè)最小業(yè)務(wù)模塊比如玩家登錄從頭到尾捋一遍然后試著加一個(gè)“新道具”或者“新消息”的完整鏈路。走完一遍你才算真正入了服務(wù)端源碼的門(mén)。至于最終改出什么樣的效果——是還原某個(gè)游戲端的完整體驗(yàn)還是做一套自己的獨(dú)立玩法那是后話。但底層這套“怎么讀、怎么跑、怎么改、怎么查錯(cuò)”的功夫一份源碼練完終身受用。本文還有配套的精品資源點(diǎn)擊獲取