根本原因是Laravel的$request对象不依赖$_POST，而是从php://input或缓存中解析数据，并适配Content-Type；$_POST仅在application/x-www-form-urlencoded或multipart/form-data时由PHP自动填充，JSON等类型下为空。
PHP 原生 $_POST 和 Laravel 的 $request->post() / $request->get() 不是同一层的东西——前者是超全局数组，后者是框架封装的请求对象方法，行为、来源、安全性逻辑完全不同。
为什么 $_POST 有时为空，但 $request->post() 却能取到值？
根本原因：Laravel 的 $request 对象不直接依赖 $_POST 数组，而是从原始请求体（php://input）或预解析缓存中提取数据，并做了内容类型适配。
-
$_POST只在 Content-Type 是application/x-www-form-urlencoded或multipart/form-data时由 PHP 自动填充；其他类型（如application/json）下它始终为空 -
$request->post()内部会先检查是否已解析过请求体，对 JSON 请求自动调用json_decode(file_get_contents('php://input'), true)，再合并进 post 数据 - 如果你在中间件里提前读了
php://input（比如做签名验证），又没重置流指针，$request->post()可能也拿不到——这是 Laravel 5.5+ 的已知行为，需手动fseek($resource, 0)
$request->get() 不等于 $_GET，也不等于 URL 查询参数的简单映射
$request->get() 实际返回的是「查询参数 + 路由绑定参数 + 显式合并的默认值」三者合并后的结果，且受路由模型绑定影响。
-
$_GET纯粹来自 URL 查询字符串（?id=123&name=test），大小写敏感，键名不做任何转换 -
$request->get('id')会先查查询参数，再查路由参数（比如Route::get('/user/{id}', ...)中的{id}），最后才 fallback 到默认值 - 如果路由定义了
{id}且 URL 是/user/456，即使没带?id=123，$request->get('id')仍返回456；而$_GET['id']直接触发Notice: Undefined index - 还支持嵌套访问：
$request->get('filter.name')会尝试解析filter[name]这类表单数组语法，$_GET不支持
混用 $_POST 和 $request->post() 容易踩的坑
最危险的是在同一个请求里交叉读取——尤其涉及文件上传、JSON 解析或中间件修改时，状态可能不一致。
- 文件上传场景：
$_FILES始终可用，但$request->file()返回的是UploadedFile实例；若你用$_POST读文本字段、又用$request->file()读文件，没问题；但若用$request->post()读文本字段，它内部可能已触发一次完整解析，影响后续流读取 - CSRF 验证绕过：
$_POST['_token']是原始值，$request->post('_token')经过 Laravel 的trim()和空格归一化，某些构造的恶意 token 可能被意外“修正”后通过校验 - 数组键名差异：
$_POST['user[email]']是字符串键，$request->post('user.email')会尝试解析成嵌套数组，两者结构不等价，硬转容易出错 - 性能开销：
$request->post()每次调用都可能触发懒加载解析，高频循环里反复调用比直接用$_POST多几倍函数调用开销
真正关键的不是选哪个“更好”，而是清楚每个调用背后发生了什么——$_POST 是 PHP 底层约定，$request 是 Laravel 的抽象层，它们面向的不是同一个抽象层级。越早意识到这点，越不容易在调试时盯着 Network 面板发呆半小时却找不到数据去哪了。
