技术博客
Composer 默认所有 composer install 或 composer update 都会联网拉取包，包括插件（比如 hirak/prestissimo、phpstan/extension-installer）。离线时直接报错：Could not fetch https://repo.packagist.org/packages.json，连 metadata 都拿不到，更别说插件本身。
安全风险路径藏在 advisories 数组每个条目的 source 字段里，它不是直接列出调用链，而是给出触发该漏洞的「最短依赖路径」——即从你的项目根开始，到引入问题包的那条最小依赖链。
WSL 默认不会把 Windows 的 PATH 自动继承过来，更不会识别 Windows 下通过 Installer 安装的 Composer。你在 WSL 里敲 composer –version 报 command not found，大概率是压根没在 Linux 环境里装过它。
Composer 本身不执行 Git hooks，pre-commit 是 Git 的钩子，必须靠第三方工具或手动集成。最直接的做法是用 composer install 或 composer update 触发钩子安装，但前提是项目里已引入支持钩子的包（比如 brainmaestro/composer-git-hooks）。
Composer 的脚本钩子全靠 scripts 字段驱动，它不是插件也不是扩展，就是个 JSON 键值对。写错位置或格式，composer install 不报错但脚本压根不触发。
加 –no-suggest 就能直接跳过所有 suggest 字段声明的包，不会提示、不会下载、也不会写入 vendor/。它不改变依赖解析逻辑，只影响“额外推荐内容”的处理阶段。
核心是改 composer.json 的 repositories 配置，把默认的 packagist.org 关掉，再加你的私有源。不关默认源的话，Composer 会先去公网找——哪怕你写了私有地址，它也可能绕过你直接连外网。
这不是 Composer 自身的问题，而是 Xdebug 的递归限制被 Composer 的依赖解析器（特别是 composer/composer 内部的 AST 解析和插件加载逻辑）意外触发。Xdebug 默认的 xdebug.max_nesting_level=256 在处理大型项目（比如含 dozens 个插件、嵌套 require-dev、或使用 path repository 的 monorepo）时很容易耗尽。
autoload 配置错一个字母，composer dump-autoload 不报错，但运行时直接 Class not found。根本原因不是“没加载”，而是 PSR-4 映射路径和命名空间不严格对齐。
这是最常见触发忽略平台检查的场景：本地 PHP 版本或扩展（如 ext-mbstring）和 composer.json 中声明的 platform 或依赖包要求不匹配，导致安装中断。