WSL 中 Windows 版 Composer 无法运行，因其为 PE 格式文件，Linux 内核不兼容；且依赖 Windows PHP 环境与扩展。须在 WSL 中单独安装 Composer 并配置 Linux PHP 环境及国内镜像源。
WSL 下的 Composer 不能直接用 Windows 版本，必须在 WSL 里单独安装并走 Linux 的 PHP 环境。
为什么 Windows 的 composer.bat 在 WSL 里跑不起来
WSL 是 Linux 内核兼容层，不是 Windows 子进程。你在 WSL 终端里敲 composer，系统找的是 /usr/local/bin/composer 或 ~/bin/composer，不是 Windows 的 composer.bat。强行用 windowspath\composer.bat 会报 bash: /mnt/c/.../composer.bat: cannot execute binary file: Exec format error —— 这是典型的 Windows PE 文件在 Linux 下无法加载。
- Windows 的
composer.phar虽然理论上可执行，但依赖 Windows 的php.exe路径和扩展（如openssl、zip），WSL 默认 PHP 不带这些 - WSL 的
php命令通常来自apt install php-cli，路径是/usr/bin/php，和 Windows 完全隔离 - 别试图用
alias composer='winpty /mnt/c/.../composer.bat'，会卡死或乱码
在 WSL 里正确安装 Composer（PHP 8.x 场景）
以 Ubuntu 22.04 / 24.04 为例，前提是已装好 PHP CLI（php -v 能输出版本）。如果没装，先运行 sudo apt update && sudo apt install php-cli php-zip php-xml php-mbstring —— 少任何一个，composer install 都可能报错 The requested PHP extension zip is missing。
- 下载官方 PHAR：
curl -sS https://getcomposer.org/installer | php - 移到全局路径：
sudo mv composer.phar /usr/local/bin/composer - 加执行权限：
sudo chmod +x /usr/local/bin/composer - 验证：
composer --version应输出类似Composer version 2.7.7
注意：不要用 sudo php composer-setup.php 那种老方法，容易因权限或临时目录问题失败；也别用 snap 或 apt 安装的 composer 包（太旧，常卡在 2.2.x，不支持 PHP 8.3+ 的新特性）。
配置国内镜像源（避免超时和 404）
默认源 https://packagist.org 在 WSL 里直连极慢，且 WSL 的 DNS 解析有时不稳定，常见错误是 [Composer\Downloader\TransportException] The "https://packagist.org/packages.json" file could not be downloaded。
- 全局换源（推荐）：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用）→ 改用：composer config -g repo.packagist composer https://packagist.org并配合composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - 更稳妥的阿里云镜像命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否生效：
composer config -g repo.packagist应输出{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
别漏掉 -g 参数，否则只对当前目录生效；也不要用 ~/.composer/config.json 手动改——格式错一个逗号就导致 composer 命令直接退出无提示。
WSL 访问 Windows 文件时的权限与路径坑
你在 /mnt/c/Users/xxx/project 里跑 composer install，看似方便，实则埋雷：
- Windows 文件系统（NTFS）挂载到
/mnt/c后，Linux 权限模型失效，chmod无效，某些包的 post-install scripts 会因“无法创建可执行文件”失败 - PHP 的
opcache或apcu在跨文件系统时缓存行为异常，composer dump-autoload可能生成错误的 autoload_classmap.php - 最佳实践：把项目放在 WSL 原生路径，比如
~/projects/myapp；用code ~/projects/myapp启动 VS Code，它能自动识别 WSL 环境并启用 Remote-WSL 插件
如果你非得在 /mnt/c 下工作，至少加一句 export COMPOSER_HOME="$HOME/.composer" 到 ~/.bashrc，避免 Composer 把 cache 写进 Windows 目录再引发编码或权限问题。
最常被忽略的是 PHP 扩展状态 —— WSL 里 php -m 看似有 zip，但实际可能是 disabled，得查 php --ini 对应的 php.ini 里有没有 extension=zip 这行，并确认该 so 文件真实存在。没这步，composer create-project 会在解压阶段静默失败。
