ci3不内置delete防护机制，需开发层面主动约束：模型层强制where条件、封装safe_delete方法校验、启用查询日志审计、数据库权限分级隔离、引入软删除替代物理清空。
CI3（CodeIgniter 3）本身不内置针对 DELETE 语句的自动防护机制，所谓“防止无条件清空数据表”，本质是开发层面的主动约束，而非框架默认行为。直接执行 $this->db->empty_table('users') 或 $this->db->delete('users')（无 where）时，CI3 不会拦截、警告或拒绝——它信任开发者传入的逻辑。因此，安全防护必须靠人为设计和流程加固。
在模型层强制要求 WHERE 条件
这是最直接有效的控制点。重写或封装删除方法，拒绝无条件操作：
- 不要直接调用
$this->db->delete('table')，而是统一走自定义方法，例如safe_delete($table, $where) - 在该方法中判断
$where是否为空或是否为数组且含有效键值，若不满足则抛出异常或记录告警 - 示例逻辑：
if (empty($where) || !is_array($where) || count($where) === 0) { throw new RuntimeException('DELETE requires non-empty WHERE condition'); }
启用查询日志与执行前审核
利用 CI3 的查询日志功能，在关键环境（如生产或预发布）开启 SQL 审计：
- 设置
$db['default']['save_queries'] = TRUE;，并在删除操作后检查生成的 SQL 是否含WHERE - 结合钩子（
post_system或自定义 hook），对包含DELETE FROM table_name且无WHERE的语句触发告警（如发邮件、写入监控平台） - 注意：此方式不能阻止执行，但可实现快速发现与追溯
数据库权限分级隔离
从基础设施层降低误操作影响面：
- 为应用数据库账号移除
DROP和TRUNCATE权限；对DELETE权限保持开放，但仅授予必要表 - 生产环境禁止使用具有
root或DBA权限的账号连接应用 - 配合只读账号用于报表类接口，写操作账号严格限定可删表范围（如通过视图或存储过程封装）
引入软删除替代物理清空
从根本上规避“清空”风险，尤其适用于用户、订单、日志等需保留痕迹的表：
- 添加
deleted_at字段（datetime 类型，允许 null） - 修改模型基类的
get()、find()等读取方法，默认附加WHERE deleted_at IS NULL - 将
delete()方法重载为更新deleted_at时间，而非真实删除 - 真正需要清空时，走 DBA 审批后的离线脚本，而非应用接口
