CSV日期导入失败主因是格式不统一及空值异常，需预处理标准化：用pandas.read_csv(parse_dates)内存解析、awk/mlr按列转换，或临时放宽数据库校验救急，但源头清洗才是根本解法。
CSV里日期被当成字符串或NULL导致导入失败
数据库（比如 postgresql 或 mysql）拒绝导入，报错类似 invalid input syntax for type date 或 incorrect date value，本质是 csv 中的日期字段没被识别为有效日期类型。常见原因不是“格式不对”，而是“格式不统一”——同一列混着 2023/05/12、12-may-2023、2023-05-12 14:30:00 甚至空格/空字符串。
- 别指望数据库自动猜：MySQL 的
STR_TO_DATE()、PostgreSQL 的TO_DATE()都需要显式指定格式，且不支持多格式 fallback - 预处理比导入时转换更可控：在 Python/Pandas 或命令行里统一规整，比靠 SQL 函数硬扛容错率高得多
- 空值和异常值必须显式处理：比如
"N/A"、"--"、全零日期"0000-00-00"，数据库通常直接拒收
pandas.read_csv() 读取时直接解析日期列
用 pd.read_csv() 加 parse_dates 参数，在内存中完成类型转换，比导入后再 ALTER COLUMN 更安全。
- 指定单列：
parse_dates=["order_date"]，会尝试按默认规则（ISO 格式优先）解析，失败则转成NaT - 指定多列或自定义格式：
parse_dates={"ship_date": "%d/%m/%Y"}，注意 Python 的格式符（%Y是 4 位年，%y是 2 位） - 遇到无法解析的值，默认变
NaT，后续可用df["date_col"].fillna(pd.NaT)显式归一 - 如果原始 CSV 有毫秒或时区（如
"2023-05-12T14:30:00.123Z"），加keep_date_col=False和infer_datetime_format=True可提速
用 awk/sed 做轻量级 CSV 日期标准化（无 Python 环境时）
服务器没装 Python，又不能改数据库配置？用 shell 工具预处理 CSV 文件本身，把日期列统一成 YYYY-MM-DD。
- 简单替换（仅 ISO 兼容格式）：
sed 's|/\([0-9]\{2\}\)/|\-\1\-|g' file.csv—— 但这种正则极易误伤其他斜杠，慎用 - 推荐用
awk按列处理：假设日期在第 3 列，且原始是DD/MM/YYYY：awk -F, -v OFS=, '{$3 = sprintf("%s-%s-%s", $3, $2, $1); print}' file.csv（需先切分） - 真正健壮的做法：用
csvkit（in2csv+csvformat）或mlr（Miller），它们能正确处理带引号、换行的 CSV 字段 - 永远备份原文件：
cp data.csv data.csv.bak，文本替换不可逆
MySQL / PostgreSQL 导入时跳过日期校验的临时方案
紧急修复已入库的脏数据，或测试阶段快速灌数据，可临时放宽约束，但绝不能用于生产表结构设计。
- MySQL：启动时加
--sql-mode=""，或运行时执行SET sql_mode = '';，会允许"0000-00-00"这类非法值（但仍是字符串存进去） - PostgreSQL：没有全局开关，但可建临时表用
TEXT类型存所有列，再用INSERT INTO real_table SELECT TO_DATE(date_str, 'DD-Mon-YYYY') FROM temp_table转换 - 关键提醒：这类操作绕过类型检查，后续查询、索引、范围扫描都可能出错，仅限一次性救急
- 真正的解法永远是源头清洗：CSV → 标准化 → 验证 → 导入，四步缺一不可
最常被忽略的是 CSV 引号和换行符对日期字段的干扰——比如 "2023-05-12" 被当字符串，或日期值跨行出现在双引号内。用 csvkit 或 Pandas 的 quoting=csv.QUOTE_MINIMAL 才算真正处理了边界情况。
