我之前也踩过CI3这个边缘情况的坑，这其实是Query Builder处理空where_in数组时的设计缺陷，再结合数据库驱动的错误处理逻辑导致的异常表现。

问题根源 #

当你给where_in传入空数组时，CI会生成语法完全无效的SQL（比如WHERE col_2_name IN ()），这种SQL会触发数据库的致命语法错误。虽然CI文档明确说明delete()执行失败时返回FALSE，但这里的特殊情况是：即使db_debug设为FALSE，底层数据库驱动遇到这种致命语法错误时，会直接终止脚本执行，而不是让Query Builder捕获错误并返回FALSE——CI3的错误处理机制在这个场景下没能正确拦截错误并转化为预期的返回值，只会把错误写入日志后就结束进程。

最稳妥的解决方案 #

核心思路是在执行删除操作前手动校验输入参数，避免生成无效SQL：

// 先检查where_in的数组是否有效
if (empty($array)) {
    log_message('error', '尝试执行删除操作，但where_in对应的数组为空');
    return FALSE; // 手动返回FALSE，符合业务预期逻辑
}

// 数组有效时再执行删除流程
$result = $this->db->where('col_1_name', 'value')
                   ->where_in('col_2_name', $array)
                   ->delete('table_name');

return $result;

如果你不想在每个用到where_in的地方都写校验逻辑，可以封装一个自定义的安全where_in方法（比如在你的基础Model里），内部自动做空数组检查，避免生成无效SQL。不建议直接修改CI核心文件（比如system/database/DB_query_builder.php），因为后续框架升级会覆盖你的修改。

额外补充 #

哪怕把db_debug设为TRUE，这种场景下也可能直接抛出页面错误而非返回FALSE，因为无效SQL属于数据库层面的致命语法错误，CI的错误处理机制无法完全拦截并转化为返回值。提前校验输入参数是最可靠的规避方式。

内容的提问来源于stack exchange，提问作者nvkrj