PHP反射机制详解：使用ReflectionClass获取类的所有方法

如果你在搜索引擎里敲下“PHP 中使用反射获取类的所有方法”这个标题，大概率不是在做简单的业务开发，而是在写某种底层组件：要给旧项目生成接口文档、要做自动路由分发、要实现依赖注入容器，或者写一套代码分析工具。我第一次真正用上这个功能，是在给一个老管理系统写 API 文档生成器的时候——那套系统里的控制器都继承自同一个基类，但不同控制器的公开方法语义差异极大，手写文档清单显然不现实，用反射去遍历类方法几乎是当时最合理的解。

反射这个机制，在 PHP 里被很多人当成“高深知识点”跳过，实际用起来却发现它其实是一套非常规整的 API。ReflectionClass拿到手之后，getMethods()一行代码就能把类里所有方法捞出来，但要真正把这些方法用在自动化工具里，后面还有一堆细节要处理：可见性过滤、继承方法剔除、参数默认值提取、静态方法识别、甚至绕过权限做内部方法调用。这篇文章从我做文档生成器的完整思路出发，把反射获取类方法这条链路从头到尾拆一遍。

1. 从 getMethods 到 ReflectionMethod：基础 API 与返回值理解

1.1 ReflectionClass 的三种实例化方式

反射操作的起点永远是ReflectionClass。这个类可以理解成一把“解剖刀”，它负责把 PHP 类元数据完整暴露出来。在拿到类方法前，得先把这把刀磨好。

实际使用中有三种创建ReflectionClass实例的方式，运行效果基本等价，但适用场景有区别：

<?php // 方式一：直接传类名字符串，最常用 $reflection = new ReflectionClass(UserService::class); // 方式二：传对象实例，PHP 会自动取目标对象所属的类 $userService = new UserService(); $reflection = new ReflectionClass($userService); // 方式三：通过字符串变量，适用于从配置文件动态读取类名的场景 $className = 'App\\Services\\UserService'; $reflection = new ReflectionClass($className);

三种方式按场景取舍。方式一用于静态分析场景，例如遍历某个目录下的所有类文件并解析它们的结构；方式二在运行时分析具体对象时更自然，比如在拦截器里判断传入对象是否具备某个方法；方式三则经常出现在框架路由里——URL 参数指定控制器名，框架把控制器名字符串交给反射去解析。

实例化ReflectionClass时，如果类不存在，会直接抛ReflectionException。这个异常一定要接住，我见过不少项目因为没处理这个异常，接口直接白屏 500。特别是方式三这种动态传类名的场景，异常处理更是刚需。

