line_profiler需通过kernprof命令启动才能使@profile生效，直接运行Python脚本会忽略装饰器；应装饰热点函数而非顶层代码，关注% Time、Time和Hits三列分析瓶颈，避免在生产环境使用。
Line_profiler 能真实反映每行代码的执行时间，但直接 pip install line_profiler 后不能立刻用 @profile 装饰器——它需要通过命令行工具 kernprof 启动，否则装饰器会被忽略。
为什么加了 @profile 却没输出？
这是最常踩的坑：@profile 不是 Python 内置装饰器，也不是 line_profiler 自动注入的魔法。它只在 kernprof 执行时才被识别和生效。
- 错误做法：直接运行
python script.py——@profile完全不触发，零输出 - 正确做法：必须用
kernprof -l -v script.py，其中-l表示启用 line profiler，-v表示打印结果 - 如果脚本依赖命令行参数，保留它们：例如
kernprof -l -v train.py --epochs 10
@profile 应该加在哪些函数上？
不是所有函数都值得 profile。重点盯住：调用频繁、含循环、涉及 I/O 或计算密集的函数。
- 别给顶层
if __name__ == '__main__':块加装饰器——它不被识别 - 避免装饰整个类或
__init__（除非初始化本身很重），优先选具体方法，如def forward(self, x): - 若函数被其他模块 import 并调用，确保
kernprof运行的是最终入口脚本，且该函数在运行路径中实际被执行 - 临时调试时，可只装饰一个疑似瓶颈函数；确认后，再逐步扩展到上下游
输出里 Line # 和 Time 到底怎么看？
关键看三列：% Time（该行占总耗时百分比）、Time（绝对微秒）、Hits（执行次数）。单行高 % Time 未必真慢，要结合 Hits 判断密度。
立即学习“Python免费学习笔记（深入）”；
- 例：某行
arr.append(x)占 25% 时间，但 Hits=100000 → 是热点；另一行json.load(f)占 30%，Hits=1 → 是单次开销大，优化方向不同 - 注意缩进影响：line_profiler 按物理行统计，for 循环体内的语句每迭代一次算一次 Hit，但 for 行本身只算一次
- 生成器表达式或列表推导式会被拆成多行显示，实际对应源码中的一整行，需对照源码定位
- 如果看到某行
Time极高但Hits=0，说明该行未执行（比如条件分支未进入），可忽略
如何避免 profile 干扰实际性能？
line_profiler 本身有开销，尤其对高频小函数，测量值会明显高于真实耗时，不能直接当绝对性能指标用。
- 不要用它测毫秒级以下操作（如单次 dict 查找）——误差可能翻倍
- 生产环境禁用：确保
@profile只存在于调试分支，或用if DEBUG:包裹装饰器逻辑 - 想对比优化效果？固定输入+多次运行取中位数，而不是只跑一次；
kernprof -l script.py && kernprof -l script.py比较两次% Time分布更可靠 - 若发现 profile 后程序变慢太多，可改用
cProfile先定位函数级瓶颈，再对重点函数用 line_profiler 细查
真正难的不是跑出数字，而是判断哪一行的「高耗时」是算法缺陷、数据结构误用，还是不可避免的外部依赖（比如网络请求）。看到 Time 高，先确认它是否真的在你的控制范围内。
