数据清洗不该塞进迁移文件，codeigniter的migration仅负责结构变更（如create table、alter column），数据清洗应使用自定义cli命令或seeder，避免污染迁移历史、破坏可回滚性与迁移压缩兼容性。
数据清洗不该塞进迁移文件
CodeIgniter 的 migration 仅负责结构变更（如 CREATE TABLE、ALTER COLUMN），不是数据清洗工具。把 DELETE FROM users WHERE created_at 这类语句硬塞进迁移，会导致回滚失败、压缩（<code>squash）异常、部署时意外删生产数据。
真正该做的是：用独立的 artisan 命令（CI4）或自定义 CLI 脚本（CI3）处理数据。例如：
php spark db:clean-old-users --before=2020-01-01
这类命令可加 dry-run 参数预览影响行数，可记录日志，可手动触发，不污染迁移历史。
验证错误信息里有换行和空格？先 trim 再存 flashdata
当调用 validation_errors() 并用 set_flashdata() 传递给前端时，返回值常含末尾换行符或多余空格，导致 JS 弹窗显示错位或空白行。
正确做法是在存入 session 前清洗字符串：
- 用
trim()去首尾空白 - 再用
preg_replace('/\s+/', ' ', ...)合并中间多个空白为单个空格（可选） - 避免直接输出未处理的
validation_errors()到 JS 字符串中
示例控制器逻辑：
$errors = trim(validation_errors());
$this->session->setFlashdata('submit-error', $errors);
表单提交成功后字段还残留？检查是否误用了 old() 或 set_value()
CI4 中没有 clear_field_data()，但表单仍“不清空”，大概率是视图里写了类似 value="= old('email') ?>" 或 value="= set_value('email') ?>" ——而你又在成功提交后没重定向，而是直接 return view('form')。
此时 old() 会从上一次 POST 的会话缓存中读出旧值，导致字段始终回填。解决方法只有两个：
- 严格走 PRG 模式：成功后必须
return redirect()->to('success')或return redirect()->back() - 如果非得原页渲染（极少见），手动清空旧输入：
$this->session->remove('old');
注意：old() 和 set_value() 是为验证失败服务的，不是为“成功后保留”设计的。
数据库查询缓存干扰清洗结果？记得 cache_off() 和精准 delete
如果你在数据清洗脚本里查了某张表（比如先 SELECT COUNT(*) 统计待删数量），又紧接着执行 DELETE，但没关缓存或没清对应缓存文件，下次查可能还是旧的 COUNT 结果。
关键点：
-
$this->db->cache_on()只对它之后**第一个**SELECT生效，别漏掉cache_off() -
INSERT/UPDATE/DELETE不触发缓存，但也不会自动失效已有缓存 - 清洗前，用
$this->db->cache_delete('users')清掉相关路径缓存，比cache_delete_all()更安全
缓存目录路径含 URI 分段，所以 cache_delete('admin', 'users') 比盲目删整个 application/cache/database/ 更可控。
