宏必须在AppServiceProvider::boot()中注册才可靠，$this指向被扩展类实例，命名需避让原生方法并加PHPDoc注释以改善IDE支持。
宏必须在应用启动早期注册，晚于这个时机（比如在控制器、中间件或命令中调用 Collection::macro()）会直接失效，调用时抛出 BadMethodCallException: Method xxx does not exist。
宏只能在服务提供者 boot() 中注册才可靠
所有 Macroable 类（Collection、Response、Request、Builder 等）的宏都必须在容器完全就绪后注册，AppServiceProvider::boot() 是最稳妥的位置。不能放在 register()（容器未绑定完成），也不能放在任何运行时上下文中（如控制器方法里）。
-
Response::macro('success', ...)放在控制器里？—— 无效，调用时一定报错 - 想临时测试？用
php artisan tinker手动注册，仅限调试，不进生产代码 - 多个宏集中管理？新建
app/Macros/CollectionMacros.php，在boot()中require_once app_path('Macros/CollectionMacros.php') - 文件里不能有命名空间、不能定义类、不能用
use，只写裸Collection::macro(...)调用
闭包里的 $this 指向什么
注册宏时传入的闭包中，$this 不是 Laravel 的请求/响应生命周期实例，而是当前被扩展类的实例本身：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
Collection::macro('isEvenCount', function () { return $this->count() % 2 === 0; })→$this是Illuminate\Support\Collection实例 -
Response::macro('success', function ($data) { return response()->json([...]); })→$this是Illuminate\Contracts\Routing\ResponseFactory（即response()辅助函数返回的对象） -
Request::macro('isMobile', function () { return $this->hasHeader('User-Agent') && ...; })→$this就是当前请求的Illuminate\Http\Request实例 - 别试图在
Response宏里读$request，没自动注入；要用request()辅助函数显式获取
命名冲突和 IDE 提示弱是真实痛点
宏名一旦和原生方法重名（比如给 Collection 定义 map 宏），Laravel 不会警告，而是静默覆盖或触发不可预测行为。更麻烦的是：PHPStorm 或其他 IDE 基本无法识别宏方法，没有自动补全、跳转或类型提示。
- 命名前先查文档：确认
Collection是否已有toCsv()、chunkBy()等方法 - 加统一前缀可降低冲突风险，比如
myToCsv()、appIsAdmin() - 在宏闭包头部加 PHPDoc 注释，能略微改善 IDE 行为：
/** @return Collection */ - 单元测试必须覆盖宏调用路径，因为静态分析工具完全“看不见”它
宏不是语法糖，它是运行时挂载的闭包指针；注册时机、$this 绑定规则、命名隔离这三点，漏掉任何一个都会让宏在某个环境里突然失灵。
