重写 behaviors() 是为了在默认行为链中插入、替换或禁用特定过滤器，如禁用 CSRF、强制 JSON 格式、添加 JWT 校验；需基于 parent::behaviors() 增量调整，确保 contentNegotiator 在 authenticator 之前执行，并显式配置 only/except 规则。
直接说结论：重写 behaviors() 不是为了“覆盖”，而是为了在默认行为链里插入、替换或禁用特定过滤器——比如去掉 CSRF、强制 JSON、加 JWT 校验，这些都得靠它。
为什么默认 behaviors 不够用
Yii2 的 yii\rest\ActiveController 自带一套 behaviors()，包含 ContentNegotiator、VerbFilter、AuthMethod（如果启用了）等。但默认配置不满足生产需求：比如它不拒绝非 JSON 请求体、不统一错误结构、不校验 Token、还可能误触发 CSRF 验证（REST 场景下无 session，CSRF 无意义）。
- 常见错误现象：
400 Bad Request但没返回具体字段错误；POST 提交 form-data 却被拒绝；Authorization: Bearer xxx头传了但没生效 - 根本原因：没显式重写
behaviors()，导致默认行为未按 API 场景裁剪 - 关键点：
parent::behaviors()返回的是数组，你可以用键名覆盖（如'authenticator'），也可以用unset()去掉不需要的（如'csrf'）
怎么安全地重写 behaviors() 并保留必要功能
重写不是全盘重写，而是有选择地调整。下面是最小可行配置，适用于大多数 v1 REST 模块：
public function behaviors()
{
$behaviors = parent::behaviors();
// 1. 禁用 CSRF（REST 无 state，必须关）
unset($behaviors['csrf']);
// 2. 替换 ContentNegotiator，只支持 JSON，且强制响应格式
$behaviors['contentNegotiator'] = [
'class' => \yii\filters\ContentNegotiator::className(),
'formats' => [
'application/json' => \yii\web\Response::FORMAT_JSON,
],
'languages' => ['en'],
];
// 3. 插入 JWT 认证（假设你已配好 jwt 组件）
$behaviors['authenticator'] = [
'class' => \api\filters\JwtAuth::className(),
'except' => ['options'], // OPTIONS 预检请求不校验
];
return $behaviors;
}
-
'except' => ['options']是必须的，否则 CORS 预检失败 - 不要删掉
'verbFilter'，它是保障 HTTP 动词语义的关键（比如阻止 POST /users/123） - 如果用了自定义
ApiResponse类，确保ContentNegotiator的formats仍指向Response::FORMAT_JSON，否则 prepare() 可能不触发
容易踩的坑：authenticator 和 verbFilter 的顺序与冲突
Yii 过滤器执行顺序影响结果。如果你手动加了 HttpBearerAuth 或自定义认证类，但发现 401 没返回标准 JSON 错误，问题往往出在这里：
-
authenticator必须在contentNegotiator之后注册，否则认证失败时响应仍是 HTML（因为 contentNegotiator 没来得及接管） - 如果同时配置了
VerbFilter和authenticator，而某个 action 被except掉了认证，VerbFilter仍会检查动词合法性——这是对的，别误以为是 bug - 最隐蔽的坑：
authenticator默认'only' => ['index', 'view', 'create', ...]，如果你加了自定义 action（如actionSearch），它不会自动包含，需显式加到'only'数组里，否则该 action 完全不校验
真正难的不是写对 behaviors()，而是理解每个过滤器在请求生命周期里的介入时机和职责边界——比如 ContentNegotiator 在 beforeAction 就设好响应格式，而 authenticator 的 beforeAction 里抛异常，会绕过后续行为，但不会跳过 afterAction。这些细节不验证一次请求链，很容易漏掉。
