调用栈不直接保护局部变量作用域，而是通过栈帧生命周期和内存布局自然保障：局部变量仅在对应栈帧内有效，函数返回后自动释放，同名变量因位于不同栈帧而互不影响，作用域规则由编译器或解释器静态/动态检查实现。
调用栈本身不直接“保护”局部变量的作用域，但它为作用域的实现提供了底层内存基础——局部变量的作用域限制，本质上是由栈帧的生命周期和内存布局自然保障的。
局部变量只在对应栈帧内有效
每次函数调用都会在栈上创建一个独立的栈帧，局部变量就分配在这个栈帧的局部变量区。这个区域从函数开始执行时分配，到函数返回时自动释放。因此：
- 变量名只在当前函数体内可见，编译器或解释器在符号解析阶段就按作用域规则拒绝跨函数访问
- 即使通过指针或引用试图传递栈上局部变量的地址，一旦函数返回，该地址指向的内存已不再受控，读写属于未定义行为
- 不同函数的同名局部变量互不影响，因为它们位于各自栈帧的不同内存位置
栈帧隔离天然阻止跨作用域访问
栈帧之间有明确边界：参数区、局部变量区、返回地址、旧基址指针（如rbp）共同构成一个逻辑封闭单元。操作系统和CPU不提供跨栈帧直接寻址局部变量的机制：
- 没有指令能“跳进”另一个函数的栈帧去读它的局部变量（除非调试器或越界访问等非常规手段）
- 寄存器如rsp（栈顶）、rbp（帧基址）始终指向当前栈帧，访问只能基于当前帧偏移
- 函数返回时，栈指针回退，原栈帧内存被后续调用覆盖或视为无效，变量彻底不可达
保护机制不针对作用域，而是防破坏
像栈金丝雀（Canary）、DEP、ASLR这些保护机制，并不是为了“维持作用域规则”，而是防止栈被恶意篡改：
- 金丝雀检测缓冲区溢出是否覆盖了返回地址——它不管变量是否越界访问，只管栈结构是否被破坏
- DEP禁止执行栈上代码，防止攻击者注入shellcode，与变量作用域无关
- ASLR打乱栈地址布局，增加劫持难度，也不影响局部变量的可见性范围
语言层作用域检查早于运行时
作用域限制主要由编译器或解释器在静态分析阶段完成：
- C/Java等编译型语言：编译时报错“undefined reference”或“out of scope”，根本不会生成访问非法局部变量的指令
- Python/JS等动态语言：运行时查LEGB链，找不到就抛NameError，不是靠内存保护，而是靠名字查找规则
- 即便关闭所有栈保护，只要不手动操作栈指针或伪造地址，语言自身的作用域语义依然成立
