技术博客
这不是 Composer 自身的问题，而是 Xdebug 的递归限制被 Composer 的依赖解析器（特别是 composer/composer 内部的 AST 解析和插件加载逻辑）意外触发。Xdebug 默认的 xdebug.max_nesting_level=256 在处理大型项目（比如含 dozens 个插件、嵌套 require-dev、或使用 path repository 的 monorepo）时很容易耗尽。
因为 composer install 默认不会跳过已有的 vendor 和 .git 目录缓存，哪怕加了 –no-cache，它只影响 Composer 的内部包元数据缓存（比如 packages.json），不清理 Git 克隆下来的源码副本。
这是最常见触发忽略平台检查的场景：本地 PHP 版本或扩展（如 ext-mbstring）和 composer.json 中声明的 platform 或依赖包要求不匹配，导致安装中断。
默认不自动同步，所有用户数据（插件、设置、快捷键）都存本地，路径取决于系统：~/Library/Application Support/Sublime Text/Packages/（macOS）、%APPDATA%Sublime TextPackages（Windows）、~/.config/sublime-text/Packages/（Linux）。Packages/ 下的 User/ 文件夹是关键——你改的所有 Preferences.sublime-settings、Key Bindings.sublime-keymap 都在这儿。
它只显示你当前项目的 license 字段（比如 myapp/myproject → MIT），**一个依赖包的许可证都不会列出来**。很多人一试就以为“全量扫描成功”，结果法务审核时才发现漏了 90% 的依赖。
Composer 的 HTTP 超时不是通过 http-basic 配置项控制的——这个配置只管认证凭据，跟超时完全无关。真正起作用的是全局或项目级的 http-timeout 配置项，单位是秒，默认值是 300（5 分钟），但弱网下往往不够用。
私有包不能靠 Packagist 自动发现，必须显式告诉 Composer 去哪找。核心是往 composer.json 的 repositories 字段里加一条配置，类型取决于你用的托管方式。
这不是 Composer 的 bug，而是它在保护你：检测到某个已安装的包（比如 vendor/foo/bar）里有被你手动改过的文件，而这些修改和该包当前安装的版本（通常来自 composer.lock）不一致。Git 会把这些改动标为“dirty”，Composer 就拦下来不让你继续——怕你覆盖掉自己的修改，或者误把脏包当成干净依赖发布。
关键不是“加仓库”，而是让 composer 知道：这个包的源不在 Packagist，得去某个 Git 地址拉。直接在 composer.json 里写 "repositories" 是最常用方式，但必须配对使用 "type": "vcs"，否则会被忽略。
因为 composer 本身是 PHP 工具，它依赖宿主机的 PHP 运行时、扩展、CA 证书、网络代理设置，甚至 ~/.composer/ 缓存路径。Docker 容器里如果只简单 apt install composer，大概率遇到：无法加载 openssl 扩展、curl 报 SSL certificate problem、composer install 卡在 Updating dependencies、或者安装的包权限错误导致 Laravel 项目启动失败。