cprofile.run() 默认不显示标准库函数调用细节，因其仅统计用户代码层，c扩展（如_json、_sre）绕过python帧栈，纯python标准库模块（如urllib.parse）才可被完整追踪。
为什么直接用 cProfile.run() 看不到标准库函数调用细节？
默认情况下，cProfile.run() 只统计用户代码层级的调用，标准库（如 json.loads()、re.compile()、os.path.join()）虽被调用，但它们的内部帧常被 C 扩展绕过，或因内置函数优化未进入 Python 帧栈，导致 profile 数据里只显示顶层调用，看不到耗时落在哪个标准库子函数上。
解决关键是强制让 profile 捕获所有 Python 层调用——包括标准库中纯 Python 实现的部分（如 xml.etree.ElementTree、urllib.parse），并避免被 C 扩展“跳过”：
- 改用
cProfile.Profile()实例，手动开启/关闭，并传入subcalls=True参数（Python 3.8+ 支持） - 确保不使用
run()这类封装接口，它会跳过 subcall 记录 - 对疑似瓶颈的标准库模块，先查其源码实现：纯 Python 模块可被 profile；C 扩展（如
_json、_ssl）则无法深入，只能看到外层 wrapper 耗时
怎样用 pstats 筛出标准库中真正耗时的函数？
pstats 默认按「本函数自身耗时」（tottime）排序，但标准库函数往往自身很快，大量时间花在它的子调用里（cumtime 高但 tottime 低）。比如 json.loads() 的 tottime 可能仅 0.001s，但 cumtime 占整体 80%，说明它触发了大量底层解析逻辑。
实操建议：
- 加载 stats 后，先执行
sort_stats('cumtime')，再print_stats(20)查看累计耗时 top 20 - 用
print_callers('json.loads')或print_callees('xml.etree.ElementTree.fromstring')查清谁在驱动它、它又调了谁 - 过滤路径：标准库路径通常含
lib/python3.x/或site-packages/，可用strip_dirs().filter('lib/python')聚焦 - 注意区分同名函数：比如
read()可能来自io.BufferedReader或socket.socket，需结合文件路径列判断
哪些标准库函数注定 profile 不到？怎么间接定位？
以下函数因 C 扩展实现，cProfile 无法进入其内部帧，只会记录外层 Python wrapper 的调用开销（通常极小）：
-
json.loads()/json.dumps()（实际走_json模块） -
re.search()/re.compile()（走_sre） -
hashlib.md5()、zlib.compress() -
struct.unpack()、array.array.append()
此时不能靠 pstats 看内部，而要：
- 对比不同输入规模下的耗时曲线：若
json.loads(s)耗时随len(s)线性增长，基本可判定是解析本身慢，而非周边逻辑 - 换用纯 Python 替代品做对照测试，例如用
simplejson（部分版本可 patch profile）或ujson（但它是更快的 C 实现，仅用于验证是否为解析瓶颈） - 用系统级工具辅助：Linux 下
perf record -e cycles:u python script.py可看到 CPU 时间真正花在哪段符号上（包括 C 函数）
一个能暴露标准库瓶颈的最小可验证示例
下面这段代码故意触发 urllib.parse.urlparse()（纯 Python 实现）和 json.loads()（C 扩展）混合场景，便于对比 profile 行为：
import cProfile
import pstats
from pstats import SortKey
<p>def test_stdlib_bottleneck():
url = "<a href="https://www.php.cn/link/24e7683835f66abc7d1b63fe5d7a4136">https://www.php.cn/link/24e7683835f66abc7d1b63fe5d7a4136</a>"</p><h1>urlparse 是纯 Python，会被完整 profile 到内部函数</h1><pre class="brush:python;toolbar:false;">parsed = urllib.parse.urlparse(url)
# loads 是 C 扩展，只看到外层 wrapper 耗时
data = json.loads('{"a": 1, "b": [1,2,3], "c": {"d": true}}')profiler = cProfile.Profile(subcalls=True, builtins=False) profiler.enable() test_stdlib_bottleneck() profiler.disable()
stats = pstats.Stats(profiler) stats.strip_dirs().sort_stats(SortKey.CUMULATIVE).print_stats(15)
运行后你会看到 urlparse 相关函数（如 _splitnetloc、_parse_params）出现在列表中，而 json.loads 仅作为单行出现，cumtime 高但无子调用 —— 这就是 C 扩展的典型 profile 特征。
真正容易被忽略的是：即使开了 subcalls=True，如果目标函数根本没进 Python 帧栈，就不可能有子调用数据。不要试图用 pstats “强行展开” C 函数，该换工具时就得换。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
