Yii中$request->get()和$request->post()不自动过滤，必须手动校验
直接用$request->get(‘id’)或$request->post(’email’)拿到的是原始用户输入，没做任何转义、类型转换或合法性检查。Yii的请求对象本身不内置“安全过滤”，所谓“安全方法”是误解——它只是更规范地封装了$_GET和$_POST，不是filter_input()的替代品。
常见错误现象：$request->get(‘id’)返回字符串"1′ OR ‘1’=’1"，后续拼SQL直接导致注入使用场景：所有从URL参数或表单提交取值的地方，尤其是用于查询条件、路由参数、JSON body解析前参数差异：get()默认返回null（当键不存在），post()同理；但两者都不处理空格截断、编码混淆、数组嵌套等边界情况性能影响几乎为零，但若在循环里反复调用get(‘x’)又不做缓存，会多一次数组查找
用$request->get() / post()配合Validator或filterInput才真正安全
Yii的安全实践不是靠请求方法本身，而是组合使用：先取值，再走验证层。最常用且推荐的方式是绑定到模型并调用validate()，而不是对每个参数单独过滤。
常见错误现象：写$id = (int)$request->get(‘id’);——看似转整型，但遇到"1abc"会变成1，仍是脏数据正确做法优先走模型验证：class SearchForm extends Model{ public $id; public function rules() { return [[‘id’, ‘integer’, ‘min’ => 1]]; }}$form = new SearchForm();$form->load($request->get(), ”);if ($form->validate()) { $id = $form->id; // 此时$id是干净的整数}轻量场景可用filter_var()：比如filter_var($request->get(’email’), FILTER_VALIDATE_EMAIL)，但注意它不处理null或空字符串，需额外判断兼容性提示：Yii 2.0 和 3.0 的Request类行为一致，但3.0更强调与PSR-7的兼容，get()可能返回NULL而非”，务必检查返回值类型
别忽略$contentType导致post()拿不到数据
当前端用fetch发application/json请求时，$request->post()永远为空——因为post()只读application/x-www-form-urlencoded和multipart/form-data的body，JSON得走$request->getBody()再解码。
常见错误现象：AJAX传{ "name": "foo" }，后端$request->post(‘name’)返回null，误以为参数丢失判断方式：$request->getContentType()返回application/json就别碰post()，改用Json::decode($request->getRawBody())（Yii2）或$request->getBody() + json_decode()（Yii3）容易踩的坑：混合使用——比如表单含文件上传（multipart）又带JSON字段，此时post()能取普通字段，但JSON字段仍需手动解析，不能指望框架自动合并
$_GET/$_POST被修改后$request->get()结果也会变
Yii的Request对象在初始化时会把$_GET和$_POST快照进私有属性，但如果你在中间件、行为或早期代码里直接改了全局$_GET，$request->get()后续调用就会反映这个改动——这不是bug，是设计使然。
常见错误现象：某处写了$_GET[‘id’] = trim($_GET[‘id’]);，后面控制器里$request->get(‘id’)拿到的是已trim过的值，但开发者以为自己还在操作原始输入建议做法：避免直接修改$_GET/$_POST；如需预处理，统一在Bootstrap或Application::beforeRequest里做，并明确记录副作用调试技巧：用var_dump($request->get())对比$_GET，能快速发现是否被意外篡改事情说清了就结束。真正的过滤动作永远发生在取值之后，而不是取值函数内部。
评论(0)