行为扩展必须注册在app/tags.php中，因其本质是事件钩子响应逻辑，需框架启动时显式声明才能被事件调度器识别，控制器或中间件中定义无效。
行为扩展的注册位置必须在 app/tags.php，不能写在控制器或中间件里
ThinkPHP 的行为（Behavior）本质是事件钩子的响应逻辑，只有在框架启动时通过 tags.php 显式声明，才会被事件调度器识别。写在控制器里只是普通方法调用，不触发行为机制；放在中间件中则属于请求流程控制，和行为扩展的生命周期无关。
常见错误现象：App\Behavior\CheckAuthBehavior 类已定义，但 app_init 事件始终不执行该行为——大概率是漏配或错配了 tags.php。
-
tags.php必须返回关联数组，键为事件名（如'app_init'），值为行为类名数组 - 类名必须是完整命名空间，且类文件需符合自动加载规范（PSR-4）
- 若使用闭包定义行为，需确保闭包在
tags.php中直接返回，不能延迟加载
behavior 方法调用时机决定是否生效：只能在事件触发点内手动触发
行为不是“自动运行”的独立模块，它依赖事件系统驱动。比如你定义了 'app_begin' => [App\Behavior\LogRequestBehavior::class]，那只有当框架执行到 Hook::listen('app_begin') 时，LogRequestBehavior::run() 才会被调用。
使用场景：想在每次请求开始前记录 IP，就挂载到 'app_begin'；想统一处理模型写入前的数据过滤，应挂载到 'model_insert' 或 'model_update' 等模型事件。
立即学习“PHP免费学习笔记（深入）”；
- 自定义事件需先用
Hook::add()注册，再在业务中用Hook::listen()触发，行为才能响应 - 行为类的
run()方法接收参数由事件触发时传入，例如app_init不传参，而view_filter会传入$content - 多个行为按数组顺序执行，后一个行为可修改前一个行为的输出（如果事件支持返回值传递）
行为类必须实现 run 方法，且不能有构造参数依赖
框架通过反射实例化行为类，不传任何参数。如果你的 __construct() 要求传 $config 或 $container，就会抛出 ReflectionException: Class xxx does not have a constructor 或参数数量不匹配错误。
性能影响：每个行为类在对应事件触发时都会被新建一次实例。频繁触发的事件（如 'view_parse'）上挂重型行为，可能带来明显开销。
- 依赖注入应改用容器获取：
app('cache')或Container::getInstance()->get('log') - 若需复用状态，可用静态属性缓存，但要注意并发安全
- 方法名必须严格为
run，大小写敏感；返回值会被后续行为或事件监听器接收（视事件设计而定）
调试行为是否注册成功：用 Hook::getListeners() 查看当前事件绑定列表
光看 tags.php 写对了没用，得确认框架真把行为加进去了。最直接的方式是在某个可控入口（如路由闭包、命令行指令）里打印监听器：
dump(Hook::getListeners('app_init'));
输出为空数组？说明注册失败；输出包含你的类名但行为没执行？检查事件是否真的被触发（比如 app_init 只在应用初始化阶段运行一次，不在 HTTP 请求中重复触发）。
- 开发环境建议开启调试模式，框架会在日志中记录事件监听与触发过程
- 行为类中加
file_put_contents('/tmp/behavior.log', "hit\n", FILE_APPEND)是比dump更可靠的运行验证方式 - 注意 CLI 和 HTTP 请求走的是不同生命周期，
app_init在命令行下也会触发，但action_begin不会
