方法调用膨胀是运行时调用链在栈上的可观测痕迹，而非栈自身产生；依赖注入图（dag）描述静态构造依赖，调用栈图反映动态执行路径，二者仅在di触发方法调用时交汇。
这个问题本质是把两个不同层面的概念强行耦合——图论建模、依赖注入体系、虚拟机栈行为，三者不在同一抽象层级上。所谓“方法调用膨胀”并非栈本身产生的现象，而是代码结构与运行时调用逻辑在栈上留下的**可观测痕迹**；而“深度依赖注入”属于设计模式/框架层的静态依赖关系，它不会自动导致栈帧爆炸，除非配合特定实现方式（如递归代理、无限委托、未设终止条件的AOP链）。
依赖图 ≠ 调用栈图：先厘清两个图的生成机制
依赖注入（DI）描述的是类与类之间“谁需要谁”的静态构造依赖关系，可建模为有向无环图（DAG），节点是组件，边是构造器/字段注入关系。这个图在Spring容器启动时解析Bean定义就已确定，不随每次方法调用变化。
而虚拟机栈反映的是单次线程执行路径上的动态调用序列，即方法A→B→C→…→Z这样一条有向链，本质是树状调用栈的某一路径投影。它由字节码指令（invokestatic/invokevirtual等）驱动，与DI容器是否介入无关。
二者交汇点只在一个地方：当DI容器通过反射或动态代理创建对象并调用其方法时，这些调用会压入栈——但此时栈深取决于实际执行的方法链长度，而非依赖图的拓扑深度。
什么情况下依赖图深度会“传导”到栈深度？
只有当依赖结构被运行时主动展开为嵌套调用时，图的深度才可能映射为栈的深度。典型场景包括：
-
递归式代理链：例如A被CGLIB代理，CGLIB代理又代理了B，B又被另一个代理包装……且每次代理的
intercept()都直接调用目标方法，形成A→proxyA→B→proxyB→C……这类人为构造的调用链 - 无终止的AOP环绕通知：@Around切面在处理目标方法前后反复调用自身或同级切面，未设置跳过条件，造成切面→目标→切面→目标的循环压栈
- 工厂方法中隐式递归构造：BeanFactory.getBean()在获取某个Bean时，触发其依赖的另一个Bean的创建，而该Bean的构造函数又反向请求原Bean（循环依赖+非懒加载+三级缓存未生效），导致构造器调用层层嵌套（虽Spring通常用提前暴露ObjectFactory解决，但极端配置下仍可能压栈）
- 响应式链中flatMap嵌套过深：Mono.flatMap内不断返回新Mono，且未用subscribeOn/observeOn切分执行上下文，在单线程EventLoop中表现为连续方法调用而非异步调度，栈帧逐层累积
如何用图论语言描述这种传导？
可以定义一个执行展开图（Execution Unfolding Graph）：
- 节点 = 实际发生的非内联方法调用（含代理、切面、回调入口）
- 有向边 = 直接调用关系（字节码层面的invoke指令流）
- 若某条路径长度 > JVM默认栈容量（如-Xss1m对应约1000–2000帧），则触发StackOverflowError
- 该图是依赖图在特定运行路径下的一个实例化投影，不是所有依赖边都会激活，也不是所有路径都等长
换句话说：依赖图提供了潜在路径集合，而栈溢出只发生在其中某一条实际被执行且足够长的路径上。
规避策略：从图结构和栈行为双角度控制
不靠减少依赖深度（那会牺牲解耦），而靠切断“图→栈”的错误映射：
- 代理层加深度限制：CGLIB Enhancer设置
setInterceptDuringConstruction(false)，避免构造期间代理调用 - AOP切面加执行守卫：环绕通知开头检查Thread.currentThread().getStackTrace()中已出现本切面次数，超阈值直接返回或抛异常
- 循环依赖显式声明：Spring中用
@Lazy打破构造期依赖，改用运行时getBean()，将栈压入转移到方法调用而非构造调用 - 响应式链扁平化：用
concatMap替代flatMap（若顺序可接受），或定期插入publishOn(scheduler)重置调用栈
本质上，这是在运行时对依赖图做“路径剪枝”，而非修改图本身。
