ThinkPHP CLI 与 FPM 是两种本质不同的执行模型：CLI 单次进程、无请求上下文、动态配置作用域窄、不自动加载运行时编译配置；FPM 常驻进程、支持连接复用、按需加载配置、具备完整 HTTP 生命周期管理。
ThinkPHP 命令行模式（CLI）和 FPM 模式在配置加载、生命周期、内存行为及适用场景上存在本质差异，不是“换种方式运行”，而是两种完全不同的执行模型。
配置加载顺序与动态性不同
两者都遵循“惯例配置 → 应用配置 → 模块配置 → 动态配置”的优先级，但 CLI 模式下动态配置的实际作用范围更窄、更易被忽略：
- FPM 模式中，在控制器或中间件里调用
config(['app.debug' => true])，该修改仅对当前 HTTP 请求生命周期有效，请求结束即失效； - CLI 模式中，同样调用
config()修改，效果也只持续到当前命令执行完毕——但因 CLI 通常单次执行即退出，且无“请求上下文”概念，多数动态配置实际没有复用机会； - CLI 不自动加载路由/模板等运行时编译配置（如
route.php编译缓存），除非显式触发（如php think optimize:route），而 FPM 每次请求都会按需检查并加载； - CLI 下若使用
app/command.php手动注册命令类，该文件本身属于“应用配置层”，但它的加载时机早于模块配置，无法被后续的动态配置覆盖。
生命周期与资源持有方式根本不同
FPM 和 CLI 的进程模型决定了它们对连接、缓存、全局变量的处理逻辑截然不同：
- FPM Worker 进程常驻，一次启动可服务成百上千次请求；Redis 连接、PDO 持久化连接、Swoole Table 实例等可跨请求复用；
- CLI 是一次性进程：执行完命令即退出，所有内存（包括 OPcache 编译结果、Redis 连接、PDO 句柄）全部释放；即使开启 PDO 持久化，CLI 下也不生效（仅 FPM/Cli-SAPI 的 fork 复用场景才起作用）；
- FPM 模式中，“读者走后，阅览室彻底打扫干净”——每次请求结束会清空 Request、Session、View 等单次上下文对象，但底层连接和 OPcache 缓存保留；
- CLI 没有“请求结束”概念，只有“进程终止”，所以像
think\facade\Cache默认驱动为 file 时，CLI 下写缓存仍会生成文件，但不会触发 FPM 中常见的 flock 争用问题（因无并发进程竞争同一缓存文件）。
环境变量与入口行为差异明显
CLI 并非简单“用 php 命令跑 index.php”，它依赖明确的运行模式识别和初始化路径：
- FPM 通过
$_SERVER['SERVER_SOFTWARE']等判断 Web 环境，自动启用 PATH_INFO 路由解析、自动设置APP_MODE = 'http'； - CLI 必须确保
APP_MODE = 'cli'被正确定义（TP6+ 通常由框架自动识别，但 TP3.2/5.x 需手动定义），否则日志、调试、缓存等模块可能加载错误类或跳过关键初始化； - CLI 下
$_SERVER全局变量极简（无 REQUEST_URI、QUERY_STRING 等），框架改用$input对象解析参数，所有命令行参数必须在configure()中预先声明，未声明则直接报错，不提供 fallback； - FPM 下可通过
$_GET/$_POST或路由变量灵活传参，CLI 则严格依赖InputOption和InputArgument，类型、必填、默认值都需代码级约束。
缓存与性能表现不可混用
同一套 ThinkPHP 配置，在两种模式下实际效果可能相反：
- OPcache 在 FPM 中是核心性能支柱，关闭
validate_timestamps可大幅提升吞吐；但在 CLI 下，OPcache 编译结果每次执行都重新生成（因进程不复用），关闭验证几乎无收益，反而增加首次加载延迟； - 使用 Redis 作为缓存驱动时，FPM 下连接可复用，CLI 下每次命令都新建连接+认证+断开，高频调用需考虑连接池或改用 Swoole Table（但 CLI 不支持 Swoole 扩展常驻）；
- File 缓存驱动在 FPM 高并发下易因 flock 锁导致阻塞，而 CLI 单进程串行执行，反而更稳定；但若多个定时任务并发运行 CLI 命令，仍可能产生文件锁冲突，此时必须改用 Redis 或数据库驱动。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
