Composer 是现代 PHP 项目依赖管理的事实标准,必须通过 composer init 初始化并运行 composer install 生成 autoload.php;线上环境严禁使用 composer update,应固定执行 composer install --no-dev 等安全命令。
Composer 不是 PHP 动态网站的“附加功能”,而是现代 PHP 项目依赖管理的事实标准——没它,连 vendor/autoload.php 都加载不了,require 第三方库会直接报错。
别从空文件夹开始手动建 composer.json。用官方推荐方式初始化:
composer --version 验证)/var/www/html/my-site),执行:composer init,按提示填包名、描述、依赖等;或更常用的是直接创建最小化配置:
composer init --name="my-site" --type="project" --require="php:^8.1"
composer install,它会读取 composer.json,创建 vendor/ 目录并生成自动加载器index.php)顶部加上:require __DIR__ . '/vendor/autoload.php';,之后才能用
new GuzzleHttp\Client() 这类类名装错包类型会导致部署失败或安全风险。注意区分用途:
composer require monolog/monolog:日志库,适合写入访问日志、错误追踪,放在 require 区(生产环境需要)composer require --dev phpunit/phpunit:测试工具,只放 require-dev,上线前运行 composer install --no-dev 可排除它composer require laravel/framework 这类全栈框架到已有网站——除非你准备重构成 Laravel 项目;小网站更推荐轻量方案,比如 composer require league/route 做路由,composer require doctrine/dbal 做数据库抽象composer require symfony/filesystem 比手写 move_uploaded_file() 更安全(自动校验路径、权限)composer install 和 composer update 到底该用哪个线上服务器必须用 composer install,否则可能破坏稳定性:
composer install:严格按 composer.lock 安装——这是关键。它锁定每个包的确切版本(包括子依赖),保证开发、测试、生产环境一致composer update:忽略 composer.lock,按 composer.json 中的版本约束(如 "^2.0")拉最新兼容版——仅应在本地开发时运行,且更新后要提交新的 composer.lock
composer update,导致某依赖悄悄升级,引发 Call to undefined method 或 JSON 解析异常;修复方法是删掉 vendor/ 和 composer.lock,再 composer install
composer install --no-interaction --optimize-autoloader --no-d
ev
不是不能用,而是用了反而增加运维负担:
mysqli_connect() 的老式网站,硬加 Composer 只是多一层 require 和 vendor/ 目录,没实际收益proc_open()(Composer 内部依赖),此时强行部署会卡在 “Failed to clone” 错误wp-content/plugins/,而 Composer 默认装进 vendor/——得配合 composer/installers 插件重定向安装路径,否则无法生效__autoload() 或 set_include_path(),两者混用会导致类找不到,必须统一到 autoload.php