symtable模块仅支持源码字符串或AST节点的静态符号分析，不适用于运行时、code对象、.pyc文件或已加载模块；其作用域类型、变量绑定状态、闭包关系等需手动遍历判断，且不验证语义正确性。
symtable 模块不能直接用于运行时符号分析，它只处理源码字符串或 AST 节点，且不反映实际执行中的变量绑定状态。
symtable.parse() 只接受源码或 AST，不支持已编译的 code 对象
很多人误以为能用 symtable.symtable(code_obj, ...) 分析 compile() 后的字节码对象，但实际会报 TypeError: expected str or AST。symtable 的设计定位是「编译前期」的静态符号收集，不是运行时反射工具。
- 必须传入原始 Python 源码字符串（如
"def f(): x = 1; return x"）或等价的ast.AST节点 - 若已有
code对象，需反向提取源码（如通过inspect.getsource()），但该方法在交互式环境或动态生成代码中常失败 - 不支持从
.pyc文件或内存中已加载模块直接提取符号表
作用域类型判断靠 SymbolTable.get_type()，但嵌套函数和闭包需手动遍历
get_type() 返回 "module"、"function"、"class" 或 "lambda"，但它不直接暴露闭包变量（free variables）与局部变量（local variables）的区分逻辑——这些信息藏在 Symbol.is_local()、Symbol.is_free() 和 Symbol.is_global() 中。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 闭包变量（如外层函数定义、被内层函数引用的变量）在内层
SymbolTable中表现为is_free() == True，但在外层表中仍是is_local() == True - 没有现成方法列出「哪些变量被当前作用域 closure」，必须递归检查每个
Symbol并比对所属SymbolTable的层级 -
SymbolTable.get_children()返回子作用域列表，但顺序不保证与源码声明顺序一致，不可依赖索引取值
符号是否被赋值由 Symbol.is_assigned() 判断，但有常见误判场景
这个布尔值仅基于 AST 中是否存在赋值语句（=、+= 等），不考虑运行时条件分支或异常路径，因此容易高估局部性。
- 在
if False: x = 1中，x仍被标记为is_assigned() == True，尽管它永远不会执行 - 类体中定义的变量（如
class C: x = 1）在类作用域表中是is_assigned()，但在实例方法中访问时属于非局部，symtable 不自动建立这种跨作用域引用链 - 导入语句（
import os）会使os在模块作用域中标记为is_assigned()，但不会记录其绑定目标类型（模块/函数/其他）
真正难的是把多个嵌套 SymbolTable 实例拼成一张连通的作用域图：symtable 提供了树状结构基础，但变量引用路径（比如 nonlocal x 如何关联到上层 x）、名称遮蔽（shadowing）的优先级、以及 global/nonlocal 声明的实际生效范围，都得靠你自己按 Python 作用域规则（LEGB）补全逻辑。它不验证语义正确性，只忠实地映射语法层面的声明位置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
