最稳方式是用Paramiko的SFTP校验文件大小+编码探测+字段对齐+文件锁+时间/大小双重缺失判断。关键在传后校验、编码适配、并发控制、缺失告警，而非仅传输本身。
用 paramiko 拉取远程 CSV 文件最稳的方式
直接调 scp 命令容易因权限、路径或连接中断失败；paramiko 能细粒度控制连接、重试和文件校验。关键不是“能不能传”，而是“传错/传漏了能不能发现”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
SSHClient+AutoAddPolicy()简化首次连接，但生产环境务必换成基于已知 host key 的验证（避免中间人） -
sftp.get()后立刻用os.path.getsize()校验本地文件大小是否与远程sftp.stat().st_size一致 - 远程路径写全：比如
/home/app/logs/data_$(date +%Y%m%d).csv，脚本里用datetime.now().strftime('%Y%m%d')拼接，别依赖远程 shell 变量展开 - 加
timeout=30到connect()，并捕获paramiko.SSHException和OSError，记录失败服务器名和错误信息
多个 CSV 合并时绕开编码和列对齐陷阱
不同服务器可能用 gbk、utf-8-sig 或无 BOM 的 utf-8 写 CSV，pandas.read_csv() 默认只认 utf-8，一读就报 UnicodeDecodeError；更麻烦的是字段顺序不一致（比如 A 服务器导出列是 id,name,ts，B 是 name,id,ts）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先用
chardet.detect(open(file, 'rb').read(10000))['encoding']探测编码，fallback 到gbk（中文 Linux 常见） - 读取时强制指定
encoding，并加engine='python'避免 C 引擎对乱码的崩溃 - 统一用
pd.concat(..., ignore_index=True, sort=False)，且合并前对每份 DataFrame 执行df = df.reindex(columns=expected_columns, fill_value=pd.NA)，expected_columns提前定义好标准字段顺序 - 跳过空文件：
if os.path.getsize(file) == 0: continue
定时执行别只靠系统 cron，得有运行锁和日志隔离
脚本每天凌晨 2 点跑，但某天某台服务器卡住导致脚本 hang 住 20 分钟，第二天 cron 又起一个新进程——两个实例同时写同一个输出文件，结果数据错乱或被截断。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
portalocker加文件锁：with open('/tmp/collect_data.lock', 'w') as f: portalocker.lock(f, portalocker.LOCK_EX | portalocker.LOCK_NB)，捕获LockException直接退出 - 日志按日期分文件：
logging.FileHandler(f'collect_{datetime.now().strftime("%Y%m%d")}.log')，别共用一个 log 文件 - 输出 CSV 文件名带日期：
output_20240520.csv，而不是覆盖latest.csv——方便回溯和排查哪天缺数据 - 在脚本开头打印
print(f"Start at {datetime.now()}")，结尾打印print(f"Done. Total rows: {len(df)}")，日志里一眼看出是否跑完
怎么判断某台服务器当天数据“没传上来”而不是“根本没生成”
不能只看文件是否存在。有些服务半夜出问题，CSV 根本没生成；有些服务生成了但权限不对，脚本拉不到；还有些是磁盘满导致文件写了一半。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 远程执行
stat -c "%y %s" /path/to/data.csv 2>/dev/null获取最后修改时间和大小，解析后判断：时间不是今天 → 缺失；大小为 0 → 异常；大小明显偏小（比如历史平均 500KB，今天只有 2KB）→ 需告警 - 把每台服务器的检查结果写进一个临时 JSON：
{"server-a": {"status": "ok", "size": 482932, "mtime": "2024-05-20T02:15:33"}, ...}，跑完再统一分析哪些 status 不是ok - 缺失超过 2 台或连续 2 天同一台缺失，自动发邮件（用
smtplib）到运维群，主题带服务器名和日期
真正难的不是“怎么拉”，是拉完之后敢不敢信这些数据。时间戳对不上、字段类型混着来、空值表示方式不统一——这些细节不盯紧，汇总结果看着整齐，实际全是坑。
