ReflectionClass::newInstance() 不解析类型提示，仅顺序传参，遇类型声明构造函数直接报错；需用 newInstanceArgs() 配合 getConstructor()->getParameters() 递归解析依赖。
为什么 ReflectionClass::newInstance() 不能直接调用带类型提示的构造函数
因为 ReflectionClass::newInstance() 不解析参数类型，只按顺序传参；它会忽略类型声明、不触发依赖注入，遇到 __construct(UserService $service) 这类签名时直接报错 ArgumentCountError。
真正能自动解构依赖的是 newInstanceArgs() 配合 getConstructor()->getParameters() 手动补全参数——这也是 Laravel、Symfony 容器的起点。
- 必须先用
getConstructor()检查是否存在构造函数（可能为null） - 对每个
ReflectionParameter调用getClass()获取类型提示，再递归解析该类 - 若参数有默认值（
hasDefaultValue()），且无类型提示，可跳过实例化 - 原始类型（
int、string）需靠配置或约定提供，反射本身不解决这个问题
如何用 ReflectionMethod 正确调用私有方法而不触发 Fatal Error
直接 $method->invoke($obj) 会失败，错误信息是 Call to private method。关键在调用前加一步：$method->setAccessible(true)。
注意：这个操作仅影响当前 ReflectionMethod 实例，不影响原方法访问控制，也不改变类定义——它只是临时绕过 Zend 引擎的可见性检查。
立即学习“PHP免费学习笔记（深入）”；
-
setAccessible(true)在 PHP 7.4+ 是必需的，早期版本（如 5.6）不需要但不推荐省略 - 调用后无需恢复
setAccessible(false)，对象销毁即失效 - 若方法是静态的，
invoke()第一个参数传null即可，不用实例 - 批量调用时建议缓存
ReflectionMethod实例，避免重复反射开销
ReflectionProperty 读写私有属性时的常见陷阱
ReflectionProperty::getValue() 和 setValue() 必须配合 setAccessible(true)，否则抛出 ReflectionException：“Cannot access private property”。但这不是唯一坑点。
更隐蔽的问题是：静态属性和实例属性的调用方式不同。对静态属性，getValue() 的第一个参数必须是 null；对非静态属性，必须传入有效对象实例——传 null 会触发 TypeError。
- 判断是否为静态：用
$prop->isStatic()，别依赖命名约定 - 获取值时若传错参数类型，PHP 8.0+ 会明确报
TypeError: ReflectionProperty::getValue(): Argument #1 ($object) must be of type ?object -
setValue()对只读属性（readonly，PHP 8.2+）仍会失败，setAccessible(true)无效 - OPcache 启用时，反复反射同一属性性能损耗明显，建议结果缓存到静态数组
生产环境用反射做动态代理时最易被忽略的性能点
动态代理常通过反射拦截方法调用（比如 AOP 日志、权限校验），但每次请求都新建 ReflectionClass 和 ReflectionMethod 实例，会导致 CPU 和内存压力陡增——尤其在高并发下。
根本问题在于：反射对象构建本身不轻量。它要从 Zend 符号表复制元数据，包括方法参数列表、注释字符串、修饰符位掩码等，这些操作无法被 OPcache 缓存。
- 必须把
ReflectionClass实例存在静态变量或 PSR-16 兼容缓存中，键名建议用get_class($obj).':'.$method - 不要在循环里反复调用
getMethods()，改用单次获取后过滤（array_filter($methods, fn($m) => $m->isPublic())） - 避免在热路径中使用
getDocComment()，它会加载并解析全部 PHPDoc 字符串，开销远超预期 - 如果只是检查方法是否存在，优先用
method_exists($obj, $name)，比反射快一个数量级
