php 8.1 起，内部函数（如 strpos）的参数类型严格化，向其传入 null 将触发弃用警告。修复方法是显式校验变量是否为非空字符串，再调用 strpos。
php 8.1 起，内部函数（如 strpos）的参数类型严格化，向其传入 null 将触发弃用警告。修复方法是显式校验变量是否为非空字符串，再调用 strpos。
在 PHP 8.1 及更高版本中，strpos() 等内置函数的参数声明已更新为非空类型（non-nullable），例如 strpos(string $haystack, string $needle)。这意味着若向 $haystack 传入 null（如 $rule->getMethods() 返回 null），PHP 将抛出如下弃用警告：
Deprecated Functionality: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated
你遇到的错误正源于此：
$oldMethods = $rule->getMethods(); // 可能返回 null
if (strpos($oldMethods, "\n") === false) { // ❌ $oldMethods 为 null 时触发警告
continue;
}✅ 正确修复方式（推荐）
应先确保 $oldMethods 是字符串类型且非 null，再执行 strpos()：
$oldMethods = $rule->getMethods();
// 方案一：使用 is_string() + 显式判空（最清晰、安全）
if (!is_string($oldMethods) || strpos($oldMethods, "\n") === false) {
continue;
}? 说明：
!is_string($oldMethods)已涵盖null、false、0、[]等所有非字符串值，比=== null更健壮；且逻辑上「非字符串」或「不含换行符」任一成立即跳过，语义准确。立即学习“PHP免费学习笔记（深入）”；
⚠️ 注意：原答案中的逻辑错误需避免
原回答给出的写法：
if ($oldMethods !== null || strpos($oldMethods, "\n") === false) { ... }存在严重逻辑缺陷：
-
||（或）导致只要$oldMethods !== null为true，右侧strpos()就仍会被执行，无法规避警告； - 即使
$oldMethods是0、false或[]，该条件也因!== null为真而进入分支，随后strpos([], "\n")仍会报错。
✅ 正确逻辑应为 “仅当是字符串时才调用 strpos”，因此必须使用 && 或前置守卫（guard clause）：
// 方案二：守卫式提前返回（更易读）
$oldMethods = $rule->getMethods();
if (!is_string($oldMethods)) {
continue;
}
if (strpos($oldMethods, "\n") === false) {
continue;
}? 补充建议
-
统一类型契约：在 Magento 模型中，可考虑为
getMethods()添加类型声明或文档注解（PHPDoc），例如@return string|null，便于 IDE 提示和静态分析； -
空值默认处理：若业务允许，也可主动兜底为空字符串：
$oldMethods = $rule->getMethods() ?? ''; if (strpos($oldMethods, "\n") === false) { continue; }（注意：
?? ''会将false、0等 falsy 值也转为空字符串，需确认业务是否可接受）
✅ 总结
| 错误做法 | 正确做法 |
|---|---|
直接对可能为 null 的变量调用 strpos()
|
先用 is_string() 校验，再调用 |
使用 || 混合判空与 strpos 逻辑 |
使用 && 或拆分为独立守卫条件 |
依赖 === null 判定（忽略其他非法类型） |
使用 is_string() 全面覆盖非字符串场景 |
升级至 PHP 8.1+ 后，此类类型敏感问题频发。养成「调用字符串函数前必校验类型」的习惯，可显著提升代码健壮性与可维护性。
