CI中直接运行composer run失败，因PHPCS和PHPStan需在composer.json的scripts中明确定义；须通过composer require --dev安装、配置autoload、统一PHP版本及扩展，并提交配置文件确保本地与CI一致。
CI里直接跑composer run会失败？检查命令是否定义在scripts里
PHPCS 和 PHPStan 不是 Composer 原生命令，必须显式声明为 script 才能用 composer run 调用。CI 报错 Script not found 说明你漏写了这一步。
- 在
composer.json的"scripts"段落里加两条：
"scripts": {
"phpcs": "phpcs --standard=PSR12 src/",
"phpstan": "phpstan analyse --level=8 src/"
}
- 确保
phpcs和phpstan已通过composer require --dev安装（不是全局安装）；CI 环境没有全局工具链，依赖必须进vendor/bin/ - 别写成
"phpcs": "./vendor/bin/phpcs ..."—— Composer 会自动从vendor/bin查找可执行文件，硬写路径反而在 Windows CI 上出问题
CI中phpstan analyse报Class not found？自动加载没生效
PHPStan 默认不加载 Composer 自动加载器，除非你明确告诉它。CI 里常见报错是找不到自己写的类，根源就在这。
- 加
--autoload参数（PHPStan ≥ 1.10）或改用--autoload-file=vendor/autoload.php - 更稳妥的做法：在项目根目录放
phpstan.neon，写明自动加载路径：
parameters:
autoload_files:
- %rootDir%/../vendor/autoload.php
- 如果用了自定义 PSR-4 映射（比如
"App\": "src/"），PHPStan 需要对应配置paths或scanDirectories，否则跳过 src/ 下的文件
PHPCS 规则和 PHPStan level 在 CI 中要不要严格？看分支策略
开发分支可以宽松，主干合并前必须卡死。CI 不是“运行一下就行”，而是“不合规则就不让过”。
-
composer run phpcs默认非零退出码 → CI 步骤失败，但默认不中断后续步骤；加--no-interaction --report=full并确保 CI runner 设置了set -e或等效机制 - PHPStan 的
--level别盲目拉到 9：level 8 已覆盖类型推导、泛型、接口实现；level 9 强制要求完整 stubs 和大量注解，CI 里容易因第三方包缺失 stub 导致误报 - 建议在
composer.json的 scripts 里拆成两个命令："phpstan-ci": "phpstan analyse --level=8 --no-progress"，去掉颜色和进度条，避免某些 CI 日志解析异常
为什么本地能过、CI 报错？环境差异比想象中多
最常被忽略的是 PHP 版本、扩展和时区。PHPCS 和 PHPStan 对 PHP 小版本敏感，尤其是 PHP 8.2+ 的只读类、枚举改进。
- CI 的 PHP 版本必须和本地开发一致（比如都用
8.2.12，不是笼统写8.2），否则 PHPStan 可能跳过新语法检查 - 确认
intl和mbstring扩展已启用 —— PHPCS 内部依赖它们做字符串处理，缺一个就静默失败或乱码 - CI 容器默认时区可能是 UTC，而某些 PHPStan 插件（如 date-time-checker）会因时区差异误判
new DateTime()调用，加date.timezone=UTC到 php.ini 或 CI 启动参数里
复杂点在于：PHPCS 和 PHPStan 的配置文件（phpcs.xml、phpstan.neon）必须随代码提交，不能靠 CI 脚本临时生成 —— 本地改了规则，CI 不同步就失去意义。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
