數據結構入門后很多人會冒出一種“我已經會鏈表、棧、隊列、樹和圖了可以像大佬一樣去開發(fā)大型項目”的錯覺。這句話有一半是對的有一半需要潑冷水。對的部分是數據結構確實是開發(fā)復雜系統(tǒng)的地基那些看起來非常龐大的項目拆到底層基本都是數組、鏈表、哈希表、樹、圖在反復組合。需要潑冷水的部分是會寫一個鏈表反轉、會手撕平衡二叉樹和能用這些結構去組織一個真實系統(tǒng)中間還有一段不小的距離。這篇內容就圍繞“數據結構入門后怎么真正開始做一個像樣的復雜項目”來寫。文章不會教你怎么把《原神》整個做出來那不是一個博客能講完的事但我會把那種量級的項目拆開看看數據結構在里面到底怎么落位再給你一套從單機到服務端、從小系統(tǒng)到復雜系統(tǒng)的實戰(zhàn)路徑。如果你已經學完基礎數據結構正卡在“能做課后題、但不知道怎么做項目”的階段這篇會比較適合你。1. 先想清楚數據結構入門到底意味著什么1.1 入門不是終點是“能讀懂系統(tǒng)”的起點很多人在學完數據結構課本后最大的誤解是“我掌握了這些東西”。實際上入門課教的是單個結構的原理和基礎操作比如往鏈表里插入一個節(jié)點、在二叉樹上做一次中序遍歷、用鄰接表存一張圖。這些能力解決的是“給一個明確場景我用對應結構完成操作”的問題。真實開發(fā)里的情況完全不同。你不會拿到一個標題叫“請用哈希表完成用戶登錄”的任務你拿到的是一個模糊需求比如“背包里可能有幾百種物品要支持快速查找、排序、疊加、丟棄還要實時同步到客戶端”。這個需求不會告訴你用什么結構需要你自己判斷。數據結構入門后真正獲得的能力叫“能讀懂系統(tǒng)的數據結構視角”?？吹阶詣友a全你能想到字典樹看到社交好友推薦你能想到圖遍歷看到排行榜你能想到跳表或優(yōu)先隊列。這個“看到現象能映射到結構”的能力比會寫結構本身更值錢。1.2 課后題和真實系統(tǒng)的差距在“組合”為什么很多人刷完 LeetCode 或期末題依然不會做項目因為課后題是單項訓練真實系統(tǒng)是復合結構。舉一個很典型的例子“維護一個在線聊天室最近 100 條消息”。課后題可能會考你“用隊列實現消息先進先出”。真實系統(tǒng)里光是這一個功能就可能組合出三層結構最外層用 Redis List 或內存隊列保存消息順序中間層用哈希表按會話 ID 索引到不同的消息隊列每一條消息本身又可能包含附件、引用、狀態(tài)位這些字段又對應到 JSON 對象或數據庫表。你不可能只靠“隊列”一個概念解決全部問題。你需要知道隊列負責順序哈希表負責定位樹或跳表負責范圍查詢最終還要考慮數據持久化。數據結構入門給你的是零件項目開發(fā)需要的是用零件組裝機器的能力。1.3 從“能寫”到“敢寫”的思維切換我見過不少讀者問數據結構學完了但總覺得項目太大不知道從哪下手。這個問題不是能力問題是拆解問題。假設目標是“做一個簡化版原神”。聽起來很嚇人但如果拆成地圖、角色、背包、任務、戰(zhàn)斗、怪物 AI 這些子系統(tǒng)每個系統(tǒng)都可以單獨設計。再往下一層每個子系統(tǒng)又對應一個或幾個核心數據結構地圖系統(tǒng)網格、圖、四叉樹背包系統(tǒng)哈希表、鏈表、有序數組任務系統(tǒng)圖依賴關系、隊列執(zhí)行順序、狀態(tài)機戰(zhàn)斗系統(tǒng)優(yōu)先隊列目標選擇、堆傷害排序、樹技能 Buff 刷新。這樣拆完你會發(fā)現沒有一個模塊是你完全不會的。能不能做出來取決于你有沒有把“數據結構知識”轉換成“模塊設計能力”。后面我會按這個思路拆一個可執(zhí)行的項目。2. 項目選型把“開發(fā)原神”翻譯成可落地的工程目標2.1 三個難度階梯別直接選最大那個如果你的目標是鍛煉數據結構落地能力不要一上來就挑戰(zhàn) 3A 級開放世界那不是訓練是打擊。我建議分成三個階梯第一階梯是“單機文字/回合制游戲”。不需要圖形渲染核心就是狀態(tài)管理、回合計算、背包和任務流程。這個階段訓練的是“數據結構能不能支撐起一個穩(wěn)定運行的邏輯循環(huán)”。第二階梯是“帶實時反饋的簡易戰(zhàn)斗或地圖系統(tǒng)”?？梢宰龀擅钚邪姹净蚝唵?Web 版本重點放在地圖尋路、目標選擇、技能范圍判斷上。這個階段訓練的是“空間數據和實時計算”。第三階梯才是“類原神的小型原型”。包含地圖、角色、背包、任務、戰(zhàn)斗、存儲六個子系統(tǒng)但每個子系統(tǒng)都用最簡版本實現。這個階段訓練的是“多系統(tǒng)組合和工程組織”。不建議跳過階梯直接做第三檔。數據結構的學習曲線需要靠完成度來鞏固一個能跑起來的小項目比一個爛尾的大項目有用得多。2.2 從需求倒推數據結構而不是先選結構很多新手容易犯的錯是“我學了圖所以我要用圖”這是本末倒置。正確做法是先列需求再倒推結構。比如你想要一個“野外地圖玩家可以移動NPC 分布在不同區(qū)域點擊 NPC 觸發(fā)對話”。先不要考慮用什么結構先拆需求地圖要快速判斷“某個位置能不能走”這需要二維數組或網格圖地圖很大且大部分區(qū)域是空地可以用稀疏存儲稀疏矩陣或空間劃分NPC 分布在特定點玩家靠近時觸發(fā)可以用空間哈?；蚓W格分區(qū)快速查找對話任務有一條鏈完成后解鎖下一環(huán)可以用有向圖表達任務依賴。同樣的系統(tǒng)不同規(guī)模會倒推出完全不同的結構選擇。地圖很小一個二維數組就夠了地圖特別大就要考慮分塊加載、空間索引。這就是為什么“先選結構再寫需求”會出問題——你還沒搞清楚規(guī)模邊界就先給自己上了難度。2.3 語言和工具鏈怎么選數據結構本身是語言無關的但落地時語言會有明顯影響。我的建議是如果你是為了校招或考研復習就按照你目標崗位和學校要求來如果純粹是為了把數據結構用起來優(yōu)先選你寫起來最不費勁、能立刻把想法變成代碼的語言。這里說一下不同語言在數據結構落地時的差異C 語言最貼近教科書但需要自己管理內存、手寫很多結構訓練強度大適合考研和基礎鞏固Java集合框架非常完善HashMap、ArrayList、LinkedList、TreeMap 都封裝好了適合快速搭建業(yè)務邏輯Python寫起來最快字典和列表非常靈活適合驗證思路和快速原型Go有 slice、map結構體組合方便適合寫服務端游戲邏輯。如果你用 Java 或 Go不需要每個結構都自己實現一遍但要清楚底層原理否則數據量一上去你會發(fā)現 map 的擴容、哈希沖突、遍歷順序都會變成問題。這部分后面專門講。注意開發(fā)項目時優(yōu)先用語言自帶的數據結構實現去搭業(yè)務自己手寫結構主要用來理解原理和實現定制邏輯。一上來就全部手寫項目會進展很慢。3. 實操拆解用數據結構實現一個“簡化版原神”核心系統(tǒng)下面我會拆幾個模塊每個模塊都用“需求 - 結構選擇 - 核心思路 - 驗證方式”的方式來寫。這是單機階段最值得練的幾個系統(tǒng)。3.1 地圖系統(tǒng)網格還是圖取決于你要做什么需求很簡單玩家在一個二維地圖上移動地圖有障礙物NPC 和怪物有固定位置玩家靠近后觸發(fā)交互。核心結構通常是二維數組或鄰接表圖。二維數組適合小地圖比如 100x100 網格每個格子存地形類型、是否可行走、當前是否有單位。這種結構寫起來直觀遍歷也快。地圖一旦變大比如 10000x10000直接用二維數組就可能浪費大量內存因為大部分格子是空地。這時可以改用稀疏存儲用哈希表記錄“非默認狀態(tài)的格子”比如map[coord] - terrain查詢時查不到就返回默認值。如果還要做尋路就需要在網格基礎上做廣度優(yōu)先搜索或 A*。在網格圖上做 BFS 理解起來最簡單從起點開始逐層擴展相鄰可行走格子直到找到終點。寫成偽代碼大概是from collections import deque def bfs_shortest_path(grid, start, end): rows, cols len(grid), len(grid[0]) visited set() queue deque() queue.append((start[0], start[1], [start])) visited.add(start) while queue: r, c, path queue.popleft() if (r, c) end: return path for dr, dc in [(-1,0),(1,0),(0,-1),(0,1)]: nr, nc r dr, c dc if 0 nr rows and 0 nc cols: if (nr, nc) not in visited and grid[nr][nc] ! 1: visited.add((nr, nc)) queue.append((nr, nc, path [(nr, nc)])) return None很多人在這一步會糾結“我是不是應該直接用 Dijkstra 或 A*”。我的建議是先跑通 BFS能走通之后再去研究 A* 的啟發(fā)式優(yōu)化。BFS 在小型地圖上完全夠用而且更容易驗證邏輯正確性。地圖系統(tǒng)的驗證標準很簡單給定起點和終點能不能在合理時間內找到一條可行路徑地圖上所有障礙物格是否會被正確跳過如果不存在路徑函數會不會返回空而不是死循環(huán)。3.2 背包與物品系統(tǒng)哈希表、雙向鏈表、有序數組怎么配合背包系統(tǒng)看起來簡單但很能體現數據結構組合能力。需求大概包括添加新物品、刪除物品、物品堆疊、按類型排序、按名稱查找、物品上限、丟棄和裝備操作。如果只用數組添加和刪除時移動元素成本高只用鏈表查詢特定物品時要遍歷只用哈希表又很難支持“按數量排序”或“按類別展示”。真實項目里通常會用組合結構。一個常見設計方案是“哈希表 雙向鏈表”的組合哈希表負責 O(1) 查找物品 ID 對應的物品槽位雙向鏈表維護物品的插入順序用于“最近獲得”或“最早過期”策略如果需要按攻擊力或數量排序再把檢索結果復制到臨時數組做排序展示完后丟棄。實際寫的時候關鍵點不是把結構寫出來而是確定“每個數據結構負責哪個操作”。我在做類似系統(tǒng)時一般會先列一個操作清單操作使用結構通過物品 ID 快速找到物品哈希表按獲得順序遍歷裝備雙向鏈表背包容量有限時踢出最舊物品雙向鏈表頭尾操作按價格從高到低展示臨時數組排序批量添加同一種材料哈希表計數并更新槽位如果使用 Java可以直接用HashMapInteger, ItemSlot加LinkedListItemSlot用 Python 則可以用 dict 加列表但要自己注意順序維護。不要迷信“標準庫已經實現了一切”組合邏輯仍然需要你自己設計。驗證背包系統(tǒng)是否正常的標準連續(xù)添加大量物品后查詢是否仍然流暢刪除中間物品后其他物品是否正常背包滿時新物品能否按策略被拒絕或替換按不同字段排序后結果是否正確。3.3 任務系統(tǒng)圖決定依賴隊列決定執(zhí)行順序任務系統(tǒng)是很多人忽略但非常值得練的模塊。它的核心不是“任務列表”而是任務之間的依賴關系。比如“先找到 NPC A才能領取任務 B完成任務 B 后解鎖任務 C”這就是一張有向無環(huán)圖。每種任務狀態(tài)可以用狀態(tài)機表達比如“未接取 - 進行中 - 可提交 - 已完成 - 已關閉”。狀態(tài)變化由事件觸發(fā)而多個事件之間可能有先后順序。設計這類系統(tǒng)時常見做法是先定義任務節(jié)點每個節(jié)點包含前置任務列表和后續(xù)任務列表然后用拓撲排序判斷整個任務鏈是否合法。如果你發(fā)現任務之間有循環(huán)依賴拓撲排序會檢測不出來這時必須檢查設計圖。def can_complete(task_id, completed, dependencies): if task_id in completed: return True for dep in dependencies.get(task_id, []): if dep not in completed: return False return True任務隊列負責“當前可以觸發(fā)的任務有哪些”。當玩家完成一個任務后把它的所有后續(xù)節(jié)點加入候選池再由邏輯決定是否直接觸發(fā)。這個“候選池”用隊列或優(yōu)先隊列都可以如果某些任務需要玩家等級滿足條件建議用優(yōu)先隊列按等級排序。驗證任務系統(tǒng)是否正常的標準一個任務完成后后續(xù)任務是否能正確解鎖玩家提前觸發(fā)未解鎖任務時能否被攔截任務鏈出現分支時是否每個分支都能獨立完成會不會出現因為循環(huán)依賴導致任務邏輯卡死。3.4 戰(zhàn)斗目標選擇優(yōu)先隊列和堆不是花架子戰(zhàn)斗系統(tǒng)的數據結構體現比較隱蔽但非常重要。比如你釋放一個技能目標是“范圍內血量最低的三個敵人”或者“距離最近的五個敵人”你需要快速從幾百個單位中篩選出目標。最直接的辦法是遍歷所有敵人計算距離或讀取血量然后排序取前 N 個。但如果一幀內有多個技能需要計算而且單位數量很多排序的耗時可能成為瓶頸。更合理的方式是使用最小堆或最大堆。取“血量最低的三個敵人”可以用大小為 3 的最大堆先放入前 3 個單位之后每個新單位如果血量小于堆頂就替換堆頂保證堆頂始終是當前候選中血量最大的那個這樣最終堆里剩下的就是血量最小的 3 個。優(yōu)先隊列除了目標選擇還可以用于技能冷卻管理和 Buff 刷新。Buff 需要按到期時間先后觸發(fā)可以用最小堆存“下一個到期 Buff”每次只需要看堆頂是否到期而不必遍歷所有 Buff。驗證戰(zhàn)斗系統(tǒng)的標準單位數量從 10 增加到 1000 時篩選耗時是否還能接受技能頻繁釋放時是否存在明顯卡頓多個技能同時計算目標時結果是否和預期一致用堆優(yōu)化后處理時間是否明顯下降。注意不要一開始就優(yōu)化。先把邏輯寫對再用日志輸出幾個關鍵點最后確認能跑、結果正確再考慮用堆替代排序。過早優(yōu)化最容易把系統(tǒng)寫亂。4. 單機跑通之后如何擴展到服務端架構4.1 單機原型和線上系統(tǒng)的差別在哪里很多項目在單機環(huán)境下能跑一旦模擬多人在線就立刻崩原因不是代碼寫得差而是設計時沒有考慮“多客戶端共享狀態(tài)”。單機游戲可以只有一個全局數組保存所有怪物位置但多人服務端不能這樣每個玩家客戶端都可能在修改同一個狀態(tài)同時請求可能并發(fā)到達。從單機轉向服務端第一步不是引入復雜的微服務而是先把“狀態(tài)存儲”和“邏輯處理”分層邏輯層只負責調用接口不直接修改全局變量狀態(tài)層統(tǒng)一管理地圖、背包、任務等數據接口層定義輸入輸出把客戶端請求轉換成數據操作。這樣做的好處是即使你只是從單機版改成兩個客戶端連同一個服務端也不會因為互相踩踏導致狀態(tài)混亂。4.2 選擇內存存儲還是引入 Redis數據結構在服務端最常見的體現之一就是緩存和存儲結構選擇。單機時你可能直接用 Python 字典存玩家在線狀態(tài)但在多人場景下需要把公共數據放進統(tǒng)一存儲。Redis 有兩種結構非常適合游戲場景List 和 ZSet。List 適合做消息順序存儲比如強制公告、聊天消息、任務動態(tài)。ZSet 適合做排行榜、等級排序、按分數篩選玩家。不只是原神很多游戲服務端都有類似的排行榜需求用 ZSet 可以做到按分數范圍快速取數據也能按排名區(qū)間取。不過我不建議在一開始就直接引入 Redis。如果只是本地跑兩個人的簡化版用 Go 的 map 加鎖就足夠。等明確出現“多進程共享狀態(tài)”或“需要重啟不丟數據”的需求再引入外部存儲。4.3 并發(fā)訪問下的數據結構安全問題如果你用 Go 或 Java 寫服務端并發(fā)的核心問題是“多個協程同時讀寫同一個結構”。最直接的方式是加鎖但鎖粒度太大會拖慢性能。一個比較穩(wěn)妥的優(yōu)化思路是“把大結構拆成多個小結構”。比如玩家背包可以先按玩家 ID 拆分成獨立的背包實例不同玩家的背包操作天然不沖突同一個玩家背包內部再用一個鎖保護。這樣全局鎖就變成了細粒度鎖沖突概率大幅下降。如果是排行榜這種全局熱點結構只加鎖會導致所有寫操作排隊這時可以考慮引入分片比如按玩家 ID 取模拆成多個小 ZSet最后合并排序。這個方案在數據規(guī)?？煽貢r比較實用數據量特別大時就需要更專業(yè)的存儲方案。單機轉服務端的驗證標準兩個客戶端同時操作同一個玩家背包數據是否一致多個玩家同時提交排行榜分數最終排序是否正確重啟服務端后哪些數據會丟失哪些需要從外部存儲恢復。5. 常見問題排查為什么你的項目總是越寫越亂5.1 啟動失敗先看依賴和版本而不是改代碼很多新手遇到報錯第一反應是“我的邏輯哪里寫錯了”但實際排查時高概率問題出在語言環(huán)境版本不匹配依賴庫沒有安裝或版本沖突文件路徑包含中文或空格導致讀取失敗端口被占用服務起不來編譯器或解釋器版本太老不支持新語法。排查順序應該是先看完整報錯信息再看當前環(huán)境版本再看輸入路徑和權限最后才檢查代碼邏輯。很多看起來像代碼錯誤的報錯其實和數據結構一點關系都沒有。我見過最典型的一個例子A* 尋路明明在本地測試正常部署到服務器后卻一直找不到路徑。最后發(fā)現是地圖配置文件換行符不同解析后多了一個不可見字符導致所有坐標判斷全部偏移。這種問題用代碼審查很難發(fā)現必須靠輸出日志比對輸入數據。5.2 輸出結果不對用“最小復現”定位問題如果程序能運行但輸出不正確不要直接改算法先做一個最小復現用例。比如你寫了一個背包排序功能正確結果是按數量降序但輸出順序混亂。這時把物品列表固定成三條已知數據打印排序前后的數組確認排序比較函數是否寫對。如果最小用例結果正確再逐漸加入真實數據直到找到觸發(fā)錯誤的那一條。這個排查過程能幫你區(qū)分“數據問題”還是“邏輯問題”。很多時候問題并不在數據結構本身而在比較函數、邊界條件或輸入數據異常。5.3 性能問題優(yōu)先看“復雜度高的熱點路徑”程序能跑但很卡很多人的第一反應是“換一個更高級的數據結構”。但更可靠的做法是先確認瓶頸在哪里。你可以先打日志記錄每個函數耗時找出最耗時的操作。如果耗時主要在“查找某個玩家的背包”再考慮用哈希表替代數組遍歷如果耗時在“排序整個排行榜”再考慮是否可以用堆或 ZSet。不要因為覺得紅黑樹很厲害就把所有代碼全部重寫成紅黑樹。還有一個常見坑是“在循環(huán)里做重復查詢”。比如在戰(zhàn)斗循環(huán)里每次都用for遍歷所有敵人來篩目標即使換成堆但如果調用頻率過高依然會消耗大量時間。這時要考慮“緩存”而不是“換結構”每隔一段時間或狀態(tài)變化時才重新計算一次目標集合。排查性能問題時還應該關注數據規(guī)模。如果只有 100 個敵人數組遍歷完全沒問題有 10000 個敵人時才需要考慮空間索引或堆優(yōu)化。數據規(guī)模沒有達到閾值優(yōu)化就只是增加復雜度。5.4 項目“寫不下去”多半是模塊邊界不清寫項目時最常見的心理崩潰點是“改一個功能另一個功能莫名其妙壞了”。這往往是模塊之間直接修改了對方的數據結構。比如任務系統(tǒng)直接讀取背包內部數組來檢查物品是否滿足條件一旦背包結構從數組改成哈希表任務系統(tǒng)就崩了。更妥善的方式是每個模塊只通過“接口”暴露能力。任務系統(tǒng)想知道玩家有沒有某件物品不應該直接讀取背包數組而是調用backpack.hasItem(itemId)方法。這樣背包內部從數組改成哈希表任務系統(tǒng)不用改任何代碼。這個思路在學數據結構時很容易被忽略但它是項目能不能持續(xù)演變的關鍵。數據結構解決的是“怎么存、怎么查”模塊接口解決的是“誰能碰、誰不能碰”。兩者配合項目才不至于寫成一個大泥球。6. 從入門到項目落地還要補哪些東西6.1 學完基礎結構后最少還要掌握這些擴展結構如果你的目標是從“會做課后題”升級到“能做項目”光靠課本里的基礎結構不太夠。我建議按項目需要逐步補字典樹自動補全、敏感詞過濾并查集連通性判斷練任務和地圖都很有用跳表替代有序鏈表適合排行榜LRU 緩存Redis 和各類系統(tǒng)里都很常用布隆過濾器判斷“可能不存在”的高效結構適合反作弊、預過濾場景線段樹或樹狀數組區(qū)間查詢和區(qū)間更新。不用一次全部學完。當你做項目時發(fā)現“普通哈希表解決不了范圍查詢”再去學樹狀數組這樣學得最快印象也最深。6.2 課程資料怎么用更高效熱搜詞里經常出現嚴蔚敏、王道數據結構、數據結構考研這些關鍵詞。如果你是學完基礎但還沒做項目資料使用策略要換一下嚴蔚敏的教材適合當字典和參考書不推薦從頭到尾當作項目指導王道數據結構適合考試復習和考研不適合直接用來學項目實踐LeetCode 和各類 OJ 適合訓練單一結構的應用但做完題目后一定要自己動手搭建項目否則知識不會自動變成能力。我比較建議的做法是“倒著用資料”先定項目再看資料里哪個結構能解決問題最后回來查實現細節(jié)。比如實現地圖尋路時需要復習圖遍歷就去查廣度優(yōu)先搜索和 A* 的實現遇到排行榜需求就去查跳表和優(yōu)先隊列。6.3 從項目回到算法形成正循環(huán)有一種常見誤區(qū)先把所有算法學完再開始做項目。實際上你永遠學不完而且很多算法如果不用很快就會忘。更好的節(jié)奏是“項目驅動學習”做一個簡化版原神需要地圖就往圖結構深入需要背包就往哈希表和鏈表深入需要任務依賴就往有向圖深入需要排行榜就往跳表和優(yōu)先隊列深入。每深入一個方向你就補齊一塊知識同時項目本身能立刻反饋“這個結構到底好不好用”。做完一個小型項目后再回頭做算法題你會發(fā)現理解深度完全不同。你不再只是死記“哈希表查找是 O(1)”而是知道“哈希表擴容會造成短暫卡頓所以批量插入時要預留空間”你不再只是背“BFS 能找到最短路徑”而是知道“在稀疏大地圖上 BFS 可能訪問太多無效節(jié)點所以要用 A* 的啟發(fā)式減少搜索范圍”。6.4 少踩這五個坑項目成功率會高很多最后把我自己踩過、也看別人踩過的坑整理一下第一個坑項目目標過大一上來就要做完整“原神”。正確做法是先做一個最簡單的版本能跑通再迭代。第二個坑不寫日志。程序出錯時只能靠猜浪費時間。至少要在關鍵流程入口、狀態(tài)變更、錯誤分支加日志輸出。第三個坑不注意輸入數據規(guī)范。地圖坐標、物品 ID、任務 ID 一定要統(tǒng)一格式否則后期所有結構都會因為邊界問題出 bug。第四個坑結構選型脫離數據規(guī)模。10 個物品用哈希表和數組差別不大100 萬個物品就必須認真選結構。第五個坑只看教程不自己動手?？匆话賯€視頻不如動手實現一個背包系統(tǒng)親身踩一次哈希沖突和擴容機制。做項目的過程其實就是把“數據結構知識”從課本里搬進真實代碼的過程。這個過程會有點悶需要反復調試但只要你把一個完整的小型系統(tǒng)從零搭起來你對數據結構的理解就會上一個臺階。到那個時候再回頭看“數據結構入門了能不能開發(fā)原神”這個問題你就不會糾結于“能不能”而是會自然地想我該先拆哪個系統(tǒng)、用哪些結構、怎么驗證每一步是否正確。這種能力才是比“學完一門課”更接近工程實踐的東西。