Composer不能直接管理PrestaShop模块，仅能管理核心依赖、第三方库及开发工具；少数兼容模块需显式支持"type":"prestashop-module"并配合软链接；模块升级、数据库变更等仍须依赖PrestaShop自身机制。
Composer 不能直接管理 PrestaShop 模块
直接在 composer.json 中 require 一个 PrestaShop 模块（比如 "prestashop/statscatalog": "^2.0"）通常不会生效——PrestaShop 的模块加载机制不依赖 Composer 自动发现或 autoload，它靠的是特定目录结构（modules/xxx/）和钩子注册。Composer 在 PrestaShop 中主要用于管理**核心依赖、第三方库或开发工具**，而非模块本身。
用 Composer 安装模块的“伪集成”方式（仅限部分兼容模块）
极少数模块作者会主动适配 Composer：提供 composer.json 并声明 "type": "prestashop-module"，同时在 autoload 中映射类，并通过 post-autoload-dump 脚本软链接到 modules/ 目录。但这类模块极少，且需模块作者显式支持。
- 确认模块是否真支持：检查其 GitHub/GitLab 仓库根目录是否存在
composer.json，且含"type": "prestashop-module" - 运行
composer require vendor/module-name --no-scripts先安装（避免脚本失败中断） - 手动执行模块提供的安装脚本（如有），例如：
php modules/vendor_module_name/install.php - 进入 PrestaShop 后台 → “模块管理”，刷新并启用该模块
更可靠的做法：用 Composer 管理模块依赖的第三方库
大多数 PrestaShop 模块自身需要 Guzzle、Monolog、Symfony Components 等库。这些可以也**应该**用 Composer 管理，但必须注意作用域隔离：
Github 1.0.0
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 不要把
vendor/放在modules/xxx/vendor/下（易被误删或暴露） - 推荐在项目根目录统一维护一个
composer.json，用"autoload": {"psr-4": {"MyModule\": "modules/my_module/src/"}}注册模块自己的命名空间 - 模块内通过
require_once __DIR__.'/../../vendor/autoload.php';加载（不推荐）或更安全地使用ClassLoader手动注册 —— 因为 PrestaShop 的Tools::getCacheId()等函数可能干扰自动加载 - 部署时运行
composer install --no-dev --optimize-autoloader，再把生成的vendor/和模块一起打包
模块升级与 Composer.lock 的陷阱
PrestaShop 模块升级往往涉及数据库变更（upgrade/ 目录）、模板覆盖、甚至核心钩子签名变化。Composer 不会触发这些逻辑：
-
composer update只更新代码文件，不会调用模块的upgrade/<version>.php</version> - 若模块版本号变更但未发布新 tag，
composer.lock可能锁定旧 commit，导致本地测试和线上行为不一致 - 禁止将
modules/目录加入gitignore后全靠 Composer 恢复——模块配置、上传的图片、自定义翻译等数据会丢失
{
"name": "my-shop/project",
"type": "project",
"require": {
"prestashop/prestashop": "^8.1.0",
"guzzlehttp/guzzle": "^7.5"
},
"autoload": {
"psr-4": {
"MyStatsModule\": "modules/mystatsmodule/src/"
}
}
}
模块不是 Composer 包，别把它当包用。真正要管好模块，得靠 PrestaShop 的模块生命周期钩子、SQL 升级脚本、后台操作日志，以及一份清晰的部署 checklist —— Composer 只是帮你把依赖库装对了而已。
