PSR-12是PHP开发的运行前提而非可选风格，要求命名统一（如$userEmail、getUserById）、4空格缩进、花括号位置规范、namespace/use后空行、常量全大写下划线、禁用?>结束标签，并需通过phpcs等工具嵌入编辑与提交流程强制执行。
直接上手学PHP规范，别从“理论大全”开始——你真正卡住的地方，往往是if后面少了个空格、class花括号换行不对、或者require_once写在了function定义前面。这些细节不靠死记，得在改错中建立肌肉记忆。
PSR-12不是选择题，是运行前提
PHP-FIG发布的PSR-12不是“推荐风格”，而是Composer、PHPStan、PHP_CodeSniffer等工具默认校验的底线。不满足它，很多静态分析和CI流程会直接报错，不是警告。
-
phpcbf能自动修复80%的格式问题，但前提是你的代码已基本符合PSR-12结构（比如类花括号必须换行，方法花括号必须同行）；否则它会跳过或出错 - IDE里装PHP CS Fixer插件后，保存即格式化——但若你写的是
if($x){（无空格、无换行），它可能不触发，因为解析器先报语法错误 - 最常被忽略的一条：
namespace声明后、use块后，必须各有一个空行；缺一个，phpcs就标红
命名不是“怎么好看”，而是“怎么不歧义”
变量名$user_name和$userName都能跑通，但混用会让git blame和IDE跳转失效；更关键的是，不同命名习惯在类型推导时会断链。
- 函数名统一用小驼峰（
getUserById），别掺杂下划线（get_user_by_id）——PSR-12虽未强制，但现代PHP生态（如Laravel、Symfony）默认按此推导契约 - 私有属性/方法加下划线前缀（
$_cache、_initConnection）是历史惯性，但PHP 8.2+的只读属性（readonly）和属性提升已让这种标记变得冗余，建议直接用private修饰+清晰命名 - 常量必须全大写+下划线，哪怕只一个词：用
API_TIMEOUT，不用ApiTimeout——否则define()和const行为不一致，且IDE无法高亮识别
PHPDoc不是摆设，是类型系统延伸
没写@param和@return的函数，PHPStan默认当mixed处理；哪怕你用了PHP 8的联合类型声明，缺少PHPDoc仍会导致IDE无法补全返回值方法。
立即学习“PHP免费学习笔记（深入）”；
-
@param必须写具体类型，@param array $data不够，要写@param array{id: int, name: string} $data或用array<string, mixed> - 构造函数里注入依赖，必须标注
@param，否则PHP-DI等容器无法正确反射实例化 - 删掉
?>结束标签——不是为了“简洁”，是因为末尾换行或空格会被输出，导致header()调用失败，而这类错误不会报错，只会静默失效
别等“写完再规范”，把检查嵌入编辑和提交环节
手动对照PSR-12检查每行代码，效率极低；真正可持续的方式，是让工具在你敲错时立刻提醒。
- VS Code里配好
phpcs+phpcbf，设置“Format on Save”，保存即修正缩进、空格、括号位置 - Git commit前加
pre-commit钩子，跑phpcs --standard=PSR12 *.php，不通过就拒绝提交 - 最易踩的坑：在
index.php这种入口文件里写echo或header()前，先确认没加载任何含输出的配置文件（比如config.php末尾多了一个空行）——这种错误不会出现在IDE里，只在浏览器F12 Network里看到“headers already sent”
规范的价值不在“看起来整齐”，而在降低协作时的意外成本；一个use语句后少空行，可能让新人花半小时查不出为什么phpstan不报类型错误——因为整个文件被判定为格式非法，直接跳过分析。
