PHP命名约定必须严格统一以保障可维护性：类名PascalCase且与文件名、命名空间路径完全一致；方法名camelCase、动词开头并加is/has/can前缀；变量名风格统一不混用；命名空间别名需短而明确。
PHP命名约定不是“选一个喜欢的风格就行”，而是直接影响代码能否被团队快速理解、IDE能否正确补全、静态分析工具能否有效介入。不统一的命名会让get_user()和getUserById()混在同一项目里，最终谁都不敢动。
类名必须用PascalCase，且严格对应文件路径
PSR-4自动加载机制依赖类名与文件路径的一致性。一旦写成usercontroller.php里放class UserController，Composer就找不到它；写成UserController.php但类名是usercontroller，也会报Class 'usercontroller' not found。
- 类名首字母必须大写，每个单词首字母都大写：
UserRepository✅，user_repository❌，userRepository❌（这是方法名风格） - 文件名必须和类名完全一致，包括大小写：
UserRepository.php，不能是userrepository.php或userRepository.php - 命名空间前缀需与目录结构严格对齐，比如
App\Models\User必须放在src/Models/User.php
方法名优先用camelCase，动词开头表达行为
方法是“能做什么”，不是“是什么”。看到calculateTotal()就知道它会返回一个数；而total()或gettotal()既模糊又违反大小写惯例。
- 一律小驼峰：
findActiveUsers()✅，FindActiveUsers()❌（那是类名），find_active_users()❌（那是函数风格，且PSR-12已明确不推荐） - 必须以动词开头：用
isValidEmail()，不用emailValid()；用renderTemplate()，不用templateRender() - 布尔型方法加
is/has/can前缀：isLocked()、hasPermission()、canDelete()，别写成locked()或deleteable()
变量和属性名用camelCase或snake_case，但别混用
PHP本身不限制变量命名风格，但混用会直接破坏可读性。比如在同一个类里同时出现$userName和$user_name，IDE无法可靠推导类型，PHPStan也会报Property $user_name has no type这类误报。
立即学习“PHP免费学习笔记（深入）”；
- 类属性推荐
camelCase：$isActive、$createdAt；如果项目历史遗留大量snake_case（如Laravel Eloquent模型），那就全程保持$created_at，但别一半一半 - 局部变量风格应与所属上下文一致：在
UserController里就用$userId，不要突然切到$user_id - 避免下划线开头的私有属性（如
$_cache），现代PHP用private修饰符就够了，$_前缀既无实际保护作用，又干扰静态分析
命名空间别名要短且无歧义，禁止用单字母
use App\Services\Payment\Stripe as S;看着省事，但三个月后没人记得S代表什么。更糟的是，当另一个文件也用S指代SlackClient，合并冲突时根本没法安全 resolve。
- 别名长度控制在2–4个字母，且能体现领域：
use App\Services\Payment\Stripe as StripePay;✅，use App\Services\Payment\Stripe as SP;❌ - 同名类冲突时，别名必须带上下文：
use App\Models\User as AppUser;+use Laravel\Passport\User as PassportUser;，而不是UserA/UserB - 别名只在当前文件生效，不要指望它能“全局缩短命名空间”——那属于设计问题，该重构模块，不该靠别名掩盖
最常被忽略的其实是“一致性”的成本：改一个get_user_data()为getUserData()看似简单，但要同步更新所有调用处、测试用例、文档注释，还要确认CI里没漏掉某个角落的snake_case残留。真要换风格，得用PHP-CS-Fixer批量处理，并配上严格的pre-commit hook卡住。否则，半新不旧的命名比全旧还难维护。
