Ansible中使用community.general.composer模块最稳妥，因其自动检测PHP路径、校验composer.json存在性，并支持no_dev、optimize_autoloader等关键参数；需先安装community.general集合，确保working_dir权限正确、PHP路径显式配置，避免Shell调用的PATH和权限陷阱。
Ansible中用community.general.composer模块安装依赖最稳妥
直接调用composer命令容易因PHP环境缺失、权限不足或路径未生效而失败；官方community.general.composer模块会自动检测PHP可执行路径、检查composer.json存在性，并支持no_dev、optimize_autoloader等关键参数，出错时也更易定位。
常见错误现象：failed: [host] => {"msg": "The module 'composer' was not found"} —— 这说明community.general collection未安装，不是模块写错。
- 先运行
ansible-galaxy collection install community.general（Ansible 2.10+必需） -
working_dir必须指向含composer.json的目录，且该目录对运行Ansible的用户（如www-data或root）有读写权限 - 若PHP不在默认
/usr/bin/php，需显式指定php_executable参数，例如php_executable: /usr/local/bin/php - 生产环境务必设
no_dev: true和optimize_autoloader: true，避免加载开发依赖和低效类加载
Shell方式安装Composer二进制文件要避开PATH陷阱
在Ansible中用command或shell模块下载并移动composer.phar后，常出现command not found: composer——根本原因不是没放对位置，而是Ansible任务默认不继承登录shell的PATH，/usr/local/bin可能不在其执行环境里。
正确做法是：不依赖全局PATH，而是用绝对路径调用；或明确刷新环境变量。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐用
get_url+command组合，避免curl管道失败静默退出：get_url: url=https://getcomposer.org/installer dest=/tmp/composer-setup.phpcommand: php /tmp/composer-setup.php --install-dir=/usr/local/bin --filename=composer - 验证是否生效：加一个
command: /usr/local/bin/composer --version任务，别只信creates参数 - 如果必须用
shell模块且依赖PATH，得显式设置environment: {"PATH": "/usr/local/bin:/usr/bin:/bin"}
中文镜像源配置必须写进config.json而非命令行参数
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/这类命令在Ansible中执行后，常发现下次运行install仍走国外源——因为Ansible默认以非交互、非登录shell执行，用户级配置文件~/.composer/config.json可能写入了root用户家目录，但实际运行PHP进程的是www-data或其他用户。
真正可靠的方案是直接写入目标用户的配置文件，或使用composer模块的global_config参数。
- 用
copy模块部署预配置好的config.json到/home/www-data/.composer/config.json（注意属主和权限0600） - 或在
community.general.composer任务中加global_config: { "repositories": { "packagist": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } } } - 别用
command跑composer config再期望它“永久生效”，尤其在容器或无家目录环境中基本无效
Vagrant provision中composer install失败多半因共享目录权限
Vagrant默认把宿主机项目目录挂载为/var/www/html，但Composer需要在该目录下创建vendor/和写composer.lock。Linux虚拟机中，挂载点的UID/GID常与宿主机不一致，导致Permission denied。
这不是Composer本身的问题，而是Vagrant同步机制的副作用。
- 在
Vagrantfile中显式设置挂载选项：owner: "www-data", group: "www-data", mount_options: ["dmode=775,fmode=664"] - 或改用
rsync同步模式（type: "rsync"），它不共享文件系统权限，而是单向复制，规避权限冲突 - 调试时临时加
become: true和become_user: www-data确保以正确用户身份执行composer install
composer_version或校验PHP版本，composer install可能在解析composer.json时直接abort，报错信息却只显示Script @php artisan package:discover handling the post-autoload-dump event returned with error code 255——这和Autoload无关，只是底层PHP版本太低撑不住新版Composer。 
