必须启用yii_debug和错误显示才能暴露真实错误：在web/index.php中确认defined('yii_debug') or define('yii_debug', true);、yii_env='dev'，并添加error_reporting(e_all); ini_set('display_errors', '1');；redis的noauth错误需检查password配置是否缺失、错误或被覆盖；serialization of 'closure'错误源于behaviors中匿名函数，应移至beforesave/aftersave处理。
Yii2 存储服务（如 Redis、数据库）报错时，默认往往不显示具体错误，只返回白屏或 500 Internal Server Error，根本原因是错误被 ErrorHandler 拦截且未开启调试模式。必须让真实错误浮出来，才能定位是连接失败、认证失败，还是序列化问题。
确认 YII_DEBUG 和错误显示已强制启用
生产环境默认静默吞异常，开发阶段第一步不是查代码，而是确保错误能“说出来”：
- 打开
web/index.php，确认存在且未注释：defined('YII_DEBUG') or define('YII_DEBUG', true); - 同时追加两行（放在
require __DIR__ . '/../vendor/autoload.php';之前）：error_reporting(E_ALL);和ini_set('display_errors', '1'); - 检查
YII_ENV是否为'dev'（同文件中），否则YII_DEBUG可能不生效
做完这三步再触发存储操作，如果仍白屏，说明 Web 服务器（如 Apache/Nginx）本身拦截了错误，需查其 error log。
Redis 报 “NOAUTH Authentication required” 怎么提示和修复
这类错误本质是配置层问题，但 Yii2 不会直接抛出可读异常，而是封装成 yii\db\Exception 或静默失败。关键要区分是密码没配、配错，还是配置被覆盖：
- 检查
main-local.php中redis配置是否含'password' => 'xxx'，且值与 Redis 服务实际密码一致 - 确认没有在
main.php里写死一个不同密码——main-local.php会覆盖main.php，但如果它没定义password，则回退到main.php的值，导致 AUTH 命令发错密码 - 用命令行验证：
redis-cli -h 127.0.0.1 -p 6379 -a your_password ping，返回PONG才算通
若云 Redis（如 AWS ElastiCache）不设密码，务必在配置中**完全删除 password 键**，而不是设为空字符串，否则 Yii2 仍会发送 AUTH 命令（带空参），触发认证失败。
“Serialization of 'Closure' is not allowed” 提示怎么定位
这个错误明确指向对象序列化失败，常见于把带闭包的 ActiveRecord 实例存进 Redis 缓存。它不会在控制器里直接抛出，而是在缓存写入时静默失败，后续读取返回 null，造成逻辑错乱：
- 典型诱因是
behaviors()中用了匿名函数，例如'value' => function() { return date('Y-m-d H:i:s'); } - 搜索项目中所有
behaviors()方法，检查返回数组里是否含function或fn关键字 - 临时在缓存调用前加
var_dump($model); die;，观察输出里是否有Closure字样 - 修复方式不是改序列化设置，而是重构：把闭包逻辑移到
beforeSave()或afterSave()，或显式转成数组再缓存
这个错误容易被忽略，因为模型本身能正常保存到数据库，只有缓存路径才会触发——所以只要用了 $cache->set() 存模型实例，就必须检查其行为定义是否“可序列化”。
数据库异常怎么让前端看到具体 SQL 错误
Yii2 默认对 yii\db\Exception 也走统一错误页，但开发时你需要立刻看到 SQL 和绑定参数，而不是“执行失败”四个字：
- 确保
components.errorHandler.maxSourceLines设为足够大（如50），否则堆栈里看不到 SQL 上下文 - 在
config/web.php的components中加入日志配置：'log' => ['targets' => [['class' => 'yii\log\FileTarget', 'levels' => ['error', 'warning']]] - 手动触发 DB 异常时（如故意写错表名），查看
runtime/logs/app.log，里面会有完整 SQL、参数、驱动错误码 - 不建议在生产环境开启
YII_DEBUG，但可在日志里保留yii\db\Command::execute级别，方便追溯
真正难排查的不是报错本身，而是错误发生后没留下任何线索——所以从第一天起就要确认日志路径可写、日志级别包含 error，且 runtime 目录权限正确（尤其 Windows 下容易因权限导致日志写失败）。
