默认情况下phpcs即使发现error也返回退出码0，导致ci误判通过；必须用--error-severity=1使error触发非零退出码，否则质量门禁失效。
phpcs 能直接用 Composer 驱动，但前提是命令路径、规则加载、退出码三处全对；否则 composer lint 看似跑通，实际在 CI 里完全失效。
为什么 composer lint 没报错却放过了所有问题
默认情况下 phpcs 即使发现 50 个 ERROR，也返回退出码 0 —— 这意味着 CI 流程会继续执行，质量门禁形同虚设。
必须显式控制退出逻辑：
-
--error-severity=1：只要出现任意ERROR（比如语法错误、缺少类型声明），就返回非零退出码 -
--warning-severity=8：只把严重WARNING（如未使用的变量、危险的eval）当失败条件，避免TODO注释之类干扰构建 - 别用
--report=full单独撑场面，它不改变退出码；真正起效的是--error-severity参数
phpcs 命令找不到？90% 是路径和调用方式错了
Composer 安装的 phpcs 只存在于 vendor/bin/phpcs，不会自动进系统 PATH。你在终端敲 phpcs 报错，不是没装，是没走对路。
正确做法：
- 在
composer.json的scripts里直接写"lint": "phpcs ..."—— Composer 会自动把vendor/bin加入子进程环境变量，不用手写路径 - 如果手动调试，Linux/macOS 用
./vendor/bin/phpcs（开头加./防止 shell 查找系统命令）；Windows 用vendor\bin\phpcs.bat - CI 脚本里禁止写
phpcs --standard=PSR12，必须用./vendor/bin/phpcs --standard=PSR12或@php vendor/bin/phpcs显式调用解释器
规则集不生效？--standard=PSR12 大小写和版本都得卡死
PSR12 不是默认启用的，不写就是空规则集；而且大小写敏感、版本依赖强。
常见踩坑点：
-
--standard=psr12（小写）→ 静默失败，不报错也不检查 - PHPCS v3.4.x 及更早版本不支持
PSR12，会报ERROR: the coding standard "PSR12" is not installed；必须升级：composer update squizlabs/php_codesniffer --with-dependencies - 项目有自定义规则文件（如
ruleset.xml），必须写全路径：--standard=./ruleset.xml，不能只写ruleset.xml - 想长期维护规则，别堆参数，建
phpcs.xml放根目录，内容含<rule ref="PSR12"></rule>，之后phpcs会自动加载
要不要加 phpcbf 自动修复？看场景再决定
phpcbf 和 phpcs 同包，但自动修复 ≠ 无风险。它能处理缩进、空格、括号位置，但改不了逻辑、注释语义、或类型推导偏差。
实操建议：
- 本地开发可配
"cs:fix": "phpcbf --standard=PSR12 src/ tests/"快速统一风格 - CI 中只运行
phpcs检查，禁用phpcbf—— 自动修改文件可能引入不可见副作用，比如误修模板字符串里的换行 - 若真要用
phpcbf在 CI 里“预修复”，必须加--dry-run --diff并捕获输出，人工确认后再提交，不能直接fix - 注意
phpcbf对 PHP 版本敏感：PHPCS v4.x 要求 PHP 7.4+，且内部命名空间已重构，混用旧版自定义 sniff 会报Class 'PHP_CodeSnifferFilesFile' not found
phpcs.xml 和 phpcs.xml.dist 同时存在时前者优先，但 CI 环境应固定用 .dist 版本并提交到仓库；另外 phpcbf 默认启用缓存，大项目二次运行快很多，但 CI 里建议加 --using-cache=no 避免缓存污染导致漏检。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
