在SQL存储过程中可直接使用递归CTE，但需置于SELECT/INSERT/UPDATE语句开头，显式设置OPTION(MAXRECURSION n)，严格过滤锚点与递归条件防环，并通过临时表复用结果。
在 SQL 存储过程中直接写递归 CTE 是完全可行的，但必须注意语法位置、作用域限制和递归安全边界——否则容易触发 MAXRECURSION 错误或无限循环。
存储过程里写递归CTE的正确位置
递归 CTE 必须作为存储过程主体中某个独立语句的一部分，不能放在变量赋值、IF 分支内部（除非整个分支是完整查询），也不能嵌套在函数调用里。最稳妥的方式是把它放在 SELECT、INSERT 或 UPDATE 语句开头，紧接 WITH 关键字。
-
WITH必须是语句的第一个词；如果前面有注释或SET，需换行并确保无空格干扰 - 不能把递归 CTE 定义在
DECLARE后、但未进入实际执行逻辑的位置——它不会被“声明”，只在首次引用时编译 - 若想复用结果，可将递归 CTE 的输出
INSERT INTO #temp，再在后续逻辑中查临时表
递归CTE在存储过程中必须显式设MAXRECURSION
SQL Server 默认递归深度上限是 100 层，而生产环境的组织架构或 BOM 层级常超此限。不加控制时，一旦超过就直接报错：The statement terminated. The maximum recursion 100 has been exhausted before statement completion.
- 必须在最终
SELECT或INSERT语句末尾加OPTION (MAXRECURSION n)，例如OPTION (MAXRECURSION 32767) -
MAXRECURSION 0表示无限制，但极不推荐——失控递归会拖垮会话甚至实例 - 该
OPTION只对当前语句生效，不能在 CTE 定义里写，也不能跨语句继承
避免父/子ID相同导致的无限循环
这是递归 CTE 最隐蔽也最常踩的坑：当递归成员返回的子节点 ID 和当前父节点 ID 一致（比如数据脏、自关联未过滤、或层级字段为空），就会原地打转。
- 定位点成员（anchor）必须严格筛选出顶层节点，例如
WHERE ManagerID IS NULL或Level = 0 - 递归成员中，必须确保 JOIN 条件能推进层级，典型写法是
ON e.ManagerID = cte.EmployeeID，而非反向 - 建议在递归成员里加
WHERE e.EmployeeID != cte.EmployeeID做兜底防呆（尤其面对不可信源数据） - 调试时可在递归 CTE 中加入
LEVEL INT列并用LEVEL + 1计数，方便观察是否卡在某一层
CTE不能跨多条语句复用，但可配合临时表解耦
一个常见误解是：定义一次 CTE，后面几个 SELECT 都能用。实际上，CTE 生命周期仅限于紧随其后的那一条语句。
- 如果存储过程需要多次查同一份递归结果（比如先统计人数、再拉明细、再算汇总），必须用
SELECT ... INTO #hierarchy落到本地临时表 - 不要用表变量
@t替代——它不支持SELECT INTO，且无法被后续语句中的 CTE 引用 - 临时表记得加索引（如
CREATE CLUSTERED INDEX IX ON #hierarchy(EmployeeID)），否则深层递归后性能断崖下跌
真正麻烦的不是语法，而是递归路径是否收敛——哪怕 CTE 写得完全合规，只要底层数据存在环状引用（A→B→C→A），MAXRECURSION 就只是延缓报错时间。上线前务必用真实数据做环检测，而不是依赖“理论上没环”。
