用PHP構建視頻瀑布流，聽起來像個不小的工程，但實際動手後你會發現，未必需要框架和數據庫。我見過不少小型視頻聚合站，僅靠一個CSV文件就跑得很穩——這種「無數據庫」的思路，對內容更新頻率不高的站點來說，反而省掉了MySQL連接開銷和SQL注入的煩惱，維護起來意外地輕鬆。說實話，有時候最樸素的方案才是最耐用的。
數據層：CSV為什麼可能比數據庫更合適？
很多人第一反應是上MySQL，但冷靜想想：視頻總量在幾千條以內的話，用PHP的fgetcsv()逐行解析，配合文件緩存機制，讀取耗時完全可以壓到毫秒級。實測一個500行的CSV，在PHP 8.0環境下解析加上緩存命中，響應時間不到10ms，這個性能對中小站點綽綽有餘了。
不過編碼是個坑。Excel導出的CSV經常是GBK或GB2312編碼，不做自動識別轉換的話，中文標題直接變成一堆亂碼。用mb_detect_encoding()檢測再配合mb_convert_encoding()統一轉成UTF-8，幾行代碼就能搞定，但沒踩過這個坑的人很容易忽略。
瀑布流佈局的核心實現
真正讓人頭疼的是前端渲染。視頻卡片高度不一，傳統float佈局會留下大量難看的空白。目前主流做法有兩種：CSS的column-count多列佈局，或者JavaScript動態計算每張卡片的位置。前者簡單，但內容是按列填充而非按行排列，順序會亂；後者精準，代價是要監聽resize事件反覆重算。
我的建議？移動端2列、平板3列、桌面4到5列的自適應網格，用CSS Grid配合媒體查詢就能覆蓋大部分場景，再加上loading="lazy"懶加載，首屏速度能提升40%以上。卡片入場時加個簡單的漸入動畫，觀感立刻不一樣——用戶對「流暢感」的感知，往往就藏在這些小細節裡。
安全這件事，真不能省
既然涉及外部視頻源，域名白名單驗證就是底線。否則理論上任何人都能往你的站裡塞惡意視頻地址，後果不堪設想。PHP端用parse_url()提取域名，跟白名單數組比對，不在名單內的直接過濾掉。輸出標題到頁面時，記得用htmlspecialchars()轉義——XSS防護說穿了就這麼幾行代碼，但省略它的代價可能是整站被掛馬。
說到底，用PHP構建視頻瀑布流的關鍵不在技術多複雜，而在於取捨。小規模站點，CSV加文件緩存足矣；等流量真的上來了，再考慮Redis或正式數據庫也不遲。先把東西跑起來、跑穩，比一開始就追求完美架構重要得多。
評論（5）
CSV 讀取編碼那個坑真的太真實了，以前被亂碼搞死好幾次
如果視頻量增加到上萬條，用文件緩存還撐得住嗎？
CSS Grid 確實方便，現在幾乎不用 JS 計算位置了
這套方案對新手很友善，不用配置數據庫直接就能跑
懶加載對視頻站真的很重要，不然首屏太慢沒人看