应根据html表单的method属性决定使用$_post或$_get：method="post"用$_post，method="get"用$_get；未声明method时浏览器默认get，易导致undefined index警告；需用$_server['request_method']确认实际请求类型。
$_POST 和 $_GET 到底该用哪个
看表单 method 属性决定——method="post" 就用 $_POST，method="get" 就用 $_GET。别硬记“登录用 POST、搜索用 GET”，先查 HTML 表单源码里的 method 值。
常见错误现象：Undefined index 警告满屏，但表单明明填了内容。大概率是 PHP 在读 $_POST['username']，而实际表单发的是 GET 请求（或反之）。
- 表单没写
method，浏览器默认按 GET 发，PHP 却在$_POST里找——查$_SERVER['REQUEST_METHOD']确认实际请求类型 -
GET数据会出现在 URL 里，长度受限（一般 2KB 左右），敏感信息（密码、token）绝不能走$_GET -
POST没有长度硬限制，但大文件上传需检查post_max_size和upload_max_filesize配置
isset() 和 empty() 判空的区别很关键
直接访问 $_POST['email'] 会触发 Notice: Undefined index；用 empty() 又可能把值为 "0" 或 0 的合法数据误判为空。
正确做法是：先确认键存在，再判断是否有效值。
立即学习“PHP免费学习笔记（深入）”；
- 用
isset($_POST['email'])检查字段是否提交（哪怕值是空字符串""或null，只要键存在就返回true） - 用
!empty($_POST['email'])检查是否非空且非假值（但"0"会被判空，慎用于数字 ID 类字段） - 更安全的写法：
isset($_POST['email']) && trim($_POST['email']) !== ''，兼顾存在性与非空白
中文乱码不是 PHP 错，是编码链断了
表单提交中文变问号或方块，90% 是 HTML 页面、表单、PHP 文件、数据库四者编码不统一，PHP 本身不改编码，只照收照传。
必须逐环确认：
- HTML 页面顶部有
<meta charset="UTF-8">，且保存为 UTF-8 编码（无 BOM） - 表单加
accept-charset="UTF-8"属性：<form accept-charset="UTF-8"></form> - PHP 文件本身用 UTF-8 编码保存（编辑器右下角看，别用记事本）
- 如果存数据库，连接时执行
SET NAMES utf8mb4（MySQL）或等效操作
漏一环，$_POST['name'] 拿到的就是乱码字节，后续怎么转都救不回来。
$_REQUEST 不是快捷方式，是隐患开关
$_REQUEST 默认合并了 $_GET、$_POST、$_COOKIE，看似方便，实则模糊了数据来源，容易被绕过校验。
比如你用 $_REQUEST['id'] 做权限检查，攻击者可以把本该 POST 提交的 id 改成 GET 参数附在 URL 后，绕过你只验证 POST 的逻辑。
- 明确数据入口：登录表单用
$_POST，搜索框用$_GET，别混用 - 禁用
$_REQUEST：在php.ini中设request_order = "GP"（去掉C），或干脆不碰它 - 框架里基本不用
$_REQUEST，原生开发也建议主动放弃
表单变量获取看着简单，但每个环节松动一点，后面调试两小时都找不到源头——尤其是编码和请求方法错配，最常发生在复制旧代码改新功能时。
