time.sleep()不可靠因只延时不管状态，易致报错或漏数据；应改用显式等待、进程清理、i/o超时及分级日志。
为什么 time.sleep() 不是可靠的流程控制手段
它只管“停”，不管“等”——脚本可能在目标进程还没启动、文件还没写完、网页元素还没渲染时就继续执行，结果不是报错就是漏数据。time.sleep(5) 看似稳妥，实则把不确定性从代码逻辑里赶到了时间维度上。
- 真实场景下，网络延迟、磁盘 IO、CPU 负载都会让“等 5 秒”变得毫无意义
- 用
time.sleep()替代状态判断，等于把重试逻辑外包给运气 - 更糟的是，它会拖慢整个脚本，尤其在批量任务中，积少成多直接拉垮吞吐量
- 推荐改用显式等待：比如
selenium.webdriver.support.ui.WebDriverWait配合expected_conditions，或对文件用os.path.exists()+ 循环轮询（加超时）
子进程管理不当导致僵尸进程堆积
用 subprocess.Popen() 启动外部命令后，如果没显式调用 .wait()、.communicate() 或没设置 start_new_session=True，子进程可能脱离父进程控制，变成僵尸或孤儿进程。linux 下积累多了会耗尽 PID 表，windows 则可能卡住句柄或端口。
- 务必在
Popen后配对处理：要么proc.communicate(timeout=30)，要么proc.wait(timeout=30) - 避免裸写
subprocess.run(..., shell=True)—— 它默认不设超时，卡死无感知 - 若需后台长期运行，用
start_new_session=True并记录proc.pid，方便后续信号控制 - 在
finally块或上下文管理器中做清理，防止异常跳过回收
没有超时机制的 I/O 操作极易挂死
http 请求、数据库查询、串口读取、文件锁等待……任何依赖外部响应的操作，一旦对方失联或响应异常缓慢，脚本就会无限阻塞。这不是“慢”，是彻底失控。
-
requests.get(url)必须带timeout=(3, 7)（连接+读取），不设 timeout 等同于放弃控制权 -
sqlite3.connect()加timeout=5参数，否则遇到锁表直接卡死 - 用
serial.Serial()时，timeout和write_timeout都得明确设值，别依赖默认的None - 自定义轮询逻辑（如等某个标志文件出现）必须内置计数器或
time.time()超时判断，不能只靠while True
日志和异常没分级也没落盘，出问题根本找不到线索
只靠 print() 或裸抛异常，等于把故障诊断工作推给运行时运气。脚本跑在服务器、定时任务或 docker 里时，控制台输出瞬间消失，你连它是否启动过都不知道。
立即学习“Python免费学习笔记（深入）”；
- 禁用裸
print()，统一走Logging，至少设level=logging.INFO，关键步骤打logging.debug() - 捕获异常后，必须
logging.exception()或至少logging.Error(str(e))，不能只写except: pass - 日志文件路径用绝对路径，比如
/var/log/mybot/run.log，避免相对路径在 crontab 中失效 - 对关键状态（如“已获取 Token”“已提交第127条数据”）做幂等标记，例如写入临时文件或数据库 status 字段，便于中断后续跑
真正难的不是让脚本“跑起来”，而是让它在没人盯着的时候，知道自己该停在哪、为什么停、下次从哪接着干。超时、状态等待、进程生命周期、可追溯日志——这四块缺一不可，漏掉任一环，自动化就只是个看起来很美的定时炸弹。