大多数 CSV 导入脚本常犯的错误（以及如何修复）

Source: Dev.to

Introduction

大多数 CSV 导入脚本都是在 30 分钟内写好的。
大多数导入失败要到 3 个月后才被发现。

问题不在 CSV 本身。
问题在于缺少保证。

在小团队中，CSV 导入通常是这样：

Read file
Loop rows
Insert into database
Print “Done”

它能工作——直到导出格式发生变化。

What Most Ingestion Scripts Get Wrong

Assumption: Column Order Never Changes

许多脚本依赖位置映射，这最终会导致破裂。
不要相信列的顺序，而是显式验证表头：

EXPECTED_HEADERS = [
    "date",
    "customer_id",
    "amount",
    "currency",
    "status"
]

if headers != EXPECTED_HEADERS:
    raise ValueError("Schema mismatch detected")

有意进行顺序敏感的比较。
如果上游更改，导入应立即停止。
静默漂移比崩溃更糟。

Guardrails for Empty or Truncated Files

空的 CSV 导入不应成功，报告只有 12 行而不是 1,200 行也不应悄悄通过。

if len(rows) == 0:
    raise RuntimeError("Empty export detected")

if len(rows) > ingestion.log 2>&1

人会忘记，Cron 不会。
自动化不仅仅是执行——更是确定性的状态转换。

Guarantees of a Safe Ingestion Pipeline

• 结构完整性 – 验证的模式和表头
• 数量合理性 – 行数的防护措施
• 原子写入 – 事务边界
• 安全重试 – 幂等 upsert 和唯一约束

其他一切都是乐观估计。

Further Reading

我在这里写了更深入的确定性导入架构拆解——包括文件归档、可观测性和生产安全措施：

Automating CSV to PostgreSQL Safely Using Python (Deterministic Ingestion)

了解如何使用模式验证、行验证、事务和 upsert 将脆弱的手动 CSV 导入替换为确定性的 Python 导入管道。