CodeIgniter配置引发500错误需直查日志、权限、重写规则和异常处理四环节：先查Web服务器及PHP错误日志定位原始异常；再验Nginx rewrite是否误用if或SCRIPT_FILENAME路径错误；接着确认命名空间下catch(Exception $e)是否因未use Exception而失效；最后核验Config目录权限、memory_limit与时区设置。
CodeIgniter 配置引发 500 错误，通常不是“配置写错了”这么简单，而是配置触发了底层异常却未被正确捕获或暴露。快速定位的关键在于跳过猜测，直击日志、权限、重写规则和异常处理这四个最常出问题的环节。
查错误日志，锁定第一现场
500 错误本身不带信息，但服务器一定会记下真正出事的地方：
- 先看 Web 服务器错误日志：Nginx 是 /var/log/nginx/error.log，Apache 是 /var/log/apache2/error.log；用
tail -n 30查最近记录，重点找含 PHP Fatal error、Uncaught Exception 或具体行号（比如UserController.php:45）的条目。 - 再看 PHP 错误日志：确认
php.ini中error_log路径，常见为 /var/log/php_errors.log；若没启用，临时在入口文件顶部加ini_set('log_errors', 1); ini_set('error_log', '/tmp/php-error.log');。 - CI 自身日志（
app/Logs/）也要扫一眼，尤其当看到 “Unable to load config file” 或 “Class not found” 时，基本就是配置加载阶段崩了。
验伪静态规则，特别是 Nginx 的 rewrite
CI 去掉 index.php 后出现 500，90% 是 Nginx 重写配置不当导致请求被错误转发或路径解析失败：
- 检查
location /块是否用了已弃用的if (!-e $request_filename)写法——它在某些 Nginx 版本下会触发 500；应改用更健壮的try_files $uri $uri/ /index.php?$query_string;。 - 确认
fastcgi_param SCRIPT_FILENAME指向的是真实物理路径，而不是拼接出的错误路径；常见坑是$document_root$fastcgi_script_name中$document_root末尾多了一个斜杠或少了一个。 - 临时把重写规则全注释掉，直接用
http://domain.com/index.php/xxx访问，如果正常，问题就锁定在 rewrite 层。
看异常捕获是否失效，尤其命名空间下的 Exception
CI4 中自定义过滤器或中间件里 catch 不住异常，最终 fallback 到框架默认处理器，就容易报 500 而不是预期状态码（如 401）：
- 检查类是否声明了
namespace App\Filters;却写了catch (Exception $e)——这实际捕获的是\App\Filters\Exception，而非全局\Exception。 - 修复方式很简单：写成
catch (\Exception $e)或use Exception;在头部引入。 - 类似情况也出现在 JWT 解析、数据库连接失败等场景，只要异常没被显式捕获，就会一路冒泡到 CI 全局异常处理器，而该处理器若再因格式化失败（如含非法 UTF-8）二次崩溃，就稳稳返回 500。
核文件权限与 PHP 设置，排除基础环境干扰
看似无关，但常是压垮骆驼的最后一根稻草：
- 确保
app/Config/目录及所有配置文件对 Web 用户（如www-data）可读；运行ls -l app/Config/看权限是否为-rw-r--r--，必要时chmod 644 *.php。 - 检查
memory_limit和max_execution_time是否过小，尤其加载多个配置或扫描服务提供者时；可在public/index.php开头加ini_set('memory_limit', '256M');快速验证。 - 确认
date.timezone已在php.ini中设置，否则 CI 初始化时可能因时区未定义抛出致命错误。
