容器解析失败主因是类型提示未匹配或绑定缺失，而非缺默认值；加=null仅掩盖问题，?type $param = null才真正允许跳过解析，接口必须显式绑定否则报unresolvable dependency。
容器解析失败不是因为“缺默认值”，而是类型提示没匹配上或绑定没到位——加默认值只是掩盖问题，甚至让错误更难定位。
构造函数参数带 = null 为什么还是报 Unresolvable dependency
PHP 的 = null 只是给参数设默认值，不等于“允许跳过解析”。容器仍会尝试解析该参数的类型提示；如果类型是接口（如 LoggerInterface）且未绑定，或具体类（如 CacheService）无法自动加载，照样抛异常。
- 写成
?CacheService $cache = null才真正表示“可为 null”，此时容器才会跳过解析 - 只写
CacheService $cache = null，PHP 要求必须传参，容器照常尝试解析，失败就报错 - 若真想绕过，应改用可空类型 + 默认值，而非依赖
= null的语义错觉
app()->make() 解析时忽略未绑定接口？
不会忽略。容器对每个带类型提示的参数都严格检查：具体类走自动加载 + 反射递归；接口必须已在 register() 中用 bind() 或 singleton() 显式绑定，否则直接中止并抛 Unresolvable dependency。
- 常见漏点：绑定写在
boot()里、config/app.php漏加自定义 provider、接口用了字符串别名（如'logger'）而非LoggerInterface::class - 测试是否生效：在
tinker里执行app(LoggerInterface::class)，看是否返回实例 - 别用
resolve()临时补救——它绕过绑定规则，会让生产环境依赖关系不可追踪
什么时候该用默认值，而不是修复绑定？
极少。默认值只适用于两类场景：参数本身是运行时可选（如 string $locale = 'en'），或你明确接受“无此服务则降级”（如日志器缺失时静默丢弃）。它不解决“容器找不到实现类”的根本问题。
- 接口未绑定 → 补绑定，不是加
= null - 类命名空间错误或文件路径不对 → 修正
use或运行composer dump-autoload - 需要多实现切换（如不同支付网关）→ 用上下文绑定
when()->needs()->give()，而非默认值硬编码
最常被忽略的是绑定时机和命名一致性：少一个 \、错一个字母、把 bind() 放进 boot()，容器都不会报语法错误，而是在第一次调用时甩出一句模糊的 Target class [xxx] does not exist —— 它不提醒你哪行代码错了，只告诉你“东西没了”。
