北京
給一個兩GB大小的CSV文件做一次過濾求和，聽著像是十分鐘就能寫完的事情。先讀文件，按行切開，循環取值，累加。代碼不過四五行，跑個五兆樣本絲般順滑。可當直接把同樣邏輯套到真實數據上時，Node直接拋出一句JavaScript堆內存溢出，哪怕順手把--max-old-space-size改成八吉，也不過是讓它多撐幾秒再倒。這時候才顧得上去看，那幾行代碼到底在讓機器干什么。
這件事里藏著一個很容易被忽視的真相：數據體量大，不等于內存占用就得跟著水漲船高。完全可以在物理內存遠小于文件本身的情況下處理它。關鍵只有一個——永遠不要讓整個文件同時出現在內存里，而JavaScript原生的生成器函數恰好給了一條干凈的實現路徑，不必把代碼寫成回調地獄，也不需要手動維護狀態機。
先把那個會爆炸的初版攤開來看。核心無非是先同步讀文件fs.readFileSync，接著按換行符split切出一個大數組，再遍歷每一行，取出指定列轉為數字做累加。在小文件上這套邏輯無懈可擊，可問題就出在第一行，而且是兩個問題疊在一起。readFileSync會把整個文件不加保留地裝進一個巨大的緩沖區，兩GB的文件就是至少兩GB的分配。緊接著的split再把這個緩沖區拆成一整個行字符串數組。如果數據有數百萬行，等于在內存里同時駐留了幾百萬個字符串對象，每個對象都自帶堆內開銷，而且所有對象同時存活。一邊是原始文件緩沖區，一邊是完全展開的行數組，內存代價幾乎翻倍。本身已經大到快要裝不下的東西，又被加倍了一次。
為了看清這種膨脹有多離譜，可以做一個簡化實驗。拿一個結構為id、name、amount的CSV文件，填充兩百萬行，文件實際大小約四十五兆，離兩GB遠得很。用上面那套“全量加載”方案跑一遍，峰值常駐內存達到了238兆，處理一個45兆的文件就吃掉了超過五倍的內存。把這個比例等比放大，同樣結構的2GB文件當場就要向系統要超過10GB的內存，而絕大多數容器的上限根本到不了這個量級。最初那個崩潰，其實在實驗里就已經把結局寫死了。
跳出代碼本身重新想一下：做一次列求和，真的有哪一刻是需要把所有行同時捏在手里的嗎？不需要。讀一行，把數字抽出來，加到當前匯總值上，然后這行數據就可以立刻扔掉，不再回頭。在整個計算過程里，第1行和第1400行永遠不需要知道彼此的存在。內存的職責只是暫時抱住當前正在處理的那一小截字節，而不是替整個文件兜底。把這個邏輯翻譯成代碼，就是一邊讀一邊算一邊釋放，而生成器函數正好讓這種“每次只吐一行”的流式處理變得跟寫同步循環一樣自然。
這場內存爆雷說到底，是思維慣性把“讀取文件”直接等價成了“把文件全部抓進內存”，緊接著又把“按行處理”等價成了“把所有行展開成數組”。一旦打破這兩個條件反射，哪怕再大的文件也不過是一串可以邊走邊消費的字節流。Node生態里的流、迭代器、生成器，其實早就給好了這種消費方式的拼圖，所缺的，往往只是在動手寫代碼之前多問一句：我到底需要同時看見多少數據。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
