技术博客
Composer 的脚本事件由 composer.json 里的 "scripts" 字段控制，它是个 JSON 对象，键是事件名（比如 post-install-cmd），值是命令或数组。脚本不会自动启用或禁用——只要定义了，对应事件触发时就会执行；删掉某条就等于禁用它。
Composer 安装或更新时卡在 Downloading… 或报 cURL error 28: Operation timed out，基本就是默认超时太短 + 网络不稳定，不是配置错，也不是源失效——改两个参数就能过。
直接跳过平台检查，用 –ignore-platform-reqs 参数。这不是“绕过问题”，而是告诉 Composer：“我清楚当前 PHP 或扩展版本不匹配 composer.json 里写的 platform 约束，但我要强制继续。”
直接运行 composer show vendor/package 不会输出该包的 autoload 配置——这是常见误解。Composer 的 show 命令只展示包元信息（如版本、描述、依赖），不解析其 composer.json 中的自动加载规则。
不能。Composer 的 vendor-dir 是项目级配置，写在每个项目的 composer.json 里，没有全局生效的 vendor 共享机制——强行共用会导致依赖版本冲突、autoload 错乱、甚至 composer install 直接失败。
Composer 不会因为包被标记为 abandoned 就拒绝安装或报错——它只是在终端输出一行黄色警告，然后照常拉取、解压、autoload。这个标记纯属元信息，不触发任何强制行为。
私有包不能靠 Packagist 自动发现，必须显式告诉 Composer 去哪找。核心是往 composer.json 的 repositories 字段里加一条配置，类型取决于你用的托管方式。
这不是 Composer 的 bug，而是它在保护你：检测到某个已安装的包（比如 vendor/foo/bar）里有被你手动改过的文件，而这些修改和该包当前安装的版本（通常来自 composer.lock）不一致。Git 会把这些改动标为“dirty”，Composer 就拦下来不让你继续——怕你覆盖掉自己的修改，或者误把脏包当成干净依赖发布。
直接运行 composer init 会进入交互式问答流程，填完项目名、描述、作者、依赖等十几项才能生成 composer.json。实际开发中，90% 的初始项目只需要最小可用配置——比如一个空的 composer.json 或仅声明 PHP 版本约束。
因为 composer install 只在已有 composer.lock 时才安装依赖；它本身不生成 lock 文件。想生成或更新 lock，必须用 composer update 或首次运行 composer install（当 lock 不存在且 composer.json 存在时）。