維護多個項目的人，大概都明白那種感覺。
平時一切都很平靜，直到某天，甲方的一句“系統是不是出問題了？”
這時候才發現，問題早就埋在那裏了。
你登錄服務器，開始翻日誌、看 trace，一邊調試一邊回想昨天是不是又改了什麼。問題最終解決了，但那種被動的感覺始終在心裏。
我後來想：
這種被動，其實是可以被解決的。
有沒有可能在客户找上門之前，我就已經知道問題在哪，甚至提前修掉？
為什麼我需要它
我手裏有不少 PHP 項目，分散在不同的服務器上。
每個項目都有自己的錯誤日誌，但它們互相獨立，沒人能統一看到全局情況。
想主動檢查，就得一台一台地上服務器翻日誌。
沒出事的時候翻這些日誌浪費時間，但不看又怕真的出了問題。
結果就是那種尷尬的狀態：
平時不想看，有事的時候措手不及。
我不想再這樣。
我希望有一個地方，能讓我一眼看到所有項目的錯誤，集中展示、集中分析。
我想要的樣子
我設想的工具應該能做到幾件事：
- 接收所有項目上報的錯誤信息；
- 按日期分類保存，支持分頁瀏覽；
- 可以在瀏覽器中直接看到最近的錯誤；
- 最好還能借助 AI 自動分析錯誤，幫我快速鎖定方向。
這就是 oh-shit-logger 的雛形。
為什麼用 Go，而不是 PHP
很多人看到這個項目時會問：
“你不是做 PHP 的？為什麼用 Go 寫？”
其實原因很簡單：我想讓它“隨拿隨用”。
PHP 雖然寫起來快，但部署環境太麻煩。
不管再怎麼簡化，總歸還是要安裝 PHP 環境
而 Go 編譯出來是一個獨立的可執行文件，
上傳到服務器就能跑，不用依賴環境，也不用額外配置。
這對我來説非常重要。
我只想有個小程序，能輕輕鬆鬆丟到任何服務器上運行，
收集日誌、展示信息，不佔資源，也不出幺蛾子。
所以最終我選擇了 Go。
它現在能做什麼
oh-shit-logger 可以在幾秒鐘內啓動。
在 Releases 裏下載編譯好的版本，上傳到服務器後執行：
chmod +x ./app
./app -port=9999 -retain=7 -user=admin -pass=123123然後訪問
http://你的服務器IP:端口號/read
就能看到所有 PHP 項目的錯誤日誌。
PHP 項目上報也很簡單，只需要在異常處理中添加一段上報邏輯：
curl_setopt($ch, CURLOPT_URL, 'http://你的服務器IP:端口號/write');錯誤信息會被自動收集、格式化、展示，並且可以通過接入的 DeepSeek AI 自動生成分析結果，告訴你錯誤可能的原因和修復方向。
AI 的部分
我接入 DeepSeek，不是為了給項目貼個“AI標籤”。
關於 AI，網上的討論很多。
有人相信它能解決一切，甚至不用寫一行代碼就能做出完整項目；
也有人覺得 AI 看似幫忙，實際上是在暗地裏埋雷；
還有人擔心長期依賴它，會讓個人的思考和判斷慢慢退化。
我這種小卡拉米肯定是參與不了這種宏大的爭論。
對我來説，AI 的上下文長度就擺在那裏，它要是承擔太多工作，難免會丟掉一些細節，而且隨着任務量的增加記憶只會越丟越多
所以我更願意把它當成一個“輔助”，就像現在的智能駕駛。
它可以給我建議，幫我節省時間，但不要直接動我的東西，最終的決定權還是在我。
有時候我們看到錯誤信息，稍微一想就知道大概出了什麼問題；
但也總有那麼些時刻，比如正在開會、接電話、或者狀態不太好時，
AI 能幫我快速過一遍問題，給出大致的方向。
這樣我可以少花點心力，留點精力去解決真正麻煩的部分。
最後的想法
我做這個項目，其實是為了解決自己的一種焦慮。
那種“系統運行着，但我不知道它哪天會出事”的焦慮。
oh-shit-logger 讓我重新掌握了節奏。
現在我不再等客户來告訴我哪裏壞了，
我能提前看到問題、分析它、修掉它。
這就是它存在的意義。
項目地址
GitHub: https://github.com/zxc7563598/oh-shit-logger
如果這個項目能幫到你，歡迎點個 Star 或提 Issue。
當然他最好幫不到你，希望你部署之後每天面對的都是一個無數據的空列表 🙏
