ThinkPHP 5.1+ 中 B 方法已被彻底移除，不可恢复；须改用中间件替代行为钩子，如登录日志用 LoginLog 中间件、模板注入用 View::share() 或 View::composer()，响应处理需注意执行时机与编码问题。
ThinkPHP 5.1+ 中 B 方法彻底不可用，别再试图“恢复”它
TP 5.1 起，B 方法（行为标签执行函数）已被完全移除，不是弃用警告，是源码里真没了。任何在 config.php 或模板中写 {:B('footer')}、或控制器里调 B('login_end') 的写法，运行直接报 Call to undefined function B()。这不是配置没开，是函数定义被删了。
迁移不是“换个别名”，而是改掉触发逻辑的底层模型——从“模板/控制器主动拉行为”，变成“请求生命周期中自动推中间件”。
用中间件替代 B 的典型场景：登录后记录日志、渲染前注入脚本、响应后写缓存
原来靠 B('login_end') 做登录成功后的钩子？现在得注册一个中间件，在 AppmiddlewareLoginLog 里判断是否已登录并写日志；原来用 {:B('header_js')} 在模板顶部插入 JS？现在应在响应返回前，用中间件往 Response 的 header 或 content 中注入，或更合理地——把 JS 注入逻辑下沉到视图层或使用 View::share() 配合模板变量。
- 登录后钩子 → 放在
app/middleware/LoginLog.php，handle()中检查session('user_id')是否新增且无历史记录 - 模板级行为（如公共 footer）→ 不再靠
B动态调，改用view_replace_str配置或View::composer()绑定到特定模板 - 响应拦截（如加 CORS、压缩 body）→ 必须用中间件，且注意执行顺序：放在
app/middleware.php的靠后位置，否则可能被后续中间件覆盖
app/middleware.php 里注册中间件时，别漏掉闭包写法和类路径的差异
TP 6 默认用数组定义中间件队列，但新手常把类名写成相对路径或漏命名空间。比如写 ['app\middleware\Auth'] 是对的，写 'Auth' 或 'middleware.Auth' 就会报 Class "Auth" not found。
立即学习“PHP免费学习笔记（深入）”；
另外，调试阶段想快速验证逻辑，可用闭包中间件临时替代：
return [
'app\middleware\CheckAuth',
function ($request, Closure $next) {
$response = $next($request);
// 模拟 B('after_response') 行为
$response->header('X-Processed', 'true');
return $response;
}
];
但上线前必须抽离为独立类——闭包无法被容器解析，也不能被 make() 管理依赖。
中间件中访问模板变量或修改视图输出，得绕过 Response 直接操作 View 实例
原来 B('page_title') 是为了动态改 $title 变量？中间件默认拿不到 View 实例，因为视图渲染发生在中间件链之后。强行在中间件里调 View::assign() 是无效的。
可行路径只有两条：
- 用
View::share('key', $value)在中间件中设全局共享变量（适合 footer 版权、站点名等静态内容） - 把逻辑上移到控制器基类的
initialize()，或用View::composer('index/index', function ($view) { ... })绑定到具体模板 - 若必须响应后修改 HTML 内容（如加统计脚本），需在中间件中读取
$response->getContent()，字符串替换后再$response->content(...)覆盖，但要注意 Content-Encoding 和字符编码，gzip 压缩后不能直接操作原始 content
最易忽略的一点：中间件执行时机早于视图渲染，所以所有“影响模板输出”的动作，本质都是事后补救，不如把结构提前设计好——B 的灵活恰恰掩盖了职责混乱的问题。
