tp8中scope需严格匹配方法签名，参数类型、调用形式、组合顺序及全局作用域交互均影响sql行为，否则静默失效。
TP6 的 scope 写法在 TP8 下基本可用，但调用方式、参数传递和组合逻辑的隐性差异会导致条件静默失效或 SQL 行为异常——不是语法报错，而是查不到数据却找不到原因。
scope 方法签名必须严格匹配，否则参数被丢弃
TP8 对方法签名更敏感，PHP 8+ 的严格反射机制会让不匹配的参数直接被忽略，且不报致命错误，只发 Warning。常见错因：
-
scopeHot($query, $days)定义了第二个参数，但调用写成User::scope('hot')->select()→$days为null，条件不生效 -
scopeHot($query, $params = [])期望接收关联数组，但误写成User::scope(['hot' => 7])→ 实际传入的是索引数组[0 => 'hot']，$params['hot']取不到值 - 把
protected function scopeHot()写成public是必须的，TP8 不再容忍访问控制错误下的“降级执行”
scope 调用不能混用字符串和数组参数形式
TP8 明确区分两种传参路径，混用会跳过整个 scope：
- 单值传参：必须用
User::scope('hot', 30)->select()，对应scopeHot($query, $days = 7) - 多键传参：必须用
User::scope(['hot' => 30, 'published' => true])->select()，对应scopeHot($query, $params = [])，再从$params['hot']取值 - 禁止写法：
User::scope('hot', ['published' => true])或User::scope(['hot'], 30)—— TP8 解析器无法映射，直接跳过该 scope
scope 组合顺序影响 limit/order 等子句的实际生效位置
TP8 的查询构建器仍按调用顺序拼接，但对 limit、order 这类非 WHERE 子句更敏感，顺序错就等于逻辑错：
-
User::scope('hot')->scope('top')->select()：先加热度条件（可能返回 500 条），再limit(10)→ 结果是热度最高的前 10 条 -
User::scope('top')->scope('hot')->select()：先limit(10)（取最新 10 条），再筛热度 → 结果可能是最新 10 条里恰好满足热度的几条，数量不稳定 - 调试建议：用
User::scope('hot')->scope('top')->buildSql()直接看生成的 SQL，别依赖“应该没错”的直觉
全局作用域（globalScope）和 scope 同时存在时，AND 条件可能互相冲突
TP8 保持全局作用域优先包裹的规则，但 PHP 8+ 下类型推导更严格，容易放大隐性冲突：
- 若模型启用了软删除全局作用域（
delete_time IS NULL），又在scopeHot()里写了$query->where('delete_time', '', null)→ 最终 SQL 是WHERE delete_time IS NULL AND delete_time NULL，恒为 false - TP8 不会警告这种逻辑矛盾，只安静返回空结果集
- 排查方式：临时关闭全局作用域测试，如
User::withoutGlobalScope()->scope('hot')->select()，确认是否 scope 自身逻辑有问题
最易被忽略的是 scope 内部做时间运算时没校验类型，比如把字符串 '7' 直接传给 subDays()，TP8 的 Carbon 实例在 PHP 8.1+ 下会抛 InvalidArgumentException，但若被 try-catch 吞掉，就只剩空结果——务必在 scope 开头加 is_numeric($days) && $days > 0 判断。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
