pycharm 报 recursionerror 通常源于真实递归而非假死，主因是调试环境额外调用 str__/__repr 等方法或运行配置差异；应通过 debug 的 frames 面板定位重复函数，检查终止条件、改用显式栈或加深度限制，而非盲目调大 recursion limit。
PyCharm 运行时抛出 RecursionError: maximum recursion depth exceeded，说明你的代码真正在递归，不是 IDE 假死或卡顿——别急着调大限制，先确认是不是逻辑问题。
PyCharm 2026.2是 JetBrains PyCharm 的指定版本安装包，下载地址指向官方 Windows 安装包直链，可用于旧项目兼容、版本回退和环境测试。
为什么 PyCharm 里跑就报错，命令行却没事？
这通常不是 PyCharm 的锅，而是运行环境差异导致的：
- PyCharm 默认用项目配置的 Python 解释器，但可能启用了 pytest、doctest 或科学模式（Scientific Mode），这些会额外包装函数调用，悄悄增加一层栈帧
- 如果你在 PyCharm 的 Run Configuration 中勾选了 Emulate terminal in output console，某些输入/输出重定向逻辑也可能引入隐式递归（比如自定义 __repr__ 被日志模块反复触发）
- 更隐蔽的是：PyCharm 的变量监视（Variables pane）会在调试时自动调用对象的 __str__ 或 __repr__ ——如果这两个方法里有递归逻辑，就会在你点开变量时突然爆栈
怎么快速定位是哪一层递归崩的？
别靠猜。在 PyCharm 的 Run → Debug 模式下复现错误，停在报错位置后：
- 看右下角 Frames 面板，从底往上数，找最早重复出现的函数名（比如 parse_node 出现了 1023 次）
- 右键该帧 → Jump to Source，直接跳到对应代码行
- 检查该函数是否漏写了递归终止条件，或终止条件永远无法满足（例如 if n == 0，但传入的是负数）
- 特别注意：Python 的 == 比较在自定义类中可能触发 __eq__，而 __eq__ 又调用了自身字段的比较，形成隐式递归链
临时绕过但不推荐的操作
仅用于验证是否为纯深度问题（比如树遍历 10 万层）：
- 在代码最开头加：import sys; sys.setrecursionlimit(15000)
- 但要注意：Windows 下实际能撑住的层数远低于设置值（知识库实测设 100000 也只到约 3220 层），因为 OS 会主动截断防止栈溢出
- 更危险的是：PyCharm 的调试器本身对栈更敏感，有时即使命令行能跑，调试器也会提前报错 —— 此时强行提限反而掩盖真实问题
真正该做的三件事
- 把递归改写成显式栈（list + while 循环），尤其适合树/图遍历场景
- 如果必须递归，加深度计数参数并主动抛异常：def f(data, depth=0): if depth > 100: raise RuntimeError("Too deep")
- 检查所有被 PyCharm 自动调用的方法：__str__、__repr__、__eq__、__hash__，确保它们不依赖自身结构做无限展开
递归深度报错从来不是“调大就行”的配置问题，而是代码里藏着没被发现的循环引用、状态未收敛或调试器误触的信号。盯着 Frames 面板看十秒，比盲目改 setrecursionlimit 有用十倍。
