date_format规则不校验空值、不验证日期存在性、严格匹配分隔符且错误信息不明确，需配合nullable/required、date规则及自定义message使用。
date_format 规则不校验空字符串，容易漏掉可选字段
很多人以为 date_format:Y-m-d 能拦住空值或 null，其实它只对非空字符串做格式解析。如果字段是可选的（比如表单里没填日期），date_format 会直接跳过校验，导致后端拿到空字符串或 null 后出错。
- 必须显式加上
nullable或required_if等前置约束，比如nullable|date_format:Y-m-d - 如果字段允许为空但一旦有值就必须合规，用
nullable|date_format:Y-m-d；如果字段必填，就用required|date_format:Y-m-d - 注意：Laravel 9+ 中
date_format对时区敏感，输入"2023-01-01T00:00:00Z"这类 ISO 8601 字符串默认会失败，得换date规则或手动配置 Carbon 解析
Y-m-d 和 Y/m/d 在 date_format 里不是等价的
看似只是分隔符不同，但 date_format 是严格按字面匹配的——它不调用 PHP 的 DateTime::createFromFormat() 的宽松模式，而是用正则级比对。写成 Y/m/d 就只能接受斜杠，Y-m-d 只认短横线。
- 别指望它自动兼容多种分隔符，想支持
2023-01-01和2023/01/01，得用date规则 + 自定义消息，或改用regex -
date_format:Y-m-d会拒绝"2023-1-1"（月份/日期没补零），哪怕 Carbon 能 parse 成功 - 实际项目中建议统一前端传 ISO 8601 格式（
2023-01-01T00:00:00Z），后端用date规则，更健壮
date_format 校验失败时抛的是 ValidationException，但错误信息不提示具体格式
默认报错是 The published at format is invalid.，用户根本不知道该填 Y-m-d 还是 Y/m/d，API 调试成本陡增。
- 必须在验证规则里加自定义 message：
'published_at.date_format' => 'The published_at must be in Y-m-d format.' - 如果用 Request 类，可在
messages()方法里集中管理；如果用validate()，就传第二个参数数组 - 注意：message 键名必须严格为
字段名.规则名，比如starts_at.date_format，拼错就不会生效
date_format 不验证日期是否存在，2023-02-30 也能过
它只检查字符串是否符合格式模板，不判断“2023-02-30”这种逻辑上不存在的日期是否真实。这会导致数据库插入失败或业务逻辑异常。
- 必须搭配
date规则一起用：date|date_format:Y-m-d，date才真正调用 Carbon 做存在性校验 -
date规则本身也支持格式（如date:Y-m-d），但它比date_format更宽泛，比如能 parse"2023-01-01 12:00"，所以若需严格限定格式，还是得组合使用 - 线上曾有 bug 是因为前端传了
"2023-04-31"，date_format:Y-m-d放行，到 DB 层才报错，延迟暴露问题
最麻烦的是格式和存在性校验要拆成两步写，而且 message 键名、空值处理、分隔符敏感这些点全得手动对齐——稍不注意，API 就在边界 case 上静默失败。
