确认包是否被使用需三步：执行composer depends查依赖链，grep -r搜索代码中引用，grep检查autoload_*.php是否含该包；删包后Class not found常因配置文件、硬编码类名或未运行dump-autoload -o导致。
依赖多不是 Composer 慢的主因，真正拖慢安装和启动的是「没被业务代码调用、却仍被 autoload 扫描或装进 vendor 的包」。精简的关键不是删得狠，而是让 Composer 知道哪些可以跳过。
怎么确认某个包到底有没有被项目用到
光看 composer.json 里的 require 或 require-dev 不够，很多包是靠传递依赖混进来的，但代码里根本没调用。
- 查谁依赖它：
composer depends vendor/package-name—— 如果返回空，说明它只是某条深层依赖链的“幽灵乘客” - 查代码是否真引用：
grep -r "PackageClass" app/ src/ --include="*.php"，注意也要搜字符串类名（比如配置文件里写的'vendor/package'） - 查 autoload 是否还包含它：
composer dump-autoload --no-dev && grep -l "package-name" vendor/composer/autoload_*.php—— 如果没命中，基本可安全移除
删包后为什么还会 Class not found
执行 composer remove vendor/package 只改 composer.json 和卸载，但以下三处常被忽略，导致运行时出错：
- 框架配置文件里残留的 service provider 或 alias（比如 Laravel 的
config/app.php） - 代码中硬编码的类名字符串，尤其是事件监听器、队列任务、中间件参数里写的
'Vendor\Package\Client' - 没重生成 autoload 映射：
composer dump-autoload -o必须跑，否则旧的autoload_classmap.php还在，PHP 会继续找已删包里的类
replace 和 provide 怎么避免下载空壳包
像 psr/log、psr/container 这类接口包，很多项目其实已有实现（比如 Laravel 自带的容器），但 Composer 仍会下个空包，徒增 autoload 条目和解析开销。
- 用
replace告诉 Composer “这个我已经有了”："psr/log": "3.0.0"写进根composer.json的replace字段，它就不再尝试安装其他版本 - 用
provide替代真实依赖：如果你自己实现了psr/http-client-implementation，就在包的composer.json里加"provide": {"psr/http-client-implementation": "1.0"}，下游项目就能直接 require 这个虚拟包而不用装 Guzzle - 注意冲突：多个包
provide同一个虚拟包时，Composer 可能选中更重的实现，建议搭配conflict封杀已知不兼容组合，比如"symfony/console": "=10.0"
--no-dev 不是万能的，但漏掉它一定出事
--no-dev 是生产部署的底线，但它只控制安装行为，不自动清理 autoload 映射逻辑。
-
composer install --no-dev --optimize-autoloader是标准组合：前者跳过require-dev安装，后者把 PSR-4 映射固化为静态数组，跳过运行时扫描 -
--no-dev不影响autoload-dev配置本身，但因为那些包根本没下载，所以它们的 autoload 规则实际无效——这点常被误认为“没起作用” - CI/CD 流水线里漏掉
--no-dev，facade/ignition或laravel/tinker可能被加载，触发未启用组件的初始化逻辑，导致异常
最麻烦的从来不是命令怎么敲，而是判断某个包到底是“没人用”，还是“没人明着用但暗地里被框架钩子拉起来了”。这类边界情况，得看运行时调用栈、断点进服务提供者、甚至临时加 debug_print_backtrace() 才能确认。
