ECC Laravel 验证循环从环境检查到队列健康检查的七阶段发布前验证指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文基于 ECC 仓库中的laravel-verification技能文档完整解析其七阶段7 phases验证循环的每个步骤、全部命令与取舍逻辑。读完本文你可以在打开 PR、依赖升级后或部署 staging/production 之前独立执行一套「环境 → Composer → Lint/静态分析 → 测试与覆盖 → 安全审计 → 迁移 → 构建/部署就绪 → 队列与调度器」的完整验证流水线并理解每一阶段为什么按此顺序排列。技能的定位与触发时机laravel-verification是 ECC 为 Laravel 项目定义的验证循环Verification Loop。技能文档的 frontmatter 声明了它的定位Bucle de verificación para proyectos Laravel: verificaciones de entorno, linting, análisis estático, pruebas con cobertura, escaneos de seguridad y preparación para despliegue. 面向 Laravel 项目的验证循环环境检查、Lint、静态分析、带覆盖率的测试、安全扫描与部署准备。来源见 docs/es/skills/laravel-verification/SKILL.md英文版原文为 skills/laravel-verification/SKILL.md。文档给出四个明确的适用场景为 Laravel 项目打开 Pull Request 之前完成重要重构或依赖升级之后staging 或生产环境的部署前验证需要跑完整的lint → test → security → deploy readiness流水线时。七阶段流水线的执行原则文档在「Cómo Funciona」How It Works一节定义了整条流水线的编排原则这是理解各阶段顺序的关键严格顺序执行从环境检查一路执行到部署就绪每一层建立在前一层之上环境与 Composer 检查是总闸门这两项是其余一切工作的前提一旦失败立即停止不要继续往下跑Lint/静态分析必须先干净只有格式与静态分析通过才执行完整测试与覆盖率安全与迁移审查放在测试之后先验证行为测试再审查数据层变更与依赖安全构建/部署就绪与队列/调度器检查是最后的闸门任何一项失败都直接阻断发布。这个顺序体现了一个核心思想先确认工具链可用再确认代码质量再确认行为正确最后确认数据与运行时基础设施可以承载发布——避免在错误的环境上浪费昂贵的测试与部署步骤。阶段 1环境检查Verificaciones de Entorno一切从确认运行时开始php -v composer --version php artisan --version同时需要人工核对三类环境状态.env文件存在且所有必需的键key都已定义生产环境中APP_DEBUGfalseAPP_ENV与目标部署环境一致production或staging。如果本地开发使用 Laravel Sail则通过 Sail 前缀执行同样的检查./vendor/bin/sail php -v ./vendor/bin/sail artisan --version这一步的价值在于后面所有阶段都依赖 PHP、Composer 和 Artisan 三个组件版本或.env缺失导致的失败往往具有迷惑性例如artisan能启动但数据库连接报错不如在第一阶段就直接暴露。阶段 1.5Composer 与 Autoloadcomposer validate composer dump-autoload -ocomposer validate校验composer.json的合法性是依赖层的第一道闸composer dump-autoload -o以优化模式-o类映射重新生成 autoload 文件保证类发现结果与实际代码一致。ECC 在文档中把它单独编号为 1.5强调它属于「环境类」检查而非「代码质量」检查autoload 不一致会导致后续阶段出现莫名其妙的Class not found与其在测试阶段排查不如在入口处排除。阶段 2Linting 与静态分析vendor/bin/pint --test vendor/bin/phpstan analysepint --test只做检查不自动修复——验证循环的目标是「发现问题」而不是「顺手改掉」避免验证过程污染工作区phpstan analyse执行静态类型分析。如果项目使用的是 Psalm 而不是 PHPStan则替换为vendor/bin/psalm这一阶段的原则是「先静态后动态」格式和类型问题在静态分析阶段发现成本最低。仓库中的 rules/php/testing.md 也呼应了同类约定例如 CI 中优先使用 pcov 或 Xdebug 保持覆盖率阈值、HTTP/Controller 测试聚焦传输层与校验而把业务规则下沉到服务层测试。阶段 3测试与覆盖率php artisan testCI 场景下带覆盖率运行XDEBUG_MODEcoverage php artisan test --coverage文档给出的最小 CI 三段式片段格式化 → 静态分析 → 测试vendor/bin/pint --test vendor/bin/phpstan analyse XDEBUG_MODEcoverage php artisan test --coverage注意XDEBUG_MODEcoverage环境变量Xdebug 默认是 debug 模式不显式切换到 coverage 模式时--coverage拿不到覆盖率数据。这一点与 rules/php/testing.md 中「Prefer pcov or Xdebug in CI, and keep coverage thresholds in CI rather than as tribal knowledge」的指引一致——覆盖率应作为 CI 的硬约束而不是口头约定。测试本身的写法PHPUnit/Pest、Factory、Sanctum 认证测试可参考同目录的 skills/laravel-tdd/SKILL.md。阶段 4安全与依赖审计composer auditcomposer audit对照已发布的安全公告检查vendor中依赖的已知漏洞。它被安排在测试之后、数据层操作之前意味着行为已被测试确认正确后再确认依赖本身没有被投毒或存在已知 CVE。更深层的 Laravel 安全审查认证与授权、Eloquent 安全、CSRF/XSS、生产环境配置由配套的 skills/laravel-security/SKILL.md 承担其中明确给出APP_DEBUG在生产环境绝不允许为true、APP_KEY必须在启动时校验、.env永不入库等规则——这些正是阶段 1 环境检查中人工核对项的展开。阶段 5数据库与迁移php artisan migrate --pretend php artisan migrate:statusmigrate --pretend只打印将要执行的 SQL 而不真正运行用于在触碰任何真实数据之前预演迁移migrate:status查看迁移的已应用/未应用状态。文档对迁移本身提出四条审查要求仔细审查破坏性迁移drop 列、drop 表、改类型等迁移文件名遵循Y_m_d_His_*格式例如2025_03_14_154210_create_orders_table.php且名称要清晰描述变更内容确保回滚可行逐个核对down()方法避免在没有显式备份的情况下发生不可逆的数据丢失。--pretend是这一阶段的精髓它让「审查 SQL」和「执行 SQL」分离破坏性变更在进入发布路径前就必须在纸面上被确认。阶段 6构建与部署就绪php artisan optimize:clear php artisan config:cache php artisan route:cache php artisan view:cache这四条命令先清缓存、再按生产配置预热三类缓存配置、路由、视图目的有两个验证 warmup 在生产配置下能成功——任何一条命令报错都说明配置缓存化例如 config 文件中残留动态逻辑存在隐患模拟生产环境实际运行的状态。文档同时要求确认两点运行时前提队列 worker 与 scheduler 已配置目标环境中storage/与bootstrap/cache/可写。仓库中的 examples/laravel-api-CLAUDE.md 给出了一个真实项目的参照栈PHP 8.2、Laravel 11.x、PostgreSQL、Redis、Horizon其中要求「格式通过 Laravel PintPSR-12、迁移提交到 git、异步任务走队列」与本阶段验证的正是同一批工程约定。阶段 7队列与调度器检查php artisan schedule:list php artisan queue:failedschedule:list核对调度任务是否按预期注册queue:failed检查失败任务积压。若项目使用 Horizonphp artisan horizon:status若queue:monitor可用用它在不处理任何任务的前提下检查积压深度--max100表示积压达到 100 即视为异常php artisan queue:monitor default --max100主动验证仅限 staging除被动检查外文档还定义了一个主动探针向专用队列派发一个 no-op 任务并用单 worker 处理它端到端验证「派发 → 持久化 → 消费」链路真正可用php artisan tinker --executedispatch((new App\Jobs\QueueHealthcheck())-onQueue(healthcheck)) php artisan queue:work --once --queuehealthcheck使用前提与验证标准必须已配置非sync的队列连接sync队列直接同步执行无法验证真正的异步链路任务需要产生可观察的副作用日志条目、healthcheck 表记录或指标以便确认它确实被处理只允许在可以安全处理测试任务的非生产环境执行文档对此有明确的「staging only / non-production」限定。两个可直接复制的完整流水线最小流程日常 PR 前可执行的最小验证集12 步php -v composer --version php artisan --version composer validate vendor/bin/pint --test vendor/bin/phpstan analyse php artisan test composer audit php artisan migrate --pretend php artisan config:cache php artisan queue:failed注意它跳过了dump-autoload、覆盖率、optimize:clear等可选步骤但保留了「环境 → Composer → Lint/静态 → 测试 → 安全 → 迁移预演 → 配置缓存 → 队列」的关键闸门。CI 风格流水线面向 CI 的完整 13 步流水线composer validate composer dump-autoload -o vendor/bin/pint --test vendor/bin/phpstan analyse XDEBUG_MODEcoverage php artisan test --coverage composer audit php artisan migrate --pretend php artisan optimize:clear php artisan config:cache php artisan route:cache php artisan view:cache php artisan schedule:listCI 流水线额外包含dump-autoload -o保证类映射优化、带覆盖率的测试、完整的缓存 warmup 序列和schedule:list与阶段 6/7 的完整要求对齐。在 ECC 中的位置与配套技能从仓库结构看laravel-verification并非孤立技能而是 ECC 中 Laravel 技能族的一员skills/laravel-patterns/SKILL.md——Laravel 工程惯用法skills/laravel-tdd/SKILL.md——测试写法本技能阶段 3 的上游skills/laravel-security/SKILL.md——安全深审本技能阶段 4 的上游skills/laravel-verification/SKILL.md——本技能发布前的统一闸门。该技能通过安装清单分发manifests/install-modules.json 中列有skills/laravel-verification条目ECC 支持按需选择安装哪些技能模块多语言文档中另有 docs/zh-CN/skills/laravel-verification/SKILL.md、docs/ja-JP/skills/laravel-verification/SKILL.md 等版本可对照阅读。总结laravel-verification的核心价值不在于任何单条命令每条都是标准的 Composer/Artisan 命令而在于把发布前验证固化成一个有顺序、有闸门、有阻断语义的流程环境/Composer 失败即停Lint 不过不进测试测试不过不碰数据与安全构建与队列检查失败即阻断发布。将本文两个 bash 流水线片段纳入 CI 或作为 PR 检查清单就能获得一个可重复执行、可审计的 Laravel 发布前验证闭环。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC Laravel 验证循环：从环境检查到队列健康检查的七阶段发布前验证指南
ECC Laravel 验证循环从环境检查到队列健康检查的七阶段发布前验证指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文基于 ECC 仓库中的laravel-verification技能文档完整解析其七阶段7 phases验证循环的每个步骤、全部命令与取舍逻辑。读完本文你可以在打开 PR、依赖升级后或部署 staging/production 之前独立执行一套「环境 → Composer → Lint/静态分析 → 测试与覆盖 → 安全审计 → 迁移 → 构建/部署就绪 → 队列与调度器」的完整验证流水线并理解每一阶段为什么按此顺序排列。技能的定位与触发时机laravel-verification是 ECC 为 Laravel 项目定义的验证循环Verification Loop。技能文档的 frontmatter 声明了它的定位Bucle de verificación para proyectos Laravel: verificaciones de entorno, linting, análisis estático, pruebas con cobertura, escaneos de seguridad y preparación para despliegue. 面向 Laravel 项目的验证循环环境检查、Lint、静态分析、带覆盖率的测试、安全扫描与部署准备。来源见 docs/es/skills/laravel-verification/SKILL.md英文版原文为 skills/laravel-verification/SKILL.md。文档给出四个明确的适用场景为 Laravel 项目打开 Pull Request 之前完成重要重构或依赖升级之后staging 或生产环境的部署前验证需要跑完整的lint → test → security → deploy readiness流水线时。七阶段流水线的执行原则文档在「Cómo Funciona」How It Works一节定义了整条流水线的编排原则这是理解各阶段顺序的关键严格顺序执行从环境检查一路执行到部署就绪每一层建立在前一层之上环境与 Composer 检查是总闸门这两项是其余一切工作的前提一旦失败立即停止不要继续往下跑Lint/静态分析必须先干净只有格式与静态分析通过才执行完整测试与覆盖率安全与迁移审查放在测试之后先验证行为测试再审查数据层变更与依赖安全构建/部署就绪与队列/调度器检查是最后的闸门任何一项失败都直接阻断发布。这个顺序体现了一个核心思想先确认工具链可用再确认代码质量再确认行为正确最后确认数据与运行时基础设施可以承载发布——避免在错误的环境上浪费昂贵的测试与部署步骤。阶段 1环境检查Verificaciones de Entorno一切从确认运行时开始php -v composer --version php artisan --version同时需要人工核对三类环境状态.env文件存在且所有必需的键key都已定义生产环境中APP_DEBUGfalseAPP_ENV与目标部署环境一致production或staging。如果本地开发使用 Laravel Sail则通过 Sail 前缀执行同样的检查./vendor/bin/sail php -v ./vendor/bin/sail artisan --version这一步的价值在于后面所有阶段都依赖 PHP、Composer 和 Artisan 三个组件版本或.env缺失导致的失败往往具有迷惑性例如artisan能启动但数据库连接报错不如在第一阶段就直接暴露。阶段 1.5Composer 与 Autoloadcomposer validate composer dump-autoload -ocomposer validate校验composer.json的合法性是依赖层的第一道闸composer dump-autoload -o以优化模式-o类映射重新生成 autoload 文件保证类发现结果与实际代码一致。ECC 在文档中把它单独编号为 1.5强调它属于「环境类」检查而非「代码质量」检查autoload 不一致会导致后续阶段出现莫名其妙的Class not found与其在测试阶段排查不如在入口处排除。阶段 2Linting 与静态分析vendor/bin/pint --test vendor/bin/phpstan analysepint --test只做检查不自动修复——验证循环的目标是「发现问题」而不是「顺手改掉」避免验证过程污染工作区phpstan analyse执行静态类型分析。如果项目使用的是 Psalm 而不是 PHPStan则替换为vendor/bin/psalm这一阶段的原则是「先静态后动态」格式和类型问题在静态分析阶段发现成本最低。仓库中的 rules/php/testing.md 也呼应了同类约定例如 CI 中优先使用 pcov 或 Xdebug 保持覆盖率阈值、HTTP/Controller 测试聚焦传输层与校验而把业务规则下沉到服务层测试。阶段 3测试与覆盖率php artisan testCI 场景下带覆盖率运行XDEBUG_MODEcoverage php artisan test --coverage文档给出的最小 CI 三段式片段格式化 → 静态分析 → 测试vendor/bin/pint --test vendor/bin/phpstan analyse XDEBUG_MODEcoverage php artisan test --coverage注意XDEBUG_MODEcoverage环境变量Xdebug 默认是 debug 模式不显式切换到 coverage 模式时--coverage拿不到覆盖率数据。这一点与 rules/php/testing.md 中「Prefer pcov or Xdebug in CI, and keep coverage thresholds in CI rather than as tribal knowledge」的指引一致——覆盖率应作为 CI 的硬约束而不是口头约定。测试本身的写法PHPUnit/Pest、Factory、Sanctum 认证测试可参考同目录的 skills/laravel-tdd/SKILL.md。阶段 4安全与依赖审计composer auditcomposer audit对照已发布的安全公告检查vendor中依赖的已知漏洞。它被安排在测试之后、数据层操作之前意味着行为已被测试确认正确后再确认依赖本身没有被投毒或存在已知 CVE。更深层的 Laravel 安全审查认证与授权、Eloquent 安全、CSRF/XSS、生产环境配置由配套的 skills/laravel-security/SKILL.md 承担其中明确给出APP_DEBUG在生产环境绝不允许为true、APP_KEY必须在启动时校验、.env永不入库等规则——这些正是阶段 1 环境检查中人工核对项的展开。阶段 5数据库与迁移php artisan migrate --pretend php artisan migrate:statusmigrate --pretend只打印将要执行的 SQL 而不真正运行用于在触碰任何真实数据之前预演迁移migrate:status查看迁移的已应用/未应用状态。文档对迁移本身提出四条审查要求仔细审查破坏性迁移drop 列、drop 表、改类型等迁移文件名遵循Y_m_d_His_*格式例如2025_03_14_154210_create_orders_table.php且名称要清晰描述变更内容确保回滚可行逐个核对down()方法避免在没有显式备份的情况下发生不可逆的数据丢失。--pretend是这一阶段的精髓它让「审查 SQL」和「执行 SQL」分离破坏性变更在进入发布路径前就必须在纸面上被确认。阶段 6构建与部署就绪php artisan optimize:clear php artisan config:cache php artisan route:cache php artisan view:cache这四条命令先清缓存、再按生产配置预热三类缓存配置、路由、视图目的有两个验证 warmup 在生产配置下能成功——任何一条命令报错都说明配置缓存化例如 config 文件中残留动态逻辑存在隐患模拟生产环境实际运行的状态。文档同时要求确认两点运行时前提队列 worker 与 scheduler 已配置目标环境中storage/与bootstrap/cache/可写。仓库中的 examples/laravel-api-CLAUDE.md 给出了一个真实项目的参照栈PHP 8.2、Laravel 11.x、PostgreSQL、Redis、Horizon其中要求「格式通过 Laravel PintPSR-12、迁移提交到 git、异步任务走队列」与本阶段验证的正是同一批工程约定。阶段 7队列与调度器检查php artisan schedule:list php artisan queue:failedschedule:list核对调度任务是否按预期注册queue:failed检查失败任务积压。若项目使用 Horizonphp artisan horizon:status若queue:monitor可用用它在不处理任何任务的前提下检查积压深度--max100表示积压达到 100 即视为异常php artisan queue:monitor default --max100主动验证仅限 staging除被动检查外文档还定义了一个主动探针向专用队列派发一个 no-op 任务并用单 worker 处理它端到端验证「派发 → 持久化 → 消费」链路真正可用php artisan tinker --executedispatch((new App\Jobs\QueueHealthcheck())-onQueue(healthcheck)) php artisan queue:work --once --queuehealthcheck使用前提与验证标准必须已配置非sync的队列连接sync队列直接同步执行无法验证真正的异步链路任务需要产生可观察的副作用日志条目、healthcheck 表记录或指标以便确认它确实被处理只允许在可以安全处理测试任务的非生产环境执行文档对此有明确的「staging only / non-production」限定。两个可直接复制的完整流水线最小流程日常 PR 前可执行的最小验证集12 步php -v composer --version php artisan --version composer validate vendor/bin/pint --test vendor/bin/phpstan analyse php artisan test composer audit php artisan migrate --pretend php artisan config:cache php artisan queue:failed注意它跳过了dump-autoload、覆盖率、optimize:clear等可选步骤但保留了「环境 → Composer → Lint/静态 → 测试 → 安全 → 迁移预演 → 配置缓存 → 队列」的关键闸门。CI 风格流水线面向 CI 的完整 13 步流水线composer validate composer dump-autoload -o vendor/bin/pint --test vendor/bin/phpstan analyse XDEBUG_MODEcoverage php artisan test --coverage composer audit php artisan migrate --pretend php artisan optimize:clear php artisan config:cache php artisan route:cache php artisan view:cache php artisan schedule:listCI 流水线额外包含dump-autoload -o保证类映射优化、带覆盖率的测试、完整的缓存 warmup 序列和schedule:list与阶段 6/7 的完整要求对齐。在 ECC 中的位置与配套技能从仓库结构看laravel-verification并非孤立技能而是 ECC 中 Laravel 技能族的一员skills/laravel-patterns/SKILL.md——Laravel 工程惯用法skills/laravel-tdd/SKILL.md——测试写法本技能阶段 3 的上游skills/laravel-security/SKILL.md——安全深审本技能阶段 4 的上游skills/laravel-verification/SKILL.md——本技能发布前的统一闸门。该技能通过安装清单分发manifests/install-modules.json 中列有skills/laravel-verification条目ECC 支持按需选择安装哪些技能模块多语言文档中另有 docs/zh-CN/skills/laravel-verification/SKILL.md、docs/ja-JP/skills/laravel-verification/SKILL.md 等版本可对照阅读。总结laravel-verification的核心价值不在于任何单条命令每条都是标准的 Composer/Artisan 命令而在于把发布前验证固化成一个有顺序、有闸门、有阻断语义的流程环境/Composer 失败即停Lint 不过不进测试测试不过不碰数据与安全构建与队列检查失败即阻断发布。将本文两个 bash 流水线片段纳入 CI 或作为 PR 检查清单就能获得一个可重复执行、可审计的 Laravel 发布前验证闭环。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考