new 运算符必须跟已定义类名，不支持直接跟变量或字符串字面量；动态创建需校验 class_exists 或用 ReflectionClass；构造函数参数须严格匹配；每次 new 都生成独立对象实例；枚举、Closure 等特殊类型不可 new；推荐用静态工厂封装复杂初始化逻辑。
new 运算符必须跟类名，不能跟变量或字符串（除非用反射）
PHP 中 new 后面直接跟的必须是已定义的类名，比如 new DateTime() 或 new User()。如果你试图写 new $className()，它在 PHP 7.4+ 会报 Fatal error: Uncaught Error: Class name must be a valid object or a string —— 实际上这句错误信息有点误导，真正原因是 PHP 默认不支持动态类名的直接 new（除非字符串是合法类名且已加载）。
常见错误现象：
-
$cls = 'DateTime'; new $cls();→ 在严格模式或某些 autoloader 下可能失败 -
new 'DateTime'();→ 语法错误，'DateTime'是字符串字面量，不是类名表达式
正确做法：
- 确保类已声明或能被自动加载（如通过 Composer 的 PSR-4）
- 动态创建时用
new $className()前，先class_exists($className)校验 - 更稳妥的动态方式是用
ReflectionClass：(new ReflectionClass($className))->newInstance()
构造函数参数传错类型或数量会直接报 Fatal Error
PHP 不会静默忽略多余参数，也不会自动转型（除非构造函数用了类型声明 + 默认值）。一旦参数不匹配，就中断执行，比如 new DateTime('invalid') 抛 Exception，而 new SplFixedArray('abc') 报 Fatal error: Uncaught TypeError。
立即学习“PHP免费学习笔记（深入）”；
使用场景中容易踩的坑：
- 调用
new PDO($dsn, $user, $pass)时漏掉第四个参数（$options 数组），PDO 可能连接成功但行为异常 - 自定义类构造函数含必填参数，却写成
new MyClass()→Fatal error: Uncaught ArgumentCountError - 传入
null给非空类型参数，如function __construct(string $name) { ... }→TypeError
建议：
- 查文档确认构造函数签名，尤其是第三方类库（如 GuzzleHttp\Client 构造参数是数组，不是单独的 base_uri）
- 开发阶段开启
declare(strict_types=1)，让类型错误更早暴露 - 必要时用 try/catch 包裹
new，特别是涉及外部输入构造类名或参数时
new 创建的是对象实例，不是副本，也不是引用别名
每次 new 都分配新内存、触发 __construct、生成独立对象。即使类里没属性，两个实例的 === 比较也返回 false。这点和 JavaScript 的 new 类似，但比 Python 的 __new__ 更“实在”——PHP 没有对象池或复用机制（除非你手动实现单例或对象池）。
性能与兼容性影响：
- 高频
new小对象（如 DTO、ValueObject）开销不大，但频繁 new 大对象（如解析后的 DOMDocument）会影响内存和 GC - PHP 8.1+ 引入枚举（
enum），枚举成员不能用new实例化，否则报Fatal error: Cannot instantiate enum - 内部类如
Closure不能用new Closure()，必须用匿名函数语法fn() => ...或function() { ... }
示例对比：
class A { public $x = 1; }
$obj1 = new A();
$obj2 = new A();
$obj1->x = 99;
var_dump($obj2->x); // 还是 1，互不影响
静态工厂方法比直接 new 更灵活，但别滥用
很多现代 PHP 库（Laravel、Symfony、Doctrine）倾向用静态方法替代裸 new，比如 Cache::pool()、Response::json()。这不是语法限制，而是为了封装逻辑：延迟加载、依赖注入、缓存复用、参数标准化。
为什么这样做：
- 避免构造函数参数膨胀（比如要传 5 个依赖，工厂可只暴露关键配置）
- 同一接口可返回不同子类实例（如
DriverFactory::create('redis')返回RedisDriver，'mysql'返回SqlDriver） - 便于测试替换（mock 工厂方法比 mock new 更容易）
但要注意：
- 工厂方法本身也要能被测试，别让它变成“上帝方法”堆砌一堆 new
- 如果只是简单包装
return new X(...$args)，没加逻辑，那不如直接 new —— 反而多一层调用 - 别把工厂塞进全局函数或静态类里搞出隐藏依赖，该 DI 的还得 DI
复杂点在于：工厂是否要管理生命周期？要不要支持上下文（如请求作用域）？这些已经超出 new 本身，但你一旦开始封装 new，很快就会碰到。
