如果你已经用 Python 写了不少脚本，却总觉得代码只是“能跑”，这篇文章或许会刷新你对这门语言的认知。以下七个思路全部来自一线实战，没有花哨的概念，只有可落地的工具与习惯。它们曾帮我省下大量无意义的调试时间，也让我在同事面前少说了几句“我再看看日志”。

让脚本自己爬起来的“自愈”模式

场景：

• 连续抓取一万条商品信息，跑到两千条时突然报错退出；
• 数据同步任务跑着跑着网络断了，整晚白跑。

过去我的做法：手动重跑、手动定位断点，第二天顶着黑眼圈继续。

现在：给主逻辑加一层“自愈”循环，崩溃后自动从失败位置继续。

import time, traceback

def task(start_index):
    for i in range(start_index, 100):
        print(f"Processing {i}")
        if i == 42:
            raise Exception("Boom!")  # 模拟异常
        time.sleep(0.5)

def run_resilient_task():
    last_index = 0
    while last_index < 100:
        try:
            task(last_index)
            break
        except Exception as e:
            print("Error occurred:", e)
            print(traceback.format_exc())
            last_index += 1          # 关键：从下一行继续
            time.sleep(1)            # 短暂冷却

run_resilient_task()

核心思路：

1. 用 try/except 包住整段任务；
2. 出错时把“进度变量”加 1，而不是从 0 开始；
3. 打印 traceback，方便事后复盘。

实际效果：一次 10 000 页的商品爬虫，从原来需要人工值守 5 小时，变为夜里挂机 30 分钟自动跑完。

不改源码也能修第三方库的“热补丁”

场景：

• 上游 SDK 的 retry 逻辑有 bug，每次失败都会无意义地等待 60 秒；
• 项目已上线，无法等官方发版，更不能把整个库 fork 一份。

做法：在运行时替换目标函数，俗称 monkey patch。

import some_library.module as m

def patched_function(*args, **kwargs):
    print("Hijacked!")
    return "Custom Result"

m.original_function = patched_function

注意点：

• 替换动作必须在第一次调用前完成；
• 只改方法体，不改方法签名，降低副作用；
• 在补丁处加注释，方便后续移除。

我用这招临时修过一个支付网关 SDK，上线当天完成，三天后官方发新版再把补丁删掉，整个过程对业务透明。

零准备就能追溯每一步的“事后审计日志”

场景：

• 脚本误删文件，却不知道哪一行执行了删除；
• 遗留代码更新数据库，但没有任何日志。

做法：利用 sys.settrace 在运行时打印每一次函数调用。

import sys, time

def trace_calls(frame, event, arg):
    if event == "call":
        code = frame.f_code
        print(f"{time.strftime('%H:%M:%S')} - Calling {code.co_name} "
              f"in {code.co_filename}:{frame.f_lineno}")
    return trace_calls

sys.settrace(trace_calls)

def my_func():
    print("Doing something risky...")

my_func()

把这段代码放在脚本最前面，就能在控制台看到时间戳、函数名、文件路径、行号。
事后排查时，把输出重定向到文件，再用 grep 搜索关键字，比翻代码快得多。

把常用小工具做成自己的“随身标准库”

场景：

• 每次新建项目都要复制粘贴 slugify、is_json 这些小函数；
• 时间一长，不同项目里的版本开始分叉，调试时搞不清哪个才是最新。

做法：

1. 在 home 目录建 ~/python_utils/；
2. 把通用函数按模块放好，例如 logging.py、text.py；
3. 在 .bashrc 或 .zshrc 里加一行：

export PYTHONPATH="$PYTHONPATH:$HOME/python_utils"

以后在任何脚本里直接：

from my_helpers.logging import debug_log

好处：

• 真正的“一次编写，到处使用”；
• 版本统一，升级只需改一处；
• 脱离任何特定项目，换电脑也能带走。

用 argparse 让脚本秒变正经命令行工具

场景：

• 脚本参数一多，位置顺序就记不住；
• 同事运行时报错，总把第四个布尔值传反。

做法：把位置参数改成可读的标志。

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('--input', required=True)
parser.add_argument('--verbose', action='store_true')
parser.add_argument('--workers', type=int, default=1)
args = parser.parse_args()

print(args.input, args.verbose, args.workers)

运行示例：

python myscript.py --input=data.csv --verbose --workers=4

进阶：

• 给常用组合起 shell 别名，例如 alias sync-dev="python sync.py --env=dev --verbose"；
• 写 README 时直接贴命令，新人 30 秒就能上手。

给任意函数加“透视眼”的 @debug 装饰器

场景：

• 数据管道有 5 层转换，输出结果异常，却不知道哪一步出错；
• 不想在每一处都写 print，污染代码。

做法：写一个装饰器，自动打印函数名、参数与返回值。

def debug(func):
    def wrapper(*args, **kwargs):
        print(f"[DEBUG] Calling: {func.__name__}")
        print(f"[DEBUG] Args: {args}, Kwargs: {kwargs}")
        result = func(*args, **kwargs)
        print(f"[DEBUG] Result: {result}")
        return result
    return wrapper

@debug
def add(a, b):
    return a + b

add(5, 3)

效果：

• 一行注解即可启用/关闭调试信息；
• 对性能几乎无影响，上线前去掉装饰器即可。

三分钟搭一个一次性 HTTP 服务的 Flask 捷径

场景：

• 需要给前端同事临时接口返回 mock 数据；
• 内网工具需要一个极简 webhook 接收点；
• 把机器学习模型包成 REST API，但不想上重量级框架。

做法：

from flask import Flask, request

app = Flask(__name__)

@app.route('/echo', methods=['POST'])
def echo():
    data = request.json
    return {'received': data}

if __name__ == '__main__':
    app.run(port=5000)

运行后，POST JSON 到 http://localhost:5000/echo 即可收到回显。
用完即走，不留下冗余配置。

写在最后

以上七个技巧的共同点是：

• 不依赖特定业务，几乎任何项目都能用；
• 实现成本低，复制粘贴即可运行；
• 省下的时间可投入到真正有价值的逻辑上。

如果你刚把它们加入日常开发，大概率会遇到“为什么没早点知道”的懊恼——别慌，这正是成长的信号。把这些片段沉淀为自己的工具箱，下次写脚本时，你会多出几分从容。