默认不启用--record-stack-traces，故仅记录底层分配点（如malloc）而无Python调用栈；需显式添加该参数才能溯源至业务代码行，否则无法看到完整调用路径。
memray 能精准定位到具体哪一行代码触发了大内存分配，但默认不记录完整调用栈路径——必须显式启用 --record-stack-traces 才能拿到函数级溯源。
为什么跑完 memray trace 看不到调用链？
默认模式下 memray run 只记录内存块大小和分配点（即最底层的 C 函数如 malloc 或 Python 的 PyObject_Malloc），不采集 Python 层调用栈。这意味着你只能看到「在 list.append 里分配了 12MB」，但不知道是哪个业务函数调用了它。
- 必须加
--record-stack-traces参数才能捕获 Python 帧信息 - 该参数会带来约 15–30% 性能开销，生产环境勿直接开启
- 若目标脚本含多线程，需额外加
--follow-fork，否则子线程分配会被忽略
如何生成带完整调用路径的 .memray 文件？
执行命令时明确指定栈追踪与输出路径，避免默认覆盖或写入临时目录：
memray run --record-stack-traces --output profile.memray your_script.py
-
--record-stack-traces是关键开关，缺它等于白跑 -
--output推荐显式指定，否则默认名易被覆盖（如多次运行都叫memray-*.bin） - 若脚本需传参，参数必须写在
your_script.py之后，例如：memray run --record-stack-traces script.py --arg1 value
怎么从 .memray 文件里查某次大分配的具体路径？
用 memray flamegraph 或 memray tree 查看时，路径深度取决于栈采样精度——不是所有帧都会显示，尤其短生命周期对象可能只留顶层调用：
立即学习“Python免费学习笔记（深入）”；
memray tree profile.memray
-
tree按累计分配量倒序排列，每行末尾的→符号后就是调用路径（如process_data → load_json → json.loads） - 若路径过短（只有 1–2 层），检查是否漏了
--record-stack-traces；若过长但无业务函数，可能是 C 扩展模块屏蔽了帧（如 numpy 内部 malloc 不透出 Python 帧） - 想聚焦某个函数，可用
--filter：例如memray tree --filter "parse_" profile.memray
常见误判：为什么 top 分配函数总显示 <frozen importlib._bootstrap>？
这是 Python 导入机制的副作用——模块首次导入时大量构建 AST、字节码和符号表，会触发集中内存分配，但它不是你的业务瓶颈。
- 这类分配通常发生在 profiling 启动初期，可结合时间轴过滤：用
memray timeline profile.memray观察分配是否集中在前 100ms - 真正要盯的是稳定运行阶段（如循环体、数据处理函数）中反复出现的高分配节点
- 若
import占比异常高（>30%），检查是否在热路径里动态 import（如函数内写import pandas）
调用栈路径的真实性依赖于 Python 解释器帧的可访问性，C 扩展、JIT 编译（如 PyPy）、或被 sys.settrace 干扰的环境，都可能导致路径断裂——这时得配合 tracemalloc 做交叉验证。
