python程序進(jìn)程掛掉？

你的問題太模糊了。我先從常見的錯(cuò)誤說，然后再從相對從大的方面來描述。

進(jìn)程掛掉可能是什么原因？

一方面是程序可能有邏輯錯(cuò)誤，導(dǎo)致了諸如下標(biāo)越界，數(shù)據(jù)異常等問題。

另一方面，可能是系統(tǒng)原因，比如代碼質(zhì)量一般，系統(tǒng)資源消耗厲害，進(jìn)程退出。

還有可能是上下游服務(wù)問題，比如 MySQL 等服務(wù)異常，上游 API 異常，配置錯(cuò)誤。

簡單說了下各種可能的異常，但對一個(gè)項(xiàng)目而言，天下問題千千萬，不可能有一條完美的準(zhǔn)則。

遇到問題，通常要從幾步出發(fā)，從排查出錯(cuò)原因、尋找解決方案和如何預(yù)防出發(fā)。

排查錯(cuò)誤的原因，這是最重要的一步，只有對癥下藥才能解決問題。

首先確認(rèn)下是否容易復(fù)現(xiàn)的問題，容易復(fù)現(xiàn)的話，通常會給出錯(cuò)誤信息。然后，我們只要在開發(fā)時(shí)調(diào)試下就好了，常見的調(diào)試方法有 print 打印來觀察問題，或者是使用一些 debug 調(diào)試工具，我相信你會用。print 的特點(diǎn)是簡單好用，但每次都有修改代碼，比較繁瑣。而調(diào)試工具就比較方便，看的信息會比較全，一些 IDE 都集成了調(diào)試工具。

對于不容易復(fù)現(xiàn)的問題，可以通過記錄日志的方式排查。有人會說，記錄日志是資源消耗，曾經(jīng)我也怎么想過。但對于現(xiàn)在的硬件配置而已，記錄日志的成本是非常小的，一個(gè)好像的項(xiàng)目肯定是集成日志的，不然就太 low 逼了，我可不敢用。

尋找解決方案，這一步需要基于前面診斷出的結(jié)果進(jìn)行排查。

一個(gè)簡單的案例。比如，提示 MySQL 連接數(shù)過多，什么情況可能導(dǎo)致這個(gè)問題？是 MySQL 配置的連接數(shù)本身就很少，還是程序設(shè)計(jì)不合理導(dǎo)致連接無法正確復(fù)用，亦或是業(yè)務(wù)量真的大了，當(dāng)前最大連接數(shù)無法承受呢。每種情況的處理方式都不同。

如何預(yù)防問題，我主要想學(xué)詳細(xì)的日志，和增加一些恢復(fù)機(jī)制。

詳細(xì)的日志就不說了，異常要記得捕獲，并且記錄發(fā)生異常的原因，這一步對排查問題非常有幫助。

另外，不是所有的異常都應(yīng)該立刻退出進(jìn)程，如果不是一些非常嚴(yán)重的錯(cuò)誤，通過日志提示下，程序還可以繼續(xù)工作。不過，有些異常還是要做一些修復(fù)處理，比如數(shù)據(jù)庫連接斷開，可嘗試重新連接，上游系統(tǒng)服務(wù)異常，可以執(zhí)行多次調(diào)用，而不是直接退出。

就簡單說這么多吧！如果有些地方講的不是很好，見諒。歡迎評論補(bǔ)充，謝謝！