前几年我也迷过递归，树、分治、回溯写出来像短诗，review 时都舍不得删。后来线上吃了一回亏：夜间批处理扫目录，图省事用了递归，没料到环境里有软链成环，深度一下子不受控。监控看着像CPU满载，初查以为死循环，抓栈才发现是帧一层层堆上去，内存抖动又把延迟放大。那之后我对“优雅”两个字谨慎多了。递归不是不能用，前提是深度有硬上界、终止条件够笨够明显、重复子问题有缓存；否则就老实显式栈或迭代。尾调用优化更值得商榷，能当加分项，不能当跨平台承诺书。测试也别只跑小样例，把最大深度、异常输入、环结构都摆上桌子。你们现在写递归，会先估深度阈值，还是默认能迭代就不递归？

软链成环这个坑，本质上是把“信任外部输入”和“控制执行深度”混为一谈了。其实

你提到“递归不是不能用，前提是深度有硬上界”，从某种角度看这个结论没问题，但值得商榷的是：文件系统遍历这类场景，深度上界本来就不该由调用栈的物理容量来兜底，而应该由业务逻辑自己画红线。POSIX标准里的 nftw() 函数在接口设计上就显式要求传入一个 maxdepth 参数，这其实是个很清晰的工程共识——当递归对象的拓扑结构不受你控制时，终止条件必须是前置的、外部的，而不是指望数据本身恰好能触发 base case。

尾调用优化那部分我比较认同你的谨慎。补充一个具体数据：V8引擎早在2017年的 v6.2 版本里就把ES6规范的TCO支持回滚移除了，原因之一是它会破坏 Error.stack 的完整性，导致线上调试丢失关键帧信息。Node.js至今也没加回来。所以在JavaScript生态里拿TCO当生产方案的，基本属于拿未兑现的支票去结账。

至于你最后问的习惯，我的做法是区分场景。如果处理的是语法树解析这种结构自洽、深度可预测的数据，递归写起来直观，就用；但凡涉及图遍历或者任何可能包含环的外部数据源，一律用显式栈配合 visited 集合。靠语言运行时的栈溢出异常来做流程控制，代价太不可控了。

话说poet2002上次好像也提过一嘴类似的问题？不知道他后来那个批处理脚本改成迭代没有。

软链成环这个坑，POSIX标准里其实给过解法。nftw() 自带 FTW_PHYS flag，不跟符号链接；或者底层用 fstatat 配合 AT_SYMLINK_NOFOLLOW，手动比对 inode + dev_t 就能判环。

你总结的那三条经验很扎实。我平时写C的习惯更粗暴一点：能迭代就不递归。不是怕栈溢出，是函数调用的 overhead 在 tight loop 里积少成多挺心疼的。

深度有硬上界的场景（比如固定层级的配置解析），递归代码确实干净。但一旦边界模糊，显式栈是唯一靠谱的选择。TCO别指望，GCC 开 `

软链成环这个坑，光靠“估深度阈值”其实兜不住。更严谨的做法是遍历前用 Floyd 判圈或者干脆维护一个 visited set，把环检测当成前置条件而不是异常输入来测。C’est plus sûr.

上次和 nerd42 聊起来，他说他们组现在强制要求递归必须带显式深度计数器，超了直接抛异常，我觉得比依赖尾调用优化靠谱多了。

软链成环这个坑太经典了。其实从图论角度看，目录树遍历本质是隐式图的 DFS，不维护 visited set 就必然有环的风险——这甚至不是递归的锅，换成显式栈一样会无限 push。

想补充一点关于尾调用优化（TCO）的数据。你提到“不能当跨平台承诺书”，非常准确。目前主流环境里，除了 Scheme/Racket 这类语言在规范层面强制要求 proper tail calls，绝大多数工程语言的 TCO 支持都很碎片化。V8 引擎曾经在 v6.x 短暂支持过 ES6 规范的 TCO，后来因为破坏了 stack trace 导致调试困难，又默默移除了。GCC/Clang 在 -O2 以上能稳定做尾递归消除，但前提是函数签名严格匹配且没有变量地址逃逸。

所以工程上的共识大概是：如果递归深度上界能用 O(1) 级别的数学推导证明（比如平衡二叉树的 log₂N），放心写；如果上界取决于外部输入或文件系统拓扑，老老实实迭代加 visited。

软链成环这个坑，我年轻的时候也踩过。那时候还在写C，扫文件系统图省事直接递归，结果跑着跑着机器没响应了。查了半天不是死循环，是栈帧把内存吃光了。当时看着core dump文件，心里就一个念头：Che disastro.

从那以后我对递归的态度就变了。话不能这么说代码写得像短诗当然好，但线上环境不看诗，只看数字。深度有没有硬上界，这是底线。没有底线的优雅就是定时炸弹。

你提的尾调用优化我也持保留意见。这东西在标准里是一回事，编译器实际怎么处理又是另一回事。跨平台指望它，跟指望所有人都会按规矩出牌差不多。

现在动手之前我一般先问自己一句：这棵树到底有多深？答不上来的，老老实实开显式栈。这事不急，慢慢养成习惯就好。

默认迭代…，稳。递归那点漂亮真不值得拿线上去赌，深度一失控就完蛋，冲就完事。

你那句"对优雅谨慎多了"，我挺有共鸣的。年轻的时候我也特别吃这一套，干净、对称、一眼能看透，总觉得那样的东西才是对的。后来经历多了才慢慢醒过来，好看和扛造，常常是两码事。
话说回来
说回递归，你讲的硬上界、笨终止条件，我外行看着都觉得是实在话。很多麻烦不是逻辑本身错了，是我们默认环境是乖的：目录乖、输入乖、调用方也乖，一旦哪个角落绕出一个环，漂亮结构说塌就塌。所以你把最大深度、异常输入、环结构都摆上桌子测，这比任何优雅都管用。

尾调用那句我想补一句，跨平台本来就不该指望编译器替你打包票。能优化是运气，不能才是常态，写的时候别把宝全压上去，反而省心。

软链成环这个坑，本质上是把“图”当“树”来遍历了。严格来说递归本身没毛病，但数据结构一旦有环，终止条件再怎么写都兜不住，除非你额外维护一个visited集合——可这就又引入了空间开销，优雅感直接打折。
嗯
其实关于尾调用优化（TCO），你提到不能当跨平台承诺书，这一点我完全同意。补充一个具体数据：ES6标准里明确规定了TCO，但截至2024年，主流引擎里只有Safari的JavaScriptCore真正实现了，V8和SpiderMonkey至今挂起。当年V8团队试过，发现TCO会破坏错误堆栈信息，导致debug极其痛苦，最后放弃了。所以指望编译器帮你收尾，在JS生态里基本是赌博。嗯

我现在写这类逻辑，习惯先问一句：深度上界能用数学证明吗？能，就递归；不能，显式栈加深度计数器。你们那边批处理现在改用什么方案了？