php -f 更适合写 CLI 脚本，因其支持 IDE 调试、require 引入、清晰错误堆栈；php -r 仅适用于单行快速验证，代码超三行即难维护且不自动加结束分号。
php -f 和 php -r 哪个更适合写 CLI 脚本
直接用 php -f 执行脚本文件是主流做法，php -r 只适合单行快速验证，别拿它写正式脚本。前者能用 IDE 调试、支持 require、有清晰的错误堆栈；后者一过三行就难维护，且不自动加 <?php ，容易漏写或错写分号。
常见错误现象：用 php -r "echo 'hello'; include 'config.php';" 报 Parse error: syntax error —— 因为 -r 不解析文件内嵌的 PHP 标签，也不处理多行换行逻辑。
-
php -f script.php：推荐，脚本里写完整 PHP 代码，含<?php开头 -
php -r 'echo date("Y-m-d");'：仅限临时调试，别放版本库 - 如果脚本需传参，
php -f script.php arg1 arg2，参数会进$argv，不是环境变量
怎么让 PHP 脚本能像命令一样直接运行（不用打 php -f）
关键在两步：加 shebang 行 + 给执行权限。PHP 解释器路径得写对，别硬写 /usr/bin/php，用 which php 查准路径，或者更稳妥地用 #!/usr/bin/env php。
容易踩的坑：脚本开头没空行、BOM 头导致 #!/usr/bin/env php 失效；或者 chmod 忘了加 x 权限，报 Permission denied。
立即学习“PHP免费学习笔记（深入）”；
- 第一行必须是
#!/usr/bin/env php，且不能有任何空格或 UTF-8 BOM - 保存为 Unix 换行（LF），Windows 换行（CRLF）会导致解释器找不到命令
- 运行
chmod +x script.php，然后直接./script.php arg1 - macOS 或某些 Linux 发行版默认禁用
env查找，可改用#!/opt/homebrew/bin/php（根据which php输出）
CLI 模式下 $argv 和 $argc 怎么用才不出错
$argv 是字符串数组，$argc 是长度，它们从命令行读取原始输入，不做任何 trim 或类型转换。最容易错的是下标越界和参数顺序误解——$argv[0] 是脚本路径本身，不是第一个业务参数。
使用场景比如写个批量重命名工具：./rename.php *.jpg --prefix=old，这时你要自己 parse --prefix，PHP 不自动做 getopt。
-
$argv[0]= 脚本名（如./deploy.php或php deploy.php） - 真实参数从
$argv[1]开始，别直接用$argv[0]当输入 - 判断参数数量用
if ($argc ，而不是 <code>empty($argv[1])，因为可能传了空字符串 - 需要复杂参数解析（如
-v --help --port=8080），用内置getopt()函数，别手写正则
CLI 脚本里 echo/print_r/var_dump 输出乱码或不刷新
CLI 下输出缓冲行为和 Web 不同：默认不自动 flush，且不识别 HTML 实体。最常遇到的是进度条卡住、JSON 输出带多余换行、中文显示成问号。
性能影响不大，但体验极差——尤其跑长任务时以为卡死，其实是输出被 buffer 住了。
- 强制立即输出：每行后加
flush(); ob_flush();，但只在需要实时反馈时用（如进度循环） - 避免
var_dump()直接打数组，改用print_r($data, true)+echo，否则格式错乱 - 中文乱码？确认终端编码是 UTF-8，脚本开头加
mb_internal_encoding('UTF-8');，别依赖setlocale() - CLI 没有
$_SERVER['HTTP_HOST']这类变量，别在 CLI 脚本里混用 Web 环境逻辑
