yii中$request->get()和$request->post()不自动过滤，返回原始用户输入，必须手动校验或结合validator、filter_var等进行安全处理。
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，能快速发现是否被意外篡改
