仅加 is_del 字段不能实现可靠软删除，因易遗漏过滤、破坏框架功能、引发数据一致性问题；须配合全局查询约束、字段初始化、索引优化及全链路改造。
PHP 软删除为什么不能只加 is_del 字段就完事？
加一个 is_del 字段只是软删除的起点，不是终点。直接在所有查询里手动加 WHERE is_del = 0 极易遗漏，尤其在关联查询、统计、分页或第三方库调用时。一旦漏写，用户就能看到“已删除”数据，或者误删未标记的数据。
怎么让 Laravel 的 Eloquent 自动过滤软删除记录？
Laravel 原生支持软删除，但必须用 SoftDeletes trait + deleted_at 字段，而不是自定义 is_del。强行用 is_del 会导致 delete() 不生效、restore() 报错、withTrashed() 失效——因为框架底层只识别 deleted_at。
如果你必须用 is_del（比如 legacy 表结构不允许改字段），就得手动重写模型行为：
class User extends Model
{
protected $casts = [
'is_del' => 'boolean',
];
public function scopeActive($query)
{
return $query->where('is_del', false);
}
public function delete()
{
$this->is_del = true;
return $this->save();
}}
立即学习“PHP免费学习笔记（深入）”；
使用时必须显式调用：User::active()->find(123)，否则 User::find(123) 仍会查出已“删除”的记录。
MySQL 查询中漏掉 is_del = 0 的典型场景
- 原始 SQL 拼接：比如
"SELECT * FROM user WHERE id = {$id}"完全没判断is_del - JOIN 查询：左表加了条件，右表没加，导致“已删除用户”的订单仍被查出来
- COUNT 统计：写
SELECT COUNT(*) FROM user得到的是总行数，不是有效用户数 - 缓存键未包含
is_del状态：缓存了含已删除数据的结果，后续请求一直读脏数据
硬切换到软删除时最常踩的坑
已有线上数据，is_del 字段默认值是 NULL 或 1，会导致历史数据全被当成“已删除”。必须在加字段后立刻执行初始化：
ALTER TABLE `user` ADD COLUMN `is_del` TINYINT(1) DEFAULT 0 NOT NULL; UPDATE `user` SET `is_del` = 0 WHERE `is_del` IS NULL;
另外，所有索引都要重新评估——如果高频查询都带 is_del = 0，建议把 is_del 加进联合索引，例如：INDEX idx_status_id (is_del, id)。否则 MySQL 可能全表扫描过滤掉大量已删除记录。
真正麻烦的不是加字段，而是让所有读写路径都意识到这个字段的存在。哪怕 ORM 层封装好了，原生 SQL、定时任务、数据分析脚本、ES 同步逻辑，都得逐个对齐。
