CLI下APP_DEBUG仍为true因读取.env配置且无环境自动识别；需显式定义、检查think入口及禁用调试输出；调度器应由systemd管理并启用mutex锁；命令需主动关闭数据库/Redis连接。
ThinkPHP 命令行模式下 APP_DEBUG 为什么还是 true？
命令行运行 ThinkPHP 应用时，APP_DEBUG 默认仍读取 env 或 .env 中的配置，不会自动切换为 false —— 这和 Web 请求不同，CLI 没有“环境自动识别”逻辑。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在入口文件
think（或自定义 CLI 入口）顶部显式设置：define('APP_DEBUG', false); - 确保
.env文件中没有APP_DEBUG=true覆盖；CLI 下.env仍会被加载，且优先级高于配置文件 - 若使用
php think xxx命令，框架会走think入口，但部分版本（如 TP6.0+）会在think脚本里重置APP_DEBUG，需检查该脚本末尾是否调用了App::debug()并传参
如何让 php think schedule:run 真正后台静默执行？
直接加 & 或 nohup 很容易失败，因为 ThinkPHP 的调度器依赖标准输入/输出流做锁检测和日志写入，后台化后可能卡死或重复执行。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
systemd或supervisord管理，而非裸跑：sudo systemctl start php-schedule-runner
- 禁用调试输出：在
config/schedule.php中设置'output' => '/dev/null'，避免日志阻塞 - 关键要加锁：确保
config/schedule.php中启用了'mutex' => true（TP6.1+ 默认开启），否则多实例并发会出问题 - 不要在
crontab里直接写php think schedule:run，而应每分钟调用一次，由框架自己判断是否该跑任务
think 命令找不到或报错 “Class 'think\Console' not found”
常见于手动部署或 Composer 安装不完整场景，本质是 think 入口文件无法加载核心类，不是权限或路径问题。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认
vendor/bin/think存在且可执行；若不存在，运行composer install --no-dev补全 - 检查
vendor/autoload.php是否被正确引入 ——think文件第一行必须是：require __DIR__ . '/../vendor/autoload.php';
- 如果项目根目录下有自定义
think文件（非 vendor 提供），删掉它，改用vendor/bin/think - TP6.0+ 的
think是 Phar 封装体，若服务器禁用了phar扩展，会直接报错，需在php.ini中启用extension=phar.so
CLI 模式下数据库连接池、Redis 连接不释放怎么办？
Web 请求结束时连接通常随进程销毁，但 CLI 长期运行时，ThinkPHP 不会自动回收连接资源，容易导致连接数爆满。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 每个命令执行完主动关闭连接：
Db::close(); Cache::store('redis')->handler()->close(); - 避免在
Command类的__construct中初始化连接，改在handle()内按需获取 - 使用连接池配置时（如
mysql.pooling = true），务必设好max_idle_time，否则空闲连接永不释放 - 定时任务中频繁操作数据库，建议用
Db::connect('read')->query(...)显式指定连接，防止主从混淆后连接复用异常
Db::close() 和 .env 的 CLI 覆盖行为 —— 这两个点不处理，跑两天就出问题。 
