php 8 防 sql 注入需 strict_types=1 + 真实预处理 + 类型校验：strict_types 阻止隐式转换，禁用模拟预处理确保服务端执行，强类型声明提前拦截非法输入，联合类型与内置函数强化语义校验。
PHP 8 环境下防 SQL 注入，只靠 PDO::prepare 或 mysqli_prepare 不够——必须配合强类型声明和严格绑定逻辑，否则照样可能漏掉数字型绕过、类型隐式转换、模拟预处理退化等漏洞。
为什么 PHP 8 的 strict_types=1 对防注入有实际作用
PHP 8 默认仍是弱类型兼容模式，intval("1 OR 1=1") 会返回 1，看似“安全”，但掩盖了输入污染问题。启用 declare(strict_types=1) 后：
- 函数参数类型声明（如
function getUserById(int $id): array）会在调用时立即拒绝非整数输入，避免把恶意字符串当整数传入 -
(int)$_GET['id']这类强制转换不再“兜底”——如果用户传的是id[]=1，数组无法转成 int，直接抛TypeError，而不是静默变成0导致查不到数据却无报错 - 配合
PDO::PARAM_INT绑定时，若变量实际是字符串，PDO 不会自动转换，而是按类型报错或截断，暴露问题而非掩盖
禁用 PDO 模拟预处理：PDO::ATTR_EMULATE_PREPARES = false
PHP 8 默认仍开启 PDO::ATTR_EMULATE_PREPARES = true，这意味着 prepare() 只是 PHP 自己做字符串替换，再发完整 SQL 给 MySQL——跟拼接没本质区别。
- 必须在创建 PDO 实例后立即设置：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - 若连接失败（比如 MySQL 不支持服务端预处理），
prepare()会返回false，不能直接链式调用->bindValue()，否则致命错误 - 验证是否生效：执行
SELECT @@session.prepared_stmt_count，真实预处理后该值应 +1
mysqli_bind_param 的类型字符串陷阱与 PHP 8 类型校验协同
mysqli_stmt_bind_param() 第一个参数是类型字符串（如 "is"），它不校验变量实际类型，只按内存布局塞值。PHP 8 的强类型能提前拦截这类隐患：
- 声明函数参数为
string $email, int $status，就能防止$_POST['status']是字符串"active"被误传进来 - 绑定前必须确保变量已赋值且类型匹配：
$status = (int)$_POST['status'];比$stmt->bind_param('si', $_POST['email'], $_POST['status'])安全得多 - 字段名、表名、
ORDER BY方向等非值上下文，仍需白名单校验：$order = in_array($_GET['sort'], ['name', 'created_at']) ? $_GET['sort'] : 'id';
容易被忽略的边界点：空值、联合类型与 NULL 安全
PHP 8 的 ?string、int|null 等联合类型不是摆设，它们直接影响绑定行为：
- 可空参数必须显式处理：
function searchUser(?string $keyword): array，不能直接bindValue(':kw', $keyword, PDO::PARAM_STR)——当$keyword === null时，应改用PDO::PARAM_NULL -
str_starts_with()、filter_var(..., FILTER_VALIDATE_EMAIL)等 PHP 8 内置函数，应在绑定前完成语义校验，而非依赖数据库层报错 - 即使用了预处理，
WHERE id IN (?)仍是错的——IN 子句无法用单个占位符，必须动态生成占位符串并绑定数组，或改用临时表
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
