Yii2中ActiveController的index方法默认不支持搜索过滤，需手动重写actionIndex并接入SearchModel；SearchModel::search()须用andFilterWhere、显式joinWith、避免SQL注入。
Yii2中ActiveController的index方法默认不支持搜索过滤
直接继承 ActiveController 并调用 index，它只做基础分页和字段投影，filter 参数会被忽略——这不是bug，是设计如此。Yii2的RESTful控制器默认把过滤逻辑交给客户端或自定义行为，不是开箱即用的。
常见错误现象：GET /api/users?name=foo 返回全部用户，name 参数完全没生效；调试发现 $this->searchModel 根本没被创建或没被应用。
- 必须显式覆盖
index方法，或挂载DataFilter行为（但后者需额外配置） - 不能依赖
ActiveController::actions()里默认的index配置 - 如果用了
yii\rest\IndexAction类，它本身不解析查询参数做模型过滤，只处理sort和page
重写index方法时如何安全接入SearchModel
最直接、可控的方式是复制 IndexAction 的逻辑，但在控制器里手动构建 ActiveDataProvider，并注入 SearchModel 实例。关键不是“怎么写”，而是“谁来负责验证和转换参数”。
使用场景：需要按字符串模糊匹配、范围查询（如 created_at 大于某时间）、关联字段筛选（如 user.profile.status）。
- 在控制器里 new 一个
SearchModel（比如UserSearch），别用new static—— 它可能不是 ActiveRecord 子类 - 调用
$searchModel->load(\Yii::$app->request->get(), '')，第二个参数传空字符串，否则默认前缀会导致参数名对不上 - 务必检查
$searchModel->validate()，失败时应返回 400 和具体错误，而不是静默忽略 -
ActiveDataProvider的query必须是$searchModel->search()返回的 Query 对象，不能直接用User::find()
public function actionIndex()
{
$searchModel = new UserSearch();
$params = \Yii::$app->request->get();
if (!$searchModel->load($params, '')) {
throw new BadRequestHttpException('Invalid search parameters');
}
$dataProvider = $searchModel->search($params);
return $dataProvider;
}
SearchModel::search() 方法里容易漏掉的三件事
很多同学写了 search() 却发现关联字段查不到、排序失效、或者 SQL 报错，问题常出在 Query 构建阶段，而不是控制器。
性能影响明显：没加 asArray() 或没选必要字段，会拖慢接口；没用 andFilterWhere() 而用 andWhere()，会导致空值参数生成 WHERE name = NULL 这种永远不成立的条件。
- 关联查询必须显式
joinWith('profile')，不能只在andFilterWhere(['profile.status' => $this->status])里提字段名 - 字符串搜索要用
andFilterWhere(['like', 'name', $this->name])，不是['like', 'name', "%{$this->name}%"]—— 后者有 SQL 注入风险且不兼容 Oracle - 日期范围要拆成两个
andFilterWhere，例如['>=', 'created_at', $this->start_date]和['end_date]，别塞进一个数组
为什么不要在ActiveController里直接改$searchModel的属性
有人图省事，在控制器里写 $searchModel->name = \Yii::$app->request->get('name')，绕过 load()。这看似简单，实则埋雷。
兼容性影响大：一旦 SearchModel 加了规则（比如 required、safe）、事件（beforeValidate）或属性类型转换（integer 字段自动 cast），手动赋值就失效或出错。
-
load()触发验证规则和属性过滤，safe属性才允许被批量赋值 - 前端传
name=（空字符串）或name=null，load()+validate()能统一处理；手动赋值后直接进 query，可能生成WHERE name = ''或更糟 - 如果
SearchModel继承自Model而非ActiveRecord，它根本没有attributes()元数据，手动赋值等于裸写魔法字符串
复杂点在于：搜索逻辑天然耦合验证、查询构建、权限控制（比如用户只能搜自己部门的数据）。这些没法靠一个“扩展 index 操作”的小技巧兜住，得在 SearchModel 里提前想清楚数据边界和字段白名单。
