变量名应避免随意缩写，须用全称如$user_id、$is_active以保障自解释性、ide补全和跨团队协作效率，仅$i、$db等公认无歧义缩写可在限定场景使用。
缩写会让变量名失去自解释性
变量名的核心作用是“不看代码就知道它存什么”，而随便缩写直接破坏这个前提。比如 $usr 看不出是 user、username 还是 usertype；$cfg 可能指 config、configuration，甚至 customer group——不同团队、不同项目里含义可能完全不同。
常见错误现象：$dt 在日志模块里可能是 datetime，在数据表映射里却是 datatable；调试时翻三四个文件才能确认它到底代表啥，时间全耗在猜上。
使用场景中尤其危险的是跨模块协作或后期维护：你写的 $tmpArr 别人接手后不敢删，因为不确定它是不是临时缓存、中间计算结果，还是某个关键状态的快照。
PHP不支持类型声明时，缩写放大歧义
PHP 默认弱类型，变量含义几乎全靠名字承载。一旦缩写模糊，IDE 和静态分析工具（如 PHPStan、Psalm）就很难推断真实语义，导致：
-
$res可能是result、response、resource或reservation，类型提示失效 -
$val无法区分是value、validation还是variable，参数校验逻辑容易漏判 - 函数返回值命名如
getUsr()，调用方根本没法确定返回的是对象、数组还是字符串
下划线命名法 + 全称更安全也更省事
PHP 社区主流（包括 PSR-12、Laravel、Symfony）都倾向小写下划线风格，配合完整单词，既避免大小写混淆，又天然支持 IDE 自动补全和 grep 搜索。
实操建议：
- 用
$user_id而不是$uid—— “id” 是通用后缀，但 “uid” 在 Linux 系统里特指 user identifier，容易引发上下文冲突 - 用
$is_active而不是$act—— 布尔变量必须一眼可读，缩写会掩盖其真假语义 - 用
$payment_method而不是$pmt_mthd—— 后者在终端里搜索pmt会命中一堆无关变量，反而降低定位效率
性能上没差异，但可维护性差距巨大：一个缩写变量改名，往往要 grep 整个项目确认所有用法；而全称变量，搜一次就能准确定位。
缩写只在极少数场景可接受
不是所有缩写都该被消灭，但必须满足三个硬条件：公认、稳定、无歧义。
例如：
-
$i、$j、$k用于简单循环计数（仅限短作用域内） -
$db在整个项目里始终代表 database connection 实例，且有文档或类型注解支撑 -
$http_status中的http是协议标准缩写，不会和https、html混淆
但像 $cnt（count？container？content？）、$hdr（header？hard drive？handler？）这类，连你自己三个月后都可能记混——那就别写。
真正难的不是“能不能缩”，而是“别人第一次读到时，会不会停顿、犹豫、查源码”。只要出现哪怕一次犹豫，这个缩写就不合格。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
