Composer仅管理PHP包依赖，不负责配置文件分发；共享开发工具配置需通过require-dev统一安装工具、scripts封装命令、配合外部手段（如Git子模块）同步配置文件。
Composer 本身不管理开发工具配置，它只管 PHP 包依赖；所谓“共享开发工具配置”，实际是靠 composer.json 的 require-dev + scripts + 合理的包选择来统一安装和调用，而不是把 .phpcs.xml 或 .phpstan.neon 这类文件“托管”给 Composer。
为什么不能直接用 Composer 管理配置文件
Composer 是依赖管理器，不是配置分发工具。它不会自动复制、同步或覆盖项目根目录下的配置文件（如 .eslintrc.js、phpunit.xml）。你看到的“共享配置”，本质是：多个项目都声明了同一个 dev 包（比如 phpstan/phpstan），再配合统一的配置文件路径约定，由工具自身去加载。
-
composer require --dev phpstan/phpstan只装二进制和类库，不放配置 - 配置仍需手动维护，或通过额外手段（如软链、模板生成、Git submodule）同步
- 若强行把配置打包进一个私有包并 require，会遇到路径解析问题：
PHPStan默认只读取当前工作目录下的phpstan.neon，不自动加载 vendor 里的同名文件
用 require-dev 统一安装工具版本
这是最可靠、最轻量的共享基础——确保所有项目用相同大版本的 linter/tester/analyser，避免“本地能过 CI 报错”这类问题。
- 在团队所有项目的
composer.json中，保持require-dev块高度一致，例如：
"require-dev": {
"phpunit/phpunit": "^10.5",
"phpstan/phpstan": "^1.11",
"friendsofphp/php-cs-fixer": "^3.14",
"nikic/php-parser": "^4.18"
}
- 禁用
^的宽泛范围（如不用"phpstan/phpstan": "*"），防止某天 CI 突然因新版本报错 - 不要把工具放在
require（生产依赖），否则上线时会多出无用 autoload 和二进制 - CI 脚本里应运行
composer install --no-interaction --no-progress --prefer-dist --optimize-autoloader，并加--no-dev部署到生产环境
用 scripts 封装常用命令别名
把重复的 CLI 调用收口到 composer.json 的 scripts，既降低记忆成本，也避免各项目参数不一致（比如有人漏 --no-ansi 导致 CI 日志混乱）。
- 示例定义：
"scripts": {
"test": "phpunit --colors=never",
"phpstan": "phpstan analyse --no-progress --level max src/",
"cs-fix": "php-cs-fixer fix --dry-run --diff",
"cs-check": "php-cs-fixer fix --dry-run --diff",
"check": [
"@phpstan",
"@cs-check",
"@test"
]
}
- 所有项目执行
composer check就跑完整检查流程，顺序和参数完全一致 - 注意路径写死风险：上面的
src/要根据项目结构调整，不能盲目复用；更健壮的做法是用环境变量或脚本包装器（如./bin/run-phpstan） -
scripts中的命令默认在项目根目录执行，所以相对路径是可靠的；但跨平台时慎用 shell 特性（如&&、$()），优先用单条命令或封装为 PHP/Shell 脚本
配置文件共享的三种可行路径
真要让配置“共享且可更新”，得绕过 Composer 自身限制，选一种副作用小、团队易接受的方式：
-
Git 子模块：把
.php-cs-fixer.php、phpstan.neon等放到独立仓库（如org/php-dev-config），各项目以子模块方式引入到.dev-config/目录，再在各自composer.json的scripts中指定--config=.dev-config/.php-cs-fixer.php -
Makefile + curl/wget：在项目根目录放
Makefile，提供make sync-config，从内部 HTTP 服务拉取最新配置（适合有内网 Git 或对象存储的团队） -
私有包 + post-install-cmd 脚本：发布一个
org/dev-config-installer包，在其post-install-cmd中用 PHP 复制 vendor 里的配置模板到项目根目录（需谨慎处理已存在文件的覆盖逻辑，建议加--force开关或交互提示）
没有银弹。子模块最透明可控，但新人容易误操作；HTTP 拉取最灵活，但引入外部依赖；私有包最“Composer 原生”，但调试 post-install-cmd 很麻烦，且 Composer 2.2+ 对脚本执行权限更严格。
