php表单处理必须强制服务端验证，用$_server["request_method"]=== "post"包裹流程，结合filter_var()与preg_match()分层校验，清洗（trim、htmlspecialchars）须在验证前，回显必转义，数据库操作须预处理，上传和csrf须专项防护。
PHP处理表单提交时，服务端验证不是“可选项”，而是数据入库前的强制关卡；跳过它或逻辑松散，$_POST 数据就会直接撞进数据库或触发XSS——哪怕前端写了10层JS校验。
判断请求方法并隔离POST逻辑
必须用 $_SERVER["REQUEST_METHOD"] === "POST" 包裹整个处理流程，否则脚本一加载就执行验证、清空错误变量、甚至尝试插入空数据。这不是防御，是裸奔。
- 不要只靠
isset($_POST["submit"])判断——按钮名可能被删、type可能写错、用户可能用curl直发POST而无submit字段 - 如果表单action为空（即提交到自身），
$_SERVER["PHP_SELF"]必须经htmlspecialchars()输出，否则会引发反射型XSS：<form action="<?=%20htmlspecialchars(%24_SERVER[" php_self>"></form> - 不推荐在GET请求里做数据修改操作，敏感字段（如密码、token）绝不能出现在URL中
用 filter_var() 和 preg_match() 分层验证字段
filter_var() 适合标准化类型（邮箱、整数、URL），快且可靠；preg_match() 用来兜底复杂规则（如中文姓名、密码强度、手机号段）。二者不是二选一，而是先后顺序：先过基础类型，再压细粒度规则。
-
filter_var($email, FILTER_VALIDATE_EMAIL)只校验格式，不查DNS；若需域名有效性，得额外调用checkdnsrr()，但要注意超时和性能影响 - 手机号正则别硬套
/^1[3-9]\d{9}$/——它漏掉170/171等虚拟运营商号段，也拦不住带+86或空格的合法输入；建议先preg_replace('/\D/', '', $phone)清洗再匹配 - 对数字范围限制（如年龄1~120），别只用
filter_var($age, FILTER_VALIDATE_INT, ["options" => ["min_range"=>1, "max_range"=>120]])，因为该过滤器会把字符串"12a"转成12并返回true；应先is_numeric()+ctype_digit()组合判断
回显数据必须用 htmlspecialchars() 转义
用户填错后重载页面，你把 $_POST["comment"] 直接塞进 <textarea>= $_POST["comment"] ?></textarea>，等于给XSS开绿色通道。所有回显值，无论来源是否“可信”，都必须过 htmlspecialchars()。
- 不要只对输出做一次转义就完事——如果后续逻辑又把该值拼进SQL或JS上下文，得按目标环境重新编码（如进JS要用
json_encode()，进SQL必须用预处理） - 密码字段永远不回显：
<input type="password" value="<?= htmlspecialchars($password) ?>">是严重错误；应始终留空，并在错误提示中说明“请重新输入” - radio/checkbox的
checked状态判断，要用isset($gender) && $gender === "male"，而不是$gender == "male"，避免字符串与数字0的弱比较陷阱
验证通过才执行数据库写入，且必须用预处理
最常见的错误是：验证失败时设了 $valid = false，但插入代码没包在 if ($valid) 里，或者验证块和插入块之间混进了其他逻辑（比如日志记录、邮件发送），导致非法数据照常入库。
- PDO预处理不是“加个问号”就完事——绑定参数必须用
bindParam()或execute([':name' => $name])，不能拼接字符串；filter_var()验证过的邮箱，仍可能含SQL元字符，不预处理照样中招 - 文件上传字段（
$_FILES）必须单独验证：is_uploaded_file()+move_uploaded_file()+ 类型白名单（如in_array($mime, ["image/jpeg", "image/png"])），绝不能依赖$_FILES["file"]["type"]，它由浏览器提供，完全不可信 - CSRF防护不能省：生成一次性token存session，表单里放隐藏域，提交后比对；否则攻击者构造恶意页面诱导用户点击，就能以用户身份发请求
最易被忽略的点：验证逻辑和数据清洗（trim()、htmlspecialchars()）的顺序。先清洗再验证，还是先验证再清洗？答案是——清洗必须在验证之前完成，否则空格会导致 empty() 判定失准，特殊字符会干扰正则匹配。但清洗后的值，才是你最终存库和回显的唯一可信源。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
