PHP服务端编程中是否应直接拒绝非字符串类型请求参数？

这确实是PHP后端开发中很容易被忽略但又至关重要的问题，结合实际项目经验和业界共识，我的结论是：绝大多数业务场景下，默认拒绝非字符串类型的请求参数，仅对明确需要的数组参数开绿灯，是更安全、更可控的选择，具体原因和做法如下：

为什么要拒绝非预期的非字符串参数？ #

• 避免隐性逻辑漏洞：PHP的函数容错性确实“超乎想象”——比如你用strlen($_GET['username'])时，如果传入的是数组，函数不会报错，反而会返回1；直接echo数组参数会输出Array字符串，要是后续有SQL拼接、字符串比较这类操作，很容易引发不符合预期的逻辑错误，甚至安全问题。
• 缩小攻击面：允许任意数组参数传入，等于给攻击者多了一个测试入口。比如某些未做类型判断的参数绑定逻辑，可能会把数组参数解析成多个值，进而引发SQL注入；或者一些框架的变量覆盖漏洞，也可能通过数组参数触发。
• 简化代码维护：如果明确所有参数都是字符串，你不需要在每个参数使用的地方都加is_string()判断，也不用处理数组转字符串的各种边缘情况，代码逻辑会更简洁，后续维护成本更低。

例外场景：什么时候需要接收数组参数？ #

当然不是所有情况都要一刀切，以下场景确实需要数组类型的参数：

• 批量操作接口，比如批量删除的?ids[]=1&ids[]=2；
• 表单中的多选控件，比如复选框组的name="tags[]"；
• 需要传递结构化数据的场景（不过这种情况更推荐用JSON格式的字符串参数，而非自动解析的数组）。

这种情况下，你需要明确指定允许数组类型的参数列表，其他参数依然严格限制为字符串。

具体实现思路 #

可以在请求入口（比如自定义的请求处理类、框架中间件）统一做参数校验：

// 预先定义允许为数组的参数名
$allowedArrayParams = ['ids', 'tags'];

// 处理GET参数
foreach ($_GET as $paramName => $paramValue) {
    if (!in_array($paramName, $allowedArrayParams) && is_array($paramValue)) {
        http_response_code(400);
        exit('Invalid parameter type: ' . $paramName);
    }
}

// 同理处理POST参数
foreach ($_POST as $paramName => $paramValue) {
    if (!in_array($paramName, $allowedArrayParams) && is_array($paramValue)) {
        http_response_code(400);
        exit('Invalid parameter type: ' . $paramName);
    }
}

总结 #

默认拒绝非字符串参数，仅放开明确需要的数组参数，是业界普遍认可的PHP参数校验最佳实践——既能有效规避大部分隐性问题，又能让你的接口逻辑更清晰、更安全。

内容的提问来源于stack exchange，提问作者DannyNiu