laravel内置邮箱验证不防表单伪造，真正防护靠csrf机制；email_verified_at无自动防护，自定义post验证接口须显式加@csrf；api路由默认无csrf保护；email规则仅校验格式，不验证真实性。
直接说结论：Laravel 内置的邮箱验证（MustVerifyEmail）本身不防表单伪造，它只管“用户点没点邮件里的链接”；真正防伪造的是 Laravel 默认启用的 CSRF 保护机制，它会拦截未经许可的 POST / PUT / PATCH 请求——包括验证请求本身。
为什么 email_verified_at 字段不能防止伪造？
用户点击验证链接后，Laravel 路由 verification.verify 接收 GET 请求，校验签名并更新 email_verified_at。这个过程不走表单提交，所以不依赖 CSRF Token。但问题在于：如果你自己写了个 POST 接口（比如 /api/verify-email）去手动更新该字段，又没加 @csrf 或没校验 token，那攻击者就能伪造请求直接把任意用户的 email_verified_at 设为非空值。
- 内置验证流程是签名 + GET，天然抗篡改，但仅限于官方路由
- 自定义验证接口若用 POST/PUT，必须显式加
@csrf或使用VerifyCsrfToken中间件 -
email_verified_at是纯数据库字段，没有任何自动防护逻辑
CSRF 令牌如何保护验证动作？
当你在前端用表单触发邮箱验证重发（比如 verification.resend），Laravel 要求该表单带 _token 字段。如果攻击者仿造一个表单提交到你的 /email/verification-notification，而没提供当前会话有效的 token，VerifyCsrfToken 中间件会直接 419 响应。
- 所有 web 中间件组下的 POST/PUT/PATCH/DELETE 路由默认受保护
- API 路由（
api/*）默认不启用 CSRF，除非你手动加throttle:api,verified类中间件组合 - Blade 模板里写
@csrf就够了，它会自动注入<input type="hidden" name="_token" value="...">
别混淆 email 格式验证和邮箱真实性验证
很多人以为 email 验证规则能防伪造，其实它只做 RFC 格式检查：test@invalid、user@no-such-domain.com 全部能过。它不查 DNS，更不连 SMTP——这和“防伪造”完全无关。
-
email规则是静态字符串校验，跟 CSRF 无任何关系 - 要确认邮箱真实存在，得用 Trumail 等外部 API，返回
deliverable: true才算数 - 这类 API 调用应在服务端完成，绝不能把 API key 暴露给前端
最易被忽略的一点：CSRF 保护只对 session-based 请求生效；如果你用 Sanctum 或 Passport 做 API 认证，且跳过了 session，那 VerifyCsrfToken 就不会运行——此时防伪造得靠签名请求头、IP 限流或一次性验证码，而不是 _token 字段。
