CSV作為數據驅動方式，說起來真是個讓人又愛又恨的存在。就拿這個「吃瓜」視頻平台來說，開發者選擇用 videos.csv 而不是資料庫，乍看之下確實方便——Excel 打開就能編輯，後台上傳直接覆蓋，連技術門檻都低了不少。但實際用下來，你會發現這種「輕量」背後藏著不少取捨，而且每個取捨都像在走鋼索，一邊是便利，另一邊是隱憂。
CSV 的優點：簡單到讓人上癮
先講優點，CSV 最迷人的地方就是「零學習成本」。不需要安裝 MySQL、不用懂 SQL 語法，就算是不熟悉技術的內容維護者，只要會用 Excel 或 Google Sheets，就能輕鬆增刪影片連結、更新分類標籤。再看這個平台的設計，它甚至做了一套上傳管理頁面，檔案只要小於 5MB、格式正確，拖進去就能自動解析，舊檔還會被備份到 data/ 目錄，這對小型站長來說真的非常友善。
另外，CSV 的結構天生適合「可讀性優先」的場景。每行一筆資料，欄位名稱清清楚楚，比 JSON 更容易被人眼快速掃描。尤其當影片數量還在一兩千筆以內時，CSV 的讀取速度幾乎感覺不到延遲，再加上一層文件快取，其實很夠用了。而且，原始碼裡還做了編碼自動判斷，連 GBK 和 GB2312 都能處理，實在是用心良苦——這就免去了檔案編碼搞混時的亂碼惡夢。
但缺點也真實存在，尤其當規模變大
當影片數量越來越多的時候，CSV 的「力不從心」就會慢慢浮現。想想看，這個平台需要支援分類篩選、關鍵詞搜索、四種排序方式，如果影片量超過一萬筆，每次用戶操作都要把整份 CSV 讀進記憶體，PHP 腳本光是在處理陣列就可能卡頓，更別說那串寫得有點粗糙的瀑布流卡面動畫。沒有資料庫的索引機制，搜索完全靠迴圈比對，這恐怕只能算「能用」，離「高效」還差一大截。
還有一個痛點是「類別異動」的麻煩。在 CSV 裡想改一個分類名稱？你得打開檔案，搜尋全部該分類的記錄，逐一取代，要是哪個欄位裡多了個逗號或換行，解析就炸了。我知道這平台的程式有做域名白名單和 URL 過濾，但 CSV 本身就缺少資料庫的約束力，沒有外鍵、沒有唯一索引，一個不小心打錯字或是欄位錯位，整批資料可能就靜默地被跳過，連警告都沒有。
個人看法：適合特定場景，但別拿去扛大型業務
我自己的經驗是，CSV 驅動很適合「個人項目」或「教學示範」，就像這個吃瓜平台一樣，它本質上比較像一個功能原型或愛好者之作。但如果未來想做會員機制、多用戶協作、或是資料分析報表，CSV 絕對撐不起來。你可別誤會，我不是要說資料庫萬歲——在這種「更新頻率低、資料量小、維護者非技術人員」的情境下，CSV 反而比 SQL 更直覺，因為它能直接用 Excel 開起來看，連後台管理介面都可以省掉一半。
但重點在於，你得認清楚它的邊界。一旦平台有了「需要頻繁寫入」的行為，例如記錄觀看次數、收藏清單、留言互動，CSV 就會變成災難——別忘了，多個用戶同時寫入同一份檔案，誰先誰後都搞不定，更別提鎖定機制。所以，如果你是準備做一個小圈子自娛自樂的影音聚合站，CSV 確實是又快又省事的選擇；但要是目標是商業化營運，還是趁早規劃資料庫遷移吧，免得將來補不完坑。
評論（6）
CSV在小專案真的滿方便的，Excel開起來就能改，不用另外學SQL
分類名稱一改就要全部搜尋取代，這個真的超麻煩，我之前改到一半檔案就壞掉
好奇問一下，如果影片量超過一萬筆，CSV讀取真的會卡頓很明顯嗎？
編碼自動判斷這個細節真的有用心，不然每次開CSV看到亂碼都想哭
我個人覺得CSV適合當作初期原型，但要上線營運還是早點換資料庫比較穩
多人同時寫入同一份CSV沒鎖定機制，這個問題在協作時真的會炸掉