PHP变量名严格区分大小写，$name与$Name是不同变量；函数和类名不区分大小写但建议统一调用；超全局变量键名、JSON键名等均保持原始大小写；需通过业务层标准化而非动态变量规避问题。
PHP变量名确实区分大小写
PHP中所有变量名严格区分大小写，$name 和 $Name 是两个完全不同的变量。这点和函数名、类名不同——函数与类在PHP中不区分大小写（但强烈建议按声明时的大小写调用，否则易引发维护问题）。
常见错误现象：
在调试时发现变量突然“消失”或值为空，其实是拼错了大小写，比如定义了 $userData 却读取了 $userdata，后者是未定义的新变量，返回 null 或触发 Notice: Undefined variable。
- 变量作用域内必须保持大小写一致，包括在
foreach、extract()、compact()等函数中传入的键名 - 超全局变量如
$_GET、$_POST本身是大写，但其内部键名仍遵循用户提交的实际大小写（HTTP协议本身不规范键名大小写，所以$_GET['Id']和$_GET['id']可能指向不同值） - 从JSON解码得到的关联数组键名，大小写完全取决于原始JSON字符串，PHP不做转换
为什么PHP要让变量名区分大小写
这是语言设计层面的决定：变量属于“符号表”直接映射，PHP解析器在编译阶段就将 $foo 和 $Foo 视为不同符号。这种设计降低了运行时歧义，也和大多数C系语言（如Java、C++）保持一致逻辑。
性能影响几乎为零，但兼容性上要注意：
从PHP 5.4到8.x，该规则始终未变；任何试图绕过它的“自动转小写”做法（比如用 strtolower() 处理变量名字符串再 $$ 动态访问）都属反模式，极易出错且不可调试。
立即学习“PHP免费学习笔记（深入）”；
- 不要用
$$做大小写归一化，例如$key = strtolower($input); $$key = 'value';—— 这会让代码失去可读性，且无法被IDE识别和补全 - 配置文件或API参数若需忽略大小写，应在业务层统一处理（如用
array_change_key_case($_GET, CASE_LOWER)），而不是依赖变量名机制 - 静态分析工具（如PHPStan）能捕获大小写不一致的变量使用，建议启用
容易踩坑的几个典型场景
大小写问题最常在“边界地带”爆发：外部输入、模板渲染、动态属性访问。
- Twig/Blade等模板引擎里，传入的变量名大小写必须和PHP层完全一致，
{{ user_name }}接收的是$user_name，不是$userName - 使用
__get()魔术方法时，如果内部逻辑没做大小写归一，$obj->ID和$obj->id会走不同分支甚至报错 - 从XML或YAML加载配置后赋值给对象属性，若源数据键名大小写混乱，而代码硬编码了某个大小写形式，就会漏读字段
-
isset($arr['Status'])和isset($arr['status'])是两回事，尤其在处理第三方API响应时务必先看原始结构
怎么快速发现并避免这类问题
靠人眼盯代码效率低，得靠工具+习惯双保险。
- 开启PHP的
E_NOTICE错误报告级别，未定义变量会立刻报Notice: Undefined variable: xxx，这是最直接的提示 - 在IDE中启用“未使用变量”和“未声明变量”检查（PhpStorm默认开启，VS Code需装PHP Intelephense）
- 对关键外部输入做标准化：比如统一用
array_change_key_case($_POST, CASE_LOWER)再进入业务逻辑，后续全部用小写键访问 - 单元测试里故意传错大小写的键名，确认是否抛出预期异常或返回空值，避免“看起来正常但其实漏逻辑”
真正麻烦的不是规则本身，而是大小写不一致往往不报错、只静默失效——值丢了、条件跳过了、日志没打出来，排查时容易绕远路。盯住变量声明那一行，复制粘贴比手动敲更安全。
