request::bind() 是为当前 request 实例动态添加可读写属性，不涉及服务容器绑定，仅限本次请求生命周期生效，且不会被 param()/input() 等方法读取。
Request::bind 是给当前请求对象动态挂属性，不是绑定服务容器
很多人看到 bind 就下意识想到服务容器的 bind() 方法，但 Request::bind() 完全是另一回事：它只是往当前 Request 实例上临时加一个可读写的属性，类似给对象塞了个字段，后续可通过 $request->key 或 $request->key() 访问。
这个操作不改变全局状态，也不影响其他请求，只对本次请求生命周期内的这个 Request 对象生效。
- 常见错误现象：
$this->request->bind('user_id', 123)写了，但在控制器其他方法里读不到$this->request->user_id—— 因为没在同一个Request实例上调用，比如中间件和控制器拿到的不是同一个对象（实际是同一个，但新手常误判） - 使用场景：在中间件或前置钩子中预处理用户身份、租户信息、灰度标识等，然后透传到后续逻辑，避免重复查库或解析
- 注意参数顺序：
Request::bind($name, $value)，第一个是字符串键名，第二个是值；不能反过来，也不能传数组当键名
和 request()->param()、input() 的本质区别在哪
Request::bind() 挂的值不会进入参数池，param()、input()、get()、post() 都查不到它。它纯粹是“手工附加字段”，和 HTTP 请求本身无关。
- 如果你写了
$request->bind('from_cache', true)，再调$request->param('from_cache')会返回null - 但
$request->from_cache或$request->from_cache()就能取到true - 这个设计其实很轻量，没有验证、过滤、默认值机制——它就是赋值+可读，仅此而已
为什么不能用 bind() 替代依赖注入或配置传递
因为 Request::bind() 是运行时行为，不可追溯、不可测试、不可拦截。它绕过了框架的数据流规范，容易造成隐式依赖。
- 调试困难：你在中间件绑了一个
'auth_user'，但控制器里直接用了$this->request->auth_user，IDE 不提示、PHPStan 不校验、单元测试难 mock - 性能无影响，但可维护性下降：多人协作时，没人知道这个字段从哪来、谁设的、什么时候被覆盖
- 替代方案更推荐：用
think\Request的扩展机制（继承重写）、或通过服务容器注入上下文对象、或在中间件里用$request->withAttribute()（TP8 支持 PSR-7 兼容方式）
TP6 和 TP8 中 Request::bind 的行为是否一致
基本一致，但 TP8 更强调“只读建议”：虽然仍允许写，但文档和核心代码里已倾向把 Request 当作不可变对象看待。你依然能调 bind()，但后续若调用 withXxx() 方法（如 withQuery()），新生成的 Request 实例不会携带之前 bind() 的字段。
- TP6：多次
bind()同名键会覆盖，且所有后续调用共享该值 - TP8：如果中间件用了
$request->withQuery(...)，控制器收到的就不是原对象，之前bind()的内容就丢了 - 所以跨版本迁移时，别依赖
bind()做关键上下文传递，尤其涉及路由分发、权限判断等环节
bind() 是个快捷但危险的捷径；多数时候，你应该回到容器注入或中间件 attribute 机制——它们不炫技，但不会在某次升级后突然失效。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
