ThinkPHP通过APP_ENV常量自动加载dev/test/prod环境配置，需在入口文件最早定义小写值；.env文件会优先覆盖常量，生产环境须删除或禁用；APP_DEBUG必须为false以避免安全与性能风险。
怎么让 ThinkPHP 自动加载不同环境的配置文件
ThinkPHP 会根据 APP_ENV 环境常量决定加载哪个配置目录，默认是 config/ 下的文件。但关键不在“能不能”，而在“怎么确保它真按你想要的走”。
-
APP_ENV必须在入口文件（如public/index.php）中最早定义，不能晚于require <strong>DIR</strong>.'/../vendor/autoload.php'; - 它的值必须是字符串，且只接受小写：比如
'dev'、'prod'，写成'DEV'或'development'都不会触发对应目录（ThinkPHP 只认dev、test、prod这三个固定值） - 如果没定义
APP_ENV，框架会 fallback 到config/目录，不会报错，也不会提示你漏配——这是最常踩的坑
示例正确写法：
define('APP_ENV', 'prod');
require __DIR__.'/../vendor/autoload.php';为什么 config/dev/ 和 config/prod/ 里的数据库配置不生效
不是路径错了，而是 ThinkPHP 的配置合并机制在作祟：它先加载 config/app.php，再加载 config/database.php，最后才叠加 config/{env}/database.php —— 但前提是后者存在且被识别为有效环境目录。
- 检查
config/{env}/下是否真的有database.php，而不是只改了app.php - 注意文件权限：Linux 下如果
config/prod/所有者是 root，而 web 服务器用户（如 www-data）无读取权，会静默跳过该目录 - 不要试图在
config/prod/database.php中覆盖整个数组，ThinkPHP 是深度合并（deep merge），所以只需写你真正想改的键，比如：return [ 'hostname' => 'db-prod.example.com', 'database' => 'myapp_prod', ];
APP_DEBUG = true 在生产环境还能开吗
不能。这不是“建议关闭”，而是直接导致安全风险和性能崩塌。
立即学习“PHP免费学习笔记（深入）”；
-
APP_DEBUG为true时，ThinkPHP 会暴露完整错误堆栈、SQL 语句、变量 dump，还允许路由调试面板、模板编译缓存自动刷新 - 更隐蔽的问题是：它会让日志写入变成同步阻塞式，高并发下可能卡住整个请求链路
- 即使你用 Nginx 把
debug页面路径全拒了，框架底层仍会执行调试逻辑，只是不输出而已
生产环境必须确保：
-
APP_DEBUG设为false -
APP_TRACE同样设为false（它独立于APP_DEBUG，但效果类似） - 日志级别应设为
'level' => ['error', 'notice']，避免记录 debug 信息
环境常量被 .env 覆盖了怎么办
ThinkPHP 6+ 默认启用 topthink/think-env，会自动读取项目根目录下的 .env 文件，并把其中的键转为 PHP 常量（如 APP_ENV=prod → define('APP_ENV', 'prod')）。
问题在于：
-
.env加载时机比入口文件早，所以你在index.php里再 define 同名常量会报Notice: Constant APP_ENV already defined - 更麻烦的是，如果
.env里写了APP_ENV=dev，但你实际部署时忘了删或改它，生产服务器就悄悄跑在开发模式下
应对方式很简单：
- 生产部署时，删掉
.env文件，或用部署脚本把它重命名为.env.bak（ThinkPHP 只认.env） - 如果必须保留
.env（比如用来管理数据库密码），那就别在里面写APP_ENV或APP_DEBUG这类影响框架行为的项 - 检查
config/app.php中的'env_file'配置项，确认它没被意外改成其他文件名
环境配置这事儿，核心就一条：ThinkPHP 不会替你判断“哪里更可信”，它只认最先定义的那个值。谁先伸手，谁说了算。
