我理解是因为可以适应更多的场景化的需求。我可以设置同一个resourceName, 针对不同的参数位置设置不同的规则。
举 2 个例子：

1. SphU.entry(resourceName, EntryType.IN, 1, 手机品牌，手机型号)，我可以单独针对手机品牌和手机型号进行限流，也就是说我这一个资源点可能是有多个参数进行把控的。
2. 用注解的方式，方法参数的位置已经是定的，方法的第2个参数可能才是热点参数。总不至于为了接入Sentinel，而去调整方法的参数位置顺序。

I understand that it is because it can adapt to more scenario-based needs. I can set the same resourceName and set different rules for different parameter positions.
Give 2 examples:

1. SphU.entry(resourceName, EntryType.IN, 1, brand, model), I can limit the current for the mobile phone brand and mobile phone model alone, which means that my resource point may have multiple parameters to control .
2. In the way of using annotation, the position of the method parameter has been fixed, and the second parameter of the method may be the hot param. It is not always possible to adjust the order of the parameter positions of the method in order to access Sentinel.

1、 SphU.entry(resourceName, EntryType.IN, 1, 手机品牌，手机型号)，我可以单独针对手机品牌和手机型号进行限流，也就是说我这一个资源点可能是有多个参数进行把控的。

如果想实现热点参数切换（从手机品牌切换到手机型号）没什么问题，并且完全是可以的，但是我感觉现实中的这种需求并不会太多。当初加了手机品牌的热点参数，后来突然就不要了？在手机品牌的基础上累加手机型号热点参数我倒觉得更实用，但是同一个资源限流是不能针对多个热点参数的。

2、 用注解的方式，方法参数的位置已经是定的，方法的第2个参数可能才是热点参数。总不至于为了接入Sentinel，而去调整方法的参数位置顺序。

这个我觉得确实是合理的，并且现实中确实存在一些这样的需求。

单纯基于这两个观点结论的话，官方可以把热点参数的相关描述可以举几个切实的例子，分别使用什么场景。这样更好的我们理解。