PhpStorm 不支持原生超全局变量（如$_POST）的键名自动补全，因其类型为动态array；需通过@var注解声明数组形状（如array{username: string}）、stub文件全局注入类型，或使用框架约定接口（如Laravel request()）实现精准补全。
PhpStorm 本身不支持“全局变量”的无上下文自动补全，因为 PHP 的全局变量（$_GET、$_POST、$GLOBALS 等）在语言层面没有固定结构，IDE 无法静态推断其键名或值类型。所谓“全局变量补全”，实际是通过类型注解、运行时模拟或框架约定来实现的“伪全局”提示——关键不在开启开关，而在让 PhpStorm 相信这些变量有明确结构。
为什么 $_POST['xxx'] 不提示字段名？
PHP 原生超全局数组是 array 类型，IDE 只能提示 array 的通用方法（如 count()），无法知道你提交了哪些表单字段。即使开了 Autopopup code completion，也不会列出 'username' 或 'email' 这类键名。
- 直接写
$_POST['user后按Ctrl+Space，只会看到array相关函数，不会补全键名 - 框架如 Laravel 的
request()->input('')能补全，是因为插件注入了字段元数据，不是靠解析$_POST - 启用
Enable PHP type inference对原生超全局无效，它只作用于类、函数返回值、赋值语句等有明确类型锚点的地方
用 @var 注解给 $_POST “加类型”
最轻量、最可控的方式：在使用前显式声明结构。这不是“全局设置”，但效果等同于为当前作用域注入补全能力。
- 在处理请求的入口文件（如
index.php或控制器方法顶部）加注释：/** @var array{username: string, email: string, age?: int} $_POST */ - 之后输入
$_POST['再按Ctrl+Space，就能看到username、email等键名建议（PHPStan 风格数组形状语法） - 如果项目用 PHP 8.1+，可用
array{...}；若用旧版 PHP，改用array<string, mixed>+ 更多@var细化，但补全精度下降 - 注意：该注解必须放在变量首次被读取前的同一作用域内，不能写在函数外再期望函数内生效
配合 ide-helper 或自定义 stub 文件做项目级覆盖
当多个文件都要补全同一组全局结构（比如所有控制器都依赖统一的请求参数契约），硬写 @var 太重复。这时应把类型定义抽到一个 stub 文件中，并让 PhpStorm 全局加载。
立即学习“PHP免费学习笔记（深入）”；
- 新建
stubs/_globals.php，内容为：/** @var array{token: string, timestamp: int, signature: string} $_REQUEST */ - 在 PhpStorm 中：Settings → Languages & Frameworks → PHP → Include Paths → 点击
+添加该 stub 所在目录（如./stubs） - 确保该文件未被标记为 “Excluded”，右键 → Mark as → Not Excluded
- 重启索引（File → Reload project from Disk），之后所有文件里对
$_REQUEST的访问都会带这个结构提示 - stub 文件里不要写可执行代码，只放
@var、@property、class声明等纯类型信息
框架场景下别碰原生超全局，走约定接口
真实项目几乎不直接操作 $_POST。Laravel 的 request()->only(...)、Symfony 的 $request->request->get(...)、或自定义的 RequestContract，才是补全友好的路径。
- Laravel 用户：装
Laravel Plugin+ 运行php artisan ide-helper:generate，request()返回类型会被识别，字段补全自然出现 - Symfony 用户：启用
Symfony Support插件，配置好symfony/var-exporter，$request->query等属性会获得完整补全 - 自建框架：在服务容器绑定处加
@var，例如/** @var \App\Http\Request $request */ $request = app('request');，比补全$_POST更可靠、更易维护
真正难的不是让 PhpStorm 补全全局变量，而是决定“这个变量到底该长什么样”。数组形状注解、stub 文件、框架契约——它们本质都是把模糊的运行时行为，翻译成 IDE 能静态消费的类型契约。一旦契约松动（比如前端传参字段变更但没同步更新 stub），补全就变成误导。所以补全越“智能”，越要有人盯住它的源头是否还真实。
