hyperf中$_post为空，因其基于swoole不依赖php-fpm，禁用超全局变量，统一通过requestinterface解析；application/json等非x-www-form-urlencoded格式下$_post必为空，须用$request->input()或$request->all()。
Hyperf 控制器里获取 POST 参数，不能直接用 $_POST，必须通过 $request->input() 或 $request->all()，且需确认请求体已正确解析（如 Content-Type 匹配）。
为什么 $_POST 是空的？
Hyperf 基于 Swoole，不依赖 PHP-FPM 的 CGI 生命周期，$_POST 仅在 application/x-www-form-urlencoded 且未被 Swoole 自动解析时才可能有值；但 Hyperf 默认禁用该超全局变量，统一走 RequestInterface 抽象层。
- 所有参数统一由
Hyperf\HttpMessage\Server\Request解析并缓存，$_POST不参与流程 - 若前端发的是
application/json，$_POST必然为空 —— JSON 不触发 PHP 自动填充$_POST - 即使 Content-Type 是
application/x-www-form-urlencoded，Hyperf 也只信任自己解析的结果，忽略$_POST
$request->input() 和 $request->all() 的区别与选法
二者都从同一份已解析的请求数据源读取（$request->getParsedBody()），但行为不同：
-
$request->input('name')：安全取单个字段，支持默认值，自动处理嵌套（如user[name]→$request->input('user.name')） -
$request->input('items.*.id')：支持通配符批量提取数组字段 -
$request->all()：返回完整解析后的关联数组，不含文件；但不会扁平化嵌套键名（user[name]仍为['user' => ['name' => 'xxx']]） - 若需原始 raw body（比如验签、透传），应调用
$request->getBody()->getContents()，而非依赖input()
常见 Content-Type 下的实际表现
Hyperf 的 Request 对不同格式的处理逻辑隐含在中间件链中（如 RequestBodyMiddleware），你不需要手动 decode，但得知道它怎么工作：
-
application/x-www-form-urlencoded：自动解析进getParsedBody()，$request->input()可直接取 -
application/json：自动 JSON decode 后塞入getParsedBody()，$request->input('data.id')照常可用 -
text/plain或application/octet-stream：getParsedBody()返回null，$request->input()拿不到任何值，只能读getBody() - 混合 multipart（含文件）：
$request->input()仅返回非文件字段，文件需用$request->file()
容易踩的坑：参数没拿到的典型原因
不是代码写错，而是环境或配置层面漏了关键点：
- 前端没设
Content-Type头，Swoole 默认当text/plain处理，导致getParsedBody()为空 - Nginx 反向代理时加了
proxy_buffering off;但没配client_max_body_size，大 POST 被截断，$request->all()只返回部分字段 - 用了
#[PostMapping]注解但没在类上加#[Controller]，导致路由未注册，请求根本没进控制器 - 在中间件里提前调用了
$request->getBody()->getContents()，body 流已被消费，后续$request->input()返回空数组
调试时最直接的办法是打一行 var_dump($request->getParsedBody());，看原始解析结果是否符合预期——比猜 Content-Type 更可靠。
