PHP filter_input 读取查询参数时为什么拿不到修改后的 $_GET

如果请求地址是 ?page=7，脚本稍后把 $_GET['page'] 改成 42，再调用 filter_input(INPUT_GET, 'page', ...)，读到的仍可能是原来的 7。原因不是过滤器失效，而是两者看的数据源不同：filter_input() 读取 PHP 从 SAPI 保存的原始外部输入；已经被脚本改写的超全局，应交给 filter_var()。

先分开原始输入与当前 $_GET

filter_input 是直接从PHP初始化阶段拿到的原始请求输入缓冲区读取内容，完全不会去读取你后续在代码中对$_GET、$_POST这些超全局变量做的任何修改，所以改完$_GET之后再调用filter_input拿不到更新后的值是正常表现。

$_GET 是根据 URL 查询串填充的超全局数组，但它在脚本运行期间仍然可以被普通 PHP 代码修改。filter_input() 的设计目标是从对应的外部输入源取值，所以它不会把后来写回 $_GET 的内容当成新的请求输入。

用最小示例复现两条读取路径

下面的示例假定通过 ?page=7 访问。为了让差异可见，先读取原始值，再故意改写当前数组，最后分别调用两个函数。

这个例子只是在说明读取边界，不建议把外部参数直接覆盖成业务值。更稳妥的做法是保留原始输入，把清洗后的结果放进另一个变量，例如 $page = ...，这样排查时还能知道用户真正传了什么。

按需求选择 filter_input 或 filter_var

如果你的问题是“用户请求里到底传了什么”，使用 filter_input()；如果问题是“当前业务变量能否作为整数使用”，使用 filter_var()。不要先修改 $_GET，再期待 filter_input() 读取修改结果。

 ['min_range' => 1]]
);

if ($page === null) {
    // 查询参数不存在，使用业务约定的默认页码。
    $page = 1;
} elseif ($page === false) {
    // 参数存在但不是合法的正整数，返回参数错误或记录日志。
    http_response_code(400);
    exit('page 参数必须是正整数');
}

若中间层已经把页码存入 $candidatePage，就不要绕回 INPUT_GET：

 ['min_range' => 1]]
);

if ($page === false) {
    // 只拒绝当前变量，不把它误认为原始查询参数。
    throw new InvalidArgumentException('页码必须是正整数');
}

把缺失、非法和有效值分开处理

使用验证过滤器时，不能只写 if (!$page)。在不使用 FILTER_NULL_ON_FAILURE 的常见写法里，参数不存在返回 null，参数存在但校验失败返回 false，验证成功则返回转换后的值。有效整数 0 也不该被真假判断误伤，所以要用 ===。

还有一个容易忽略的点：FILTER_DEFAULT 等同于 FILTER_UNSAFE_RAW，默认并不会替你完成格式校验。需要判断整数、邮箱或 URL 时，应显式指定对应的 FILTER_VALIDATE_* 过滤器，并按返回值设计分支。

相关问题

修改 $_POST 后，filter_input(INPUT_POST, ...) 也会读旧值吗？

同样应按两条数据源理解：filter_input() 面向原始外部输入，当前变量则交给 filter_var()。不要把某一次 $_POST 的行为假设成会同步到输入存储。

需要一次校验多个查询参数怎么办？

可以使用 filter_input_array(INPUT_GET, $definition) 集中声明规则；如果数据已经在一个普通数组里，则对应使用 filter_var_array()。选择标准仍然是“原始外部输入”还是“当前数组”。

为什么分页参数建议单独保存？

把原始输入、验证结果和最终业务默认值分成不同变量，能够保留排错线索，也不会让控制器后续代码误以为修改后的 $_GET 代表用户原始请求。