ThinkPHP因日志目录不可写导致崩溃且无错误输出，根本原因是Log::write()静默失败后异常处理链断裂。应确保runtime/可写、开启display_errors、注册shutdown_function捕获致命错误，并配置日志fallback机制。
日志目录不可写导致 ThinkPHP 崩溃且无错误输出
ThinkPHP 默认在 runtime/log/ 下写日志，一旦该目录权限不足、磁盘满或被误删，Log::write() 会静默失败，而后续若又触发异常（比如数据库连接失败），因日志系统已瘫痪，think\exception\Handle 尝试记录错误时再次失败，最终直接 Fatal error: Uncaught Exception，页面白屏且无任何线索。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 上线前务必确认
runtime/目录可写，且父路径（如storage/）不被 open_basedir 限制 - 用
ls -ld runtime/ runtime/log/检查权限，非 CLI 环境下注意 Web 服务器用户（如www-data或nginx）是否拥有写权限 - 临时应急：在
public/index.php顶部加error_log("TP start at " . date('Y-m-d H:i:s'), 3, '/tmp/tp_boot.log');，绕过框架日志系统捕获最早期启动状态
开启 app_debug = true 但依然看不到异常堆栈
调试模式开启后仍白屏，常见原因是 PHP 配置压制了错误显示：display_errors = Off 或 error_reporting = 0，导致 ThinkPHP 的异常处理器没机会接管——错误在框架加载前就被 PHP 忽略了。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 检查
phpinfo()输出中display_errors和error_reporting实际值，CLI 和 FPM 可能不同配置 - 在
public/index.php开头强制开启：ini_set('display_errors', '1'); error_reporting(E_ALL);，确保异常至少能输出到响应体 - 若用 Nginx + PHP-FPM，确认
fastcgi_params中未覆盖PHP_VALUE导致display_errors被重置
自定义异常处理器无法捕获致命错误（E_ERROR / E_PARSE）
ThinkPHP 的 think\exception\Handle 默认只处理 Exception 和 Error（PHP 7+），但像语法错误（E_PARSE）、内存耗尽（E_ERROR）这类解析期/执行期致命错误，不会触发 set_exception_handler，只能靠 set_error_handler + register_shutdown_function 补漏。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
public/index.php最早位置注册关机函数：register_shutdown_function(function () { $e = error_get_last(); if ($e && in_array($e['type'], [E_ERROR, E_PARSE, E_CORE_ERROR])) { file_put_contents('/tmp/tp_fatal.log', print_r($e, 1), FILE_APPEND); } }); - 避免在关机函数里调用 ThinkPHP 类（如
Log::write），此时容器可能已销毁；改用原生file_put_contents -
set_error_handler可捕获E_WARNING等，但注意它不能捕获E_ERROR，必须和关机函数配合
日志写入失败时 fallback 到 syslog 或标准错误输出
当 runtime/log/ 不可用，又不想让日志完全丢失，可修改日志驱动为 syslog 或直接写 STDERR，但需注意 ThinkPHP 日志门面（Log::）默认不支持动态切换驱动。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
config/log.php中预设多级 fallback：'default' => env('LOG_DRIVER', 'file')，再通过环境变量LOG_DRIVER=syslog切换 - 若必须硬编码 fallback，可在
common.php中重写Log::init()，先尝试创建runtime/log，失败则降级为['type' => 'test']（输出到STDERR） - 使用
syslog驱动时，确认 PHP 已启用syslog扩展，且 Linux 的runit或rsyslog正常运行，否则日志会静默丢弃
真正棘手的是日志系统自身崩溃引发的连锁失效——它不像业务逻辑错误有明确报错点，而是让所有错误都“消失”。每次部署后手动验证 runtime/ 可写性、关机函数是否生效、以及 /tmp/ 是否有 fallback 日志，比事后翻几十个空日志文件更省时间。
