php代码规范的核心在于可读性与可维护性：命名直说意图、函数单一职责、错误处理明确、逻辑边界清晰，而非仅遵循psr-12格式。
PHP 代码是否“规范”，不取决于有没有用上 PSR-12 或是不是缩进四格，而在于别人（包括三个月后的你自己）能不能不查文档、不翻上下文就看懂 $user->save() 这一行到底干了什么、有没有副作用、失败了会抛什么异常。
命名要直说意图，别玩缩写和拼音
变量、方法、类名不是密码游戏。看到 $usr 得猜是 user 还是 usd rate；getUsrInfo() 比 getUserData() 更模糊——data 是数组？对象？还是 raw JSON 字符串？
-
$user比$u或$usr好，哪怕多敲两个字母 -
calculateTotalPriceWithTax()比calc()强，哪怕它只在三行内调用一次 - 布尔型变量/方法名必须带 is / has / can：比如
isEmailVerified、canDeletePost()，而不是email_verified或deleteable - 避免拼音：
$yonghu在团队协作或 IDE 自动补全里等于自废武功
函数体别超 20 行，且只做一件事
一个叫 processOrder() 的方法，如果里面混着校验库存、扣减余额、发短信、写日志、触发 webhook，那它已经不是函数，是“流程脚本”。下次改发短信渠道，你得通读全部逻辑防误伤。
- 把校验拆成
validateStock()，把通知拆成notifyUserBySms()，把日志单独抽成logOrderProcessed() - 每个函数只返回一种类型：要么总是
bool，要么总是array|false，别用return $result ?: null让调用方反复isset()判断 - 参数超过 3 个时，优先用值对象（Value Object）或关联数组（但得配好类型注释），别硬塞
function createInvoice($id, $type, $date, $currency, $taxRate, $notes)
错误处理别吞异常，也别裸 throw
try { ... } catch (Exception $e) { } 是最危险的静默陷阱；而 throw new Exception('Failed') 又让下游完全无法区分是网络超时还是数据库唯一键冲突。
立即学习“PHP免费学习笔记（深入）”；
- 捕获具体异常类：
catch (PDOException $e)、catch (HttpClientException $e)，别一锅端 - 重抛时保留原始异常链：
throw new OrderProcessingException('Payment failed', 0, $e) - 业务逻辑里少用
die()或exit()，它们绕过所有 shutdown handler 和中间件，线上查问题时等于关掉所有探针 - 对可预期失败（如用户邮箱已存在），用返回值或特定异常（如
UserAlreadyExistsException），而不是靠if ($result === false)魔数判断
PSR-12 不是终点，是起点
格式化工具（如 PHP-CS-Fixer）能帮你统一缩进、空格、花括号位置，但它不检查 new DateTime('now') 是否该换成 new DateTimeImmutable('now')，也不提醒你 foreach ($items as $item) 里直接修改 $item 并不会更新原数组。
- 先跑
php-cs-fixer fix --rules=@PSR12，再人工过一遍逻辑边界 - 在 CI 中强制检查：提交前没过
phpstan analyse或psalm --no-cache就不让合并 - 注释别写“初始化变量”，而写“此处跳过缓存因需实时汇率”——后者才是未来救你的那行字
真正难的从来不是“怎么写对”，而是“怎么让下一个人不用停下来想你在想什么”。变量名、函数职责、错误路径，这三处写清楚了，PSR 就只是顺手的事。
