為什麼要用遞迴

程式設計裡面估計最讓人摸不著頭腦的基本演算法就是遞迴了。很多時候我們看明白一個複雜的遞迴都有點費時間，尤其對模型所描述的問題概念不清的時候，想要自己設計一個遞迴那麼就更是有難度了。

很多不理解遞迴的人（今天在csdn裡面看到一個初學者的留言），總認為遞迴完全沒必要，用迴圈就可以實現，其實這是一種很膚淺的理解。因為遞迴之所以在程式中能風靡並不是因為他的迴圈，大家都知道遞迴分兩步，遞和歸，那麼可以知道遞迴對於空間效能來說，簡直就是造孽，這對於追求時空完美的人來說，簡直無法接接受，如果遞迴僅僅是迴圈，估計現在我們就看不到遞迴了。遞迴之所以現在還存在是因為遞迴可以產生無限迴圈體，也就是說有可能產生100層也可能10000層for迴圈。例如對於一個字串進行全排列，字串長度不定，那麼如果你用迴圈來實現，你會發現你根本寫不出來，這個時候就要呼叫遞迴，而且在遞迴模型裡面還可以使用分支遞迴，例如for迴圈與遞迴巢狀，或者這節列舉幾個遞迴步進表示式，每一個形成一個遞迴。

用歸納法來理解遞迴

數學都不差的我們，第一反應就是遞迴在數學上的模型是什麼。畢竟我們對於問題進行數學建模比起程式碼建模拿手多了。 （當然如果對於問題很清楚的人也可以直接簡歷遞迴模型了，運用數模做中介的是針對對於那些問題還不是很清楚的人）

自己觀察遞迴，我們會發現，遞迴的數學模型其實就是歸納法，這個在高中的數列裡面是最常用的了。回憶一下歸納法。

歸納法適用於想解決一個問題轉化為解決他的子問題，而他的子問題又變成子問題的子問題，而且我們發現這些問題其實都是一個模型，也就是說存在相同的邏輯歸納處理項。當然有一個是例外的，也就是遞迴結束的哪一個處理方法不適用於我們的歸納處理項，當然也不能適用，否則我們就無窮遞迴了。這裡又引出了一個歸納終結點以及直接求解的表示式。如果運用列表來形容歸納法就是：

• 步進表示式：問題蛻變成子問題的表示式
• 結束條件：什麼時候可以不再是用步進表示式
• 直接求解表示式：在結束條件下能夠直接計算返回值的表示式
• 邏輯歸納項：適用於一切非適用於結束條件的子問題的處理，當然上面的步進表示式其實就是包含在這裡面了。

這樣其實就結束了，遞迴也就出來了。遞迴演算法的一般形式：

最典型的就是N!演算法，這個最具有說服力。理解了遞迴的思想以及使用場景，基本就能自己設計了，當然要想和其他演算法結合起來使用，還需要不斷實踐與總結了。