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