to_date在oracle中无法安全处理脏数据，会直接报错；必须通过regexp_like预筛+范围校验，或封装带异常捕获的safe_to_date函数实现容错，跨库需改用对应数据库的try系函数。
TO_DATE函数在Oracle中根本不能“安全”处理脏文本
直接说结论：TO_DATE 是强校验函数，遇到格式不匹配、空格、多余字符、NULL 或非日期字符串，立刻抛出 ORA-01843: not a valid month 或 ORA-01858: a non-numeric character was found where a numeric was expected。它没有容错机制，所谓“安全转换”必须靠外围逻辑兜底。
用CASE + REGEXP_LIKE预筛再调TO_DATE
真正能落地的方案是：先用正则判断文本是否大致符合目标格式，再进 TO_DATE。比如统一按 'YYYY-MM-DD' 解析：
CASE
WHEN REGEXP_LIKE(date_str, '^[0-9]{4}-[0-9]{2}-[0-9]{2}$')
AND TO_NUMBER(SUBSTR(date_str, 1, 4)) BETWEEN 1900 AND 2100
AND TO_NUMBER(SUBSTR(date_str, 6, 2)) BETWEEN 1 AND 12
AND TO_NUMBER(SUBSTR(date_str, 9, 2)) BETWEEN 1 AND 31
THEN TO_DATE(date_str, 'YYYY-MM-DD')
ELSE NULL
END
- 仅靠
REGEXP_LIKE不够——它无法校验 2023-02-30 这种非法日期，得补月份/日范围检查 -
TO_NUMBER转换前必须确保子串全是数字，否则REGEXP_LIKE通过但TO_NUMBER仍报错 - 别用
TRIM代替正则——TRIM(' 2023-02-01 ')可行，但TRIM('2023-02-01xxx')无效
用自定义函数封装容错逻辑（推荐）
把校验+转换打包成 PL/SQL 函数，复用性高且业务层干净：
CREATE OR REPLACE FUNCTION safe_to_date( p_str IN VARCHAR2, p_fmt IN VARCHAR2 DEFAULT 'YYYY-MM-DD' ) RETURN DATE IS BEGIN RETURN TO_DATE(TRIM(p_str), p_fmt); EXCEPTION WHEN OTHERS THEN RETURN NULL; END;
- 注意：
WHEN OTHERS在生产环境慎用，建议捕获具体异常如VALUE_ERROR或INVALID_NUMBER - 函数内
TRIM只清首尾空格，对中间乱码（如'2023- 02-01'）无能为力，仍需前置清洗 - 调用时写
safe_to_date(my_col, 'DD/MM/YYYY')比裸写TO_DATE更可控
其他数据库没有TO_DATE？别硬套Oracle习惯
MySQL 用 STR_TO_DATE，PostgreSQL 用 TO_DATE（但行为不同），SQL Server 用 TRY_CONVERT。强行在非Oracle库写 TO_DATE 会直接报错：
- MySQL：
STR_TO_DATE(date_str, '%Y-%m-%d')对非法输入返回NULL，天然比 Oracle 安全 - PostgreSQL：
TO_DATE(date_str, 'YYYY-MM-DD')遇错也报异常，得配合EXCEPTION块或改用TO_TIMESTAMP+CASE - SQL Server：
TRY_CONVERT(DATE, date_str)是首选，失败即返NULL，无需手工捕获
跨库迁移时，最常被忽略的是异常传播方式——Oracle 的 TO_DATE 错误不可抑制，而多数现代数据库提供 TRY_ 系列函数，这点不厘清，上线就炸。
