技术博客
不是网络慢，也不是包源问题，composer install 在解析依赖阶段爆 Allowed memory size exhausted，基本就是 PHP 内存限制撞上了 Composer 本身的高开销。2G 是常见上限，但 Composer 2.x 在复杂项目里轻松吃掉 1.5G+，尤其带大量 require-dev 或历史版本约束时。
它不提供图形化向导，也不在菜单里放个 New Project。所谓“项目”，只是 Sublime 记住了一组打开的文件夹路径 + 一些配置（比如构建系统、设置覆盖），本质是生成一个 .sublime-project 文件。你得手动创建或让 Sublime 自动帮你存。
Composer 默认把依赖装进 vendor 目录，想改名字，最直接的方式是在项目根目录的 composer.json 里加配置项。不是全局改，是每个项目自己决定。
宝塔默认会在 PHP 配置中禁用 putenv、proc_open 等函数，而 Composer v2+ 的 self-update 必须调用它们——所以你敲了命令却提示“权限不足”“无法写入”，甚至直接静默失败，大概率不是权限问题，而是 PHP 层面拦住了。
这是最常见场景：本地 PHP 版本或扩展（如 ext-gd、ext-mbstring）不满足 composer.json 中 config.platform 或依赖包的 require 声明，导致安装中断。
直接在 composer.json 的 config.platform.php 或根级 require.php 中声明，二者作用完全不同：require.php 是项目运行所依赖的 PHP 最低（及可选上限）版本，Composer 会据此筛选兼容的包；config.platform.php 是“假装”当前环境是某个 PHP 版本，用于构建或 CI 场景下绕过本地真实版本限制。
Sublime 默认开启括号匹配，但很多人改过设置后把它关掉了，结果装了插件也“没反应”——其实根本没走到插件那步。必须先确保原生功能正常，否则 BracketHighlighter 的高亮可能被压制或覆盖。
你执行 composer install，却装了旧版包，甚至报错说找不到刚发布的 v2.3.0 —— 这不是你本地 composer.json 写错了，是镜像源没同步上游 Packagist 的元数据。国内主流镜像（如腾讯、阿里、华为）通常有 5–30 分钟延迟，高峰期可能更久。
Composer 启动时会先检查 COMPOSER_HOME 环境变量，如果设置了，就用它作为用户级配置目录（默认是 ~/.composer）。这个变量直接决定 auth.json、config.json 和插件缓存的落盘位置。
不能。它只支持回退到「上一个通过 self-update 升级前的版本」，且仅限一次——比如你从 v2.5.8 升到 v2.6.0，执行 composer self-update –rollback 会回到 v2.5.8；但如果又升到了 v2.6.1，再运行这个命令，只会回到 v2.6.0，而不是最初的 v2.5.8。