UPDATE只修改SET中指定字段，其他字段保持不变；需动态拼接SET、用命名占位符防顺序错乱、严格校验WHERE条件、启用PDO异常模式并检查SQL模式与数据长度。
UPDATE语句里只写要改的字段，其他字段不会动
PHP 中执行 UPDATE 时，数据库本身就不会碰你没列出来的字段——这是 SQL 标准行为，不是 PHP 的功能。只要你的 SET 子句里只包含 name = ?, status = ? 这类赋值，email、created_at 等字段就完全不受影响。
常见错误是误以为“不传某个参数=设为空”，结果在 PHP 拼 SQL 时把未传字段也塞进了 SET，比如硬编码写成 SET name = ?, email = ?, status = ?，但只给前两个占位符绑定值，第三个就变成 NULL 或报错。
- 只把用户真正修改过的字段加进
SET，比如表单只提交了title和is_published，SQL 就只写这两个 - 用数组动态拼接
SET部分：$fields = []; $params = [];，对每个待更新字段array_push($fields, "$key = ?"); array_push($params, $value); - 注意空字符串
''和NULL的区别：如果业务允许空字符串，就传''；如果字段定义为NOT NULL，别让它意外变成NULL
用 PDO 预处理时，bindParam 要和 ? 顺序严格对应
很多人写 $stmt->execute([$name, $status])，但忘了 SQL 里 ? 出现顺序必须和数组元素顺序一致。一旦字段动态增减，顺序错乱就会导致数据写到错误字段上——比如把 $status 值写进 name 字段。
更稳妥的做法是用命名占位符（:name、:status），避免依赖位置：
立即学习“PHP免费学习笔记（深入）”；
$sql = "UPDATE posts SET title = :title, is_published = :is_published WHERE id = :id";
$stmt = $pdo->prepare($sql);
$stmt->bindParam(':title', $title, PDO::PARAM_STR);
$stmt->bindParam(':is_published', $is_published, PDO::PARAM_INT);
$stmt->bindParam(':id', $id, PDO::PARAM_INT);
$stmt->execute();
- 命名占位符不怕字段增减或顺序调整，可读性也强
- 如果坚持用问号占位符，务必确保
execute()数组和 SQL 中?的出现顺序 1:1 对齐 - 不要在
WHERE条件里混用未过滤的变量——哪怕只更新指定字段，WHERE id = $_GET['id']仍是 SQL 注入高危点
WHERE 条件漏写或写错，会导致全表误更新
这是最危险的坑：UPDATE users SET status = 0 没加 WHERE，整张表用户全被禁用。PHP 里常因条件判断逻辑疏漏导致这个问题，比如 if ($id) { ... } else { // 忘了 return 或 throw } ，结果走到 execute() 时 $id 是空或 0，WHERE id = 0 又恰好匹配到默认记录。
- 强制校验
WHERE所需参数存在且合法，例如if (empty($id) || !is_numeric($id)) { throw new InvalidArgumentException('Invalid ID'); } - 开发环境打开 PDO 的异常模式：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)，让错写 SQL 时直接报错，而不是静默失败 - 上线前在测试库执行
EXPLAIN UPDATE ...（部分 MySQL 版本支持）或先用SELECT COUNT(*)验证WHERE是否命中预期行数
批量更新多个字段时，注意 MySQL 的 STRICT_TRANS_TABLES 模式
当某字段有长度限制（如 VARCHAR(10)），而你试图更新超长值，在启用严格模式时会报错 Data too long for column；否则可能被截断且无提示。PHP 层看不到这个“成功”，但数据已失真。
- 检查 MySQL 当前 SQL 模式：
SELECT @@sql_mode;，确认是否含STRICT_TRANS_TABLES - 对用户输入做前置校验，比如用
mb_strlen($title) 匹配数据库字段定义，比等报错再处理更可控 - 更新后可用
$stmt->rowCount()判断是否真有行被修改——返回 0 不代表失败，可能是新旧值一样，但也可能是WHERE没匹配到任何行
字段级更新看着简单，但动态拼接、占位符顺序、WHERE 安全、数据截断这四点，任一出问题都可能引发线上事故。尤其在表结构随业务频繁变动时，靠人肉核对 SQL 很难兜住底。
