1、（用于读懂递归代码）状态：总的状态 = 当前处理的事情 + 剩余的状态

比如： dfs(5) = xxxx + dfs(4)

2、（用于自己有写递归代码的意识）(这个其实是递归) 如果操作若干个对象，结果在操作某个对象的时候，诶… 这个对象成精了，它也具有向我这样的操作别人的能力了，这时候，这个成精的对象就要用递归了

3、（用于自己有写递归代码的意识）需要画出多叉树图，来穷尽出所有的方案，然后找到你需要的方案

自己怎么才能够主动的写对递归代码，而不是被动的看别人的递归代码。也就是常被吐槽的“递归代码一看就会，一写就废”

什么时候需要用到回溯，更准确的说是递归

一个规模比较大的事情，如果你操作了一部分，然后发现剩余的部分，可以在你已经操作的那一部分的基础之上，按照你相同的逻辑进行处理。并且这样可以把一整块事情给处理掉，这时，你就可以用递归了。

因此如果你在处理一件事情时，如果发现了这样的两个特点时，你就可以用递归了。 第一点：处理这件事情，是有前后铺垫的，也就是前面的操作是为后面做铺垫的，换句话说就是前面的操作是为后面打基础的。后面的所有操作都要以前面的操作为基础，为准绳。 第二点就是你前后处理的逻辑是相同的。

而每一步的时候，有多少个dfs函数呢？这就看你当前的这步操作有多少种选择。如果你当前的这步操作有4个选项可供你选择的，那当前的这一步就有4个dfs方法，如果在这个基础之上的下一步，只有2个选项可供你选择的，那就下一层就只有2个dfs方法。

其实换句话说递归其实就是 处理整个事情 = 处理一部分 + 按照相同的处理方法处理剩余的部分！这才是递归的精髓。

再写一次：

处理整件事情 = 处理一部分 + 按照相同的办法处理剩余的部分

这里的处理整件事情 ====> 就是 DFS(all)
处理一部分就是 ========> 业务代码(具体处理部分的代码)
按照相同的办法处理剩余的部分 =======> 就是 DFS(others)

比如：
DFS(10 ) = xxx + DFS(9)

总共要处理十个单位的东西 DFS（10）
我已经处理了一部分 xxxx
剩下的一部分就是 DFS（9）