C的遞迴太難理解了，誰能詳細解釋一下？

簡而言之，遞迴是指應用程式呼叫自身來查詢和訪問分層資料結構。 使用遞迴可以使**更加簡潔明瞭，可讀性更強（不一定適合初學者），但是因為遞迴需要系統棧，所以空間消耗比非遞迴要大得多，如果遞迴深度太大，系統資源可能不夠用。

通常有一種觀點認為，遞迴可以在沒有遞迴的情況下使用，遞迴可以用迭代代替。

誠然，從理論上講，遞迴和迭代在時間複雜度上是等價的（不考慮函式呼叫的開銷和函式呼叫產生的堆疊開銷），但在實踐中，遞迴確實不如迭代效率高。

萬物的存在都需要時間的檢驗，遞迴沒有被歷史掩埋，也就是說，存在是有原因的。 從理論上講，所有遞迴函式都可以轉換為迭代函式，反之亦然，但成本通常很高。 但是，從演算法結構的角度來看，遞迴宣告的結構不可能總是轉化為迭代結構，因為結構本身的擴充套件屬於遞迴的概念，在設計的早期階段根本無法通過迭代方法實現，就像動態多型的東西不能總是用靜態多型來實現一樣。

這也是為什麼在結構設計中，通常使用遞迴方法代替迭代方法的原因，乙個非常典型的例子是類似於鍊表，遞迴定義的使用非常簡單，但是對於記憶體定義（陣列模式）它的定義和呼叫處理指令變得非常晦澀難懂，尤其是在遇到迴圈等問題時， 圖形、網格等，從描述到實現的迭代方法的使用變得不切實際。因此，實際上，所有迭代都可以轉換為遞迴，但遞迴不一定可以轉換為迭代。

採用遞迴演算法的前提是，當且僅存在預期的收斂時，才能使用遞迴演算法，否則就不能使用遞迴演算法。

遞迴其實對程式設計師來說很方便，遞迴可以很容易地通過數學公式轉換成程式。 優點是易於理解和程式設計。 但是遞迴是通過堆疊機制實現的，每一層都要更深，要占用乙個堆疊資料區，而對於一些巢狀層很深的演算法來說，遞迴會無能為力，最終會在記憶體空間上崩潰，而遞迴也帶來了大量的函式呼叫，這也有很多額外的時間開銷。

所以當深度大時，它的時空性質不好。

雖然迭代效率高，執行時間只是因為迴圈次數的增加而增加，沒有額外的開銷，也沒有空間的增加，但缺點是不容易理解，寫複雜的問題也很困難。

因此，Enoch 不同意“如果能用遞迴，就不需要遞迴，遞迴可以用迭代代替”的理解，Enoch 不敢同意，或者辯證地看，不能一棍子打死。

資源。 blog/cns!9cf795352e94bf70!

多讀書，多寫程式。