$_POST仅在POST请求且Content-Type为application/x-www-form-urlencoded或multipart/form-data时有效；JSON等格式需用php://input读取并手动解析。
$_POST 只在 POST 请求中可用，不是“只要发了数据就自动有”
很多人以为只要前端发了 POST 请求，$_POST 就一定有值——其实它依赖两个前提：请求方法确实是 POST，且 Content-Type 是 application/x-www-form-urlencoded 或 multipart/form-data。如果前端用 fetch 发送 JSON（Content-Type: application/json），$_POST 会是空数组，哪怕请求体里明明有数据。
验证方式很简单：
- 先检查
$_SERVER['REQUEST_METHOD'] === 'POST' - 再看
$_SERVER['CONTENT_TYPE']是否匹配上述两种类型 - 若不匹配，别硬读
$_POST，该用file_get_contents('php://input')去取原始流
$_POST 不会自动解码嵌套结构，比如 JSON 字段或数组名带点号
HTML 表单字段名写成 user.profile.name 或 data[0][id]，PHP 会按规则自动展开为多维数组，但前提是字段名符合 PHP 的数组命名语法。而如果前端把整个 JSON 字符串塞进一个字段（如 &data={"a":1}），$_POST['data'] 拿到的只是字符串，不是数组。
常见踩坑点：
立即学习“PHP免费学习笔记（深入）”；
-
$_POST['config']看起来像数组，实际是 JSON 字符串 → 需手动json_decode($_POST['config'], true) - 字段名含点号、中括号以外的符号（如
user.email）可能被 PHP 截断或忽略 → 改用下划线或明确约定键名格式 - 空字段提交后
$_POST里根本不会出现这个 key → 别直接$_POST['xxx']，要用$_POST['xxx'] ?? ''或filter_input(INPUT_POST, 'xxx')
$_POST 和 $_REQUEST 混用容易引发安全与逻辑混乱
$_REQUEST 默认合并了 $_GET、$_POST、$_COOKIE，顺序由 request_order 配置决定（默认 GP C）。这意味着同名参数时，$_GET 可能覆盖 $_POST，尤其在调试时加了 URL 参数却没意识到。
实操建议：
- 永远优先显式使用
$_POST处理表单提交，避免依赖$_REQUEST - 禁用
$_REQUEST的 Cookie 合并（改php.ini中request_order = "GP"） - 对关键字段（如
id、action）做来源校验：检查是否只来自 POST，而非被 GET 参数悄悄篡改
文件上传时 $_POST 和 $_FILES 是分离的，别指望 $_POST 包含文件内容
当表单设了 enctype="multipart/form-data"，文件字段不会出现在 $_POST 里，而是单独进 $_FILES。哪怕你给文件 input 起名叫 avatar，$_POST['avatar'] 也一定是 null 或未定义。
必须同步检查两部分：
isset($_FILES['avatar']) && $_FILES['avatar']['error'] === UPLOAD_ERR_OK-
!empty($_POST['username'])等其他字段是否合规 - 注意
$_FILES['avatar']['tmp_name']是临时路径，必须用move_uploaded_file()移走，否则请求结束就被删
最常被忽略的是：上传失败时 $_FILES 数组仍存在，但 error 值非零，直接拿 tmp_name 会导致空文件或警告。
