技术博客
执行 composer config –unset repos.packagist 后，Composer 会彻底删除 repos.packagist 这个自定义源配置，但**不会自动恢复官方 Packagist 源**——因为官方源不是靠这个键名启用的，而是默认内置、且由 packagist.org 的隐式 fallback 机制提供。一旦你删了它，又没手动加回，composer install 或 composer require 就可能报错找不到包。
不能直接删。composer remove 是 Composer 2.2+ 引入的命令，但它只做两件事：从 composer.json 的 require（或 require-dev）里移除对应包名，并执行一次 composer install（即重装依赖）。它不会自动清理已安装但未声明的包，也不会处理手动修改过 composer.json 后残留的 vendor/ 文件。
直接执行一条命令就能切回 Packagist 官方源，不需要手动编辑配置文件。运行以下命令即可将当前配置的镜像源重置为 Packagist 官方源（https://packagist.org）：
Composer 本身不提供 pre-install-cmd 这样的原生脚本钩子，但你可以通过 scripts 配置 + composer install 的 –no-scripts 行为，或借助插件/包装脚本实现“执行 install/update 前运行自定义逻辑”的效果。最实用、无需额外依赖的方式是利用 Composer 的 pre-autoload-dump 或 pre-update-cmd/pre-install-cmd —— 等等，这里需要先澄清一个关键点：
Composer 不支持 SQL 风格的 % 或正则式模糊匹配，但通过 version constraint（版本约束）机制，可以实现等效的“通配符式”安装。关键不是搜索包名，而是声明你想要哪个范围的版本。
直接运行 composer show 就能列出所有已安装的包及其版本，但默认只显示顶层依赖；想看完整依赖树或精确查某个包的版本，得加参数或换命令。
Composer 的 suggests 字段本身**不触发自动安装**，也不影响依赖解析，它只是个静态提示——想靠它“引导用户装关联包”，必须配合文档、脚本或工具链，否则基本没人会注意到。
当你的项目依赖某个 Composer 包 A，而 A 又依赖包 B，但包 B 已被另一个包 C 用 “replace” 声明替代（比如 “monolog/monolog”: “2.0.0” 被 “monolog/monolog”: {“replace”: {“psr/log”: “^1.0”}} 的包间接影响），实际安装时可能报错或行为异常。核心问题不是“不能装”，而是 Composer 在解析依赖图时发现版本冲突、提供关系不明确，或自动替换逻辑未按预期生效。
在现代PHP应用部署中，Composer不仅是依赖管理工具，还能通过其Scripts机制优化部署流程。合理使用Composer Scripts预热应用程序缓存，能显著减少首次请求的响应时间，提升用户体验。
PSR-4 映射失败，90% 是因为 autoload 配置里路径没对齐命名空间层级，或文件结构没严格遵循“命名空间 = 目录路径”规则。