依赖注入对象来自容器并由反射自动实例化，参数绑定变量来自url路径或查询字符串并由路由层按名提取赋值；两者来源、机制与触发条件完全不同。
依赖注入和参数绑定的来源完全不同
依赖注入的对象来自容器，由 think\Container 通过反射自动实例化；参数绑定的变量来自 URL 路径或查询字符串，由路由层按名称提取后直接赋值。
常见错误现象：在 index($id, UserService $service) 中，$id 拿不到、$service 是 null——这说明你混淆了两者的触发条件：前者没匹配到路径变量或缺默认值，后者容器根本没识别出类或没走注入流程。
-
$id必须对应 URL 中的:id段（如/user/123），且方法签名里要写$id = 0，否则直接抛异常 -
UserService $service要求类文件存在、命名空间与路径严格一致、已执行php think optimize:autoload、并在app/provider.php中显式绑定 - 两者可共存，但顺序无关：你可以写
index(UserService $s, $id = 0, Request $r)，框架会分别处理对象注入和路径绑定
参数绑定只认名字，不认类型；依赖注入只认类型，不认名字
参数绑定是纯字符串匹配：Route::get('post/:id', 'Post/read') 要求方法必须有 $id 参数名，哪怕你改成 $postId 就报错；而依赖注入完全忽略变量名，只看类型提示——read(UserService $a) 和 read(UserService $whatever) 效果一样。
容易踩的坑：有人把 Request $request 当作参数绑定来用，结果发现 $request->param('id') 总是空——其实它压根不从 URL 取值，而是封装了整个请求上下文，和 $id 这种绑定变量不是一回事。
- 参数绑定变量不能带类型声明（PHP 8+ 支持联合类型除外），否则会破坏匹配逻辑
- 依赖注入变量必须带完整类型提示，且该类必须能被
class_exists()认出，否则注入失败为null - 如果同时需要
$id和Request，别试图用input('id')替代绑定——那是绕过机制，失去路由校验（比如没加pattern(['id' => '\d+'])就可能传入非法字符串）
依赖注入支持递归解析，参数绑定不支持任何嵌套
当你注入 UserService $service，而 UserService 构造函数又依赖 UserRepository $repo，容器会自动递归解析并实例化整个依赖树；参数绑定永远只做一层扁平映射，$id 就是整数，$name 就是字符串，不会尝试去“构造”它们。
性能影响明显：依赖注入首次调用会有反射开销，但后续走单例缓存；参数绑定每次请求都重新提取、转换、校验，尤其是用了 pattern() 正则时，路径越长匹配越慢。
- 依赖注入失败时通常静默为
null（除非开启严格模式），而参数绑定失败直接抛think\Exception导致 500 - 接口绑定（如
'UserRepository' => 'MySQLUserRepository'）只对依赖注入生效，对参数绑定无意义 - 不要在参数绑定变量上加类型声明试图“强制转换”，PHP 会报致命错误，例如
read(int $id)在 PHP 7.4 下无法运行
控制器里构造函数注入默认不生效，但参数绑定一定生效
ThinkPHP 默认用 new Index() 实例化控制器，绕过容器，所以 __construct(UserService $s) 完全不会触发；但所有操作方法（如 index()）的参数绑定，只要路由匹配成功就一定执行。
这是最常被忽略的差异点：你以为写了构造函数就能用依赖，结果 $this->service 始终为 null，调试半天才发现根本没进构造函数。
- 解决构造函数注入失效，必须在
app/provider.php的providers数组中加入控制器全类名，例如app\controller\Index::class - 更推荐改用操作方法注入（
public function index(UserService $s)），无需额外配置，且天然支持容器生命周期管理 - 参数绑定没有这种限制，
index($id)在任何控制器里都照常工作，哪怕你删了provider.php
500 错误可能卡在容器没加载，也可能卡在路由没配正则。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
