PHP filter_input 为什么读取不到代码中后改的值

如果你先执行 $_GET['page'] = '2';，再调用 filter_input(INPUT_GET, 'page')，结果仍可能不是 2。原因不是过滤器失效，而是两者读取的对象不同：filter_input() 面向请求进入 PHP 时由 SAPI 提供的原始输入，代码后来改写的 $_GET 只是当前脚本里的可变数组。

PHP filter_input 读取的是原始请求快照

把一次请求想成两条路径更容易排查。PHP 收到 HTTP 参数后，SAPI 先形成原始输入快照；随后 PHP 暴露出 $_GET 或 $_POST，脚本可以继续修改它们。filter_input 走的是前一条路径，所以它适合读取“用户原本提交了什么”，不适合读取“业务代码刚刚整理后的当前变量”。

上面的注释强调的是读取边界，不应把注释里的结果当成所有运行环境的固定输出：脚本必须真的通过 GET 请求传入 page，过滤器也会影响返回值。官方手册明确提醒，正在过滤的超全局内容是 SAPI 提供的原始内容，早于用户修改；因此先改数组、再期待 filter_input 读取新值，本身就是错误的假设。

官方地址：https://www.php.net/manual/en/function.filter-input.php

改写后的超全局变量改用 filter_var

如果业务已经把输入转换成默认值、拼接了字段，或者在测试中直接改写了 $_GET，正确做法是先取出当前值，再交给 filter_var。这样过滤对象就是当前变量，而不是请求快照。

 [
            'min_range' => 1,
            'max_range' => 100,
        ],
    ]
);

if ($page === false) {
    // 过滤失败时走明确的错误分支，不把 false 当成页码 0。
    throw new InvalidArgumentException('page 必须是 1 到 100 的整数');
}
echo $page;

这里使用严格的 === false 判断，是为了避免把合法的边界值和失败值混在一起。输入过滤本身也不等于业务授权：页码范围可以由过滤器检查，但用户是否能访问某个资源仍要由业务权限逻辑决定。

区分缺失、过滤失败和数组参数

filter_input 的返回值不是只有“有值”和“没值”两种。普通情况下，变量未设置时返回 null，过滤失败时返回 false，过滤成功才返回过滤后的值。若请求参数可能是数组，应明确声明数组形态，否则把数组当标量处理会让结果判断失真。

用最小检查清单定位读取不一致

遇到“明明改成了新值，filter_input 却读不到”的问题，可以按下面顺序检查：

1. 确认参数确实来自 INPUT_GET、INPUT_POST 或其他匹配的输入源。
2. 确认代码是在读取前修改了超全局数组；如果是，改用 filter_var。
3. 确认过滤器是验证还是清理，默认的 FILTER_DEFAULT 并不等于严格验证。
4. 对返回值使用严格比较，单独处理 null、false 和数组。
5. 把原始输入读取和业务归一化分成两个变量，减少后续误读。

常见问题

filter_input 会自动过滤危险字符串吗？

不会。默认的 FILTER_DEFAULT 是 FILTER_UNSAFE_RAW 的别名，默认不做实际过滤。应按字段选择验证器，并在输出到 HTML、SQL 或命令等不同边界时使用对应的安全处理。

把 $_GET 改成默认值后，怎么继续复用过滤逻辑？

把默认值放进普通变量，再调用 filter_var。不要通过修改 $_GET 来“伪造请求”，否则阅读代码的人会误以为后续 filter_input 能读到这个值。

为什么调试时要同时打印两个变量？

因为 $_GET 代表脚本当前看到的数组，而 filter_input 代表原始输入路径。两者同时记录，才能快速判断问题来自请求、修改时机还是过滤器结果。