使用模板生成Excel触发Xdebug无限循环错误，求排查

可能原因及排查步骤 #

• 模板解析的递归层级过深
  SheetsService处理模板标记时，若数据源是多层嵌套的数组/对象结构，解析逻辑会递归遍历每一层，当嵌套层数超过Xdebug默认的max_nesting_level=256阈值时，就会触发栈溢出错误。而GridService是直接生成单元格，不存在这种递归解析逻辑，所以不会触发问题。
  排查：临时在项目的php.ini或.user.ini中设置xdebug.max_nesting_level = 512，如果错误消失，说明是递归层级问题。此时需要简化数据源的嵌套结构，或修改SheetsService的解析逻辑以限制递归深度。

• 数据源存在循环引用
  如果$products数组/对象中存在循环引用（比如某个对象的属性指向自身，或两个对象互相引用），SheetsService解析时会不断遍历循环引用的结构，导致无限递归触发栈溢出。
  排查：用var_dump($products)或print_r($products)输出数据源，检查是否存在*RECURSION*标识。如果有，需要修正数据源，移除循环引用。

• SheetsService版本或实现差异
  当前项目使用的SheetsService版本可能和其他正常项目不同，新版本的模板解析逻辑存在递归bug，导致无限循环。
  排查：对比其他正常项目的SheetsService依赖版本（比如composer.lock中的记录），回退到相同版本测试是否解决问题。

• 模板标记解析逻辑冲突
  虽然模板写的是[products.name]，但当前项目的SheetsService可能对标记语法的解析规则特殊，误将其识别为需要递归处理的嵌套标记（而非简单的属性访问），导致重复解析触发栈溢出。
  排查：修改模板为最简单的标记（比如[test]），同时设置数据源为['test' => 'hello']，测试是否还报错。如果不报错，说明原标记的解析逻辑存在问题，需要检查模板引擎的语法规则。

• Xdebug配置局部差异
  同一电脑下，当前项目可能通过.htaccess、局部php.ini或框架配置，覆盖了全局的Xdebugmax_nesting_level值，导致栈深度阈值更低。
  排查：在代码中添加echo ini_get('xdebug.max_nesting_level');，输出当前项目的栈深度限制，和其他正常项目对比。如果数值更低，调整该配置即可。

内容的提问来源于stack exchange，提问作者Erbi Silva