Capifony 已停止维护，因依赖过时的 Capistrano 2.x 和 Ruby 1.9–2.3，不兼容 Composer 2+ 与 Symfony 4+/Laravel 6+ 目录结构，最后发布于 2015 年且仓库已归档。
Capifony 已停止维护，capifony 不再兼容现代 PHP 项目和 Composer 2+，强行使用会导致部署中断、依赖解析失败或权限错误。
为什么 capifony 现在基本不可用
Capifony 是基于 Capistrano 2.x 的旧封装，依赖已弃用的 symfony/symfony 集成方式和 Ruby 1.9–2.3 语法；Composer 2 默认禁用 --no-scripts 和 --no-plugins 的宽松模式，而 capifony 的 composer:install 任务硬编码了这些参数；其 shared_children 和 web_path 配置与 Symfony 4+/Laravel 6+ 的目录结构（如 public/）不匹配。
-
capifony最后一次发布是 2015 年，官方仓库已归档 - Ruby 3+ 下运行
cap命令会触发NoMethodError: undefined method `map' for nil:NilClass - Composer 安装时卡在
Loading composer repositories with package information，实为 capifony 传入了无效的--prefer-dist --no-dev组合导致超时
替代方案：用原生 capistrano + 自定义任务
直接使用 Capistrano 3.x（Ruby ≥ 2.4），通过几行 deploy.rb 就能复现 capifony 的核心逻辑，且可控性强、易调试。
- 在
Capfile中只 requirecapistrano/composer和capistrano/bundler，不要 requirecapifony - 重写
composer:install任务，显式指定--no-interaction --optimize-autoloader --no-progress - 用
set :composer_install_flags, '--no-dev'控制环境，而非依赖 capifony 的stages插件 - 对
public/目录做符号链接时，改用ln -nfs而非 capifony 的shared_children，避免 Laravel/Symfony 项目中storage/权限异常
关键配置项必须手动覆盖
Capistrano 3 默认行为与 PHP 部署强相关，以下几项不改就会出错：
立即学习“PHP免费学习笔记（深入）”；
-
set :application, 'myapp'— 必须设，否则deploy:check报undefined local variable or method `application' -
set :repo_url, 'git@github.com:user/repo.git'— SSH URL，HTTPS 会导致部署机无权拉取私有库 -
set :composer_vendor_dir, 'vendor'— 若项目用COMPOSER_VENDOR_DIR环境变量，此处必须同步 -
set :linked_files, %w[.env]—.env必须显式声明，capifony 的自动识别在 Capistrano 3 中不存在 -
set :default_env, { 'PATH' => '/opt/php/bin:/usr/local/bin:$PATH' }— 否则composer命令找不到，报bash: composer: command not found
部署前必跑的验证命令
别跳过本地检查，很多问题在 cap production deploy 时报错才暴露，其实早就能发现。
-
cap production deploy:check— 检查远程目录权限、SSH 连通性、composer是否在$PATH -
cap production composer:install— 单独执行安装，观察是否卡在autoload_static.php生成（常见于 SELinux 或opcache.restrict_api开启） -
cap production deploy:pending— 确认 Git commit hash 正确，避免因本地未git push导致部署旧版本 -
ssh user@host 'ls -la /var/www/myapp/shared/.env'— 手动确认共享文件存在且权限为 600（chmod 600不能靠 capistrano 自动完成）
真正麻烦的不是写部署脚本，而是 PHP 运行时环境差异：同一份 composer.json 在部署机上可能因 ext-zip 缺失、memory_limit 不足或 date.timezone 未设而静默失败。建议把 php -m、php -i | grep -E "(memory_limit|timezone|extension)" 加进部署前健康检查任务里。
