PHP日期解析失败常因字符串含换行符等空白字符，需先用str_replace替换\r\n\r\n为空格再trim清理，然后用DateTime::createFromFormat指定格式解析并验证。
PHP 字符串里混着换行符（\n、\r\n）时，strtotime() 或 DateTime::__construct() 很可能直接返回 false，导致日期解析失败——这不是格式不对，是字符串里藏了看不见的“脏字符”。
先清理换行和首尾空白再解析
绝大多数情况下，问题根源不是日期格式本身，而是字符串前后或中间夹了换行、回车、制表符。PHP 的日期解析器对这类空白极其敏感，哪怕只多一个 \n 就会静默失败。
- 用
trim()去掉首尾所有空白（包括\n、\r、\t、\0、\x0B） - 如果中间也可能有换行（比如用户从文本域粘贴的日期），加一步
str_replace(["\r\n", "\r", "\n"], ' ', $str)把换行全替换成空格，再trim() - 别依赖
filter_var($str, FILTER_SANITIZE_STRING)—— 它在 PHP 8.1+ 已被移除，且不处理换行
用 DateTime 构造时捕获 parse 失败
DateTime 比 strtotime() 更严格也更可控，但不会报错，只会静默创建一个错误时间（如 1970-01-01）。必须主动检查是否解析成功。
try {
$cleaned = trim(str_replace(["\r\n", "\r", "\n"], ' ', $input));
$dt = new DateTime($cleaned);
echo $dt->format('Y-m-d H:i:s');
} catch (Exception $e) {
// 这里会捕获格式非法，但不会捕获因换行导致的解析失败
// 所以重点还是靠上面 clean 步骤 + 后续验证
}
// 更可靠的做法：解析后比对原始字符串（不含空白）是否能 round-trip
$cleaned = trim($input);
$dt = DateTime::createFromFormat('Y-m-d', $cleaned);
if ($dt === false || $dt->format('Y-m-d') !== $cleaned) {
// 解析失败或格式不匹配
}
常见来源场景与对应处理建议
不同输入源带来的换行类型不同，处理策略也要区分：
立即学习“PHP免费学习笔记（深入）”；
-
HTML 表单
提交：默认带\r\n（Windows）或\n（macOS/Linux），必须trim()+ 替换换行 -
CSV 文件读取：字段可能被双引号包裹，但换行仍可能出现在字段内；用
fgetcsv()而非file_get_contents()+explode() -
cURL 或 API 返回的 JSON 中的日期字段：理论上不该有换行，但若服务端拼接出错，可用
json_decode($json, true, 512, JSON_INVALID_UTF8_IGNORE)避免因非法字符导致整个解码失败 -
数据库查出的 CHAR/VARCHAR 字段：MySQL 的
CHAR类型会补空格，SQL Server 可能存\r\n；入库前就该用TRIM()，查询后仍建议再trim()
别忽略时区和格式歧义
清理完换行只是第一步。例如字符串是 "01/02/2023\n"，trim() 后变成 "01/02/2023"，但 DateTime 在无明确格式时按美国习惯解析为 2023-01-02（月/日/年），而非中国常用的日/月/年。这时候不能靠猜：
- 明确指定格式：用
DateTime::createFromFormat('d/m/Y', trim($str)) - 统一转为 ISO 格式（
Y-m-d）再解析，避免地区差异 - 若来自用户输入，最好前端就用
，后端只收YYYY-MM-DD
换行本身不难删，难的是它常和格式模糊、时区混乱、输入源不可控裹在一起——清理动作要前置，验证逻辑要跟上，别等 date('Y-m-d', strtotime($str)) === false 才发现根本没进解析环节。