<?php try { $reflection = new ReflectionClass($className); } catch (ReflectionException $e) { // 上报日志，同时给调用方一个友好的兜底 error_log("类加载失败: {$className} - {$e->getMessage()}"); // 可以在这里返回一个预设的空方法清单 }

1.2 getMethods 返回的是什么对象数组

类的元数据就绪后，getMethods()是这次的主角。它的返回值是一个数组，数组里每一个元素都是一个ReflectionMethod对象，这个对象的作用是描述类的单个方法。也就是说，getMethods()返回的不是方法名数组，而是方法对象数组。

<?php $reflection = new ReflectionClass(OrderService::class); $methods = $reflection->getMethods(); foreach ($methods as $method) { // $method 是 ReflectionMethod 实例，不是字符串 echo $method->getName() . PHP_EOL; }

之所以返回对象而不是字符串，原因很简单：调用方拿到的是数组，但后续往往还需要获取方法的参数列表、返回类型、可见性、是否静态、定义所在类等大量元数据。如果只返回字符串，又得循环再包一层反射调用，效率上和代码优雅度上都差很多。PHP 在反射 API 设计上遵循的是“一趟拿全”原则，对象直接承载完整元数据。

1.3 ReflectionMethod 核心信息读取速查

拿到ReflectionMethod对象后，高频信息的基本读取方式如下：

这段 API 理解是后面所有进阶操作的地基。之所以单独提出来，是因为实际开发中这两个对象——ReflectionClass和ReflectionMethod——经常被混在一起用。比如有人在循环里反复new ReflectionMethod($class, $methodName)，却没意识到$method本身已经携带了全部信息，直接用就行，这等于白做了一次重复工。

2. 过滤方法的三个层级：可见性、静态性与继承来源

2.1 可见性过滤的具体写法与位掩码逻辑

getMethods()默认返回这个类所有可见方法，包括 public、protected、private。但实际工具开发中，我们绝大多数时候只关心 public 方法。比如文档生成器、路由分发器，本质上都是面向外部调用契约，private 方法属于内部实现细节，不应该暴露在文档里。

过滤可见性有两种方案。

方案一是先取回全部方法，再用isPublic()判断过滤：

<?php $reflection = new ReflectionClass(OrderService::class); $publicMethods = array_filter($reflection->getMethods(), function ($method) { return $method->isPublic() && !$method->isConstructor(); });

方案二是直接利用getMethods()的参数过滤。这个参数是 PHP 预设的属性过滤器，通过位掩码组合出你关心的方法类型：

<?php // 只获取 public 方法 $reflection = new ReflectionClass(OrderService::class); $publicMethods = $reflection->getMethods(ReflectionMethod::IS_PUBLIC); // 获取 public + protected 方法 $methods = $reflection->getMethods(ReflectionMethod::IS_PUBLIC | ReflectionMethod::IS_PROTECTED); // 静态方法 + 公开方法 $staticPublicMethods = $reflection->getMethods( ReflectionMethod::IS_STATIC | ReflectionMethod::IS_PUBLIC );

位掩码组合的规则不复杂：用|把多个常量拼起来，PHP 底层会根据这些位去筛选目标方法。三种定义的常量是ReflectionMethod::IS_PUBLIC、IS_PROTECTED、IS_PRIVATE、IS_STATIC、IS_ABSTRACT和IS_FINAL，按需挑选即可。

两个方案对比，方案二代码更短，语义也更直接，推荐作为默认选择。但方案一也不是没价值——当过滤逻辑比较复杂，比如“公开方法 + 非构造函数 + 方法名以 get 开头”这种多条件组合时，在循环里自己写判断反而更灵活直观。

2.2 默认包含父类方法的坑：getDeclaringClass 的正确用法

这是我在文档生成器项目里踩过的一个很深的坑。OrderService继承了一个抽象基类AbstractService，基类里定义了getList()、save()、delete()这些通用数据操作方法。子类只写了一层薄薄的包装或干脆只写了构造方法。用getMethods()全量扫描后，返回值里赫然躺着基类的方法。

对文档场景来说，基类方法通常是通用能力，文档里单独展示一次就够了，在子类的接口文档中重复展示不仅冗余，还会让读者搞不清这些接口到底是谁实现的。更关键的是，如果你要做的是“这个类自己实现了哪些对外接口”的功能清单，把继承来的方法一并列出来会完全偏题。

正确的处理方法是用getDeclaringClass()判断声明源：

<?php $reflection = new ReflectionClass(OrderService::class); $className = $reflection->getName(); $selfMethods = array_filter($reflection->getMethods(), function ($method) use ($className) { // getDeclaringClass 返回声明这个方法的类，如果方法是在父类声明的，这里返回的是父类对象 return $method->getDeclaringClass()->getName() === $className; });

当方法的声明类和当前反射类名匹配时，说明是类自己定义的方法；不匹配时的两种情况都要心里有数：要么方法来自父类，要么来自 trait。trait 方法也会有同样的声明归属问题，getDeclaringClass()会把 trait 剥离后的具体使用类作为声明来源，这里面的细节项目需求不同，处理策略会有差异。但从通用工具的角度看，判断声明类和当前类名是否一致，是过滤继承方法的通用规则。

2.3 构造函数与魔术方法的取舍策略

过滤方法的第三个维度是方法类型。PHP 类的方法里有两个不能当普通接口方法对待的存在：构造函数__construct和魔术方法家族（__call、__get、__toString等）。

构造函数是一个类的初始化入口，它不是对外业务接口——虽然有些模式里会通过反射newInstanceArgs传入参数创建对象，但你就不会想写 API 文档时报出__construct这个方法名。魔术方法则是 PHP 的动态兜底机制，绝大多数情况下它不是真实的业务能力。在我写文档生成器时，默认规则就是把构造函数和魔术方法全部剔除。

剔除逻辑放在过滤器里，代码如下：

<?php $methodFilter = function ($method) use ($className) { // 构造和析构不展示 if ($method->isConstructor() || $method->isDestructor()) { return false; } // 以 __ 开头的其他魔术方法（__call、__get、__set、__toString 等）一律跳过 if (str_starts_with($method->getName(), '__')) { return false; } // 只保留当前类自己声明的方法 if ($method->getDeclaringClass()->getName() !== $className) { return false; } return true; }; $methods = array_filter($reflection->getMethods(), $methodFilter);

这里用str_starts_with($method->getName(), '__')处理魔术方法非常省心，PHP 的所有魔术方法都是双下划线开头，普通业务方法几乎不可能取这样的名字。

3. 获取方法的参数细节：类型、默认值与可选参数判断

3.1 getParameters 返回的对象如何解析

方法过滤到位后，下一步通常是解析方法的参数列表。这在文档生成器、代码分析器和依赖注入容器中都是刚需。ReflectionMethod::getParameters()返回的是一个ReflectionParameter对象数组，每个对象代表一个参数。

ReflectionParameter能提供的核心信息：参数名、参数类型、是否可选、是否有默认值、默认值是什么、是否引用传递。对应读取方式如下：

<?php foreach ($methods as $method) { foreach ($method->getParameters() as $parameter) { echo $parameter->getName() . PHP_EOL; echo $parameter->getType() . PHP_EOL; // 返回 ReflectionType 对象，转字符串得到类型名 echo $parameter->isOptional() ? '可选' : '必填' . PHP_EOL; echo $parameter->isDefaultValueAvailable() ? $parameter->getDefaultValue() : '无默认值' . PHP_EOL; } }

参数类型这里有一个容易踩坑的地方：getType()返回的是ReflectionType对象。如果直接把对象当字符串用，PHP 的__toString方法会给你一个字符串类型名，这在多数场景下够用。但碰到联合类型（int|string）时，返回类型实际是ReflectionUnionType，它也是ReflectionType的子类，字符串转换后得到的是int|string，倒也直观。

如果项目运行在 PHP 8.0 以上，参数类型还可能是ReflectionNamedType，它有getName()方法可以拿到类型名。稳妥的解析代码应该带上getType()为 null 的判断，因为老项目中大量存在完全没写类型声明的参数。

<?php $type = $parameter->getType(); if ($type === null) { $typeName = 'mixed'; // 视项目约定而定，也可以记作 null } else { $typeName = (string) $type; }

3.2 默认值提取的两个注意点

参数默认值看起来是一个简单操作——直接调getDefaultValue()——实际使用时有两个明显的坑。

第一个坑：只有isDefaultValueAvailable()返回 true 时才能调getDefaultValue()。如果一个参数没有默认值，直接调用getDefaultValue()会抛出ReflectionException。不过官方文档定义是“仅当参数有默认值时调用此方法”，很多新手漏掉这个检查，导致代码直接崩溃。顺手提一句，isOptional()其实可以涵盖“默认值可用”的语义，但可选参数还有一种情况是“在参数后面跟着足够多带默认值参数”，所以两个判断不是完全等价。保守起见，直接用isDefaultValueAvailable()判断。

第二个坑，而且是大坑：默认值是常量或数组时，不同 PHP 版本的行为不完全一致。PHP 8.1 之前，getDefaultValue()返回的是常量的名称字符串，比如DEFAULT_STATUS；PHP 8.1 之后，对于枚举、类常量这类复杂默认值，返回值会是对应对象或常量解析后的值。如果文档生成器需要保留参数默认常量的字面表达，这会造成跨版本行为差异。处理方式是在读取默认值时包一层类型判断：

<?php $defaultValue = null; if ($parameter->isDefaultValueAvailable()) { $defaultValue = $parameter->getDefaultValue(); // 如果返回的是字符串且恰好是常量名，可以按需做常量名反查；如果是数组则直接输出 }

3.3 引用传递与可变参数如何识别

ReflectionParameter还提供两个在方法分发时非常重要的判断：isPassedByReference()判断参数是否引用传递，isVariadic()判断是否为可变参数（...$args）。

依赖注入容器的参数绑定环节，这两个判断直接决定调用方式。引用传递参数必须确保传入的是变量，而且调用后该变量值可能被修改；可变参数则需要把数组参数展开传入，call_user_func_array或invokeArgs才会正确处理。

判断逻辑：

<?php foreach ($parameter->getParameters() as $param) { if ($param->isVariadic()) { // 可变参数，调用时要做数组展开处理 } elseif ($param->isPassedByReference()) { // 引用传递，调用前要准备好变量，调用后不能丢弃 } }

这两个方法平时用得少，但在封装通用方法调用器时非常关键。比如写一个所有控制器的统一调度器，把请求参数自动绑定到控制器方法参数上，这里必须准确区分可变参数和引用参数，否则调用结果可能就是错位的。

4. 动态调用与属性联动：invokeArgs 和反射的实际生产力价值

4.1 invokeArgs 完整用法：向方法动态传参

反射的价值不仅在于读元数据，还在于动态调用。解析完方法参数后，往往下一步就是正在把这些参数传给方法、把它真正跑起来。ReflectionMethod提供了两个调用入口：invoke($obj, ...$args)和invokeArgs($obj, $argsArray)。

我在实际项目里更推荐invokeArgs，因为大多数动态调用场景中，参数本来就是以数组形式从外部获得的——通常是请求参数数组，或者容器绑定好的依赖数组。直接传数组避免了展开操作，调用代码也更简洁。

<?php $reflection = new ReflectionClass($controllerClass); $controller = $reflection->newInstance(); // 无参构造的控制器 $method = $reflection->getMethod($actionName); // 假设 $params 是由参数名到值的关联数组 $result = $method->invokeArgs($controller, $params);

这个方法对静态方法同样适用，第一个参数传 null 即可：

<?php $method = new ReflectionMethod(Calculator::class, 'add'); $result = $method->invokeArgs(null, [3, 5]);

一个隐蔽但重要的细节是：invokeArgs的参数数组默认是按位置顺序匹配的。如果你给的是关联数组，PHP 会根据参数名自动关联。官方文档明确写的是，如果参数数组是关联数组，键会与方法参数名对应。但这里有个版本差异——PHP 8.0 之前关联数组键能被忽略掉。好在 PHP 8 之后这个行为基本稳定，用关联数组传参反而让代码语义更明确。

4.2 配合构造函数创建实例：从 newInstance 到绕过访问限制

动态调用方法前先要创建对象。ReflectionClass::newInstance()和newInstanceArgs()是创建实例的两条路径。构造函数的参数绑定方式很直观：

<?php $reflection = new ReflectionClass($className); $constructor = $reflection->getConstructor(); if ($constructor === null) { $instance = $reflection->newInstance(); } else { $args = []; // 这里按构造参数名从容器/配置中取值填充 $instance = $reflection->newInstanceArgs($args); }

可以先通过getConstructor()判断类是否有构造函数，没有就无参实例化，有就解析参数列表再绑定。这套逻辑是很多容器和工厂的底层原型。

另一个容易漏掉的黑科技是ReflectionMethod::setAccessible(true)。在 PHP 8.1 之前，通过反射调用非 public 方法是历史上比较常用的一种方式，特别是在写单元测试时想调动 protected/private 方法去验证内部逻辑。这个方法在你做测试替身、私有方法单测时很好用。但从 PHP 8.1 开始，所有方法调用默认已经可以通过反射直接调用，不再需要setAccessible。如果你的项目还在用老写法，那只是“无害冗余”，可以继续跑，但新代码里不值得再多写这一行。

<?php // 老写法（PHP 8.1 前曾必须写） $method->setAccessible(true); $result = $method->invoke($object); // PHP 8.1+ 可以直接调用 $result = $method->invoke($object);

平时写应用代码时用反射调用私有方法不是推荐选择——它绕过了封装边界，会让代码变得难以维护。但测试老项目里那些不能改签名的方法时，这套能力是真能救命的。

4.3 反射其他属性：方法上的注释、返回类型与 named arguments

除了方法本身，反射还能带出方法定义处的注释。getDocComment()返回方法的 PHPDoc 注释块，在文档生成器里，这个方法就是核心功能来源。

<?php $doc = $method->getDocComment();

我在写文档生成器时，方法名、参数、默认值这些是骨架，方法的 PHPDoc 注释则提供了“人类可读”的业务说明。如果getDocComment()返回 false，就回退到只展示签名信息。

返回类型方面，getReturnType()也可以进行联合判断，确保文档里的返回类型完整：

<?php $returnType = $method->getReturnType(); if ($returnType !== null) { echo (string) $returnType; // 输出如 void、string、Order|null }

PHP 8 还支持 named arguments，反射调用时也能利用这一点。不过这里的代码量会更多，核心思路是在invoke/invokeArgs前，把方法参数名和调用方数据的键对齐。这种做法可以跳过参数位置匹配的问题，只是对调用数据的格式要求更高，要看项目实际需要再决定。

5. 实战案例：自动生成类方法清单与性能避坑

5.1 完整代码：控制器方法清单生成器

把以上所有点串起来，一段实用的“类方法清单生成器”长这样。这个工具可以直接用在我前面说的 API 文档自动生成场景，也可以用在模块权限列表自动生成上——从控制器方法反推可调用操作清单。

<?php /** * 获取类对外暴露的方法清单 * * @param string $className 类名 * @return array<int, array<string, mixed>> */ function getPublicMethodsList(string $className): array { try { $reflection = new ReflectionClass($className); } catch (ReflectionException $e) { return ['error' => $e->getMessage()]; } $className = $reflection->getName(); $methodList = []; // 只取 public 方法，其余信息在循环里精细过滤 $methods = $reflection->getMethods(ReflectionMethod::IS_PUBLIC); foreach ($methods as $method) { // 过滤：构造函数、析构函数、魔术方法、继承方法 if ($method->isConstructor() || $method->isDestructor()) { continue; } if (str_starts_with($method->getName(), '__')) { continue; } if ($method->getDeclaringClass()->getName() !== $className) { continue; } // 收集参数详情 $params = []; foreach ($method->getParameters() as $param) { $type = $param->getType(); $params[] = [ 'name' => $param->getName(), 'type' => $type === null ? null : (string) $type, 'optional' => $param->isOptional(), 'default' => $param->isDefaultValueAvailable() ? $param->getDefaultValue() : null, 'variadic' => $param->isVariadic(), 'byRef' => $param->isPassedByReference(), ]; } $methodList[] = [ 'name' => $method->getName(), 'params' => $params, 'return' => $method->getReturnType() ? (string) $method->getReturnType() : null, 'static' => $method->isStatic(), 'doc' => $method->getDocComment() ?: '', ]; } return $methodList; }

这个函数里把前面讲过的所有关键点都汇总了：反射异常的捕获、可见性过滤、继承方法剔除、构造和魔术方法跳过、参数细节完整提取。直接复制到项目中改一改类名和输出格式，就能跑起来。

5.2 性能开销和数据缓存策略

反射性能是绕不开的话题。PHP 反射 API 的性能开销并非为零，但也远没有到“用了就崩”的程度。一个类的方法数量通常在几个到几十个之间，getMethods()加参数遍历的总时间在毫秒以内，这种量级在单次请求里完全不是问题。

真正的问题出在循环调用上。比如你要批量扫描 100 个类文件，每个类都做完整的反射解析，那就另当别论了——累计开销很可能让接口响应时间明显上升。

面对这类批量场景，实践中比较稳妥的方案是：给反射结果加缓存。缓存键可以用类的文件修改时间，类文件变了就重新解析缓存并覆盖；类文件没变就直接读缓存。这个策略很多大型框架的容器和 IDE 工具都在用。

一个轻量级缓存实现思路：

<?php function getCachedMethodsList(string $className): array { $cacheFile = sys_get_temp_dir() . '/method_cache_' . md5($className) . '.php'; // 缓存存在且有效期内直接返回 if (file_exists($cacheFile) && (time() - filemtime($cacheFile) < 3600)) { return include $cacheFile; } $list = getPublicMethodsList($className); // 写入缓存 file_put_contents($cacheFile, '<?php return ' . var_export($list, true) . ';'); return $list; }

这个方案不涉及复杂组件，对中小项目够用。如果是用 Redis 或 APCu 的环境，把include换成缓存读取即可，思路一致。

另一种保守思路是：把反射限制在开发环境或特定的命令行工具里使用。比如 API 文档生成器设计成在部署前手动执行一次，而不是每次请求都跑，这样性能敏感度自然降下来了。我自己的项目就是这么做的——只在一个后台管理页面触发“重新扫描控制器”，扫描结果落库，线上的文档模块只读数据库，不碰反射。

5.3 最佳实践：什么时候该用反射，什么时候别用

反射是一把双刃剑。它最大的价值是通用性——不关心每个类的具体实现逻辑，而是通过统一的元数据接口去驱动各类业务对象。写框架、写组件、写代码生成器时，反射几乎不可替代。

但普通业务代码里不适合乱用。一个业务方法明明可以在代码里直接调用，非要用反射绕一圈去调用，既牺牲了性能，又模糊了调用意图，还会让 IDE 的代码追踪失效。在设计以下类型的代码时不要考虑反射：常规 CRUD 操作、两个固定类之间的相互调用、已经有明确接口约束的场景。

用反射的正确形态是：在“你需要处理很多未知类”的时候。比如控制器分发器需要根据用户请求动态定位到不同控制器方法，依赖注入容器需要将配置中的类实例化并填充依赖，单元测试需要验证私有方法的输出，这些“未知”成为常态的场景才是反射的主场。

判断一个需求是否需要用反射，我的经验标准就一条：如果代码里需要出现很多个switch或者if-else去判断不同的类分别执行不同逻辑，先停下来想想能不能反射统一处理。如果能，那反射带来的收益远大于那一点点性能损耗；如果只是两个已知类之间的调用，直接写代码比反射清晰得多。

6. 实际项目中再补充的三个经验技巧

6.1 方法名大小写不要去较真

PHP 本身的方法名大小写不敏感，getOrder和getorder在 PHP 里是同一个方法。但反射的getName()返回值是定义时的原始大小写形式。如果你用请求参数里的字符串去匹配反射返回的方法名，比如前端传了个getorder，你反射拿到的却是getOrder，直接比较就会失败。

这里稳妥的做法是比较前统一转小写：

<?php $methodMap = []; foreach ($reflection->getMethods(ReflectionMethod::IS_PUBLIC) as $method) { $methodMap[strtolower($method->getName())] = $method; } $actionName = strtolower($request->get('action')); if (isset($methodMap[$actionName])) { $method = $methodMap[$actionName]; }

这个坑我在写路由分发的时候踩过一次，当时前端传参的大小写风格和后端方法名不一致，整个接口直接 404。后来统一转小写后问题就消失了。

6.2 用 isUserDefined 区分内部类方法

如果反射的目标不限于我们自己写的项目类，比如也在分析第三方vendor目录里的类，ReflectionMethod::isUserDefined()会很有用。这个方法返回 true 表示方法是用户定义的，返回 false 表示来自 PHP 内部扩展类。类似地，ReflectionClass::isInternal()可以直接判断这个类是不是 PHP 内置类。

在生成文档时需要过滤掉继承自内部类的方法时，这组判断可以帮上大忙。比如你在扩展ArrayObject或Exception，里面积累了一堆内部类方法，文档里如果全部展示出来，整个页面会变得冗余。

<?php if ($method->isUserDefined()) { // 用户定义的方法，可以进入文档 }

这里注意一个细节：子类重写父类方法时，getDeclaringClass()一般认为声明这个方法的类是子类，isUserDefined()也返回 true，因为子类是在用户代码里定义的。只有真正来自 PHP 扩展的方法才会让isUserDefined()返回 false。

6.3 借助反射写测试替身时的边界意识

最后说说反射在单元测试中的边界问题。PHPUnit 这类测试框架内部大量使用反射，我们要写好测试替身、模拟私有逻辑时，反射是最直接的手段。

比如测一个类里私有方法calculateDiscount的逻辑，可以这样：

<?php $reflection = new ReflectionClass(PriceCalculator::class); $calculator = new PriceCalculator($someDependency); $method = $reflection->getMethod('calculateDiscount'); // PHP 8.0 以下可以先 setAccessible(true)，8.1+ 可略 $result = $method->invoke($calculator, 100);

这种方法在测试老代码时极其实用，很多老项目里方法没有拆开成独立的类，逻辑全堆在私有方法里，还不能直接改签名——反射测试替身是成本最小的绕过方式。但有一个边界要守住：别把这种能力写进业务逻辑。测试里绕过封装是为了验证实现，业务代码里绕过封装就是破坏封装。

另外在写测试时，可以通过反射读取对象内部属性状态做断言。原理是一样的，ReflectionProperty负责读取私有属性，拿到值后与预期比较。这同样是测试替身场景下的常规操作，逻辑和ReflectionMethod完全对称。

回头看我写文档生成器的那个项目，核心代码其实也就几十行，真正费时间的是处理各种边缘情况：继承的方法要不要展示、魔术方法怎么归类、参数默认值在不同版本下的表现形式。反射这个机制的门槛不高，一套 API 背熟就能跑通基本流程，但把它真正用到生产环境的自动化工具里，上面的这些细节才是决定工具好用还是难用的分水岭。希望这篇实操梳理能把 PHP 反射获取类方法的完整链路讲透，下次你写代码分析工具或者容器时，可以直接照着这套思路落地。