$_GET和$_POST拿不到数据是因为未匹配HTTP请求方法与Content-Type：$_POST仅响应application/x-www-form-urlencoded或multipart/form-data，JSON请求需用php://input解析；$_GET依赖URL查询字符串，且二者均需确认method属性、请求头及无输出干扰session_start()。
$_GET 和 $_POST 拿不到数据？不是变量没“定义”，而是你没对上请求上下文——PHP 不会凭空填充它们，只按 HTTP 方法和编码规则填。
为什么 $_POST 总是空数组？
它只响应两种 Content-Type：application/x-www-form-urlencoded（表单默认）和 multipart/form-data（文件上传）。前端若发的是 JSON（Content-Type: application/json），$_POST 必然为空，这是设计使然，不是 bug。
- 先确认请求方法：
var_dump($_SERVER['REQUEST_METHOD']);，别在 GET 请求里硬查$_POST - 检查请求头：
var_dump($_SERVER['CONTENT_TYPE'] ?? '');，JSON 或 XML 数据得走file_get_contents('php://input')+json_decode() - 表单
method属性写错、漏写，或用了fetch但没设body格式，都会导致后端收不到
$_SESSION 为什么每次都是新会话？
session_start() 不是“可选步骤”，而是会话机制的开关。它失败时通常静默，不报错，只让 $_SESSION 始终为空。
- 必须放在脚本最开头，前面不能有任何输出（包括 UTF-8 BOM、空格、
echo、HTML 标签） - 用
session_status() === PHP_SESSION_ACTIVE显式判断是否真启动成功，别只靠isset($_SESSION) - 检查
session.save_path是否可写（ini_get('session.save_path')+is_writable()） - 反向代理或负载均衡环境下，需确保 session 存储（如 Redis）一致，且 Cookie 的
domain设置匹配访问域名
$_SERVER['HTTP_HOST'] 和 $_SERVER['SERVER_NAME'] 到底该用谁？
一个来自客户端请求头（可伪造），一个来自服务器配置（不可篡改），用途完全不同。
- 拼接跳转 URL、生成当前页面绝对链接时，用
$_SERVER['HTTP_HOST']—— 它反映用户实际访问的地址（比如https://$_SERVER['HTTP_HOST']/callback） - 做白名单校验、API 域名限制、内部服务路由时，用
$_SERVER['SERVER_NAME']—— 它由 Nginx/Apache 配置决定，更可信 - 反向代理下
HTTP_HOST可能被清空或污染，此时应结合$_SERVER['SERVER_ADDR']和$_SERVER['SERVER_PORT']做 fallback - 注意：
$_SERVER['HTTPS']是字符串"on"或空，不是布尔值，别写if ($_SERVER['HTTPS'])
$_REQUEST 能不能图省事直接用？
能，但代价是调试困难、安全边界模糊、来源不可控。它把 $_GET、$_POST、$_COOKIE 全混在一起，同名键会被后者覆盖（默认顺序：CGP，即 Cookie > GET > POST）。
立即学习“PHP免费学习笔记（深入）”；
- 登录页如果允许
?next=/admin传跳转地址，又同时接收$_REQUEST['next']，攻击者可能通过 Cookie 注入恶意跳转 - 排查“参数突然变”问题时，你得翻三处来源，而明确用
$_POST['submit']就只看表单提交逻辑 - 框架和现代项目基本弃用它；PHP 8.1+ 已标记为“不鼓励使用”，未来可能移除
- 真要统一入口，建议封装函数：
function input(string $key, string $method = 'post'): ?string { ... }，自己控制优先级和过滤
$_FILES 为空不只是因为没选文件，还可能是 upload_max_filesize 超限却没报错；$_COOKIE 读不到，未必是没设，可能是 Secure 或 SameSite 策略拦截。这些细节不跑一次真实请求+抓包+查日志，光看文档永远摸不准。 
