Composer require 失败主因是稳定性设置或包不可见，需检查 minimum-stability、仓库可见性及版本兼容性；安装开发版需加 @dev 标识；Class not found 须执行 dump-autoload -o 并确认 autoload 配置；升级应限定范围并更新依赖；卸载模块需先禁用再 remove，最后手动清理与重编译。

composer require 时提示 package not found 或 version conflict

Magento 2 的模块依赖受 composer.json 中的 minimum-stability 和 prefer-stable 控制。默认 Magento 官方项目设为 "minimum-stability": "stable"，这意味着你无法直接 require dev 分支、-dev 后缀或未打 tag 的私有包。

• 确认目标包是否在 Packagist 或你的私有 repo（如 Satis / Private Packagist）中公开可查；运行 composer show vendor/module-name 测试可见性
• 若需安装开发版（例如 GitHub 上未发布 tag 的分支），临时允许非稳定版本：composer require vendor/module-name:dev-develop --no-update，再手动修改根目录 composer.json 中对应行，追加 "@dev" 稳定性标识，最后执行 composer update vendor/module-name
• 常见冲突源于 Magento 版本锁死：比如你用的是 Magento 2.4.6，而某模块只声明支持 "magento/framework": "^103.0.0"（对应 2.4.5），此时不能硬升，应找兼容 2.4.6 的分支或联系作者更新 composer.json

启用新模块后执行 setup:upgrade 却报 Class not found

这通常不是 Composer 问题，而是 Magento 的 autoloader 没加载到新类——根本原因是 composer dump-autoload 没触发或失败。

Git Deployer

将静态站点内容推送至 GitHub Pages 仓库。克隆、复制文件、带时间戳提交并强制推送。用于更新 GitHub Pages 站点和部署。

下载

• 确保模块已正确放入 vendor/（由 composer require 安装）或 app/code/（手动开发模块），且其 composer.json 包含合法的 autoload 配置，例如：

  {
      "autoload": {
          "psr-4": {
              "Vendor\Module\": ""
          }
      }
  }

• 运行 composer dump-autoload -o（-o 表示优化，生成 class-map，推荐始终加上）
• 如果模块在 app/code/ 下，还需确认该路径已加入 Composer 的 autoload：检查项目根目录 composer.json 的 autoload/psr-4 是否包含 "Vendor\Module\": "app/code/Vendor/Module/"，没有就补上并重跑 dump-autoload
• 清空 generated/ 和 var/cache/，再试 bin/magento setup:upgrade

如何安全地升级 Magento 核心或第三方模块

直接 composer update 可能批量升级所有依赖，引发未知兼容问题。生产环境必须限制范围。

• 只升级 Magento 核心：运行 composer update magento/product-community-edition --with-dependencies（CE 版）或 magento/product-enterprise-edition（EE 版）。--with-dependencies 保证 framework、setup、eav 等关键子包同步更新
• 只升级某一个第三方模块（如 dotmailer/dotmailer-magento2-extension）：composer update dotmailer/dotmailer-magento2-extension --with-all-dependencies（注意是 --with-all-dependencies，它会连带升级其直接依赖，但不碰其他无关包）
• 永远不要在生产环境跳过 composer install --no-dev：开发依赖（如 phpunit、phpcs）不应出现在线上，否则可能暴露调试入口或增大攻击面
• 升级前务必备份 composer.lock 和数据库；升级后运行 bin/magento setup:di:compile 和 bin/magento setup:static-content:deploy（如需要）

删除模块时 composer remove 不生效或残留数据库表

composer remove 只卸载代码和依赖，不会调用 Magento 的模块卸载逻辑（如 Uninstall.php），更不会删表。

• 先停用模块：bin/magento module:disable Vendor_ModuleName
• 再移除 Composer 包：composer remove vendor/module-name（注意不是 require --dev 那种写法）
• 手动清理残留：
  • 删除 app/code/Vendor/ModuleName（如果是本地开发模块）
  • 检查 setup_module 表，确认该模块记录已删（bin/magento setup:upgrade 会自动清理已禁用模块的记录，但有时需手动 DELETE FROM setup_module WHERE module = 'Vendor_ModuleName';）
  • 如有自定义表，且模块含 Uninstall.php，可运行 bin/magento setup:uninstall --module=Vendor_ModuleName（仅限 CLI 可用模块，且必须满足 Magento 卸载契约）
• 最后执行 composer dump-autoload -o + bin/magento setup:upgrade + 清缓存

Composer 在 Magento 2 里不是“装完就完”的工具，它和 Magento 的模块生命周期、autoloader、DI 编译深度耦合。最易忽略的是：每次改 composer.json（无论增删模块还是调版本）后，dump-autoload 和 setup:upgrade 缺一不可，且顺序不能反。