直接运行 composer require --dev squizlabs/php_codesniffer 安装 PHP_CodeSniffer 为本地开发依赖，推荐使用 vendor/bin/phpcs 调用并配合 phpcs.xml 配置 PSR12 标准，避免全局安装与环境干扰。
怎么用 Composer 安装 PHP_CodeSniffer
直接运行 composer require --dev squizlabs/php_codesniffer 就行，不需要全局安装。本地项目依赖更安全，版本也容易锁定。
常见错误现象：phpcs 命令找不到 —— 因为没加 vendor/bin/ 到 PATH，或者用了全局安装但版本和项目不一致。
- 推荐始终用
vendor/bin/phpcs调用，避免环境干扰 -
--dev参数必须加，规范检查工具不该进生产环境 - 如果项目已锁定了旧版（比如 2.x），升级到 4.x 会报错：标准名变了（
PSR2→PSR12），别硬改配置，先看报错里的标准名提示
怎么让 phpcs 检查当前代码是否符合 PSR-12
PSR-12 是目前主流的 PHP 代码规范，但 phpcs 默认不启用任何标准，必须显式指定。
执行 vendor/bin/phpcs --standard=PSR12 src/ 即可检查 src/ 目录。注意大小写：是 PSR12，不是 psr12 或 PSR-12，输错就报 The specified coding standard "xxx" is not installed。
立即学习“PHP免费学习笔记（深入）”；
- 想省略每次敲
--standard=PSR12，就在项目根目录加phpcs.xml，内容至少包含<rule ref="PSR12"/> - 检查单个文件时，路径别漏掉扩展名，
phpcs test.php可以，phpcs test会静默跳过 - PHP 8+ 项目用 PHPCS 4.x 没问题；但若用了
match表达式，老版本 PHPCS（如 3.5.8 之前）会解析失败，直接报语法错误
怎么快速修复 phpcs 报出的问题
phpcbf（PHP Code Beautifier and Fixer）是配套工具，能自动修大部分格式问题，比如缩进、空格、花括号换行。
运行 vendor/bin/phpcbf --standard=PSR12 src/，它会边修边打印改了哪些文件。但别无脑全量跑 —— 有些规则它修不了（比如变量命名是否语义化），有些修了反而坏逻辑（比如把 if ($a && $b) 拆成多行后破坏短路逻辑的可读性）。
- 先用
phpcs看报告，重点关注ERROR级别项（通常是语法或结构硬伤），WARNING级别可酌情忽略 -
phpcbf不会删代码、不改逻辑，但它可能把你的手动对齐空格全干掉，导致 diff 飞起 - CI 流程里只跑
phpcs，别放phpcbf自动提交，那等于把代码风格决策权交给机器
为什么 vendor/bin/phpcs 在 Git Hook 里执行失败
Git Hook 脚本默认用系统 shell 启动，PATH 很干净，vendor/bin/phpcs 找不到 PHP 解释器，或找不到依赖 autoload，报错类似 Could not open input file: vendor/bin/phpcs 或 Class 'PHP_CodeSniffer\Runner' not found。
根本原因不是权限，而是 Hook 进程的工作目录和环境变量跟终端不一致。
- 在 Hook 脚本开头加
cd "$(git rev-parse --show-toplevel)"，确保在项目根目录执行 - 显式调用 PHP：
php vendor/bin/phpcs --standard=PSR12 --report=checkstyle ...，别依赖 shebang - 别用
composer exec phpcs—— 它依赖 composer 全局可用，而 Hook 里不一定有
phpcs.xml、.editorconfig、IDE 设置里，三者稍有不一致，团队成员就会互相“污染”代码风格。盯住一个入口（比如 phpcs.xml），其他地方全按它对齐。 
