thinkphp配置加载优先级从高到低为：动态配置＞环境变量（.env）＞应用配置（app/config.php）＞全局配置（config/目录）＞框架默认配置（convention.php），后加载的同名配置覆盖前序配置。
PHP框架的配置加载不是“读一个文件就完事”，而是按环境、优先级、触发时机分层叠加的过程。改了config/app.php却没生效？大概率是被更高优先级的配置覆盖了，或者根本没走到这个加载路径。
配置加载路径取决于运行入口和SAPI类型
同一个项目，php artisan serve启动的Laravel、Nginx+PHP-FPM访问的ThinkPHP、CLI下跑的php test.php，加载的配置文件可能完全不同——因为PHP会根据当前SAPI（CLI/FPM/Apache）加载不同的php.ini，而框架又基于此初始化自己的配置查找逻辑。
- ThinkPHP在
base.php中通过Loader::register()注册自动加载器，但配置加载早在那之前就由App::init()触发，它先查.env，再合并config/目录下所有.php文件 - Laravel的
Illuminate/Foundation/Application在构造时就调用loadEnvironmentFrom()读.env，再通过getConfigurationLoader()从config/目录加载，但具体哪些文件被加载，受APP_ENV环境变量控制（如config/database.php会被加载，config/logging.php在测试环境可能跳过） - CLI命令下，很多框架会跳过
.env加载（除非显式调用loadEnvironmentFrom()），直接走默认配置，这也是为什么php artisan tinker里看到的数据库配置和Web请求不一致
配置优先级不是线性顺序，而是多层覆盖
ThinkPHP明确列出优先级：环境变量（.env） > 应用配置（app/config.php） > 全局配置（config/*.php）。但Laravel更隐蔽：它把.env解析成$_ENV后，再用env()辅助函数读取，而config/*.php里写的env('DB_HOST', '127.0.0.1')才是最终生效点——也就是说，.env本身不直接覆盖配置，而是提供给env()函数的原始输入。
- 修改
.env后必须清空bootstrap/cache/config.php缓存，否则Laravel仍用旧值 - ThinkPHP的
config:cache命令生成的runtime/config.php会完全绕过.env，此时.env修改无效 - 某些框架（如CodeIgniter）允许在控制器里用
$this->config->set_item()动态覆盖，这种运行时修改只对当前请求有效，且优先级高于所有文件配置
框架不会自动重载配置，缓存和重启是硬性前提
开发时改了config/database.php，浏览器刷新没反应？不是框架bug，是它根本没重新读这个文件。绝大多数PHP框架在应用启动时一次性加载并缓存全部配置，后续请求直接读内存副本。
- Laravel的
config:clear删的是bootstrap/cache/config.php，不是config/源文件；config:cache会把所有config/*.php合并成单个PHP数组文件，大幅提升读取速度，但代价是.env失效 - ThinkPHP的
php think clear:config清的是runtime/config.php，但如果你开了OPcache，还得执行opcache_reset()或重启PHP-FPM，否则OPcache仍返回旧的编译后配置文件 - CLI命令如
php artisan queue:work是长进程，配置加载只发生一次，改了配置必须手动kill并重启worker，否则永远用旧配置
真正容易被忽略的是：配置加载和自动加载（spl_autoload_register）是两套独立机制。前者管array数据怎么来，后者管class文件怎么找。混淆这两者，就会在调试Class 'config' not found时去翻config/目录，而实际问题出在vendor/autoload.php没被引入。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
