Composer源码在GitHub官方仓库，克隆命令为git clone --depth 1 https://github.com/composer/composer.git；需用make install或php -d extension=phar.so bin/composer install安装，改代码后通过php bin/composer验证，PR前须匹配PHP版本、运行make cs-fix、避免硬编码路径。
Composer源码在哪，怎么克隆到本地
Composer官方仓库在GitHub上，主分支是 main，不是 master。直接克隆会拉下完整历史，但你真正需要的只是能跑起来、能调试的可执行版本。
- 用
git clone --depth 1 https://github.com/composer/composer.git节省时间，避免下载几万次提交 - 别急着
composer install—— Composer自身不依赖全局composer命令来安装，它用的是make install（基于Makefile）或手动php -d extension=phar.so bin/composer install - 确保 PHP 启用了
phar和zlib扩展，否则bin/composer运行时会报PharException: unable to open phar
改完代码怎么验证是否生效
Composer是命令行工具，改了逻辑必须通过真实命令触发才看得见效果，光跑单元测试不够。
- 改完后先用
php bin/composer直接运行，而不是composer—— 后者调用的是全局安装的稳定版，跟你本地代码无关 - 想模拟真实使用场景？把
bin/composer软链接到/usr/local/bin/composer-dev，然后用composer-dev require foo/bar测试 - 注意
bin/composer是个自加载脚本，修改src/Composer/Command/InstallCommand.php后，不需要重新生成 phar，改完保存就能立刻测
PR前必须绕过的三个CI陷阱
Composer的GitHub CI对环境和风格极其敏感，很多PR卡在CI不是因为逻辑错，而是没看清楚检查项。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- PHP版本必须匹配：CI跑
8.1、8.2、8.3，你本地用8.4写的match表达式会直接让CI挂掉 - CS（代码风格）用的是
php-cs-fixer，不是 PSR-12 默认规则 —— 检查前先跑make cs-fix，否则Array前要不要空格、function()里要不要空格都会被拒 - 单元测试里禁止硬编码路径，比如
/tmp/test；要用sys_get_temp_dir()+uniqid()构造临时目录，否则在Windows或Docker里必失败
为什么你的bugfix在本地有效，但别人复现不了
Composer行为高度依赖 composer.json 结构、平台配置、甚至 HOME 目录下的 auth.json，很多“修复”只在特定上下文成立。
- 测试时务必清空
~/.composer/cache/，否则旧的包元数据缓存会让新逻辑不触发 - 别只在项目根目录测，要覆盖三种典型场景：
composer require（无锁文件）、composer update（有composer.lock）、composer install --no-dev（禁用dev依赖） - 如果你改的是插件机制（比如
PluginInterface），记得关掉所有第三方插件测试，方法是加-n参数：php bin/composer -n install
最常被忽略的一点：Composer的 autoloader 是动态生成的，改了 autoload 配置后，不删 vendor/autoload.php 就直接跑，会沿用旧映射 —— 这个细节连不少老贡献者都会漏。
