PHP 命令速查表 - PHP 常用命令与 Composer 管理大全
这套速查给写 PHP 应用、尤其是基于 Composer 的框架（Laravel、Slim 等）或负责其部署的开发者。它覆盖从 CLI 跑脚本、用内置服务器本地起站点，到 Composer 装依赖、重生成 autoload、核某扩展有没有加载，以及用 php -l 在提交前拦下语法错误。与一条条罗列 php 命令不同，这里按"本地搭起来→装依赖→排查扩展→上线前检查"的流程组织。读完应能独立跑起一个 Composer 项目、同步 autoload，并把它过一遍 lint。
CLI 运行 8
php script.phpphp -aphp -S localhost:8000php -S localhost:8000 -t public/php -l script.phpphp -r "echo phpinfo();"php -iphp -mComposer 依赖管理 10
composer initcomposer installcomposer updatecomposer require vendor/packagecomposer remove vendor/packagecomposer dump-autoloadcomposer dump-autoload -ocomposer showcomposer outdatedcomposer self-update扩展与配置 6
php --iniphp -d memory_limit=256M script.phpphp -d display_errors=1 script.phppecl install extensionpecl uninstall extensionphp -r "echo PHP_VERSION;"Laravel 常用命令 8
php artisan servephp artisan migratephp artisan migrate:freshphp artisan make:model Post -mcrphp artisan route:listphp artisan config:cachephp artisan queue:workphp artisan tinker性能分析 4
php -d xdebug.mode=profile script.phpphp -d opcache.enable_cli=1 script.phpstrace -p <pid>php -r "echo memory_get_peak_usage();"命令示例
用 php -l 在提交前拦下语法错误
php -l script.php它不执行代码，所以静态方法和配置读取里的问题查不出来，只能拦语法层面的错误。CI 里可以对目录批量跑，先本地过了再提交能省一轮流水线时间。
输出
No syntax errors detected in script.php
确认扩展是否真的被加载
php -m
php --ini扩展不在 php -m 里时，先看 Scan 目录下的 ini 是否写了启用语句——装了但未启用是最常见的「装不上」现象。Web 与 CLI 用的 ini 不同，本地 php -m 通过不代表线上 PHP-FPM 也有。
输出
[PHP Modules] ctype curl dom json mbstring openssl pdo_mysql tokenizer Configuration File (php.ini) Path: /etc/php/8.3/cli Loaded Configuration File: /etc/php/8.3/cli/php.ini Scan for additional .ini files in: /etc/php/8.3/cli/conf.d
部署收尾：优化模式重建 autoload
composer install
composer dump-autoload -o
composer showinstall 保证版本与 lock 一致，-o 生成确定的类映射减少运行时查找。composer show 列出的实际版本可以和 composer.json 的约束对照，确认线上装的确实是预期那套。
输出
Loading composer repositories and package information Installing dependencies from lock file (including require-dev) Generating optimized autoload files 1 package you are using is looking for funding. monolog/monolog 3.6.0 Structured logging symfony/console 6.4.7 Symfony Console Component
Laravel：先看清路由与积压，再决定是否迁移
php artisan route:list
php artisan migrateroute:list 能确认路由确实注册上了，404 时先看这里而不是怀疑控制器。migrate 的输出只有 Migrated 才算成功；生产上不要用 migrate:fresh，它会回滚全部迁移。
输出
GET / ............................................ posts › index
POST /posts ....................................... posts › store
GET /posts/{post} ............................... posts › show
Migrating: 2026_09_12_000000_create_posts_table
Migrated: 2026_09_12_000000_create_posts_table常见坑与注意事项
- php -S 是单进程开发服务器，并发请求会排队甚至超时，只能用于本地；线上必须走 Nginx + PHP-FPM。
- composer update 会改写 composer.lock 并连带升级无关依赖，部署脚本或 CI 里用 install 而非 update，否则线上版本会随时间漂移。
- php -d 设置的参数只对本次进程生效（如 memory_limit），不会写进任何配置文件，别指望调试时的临时放宽被保留下来。
- php -i 会输出完整配置路径与扩展信息，属于诊断输出，不要留在用户可见的响应或日志里。
- php artisan queue:work 以前台方式运行，长时间无人值守要交给进程管理器托管，否则终端一关队列就停了。
提示
- 生产环境务必执行 composer dump-autoload -o 优化性能。
- php -S 仅用于开发，生产请用 Nginx + PHP-FPM。
- Laravel 生产环境要缓存配置、路由和视图：config:cache、route:cache、view:cache。
常见问题
composer install 和 composer update 什么时候用哪个？
看你要不要改依赖版本。composer install 严格按 composer.lock 里锁定的版本装，团队每个人和每次部署拿到的都是同一套依赖，这是可复现的前提；composer update 会忽略 lock、按 composer.json 的约束去解析当前能拿到的较新版本并刷新 lock 文件。只改了业务代码就用 install，只有主动升级依赖时才用 update，否则一次无关的 update 会把无关包也带上去。
为什么新增一个类之后页面报 class not found？
因为 autoload 的类映射没重新生成。Composer 的 PSR-4 映射在 vendor 目录里以缓存文件形式存在，新增类时旧的映射里没有这条记录，于是自动加载找不到它。跑一次 composer dump-autoload 重建映射即可，不用重装依赖。生产部署时用 composer dump-autoload -o 走优化模式，把 PSR-4 规则扫描成一份确定的类映射表，减少运行时的文件查找。
php -l 只能检查语法，那它还有什么用？
它快，而且足够挡住一大类线上事故。php -l 只解析不执行，成功时输出 No syntax errors，因此可以在 CI 里对整个目录做扫描，几十毫秒就能覆盖所有文件，不必启动应用。而需要真跑一遍才能暴露的问题——扩展没加载、配置读错、依赖缺失——由 php -m 和 php -i 分别确认。合理的分工是：语法用 -l，扩展与配置用 -m/-i，运行时行为才实际执行脚本。
php -m 里没有需要的扩展，怎么确认它到底装没装？
php -m 列出的是当前这个 CLI 二进制实际加载的扩展，先用它确认「没加载」而不是「没安装」——扩展文件存在但未启用的情况很常见。php -m 没有就再看 php -i 的输出，其中包含 extension_dir 指向的目录路径和已加载 ini 列表，用 php --ini 能直接看到 ini 的搜索路径和优先级。确认目录里没有对应扩展文件时才需要 pecl install 装上；装了仍不出现，就说明它没被写进 ini，需要启用后再验证。
php -S 内置服务器能拿来部署线上吗？
不能。php -S 是单进程的开发服务器，设计目的是让你不装 Nginx/Apache 就能本地起站点看效果，它一次只处理一个请求、没有并发处理能力，也没有超时与访问控制。要指定文档根目录时用 php -S localhost:8000 -t public/，把入口文件放在 public/ 下配合前端控制器，这样和生产的目录布局保持一致；上线仍应交给 Nginx + PHP-FPM 这类真正能并发处理请求的服务。
由 巧匠 维护
公开更新于 2026年7月21日，内容持续校对官方文档。