PHP删除必须服务端二次确认、POST提交、校验数据归属、预处理SQL、重定向防重复。关键在于隔离确认与执行流程，并验证用户权限，否则易致越权或误删。
PHP 删除前必须拦截用户操作
直接执行 DELETE 语句没有任何防护，一旦点击就删，连 Undo 都没有。真实项目里，所有可删除入口都得强制加二次确认——不是靠 JS 弹窗“确定吗？”这种容易被绕过的前端提示，而是服务端必须验证用户是否明确触发了“确认删除”动作。
用隐藏字段 + 表单状态区分“点击删除”和“确认删除”
常见错误是把删除逻辑写在 GET 请求里（比如 /delete.php?id=123），这会导致浏览器刷新、爬虫抓取甚至 Referer 泄露时误删。正确做法是用 POST 表单，并通过一个隐藏字段标识当前请求阶段：
后端判断 $_POST['step'] === 'confirm' 才执行 SQL；否则只渲染确认页面。这样即使用户刷新确认页，也不会重复提交删除。
数据库操作前必须查一遍是否存在且归属当前用户
防止越权删除的关键不是“用户点了确认”，而是“用户有权删这条”。不能只校验登录态，必须查库确认该记录的 user_id 或权限字段匹配当前会话：
立即学习“PHP免费学习笔记（深入）”；
-
SELECT id FROM posts WHERE id = ? AND user_id = ?—— 查不到就直接报错或跳回列表页 - 别用
DELETE FROM posts WHERE id = ?直接删，要带上归属条件：DELETE FROM posts WHERE id = ? AND user_id = ? - 用 PDO 预处理，避免拼接 ID 导致 SQL 注入：
$stmt = $pdo->prepare("DELETE FROM posts WHERE id = ? AND user_id = ?");
删完必须重定向，禁止留在原页面
删完如果还留在 POST 页面，用户按 F5 就会再次提交——这是最常被忽略的坑。删成功后务必用 header('Location: /posts') 跳转，且跳转前要确保事务已提交或错误已捕获。
更稳妥的做法是删完跳转到带提示的页面，比如：header('Location: /posts?msg=deleted')，然后在列表页读取 $_GET['msg'] 显示绿色提示。这样既防重复提交，又给用户明确反馈。
真正危险的不是不会写 SQL，而是没把「确认动作」和「执行动作」在流程上彻底隔离，也没校验数据归属。只要漏掉其中一环，删库跑路就只是多点一次鼠标的事。
