TP5.1不存在配置自动合并机制，模块与应用配置完全独立、按加载顺序覆盖而非合并；验证方式为同名配置项（如database.debug）在模块中设true时，config()读取结果恒为true，证实仅为覆盖行为。
ThinkPHP 5.1 默认不启用配置自动合并机制，所谓“自动合并”在 TP5.1 中并不存在于核心行为里——它本身已明确将模块配置与应用配置**完全独立、不再合并**（见官方说明：“模块的配置与应用配置完全独立不再合并”）。
为什么你会觉得有“自动合并”？
常见误解来源有两个：
- 误将多模块开发时的 配置加载顺序覆盖 当作“合并”：比如模块 A 加载了
database.php，模块 B 也加载同名配置，后加载的会覆盖前一个，看起来像“合并结果”，实则是简单覆盖； - 混淆了 TP5.0 或更早版本的行为：TP5.0 确实存在部分配置项的层级合并逻辑，但 TP5.1 已移除该设计，改为严格按配置文件路径和加载时机决定最终值。
确认当前无合并行为的方法
你可以通过以下方式验证配置是否被“合并”：
- 在
app/config/database.php中设置'debug' => false； - 在某个模块的
config/database.php中设置'debug' => true； - 运行
config('database.debug')—— 结果一定是true，因为模块配置优先级更高，不是合并，而是覆盖。
如需彻底隔离各模块配置作用域
虽无“合并”可关，但可主动规避干扰：
立即学习“PHP免费学习笔记（深入）”；
-
避免同名配置文件：不同模块使用不同命名的配置文件（如
db_main.php、db_log.php），用config('db_main.host')显式调用； -
禁用模块自动加载配置：在模块的
common.php或初始化逻辑中，不调用config::load()加载非必需配置； -
动态清空冗余项：启动时执行
config::set('database', []);清掉可能被误加载的全局 database 配置（谨慎使用，仅限特殊场景）。
不需要额外关闭开关，也不用修改核心。TP5.1 的配置机制本身就是解耦、覆盖、显式加载的——你看到的“合并感”，基本是加载时机或命名冲突导致的覆盖错觉。
