bindparam()的类型参数需严格匹配变量实际类型与数据库字段定义：pdo::param_str（默认，安全兜底）、pdo::param_int（仅限整型变量+int/bigint字段）、pdo::param_bool（仅限true/false）、pdo::param_null（显式绑定null）；mysqli则用"s""i""d""b"字符对应字符串、整数、浮点、二进制，必须与php变量内存类型一致，不可依赖其做类型清洗。
pdo::prepare() 中 bindparam() 的类型参数怎么选
PHP 使用 PDO 操作数据库时，bindparam() 第三个参数决定绑定值的 SQL 类型，不指定或选错会导致隐式转换失败、截断、甚至 SQL 注入风险（比如把字符串当整数处理后绕过校验）。
常见错误现象：bindparam(':id', $id) 不传类型，当 $id 是字符串 "123abc" 时，MySQL 可能静默转成 123；而 PostgreSQL 直接报错 ERROR: invalid input syntax for integer。
-
PDO::PARAM_STR：默认值，适用于所有字符串、NULL、布尔（会转成"1"或""），最安全的兜底选择 -
PDO::PARAM_INT：仅当变量是整型且数据库字段为INT/BIGINT时用；注意 PHP 的int在 32 位系统上限是 2147483647，超大会被转成 float，此时必须用PDO::PARAM_STR配合BIGINT字段 -
PDO::PARAM_BOOL：只传true/false，映射到 MySQL 的TINYINT(1)或 PostgreSQL 的BOOLEAN；不要传1/0整数再配这个类型，会出错 -
PDO::PARAM_NULL：显式绑定 NULL，比传null变量更明确，尤其在联合类型字段（如INT NULL）中避免歧义
MySQLi 中 bind_param() 的类型字符必须严格匹配变量实际类型
MySQLi 的 bind_param() 不靠常量，而是用字符串中单个字符声明类型："s"（string）、"i"（integer）、"d"（double）、"b"（blob）。这里不是“期望类型”，而是“当前变量内存里的类型”——PHP 会按这个字符去解释变量二进制内容。
典型翻车场景：从 $_GET['page'] 拿到的 "1" 是字符串，但写了 bind_param("i", $page)，PHP 就强行把它当整数解析；如果 $page = "1abc"，MySQLi 会截成 1 并静默执行，查不到预期数据却无报错。
- 始终先用
filter_var($input, FILTER_VALIDATE_INT)或is_int()校验后再绑定，别依赖bind_param()做类型清洗 - 浮点数统一用
"d"，哪怕值是5.0；用"i"强转会丢小数位 - 二进制数据（如图片 blob）必须用
"b"，且需配合mysqli_stmt::send_long_data()分段写入，直接bind_param("b", $data)只适合小 blob
PostgreSQL 的 pg_query_params() 为什么几乎不用手动指定类型
PostgreSQL 协议本身支持类型推导，pg_query_params() 的参数数组里传什么 PHP 类型，驱动就按对应 PostgreSQL 类型发送（string → TEXT/CHAR，int → INTEGER，null → NULL）。它没有类似 PDO 的 bindparam() 类型参数，也不需要。
但陷阱藏在边界情况里：
- PHP 的
float传过去是DOUBLE PRECISION，如果字段是NUMERIC(10,2)，可能因精度丢失被拒绝插入，得先用round($val, 2)或转成字符串再传 - 时间类字段（
TIMESTAMP WITH TIME ZONE）接收字符串时，必须符合 ISO 8601 格式（如"2024-05-20T14:30:00+08:00"），不能传"2024-05-20 14:30:00"——后者会被当成本地时区，时区偏移错乱 - JSON 字段要传
json_encode()后的字符串，不是 PHP 数组；否则 PostgreSQL 收到的是"Array"字符串字面量
ORM 层（如 Laravel Eloquent）里类型绑定藏在哪
Eloquent 本身不暴露绑定类型接口，类型由模型的 $casts 属性和数据库连接驱动共同决定。比如 'status' => 'boolean' 会让写入时自动转成 tinyint(1)，读取时转回布尔——但这只是 PHP 层转换，底层 PDO 绑定仍是 PDO::PARAM_STR。
真正影响绑定类型的，是连接配置里的 options：
- 加
PDO::ATTR_EMULATE_PREPARES => false：强制走真实预编译，让 PostgreSQL/MySQL 服务端做类型校验，能提前暴露类型不匹配问题（例如把字符串绑到INT字段） - 不加该选项（默认 true）：PDO 自己模拟预编译，把所有参数当字符串拼进 SQL，失去类型保护，也容易触发 MySQL 的 prepared statement 缓存 bug
- Laravel 8+ 默认关闭模拟预编译，但老项目升级后若出现
"SQLSTATE[HY093]: Invalid parameter number"错误，大概率是某处用了未定义的占位符名，跟类型无关，先检查 SQL 字符串
类型绑定不是“写完能跑就行”的环节，尤其在跨数据库迁移或处理用户输入时，一个 PDO::PARAM_INT 和 PDO::PARAM_STR 的差别，可能让同一条语句在 MySQL 里成功、PostgreSQL 里报错、SQLite 里静默截断——验证输入类型、匹配字段定义、关掉模拟预编译，这三步漏掉任何一步，都可能变成线上排查半夜三点的 bug。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
