PHP可空类型加?是为显式声明null为合法值且受类型系统约束，而非简单支持null；它使null成为类型签名中可读、可校验、可预测的一等公民。
PHP 可空类型加问号（?）不是为了“支持 null”，而是为了**显式声明 null 是合法值且受类型系统约束的一部分**——它把原本隐式的、容易引发 TypeError 的 null，变成类型签名里可读、可校验、可预测的一等公民。
为什么不能直接传 null 而不加 ?
PHP 在启用 declare(strict_types=1) 时，类型检查是硬性的。比如：
function getName(int $id): string {
return $id === 1 ? 'Alice' : null; // ❌ TypeError: Return value must be of type string
}
即使逻辑上想返回 null，只要签名没写 ?string，运行时就炸。不加 ? 意味着类型系统认定 null 是非法输入/输出，跟类型不匹配一样严重。
-
string表示“必须是字符串，绝不能是null” -
?string表示“只能是字符串或null，其他值（如0、false、''）仍会报错” - 它不是松绑，而是收紧：把
null从“意外闯入者”变成“持证入场者”
?array 和 array|null 有区别吗
语义和运行时行为完全等价，但写法意图不同：
立即学习“PHP免费学习笔记（深入）”；
-
?array是 PHP 7.1+ 官方推荐的简洁语法，强调“这个数组类型本身允许为空” -
array|null是 PHP 8.0+ 联合类型（union types）的通用写法，更灵活（比如int|string|null），但对单类型可空场景略冗长 - 两者在
declare(strict_types=1)下表现一致；但用?array更直白，IDE 和静态分析工具也更倾向识别它为“可空数组”而非泛化联合类型
不加 ? 却默认接受 null 的常见坑
很多老代码靠“不声明类型”或用 mixed 来回避问题，结果埋下隐患：
- 函数参数写
function process(array $items)，调用方传了null→ 直接Warning: Invalid argument supplied for foreach() - 返回值没标
?User，ORM 查不到用户时返回null→ 调用方访问$user->getName()报Fatal error: Call to a member function - 属性声明为
private User $logger;，构造时没传值又没设默认 →Typed property must not be accessed before initialization
这些都不是“PHP 不支持 null”，而是类型契约没说清楚，导致错误发生在运行时而非定义时。
什么时候必须加 ?，什么时候反而不该加
关键看业务语义是否天然允许“缺失”：
- ✅ 必须加：
findUser(int $id): ?User（用户可能不存在）、getAvatarUrl(?string $avatarPath): ?string（头像路径可能为空） - ✅ 必须加：
__construct(?LoggerInterface $logger = null)（依赖可选） - ❌ 不该加：
strlen(string $str): int（字符串长度不可能是null，加?string反而误导调用方以为可以传null） - ❌ 不该加：
array_keys(array $array): array（返回值永远是数组，永远不为null）
最易被忽略的是：加了 ? 后，你得在函数体内主动处理 null 分支——否则只是把错误从类型层推迟到逻辑层。比如 ?array $items 进来，不判空就直接 foreach，照样崩。
