Composer 是 Magento 2 的底层依赖骨架，跳过它手动操作会导致模块未安装或类找不到；安装扩展后需手动启用模块并运行 setup:upgrade 才能生效。
Composer 不是“可选工具”，而是 Magento 2 的底层依赖骨架——跳过它手动放文件、改目录、硬编码启用，等于绕开引擎直接拧螺丝，迟早报 Module 'Vendor_Module' is not installed 或 Class not found。
composer require 安装扩展后模块没启用？
Composer 只负责把代码放进 vendor/（或按 extra/map 放进 app/code/），它不触发 Magento 的模块注册机制。
- 必须手动执行
php bin/magento module:enable Vendor_ModuleName（模块名来自etc/module.xml中的<module name="Vendor_ModuleName">） - 接着运行
php bin/magento setup:upgrade，否则数据库 schema/data 不更新，module:status里仍显示禁用 - 如果扩展声明了
"type": "magento2-module"且含合法registration.php，Composer 安装时会自动写入config.php；但若缺失任一条件（比如漏registration.php或返回值不是ComponentRegistrar::MODULE），setup:upgrade会直接忽略该模块
安装失败常见报错和对应检查点
典型错误如 [RuntimeException] Could not load package vendor/module in https://repo.magento.com 或 Your requirements could not be resolved to an installable set of packages，背后往往是环境或配置卡点：
-
auth.json缺失或 token 过期：Magento Marketplace 包必须认证，文件需放在项目根目录或COMPOSER_HOME，内容格式为{"http-basic": {"repo.magento.com": {"username": "...", "password": "..."}}} - PHP 版本不匹配：例如
magento/framework104.x 要求 PHP 8.2+，而本地是 8.1 → 运行php -v和composer prohibits magento/framework确认冲突源头 - 版本约束冲突：两个扩展同时 require 不同主版本的
monolog/monolog→ 用composer depends monolog/monolog查谁在拉旧版，再决定降级某扩展或联系作者适配 - 私有包未配置仓库：若扩展来自内部 Packagist，
composer.json中必须显式声明"repositories"，且类型为"composer"，URL 需可访问
升级/卸载扩展为什么不能删 vendor 文件夹？
直接删 vendor/ 或 app/code/ 下目录，会破坏 Composer 的锁文件（composer.lock）与实际文件的一致性，后续 composer install 可能拒绝恢复，或导致 autoloader 错乱。
- 升级指定包：用
composer update vendor/module-name，而非全局composer update（生产环境严禁） - 卸载：用
composer remove vendor/module-name，它会自动删代码、删require条目、重写composer.lock - 卸载后务必执行
php bin/magento module:disable Vendor_ModuleName+setup:upgrade，否则残留的config.php条目可能干扰其他模块加载 - 若已误删，先
git checkout -- composer.json composer.lock恢复声明，再composer install --no-plugins强制重装（避免插件二次篡改）
最易被忽略的是 composer.json 里 "type": "magento2-module" 这一行——没有它，magento/composer-root-update-plugin 就不会介入，registration.php 再标准也进不了 config.php。别只盯着功能代码，先验这个字段。
