ThinkPHP 6 的 CLI 命令不自动加载 .env 是设计使然，需在自定义命令 handle() 开头手动调用 $this->app->loadEnv(ROOT_PATH . '.env')；定时任务推荐统一使用 php think schedule:run 触发，该命令内置环境变量加载逻辑，可避免重复处理。
ThinkPHP 6 的 think:command 命令不自动加载 .env 怎么办
TP6 的命令行任务（包括定时任务）默认不会读取 .env 文件，这是设计使然——CLI 环境和 HTTP 请求环境是隔离的。直接在命令中调用 env('DB_HOST') 返回 null 或空字符串，不是配置错了，而是根本没加载。
实操建议：
- 在自定义命令类的
handle()方法开头手动触发加载：if (is_file(ROOT_PATH . '.env')) { $this->app->loadEnv(ROOT_PATH . '.env'); } - 确保
ROOT_PATH正确（通常为项目根目录，含末尾斜杠），否则路径拼接失败导致静默跳过 - 不要放在
__construct()中——此时容器尚未完全初始化，$this->app可能不可用 - 如果使用多环境（如
.env.production），需按实际文件名传参，TP6 不会自动识别环境后缀
在 crontab 中执行 TP 命令时 .env 仍为空的常见原因
Linux 定时任务以独立 shell 用户身份运行，工作目录、环境变量、甚至 PHP CLI 配置都可能与手动执行不同。即使代码里写了 loadEnv()，也可能因路径错误或权限问题失效。
排查和修复要点：
立即学习“PHP免费学习笔记（深入）”；
- 在 crontab 条目中显式指定工作目录：
cd /var/www/myapp && php think my:task
- 避免使用相对路径读取
.env，全部改用绝对路径，例如/var/www/myapp/.env - 确认运行 crontab 的用户对
.env文件有读取权限（ls -l .env查看） - 临时加日志验证是否真的加载成功：
file_get_contents(ROOT_PATH . '.env')
看是否返回内容，而非只依赖env()返回值
env() 和 config() 在定时任务中的行为差异
env() 是原始环境变量读取函数，只在 .env 加载后才有效；而 config() 是框架配置层，部分配置（如数据库）可能在命令启动时已由框架初始化，但其底层仍依赖 env() 解析。若 env() 为空，config('database.hostname') 同样会回退到默认值或报错。
关键区别：
-
env('APP_DEBUG')—— 必须先loadEnv()才能拿到真实值 -
config('app.app_debug')—— 若该配置项在config/app.php中写死为true，则不受.env影响；但若写成env('APP_DEBUG', true)，就又绕回去了 - 数据库连接等动态配置，几乎都依赖
env()，所以不加载.env就连不上库
更稳妥的替代方案：用 php think schedule:run 而非裸 crontab
TP6 内置的调度器（Schedule）本身已内置 .env 加载逻辑，只要通过 php think schedule:run 触发，就不会漏掉环境变量。
操作方式：
- 在
app/command/Schedule.php中定义你的任务（或直接在app/Console.php的schedule()方法里注册） - crontab 只保留最简指令：
* * * * * cd /var/www/myapp && php think schedule:run >> /dev/null 2>&1
- 所有任务内部无需再手动
loadEnv()，框架已统一处理 - 注意：该方式要求
schedule:run每分钟执行一次，不能用*/5这类间隔——TP 调度器自己控制精度
真正容易被忽略的是：很多团队把定时任务写成独立脚本，绕过 think schedule，结果每次都要重复处理环境加载、异常捕获、日志写入——其实框架已经提供了更健壮的入口，只是没意识到它也适用于生产级定时场景。
