ThinkPHP在命令行（CLI）模式下的环境变量加载_定时任务配置-ThinkPHP-PHP中文网

thinkphp cli 模式默认不加载 .env 文件，需手动调用 dotenv::createimmutable(__dir__)->safeload() 或 env::load()；定时任务须由系统 cron 触发 schedule:run，不可后台常驻；环境变量在 systemd/supervisor 中需显式声明。

thinkphp在命令行（cli）模式下的环境变量加载_定时任务配置

CLI 模式下 `.env` 文件默认不加载

ThinkPHP 在 Web 请求中会自动读取根目录的 .env，但 CLI（比如执行 php think command:run 或系统 cron 调用）默认跳过这一步——不是 bug，是设计如此：CLI 启动路径可能不在项目根，或环境上下文不同，框架选择“不猜”，交由开发者显式控制。

常见错误现象：getenv('DB_HOST') 返回 false 或空，Config::get('database.hostname') 仍是默认值，定时任务连不上数据库。

确保 CLI 执行时工作目录为项目根（cd /path/to/project && php think xxx），否则 .env 路径解析失败

在 think 入口文件末尾手动触发加载：

if (PHP_SAPI === 'cli') {
    $dotenv = \Dotenv\Dotenv::createImmutable(__DIR__);
    $dotenv->safeLoad();
}

若使用 ThinkPHP 6.1+ 内置的 think-env，需确认已安装且 config/app.php 中 'env_file' => '.env' 已生效；但 CLI 下仍需主动调用 Env::load()

定时任务里不能依赖 `$_SERVER` 或请求上下文

Web 环境中常用的 request()、session()、cookie() 在 CLI 下全部不可用，连 $_SERVER['HTTP_HOST'] 都是空的。所有配置必须提前固化或从环境变量/配置文件读取。

典型翻车场景：定时任务里调用一个本该只在 HTTP 上下文中运行的 Service，结果抛出 InvalidArgumentException: Request instance is not available。

剥离业务逻辑与请求耦合：把数据库操作、消息发送等抽成独立 Command 类，构造函数只接收必要参数（如 $config、$logger），不依赖全局 request 实例
避免在 Command 的 handle() 里直接调用 url()、redirect() 等 HTTP 专属函数
日志写入路径要显式指定，别用 LOG_PATH 这类可能依赖 $_SERVER 推导的常量；改用 __DIR__ . '/../runtime/log/'

`php think schedule:run` 不等于 Linux cron

php think schedule:run 是 ThinkPHP 自己实现的「调度器」，它只负责检查当前有没有到点的任务并执行一次，**不持久、不守护、不重试**。它本身仍需被外部进程（如系统 cron）定期触发。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

错误做法：只在服务器跑一个 nohup php think schedule:run &，以为这样就能“一直跑”。实际它执行完就退出，根本不会监听后续时间点。

Linux cron 示例（每分钟检查一次）：

* * * * * cd /var/www/project && php think schedule:run >> /dev/null 2>&1

注意路径切换（cd）和输出重定向，否则 cron 会因找不到 think 或权限问题静默失败
如果任务执行时间长于 1 分钟，需在 app/command/Schedule.php 中设置 $schedule->command('xxx')->withoutOverlapping(); 防止并发

环境变量在不同启动方式下作用域不一致

你在 shell 里 export APP_ENV=production，再运行 php think xxx，这个变量对 PHP 进程可见；但如果你用 systemd 或 supervisor 启动定时服务，它们默认不继承 shell 环境变量。

表现就是：手动执行一切正常，放进定时任务后配置全回退到默认值。

最稳方案：把关键配置写进 .env 并确保 CLI 下成功加载（见第一个副标题）
systemd 示例（/etc/systemd/system/think-schedule.service）中必须显式声明：
```
Environment="APP_ENV=production"
Environment="DB_HOST=127.0.0.1"
```
supervisor 配置里用 environment=APP_ENV="production",DB_HOST="127.0.0.1"

环境变量和 CLI 启动路径这两个点，最容易在上线后突然失效——因为开发时总是在项目根目录手动敲命令，而生产环境的 cron、systemd、容器启动路径和变量注入方式完全不同。