From ddb9930f7aef633ea1efff7288aafc7633dd9a24 Mon Sep 17 00:00:00 2001 From: kayx23 Date: Wed, 28 Oct 2026 15:49:18 +0800 Subject: [PATCH] docs: port source-verified terminology corrections --- docs/en/latest/router-radixtree.md | 12 ++++--- docs/en/latest/stream-proxy.md | 3 +- docs/en/latest/terminology/consumer.md | 33 +++++++++---------- docs/en/latest/terminology/credential.md | 8 ++--- docs/en/latest/terminology/global-rule.md | 2 +- docs/en/latest/terminology/plugin-metadata.md | 20 +++++------ docs/en/latest/terminology/secret.md | 2 +- docs/zh/latest/terminology/consumer.md | 31 ++++++++--------- docs/zh/latest/terminology/credential.md | 8 ++--- docs/zh/latest/terminology/global-rule.md | 2 +- docs/zh/latest/terminology/plugin-metadata.md | 18 ++++------ 11 files changed, 63 insertions(+), 76 deletions(-) diff --git a/docs/en/latest/router-radixtree.md b/docs/en/latest/router-radixtree.md index c375360ef472..0b32d1aa118a 100644 --- a/docs/en/latest/router-radixtree.md +++ b/docs/en/latest/router-radixtree.md @@ -23,7 +23,7 @@ Title: Router Radixtree ### What is Libradixtree? -[Libradixtree](https://github.com/api7/lua-resty-radixtree) is an adaptive radix tree that is implemented in Lua for OpenResty and it is based on FFI for [rax](https://github.com/antirez/rax). APISIX uses libradixtree as a route dispatching library. +Libradixtree is an adaptive radix tree implemented in Lua for OpenResty and based on FFI for [rax](https://github.com/antirez/rax). APISIX uses libradixtree as a route dispatching library. ### How to use Libradixtree in APISIX? @@ -194,18 +194,20 @@ route like will match both `/blog/dog` and `/blog/cat`. -For more details, see https://github.com/api7/lua-resty-radixtree/#parameters-in-path. +Named parameters match one path segment. A trailing wildcard parameter matches the remaining path segments. ### How to filter route by Nginx built-in variable? -Nginx provides a variety of built-in variables that can be used to filter routes based on certain criteria. Here is an example of how to filter routes by Nginx built-in variables: +The Route `vars` field accepts APISIX expressions. Each basic condition uses the form `[variable, operator, value]`. Conditions in the outer array are combined with AND by default. Supported operators include equality and inequality comparisons, numeric comparisons, regular-expression matching, membership checks, array containment checks, and IP address matching. + +Nginx provides built-in variables that can be used in these expressions. The following example filters a route by request variables: ```shell $ curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -i -d ' { "uri": "/index.html", "vars": [ - ["http_host", "==", "iresty.com"], + ["http_host", "==", "example.com"], ["cookie_device_id", "==", "a66f0cdc4ba2df8c096f74c9110163a9"], ["arg_name", "==", "json"], ["arg_age", ">", "18"], @@ -220,7 +222,7 @@ $ curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X }' ``` -This route will require the request header `host` equal `iresty.com`, request cookie key `_device_id` equal `a66f0cdc4ba2df8c096f74c9110163a9` etc. You can learn more at [radixtree-new](https://github.com/api7/lua-resty-radixtree#new). +This route requires the request host to equal `example.com`, the `_device_id` cookie to equal `a66f0cdc4ba2df8c096f74c9110163a9`, and the remaining expressions to match. ### How to filter route by POST form attributes? diff --git a/docs/en/latest/stream-proxy.md b/docs/en/latest/stream-proxy.md index 1fb9ac0bb474..9c61b54e2b44 100644 --- a/docs/en/latest/stream-proxy.md +++ b/docs/en/latest/stream-proxy.md @@ -81,11 +81,12 @@ More examples can be found in [test cases](https://github.com/apache/apisix/blob ## More stream route filtering options -Currently there are three attributes in stream routes that can be used for filtering requests: +Stream routes can filter connections with the following attributes: - `server_addr`: The address of the APISIX server that accepts the L4 stream connection. - `server_port`: The port of the APISIX server that accepts the L4 stream connection. - `remote_addr`: The address of client from which the request has been made. +- `sni`: The TLS Server Name Indication value. This field applies to TLS-enabled stream listeners. Here is an example: diff --git a/docs/en/latest/terminology/consumer.md b/docs/en/latest/terminology/consumer.md index 17fc7d8f5010..1e33b031547a 100644 --- a/docs/en/latest/terminology/consumer.md +++ b/docs/en/latest/terminology/consumer.md @@ -29,38 +29,35 @@ description: This article describes the role of the Apache APISIX Consumer objec ## Description -For an API gateway, it is usually possible to identify the type of the requester by using things like their request domain name and client IP address. A gateway like APISIX can then filter these requests using [Plugins](./plugin.md) and forward it to the specified [Upstream](./upstream.md). - -It has the highest priority: Consumer > Route > Plugin Config > Service. - -But this level of depth can be insufficient on some occasions. +In APISIX, a **Consumer** represents a user, application, or host that sends requests through the gateway. Consumers are typically used with authentication plugins, which identify a Consumer from request credentials and make its plugin configuration available while APISIX processes the request. ![consumer-who](../../../assets/images/consumer-who.png) -An API gateway should know who the consumer of the API is to configure different rules for different consumers. This is where the **Consumer** construct comes in APISIX. +Consumers can carry plugin configuration and can reference a [Consumer Group](./consumer-group.md) for shared plugin configuration. When the same plugin is configured in more than one local object, APISIX merges those configurations according to the [plugin merging precedence](./plugin.md#plugins-merging-precedence). ### Configuration options The fields for defining a Consumer are defined as below. -| Field | Required | Description | -| ---------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `username` | True | Name of the consumer. | -| `plugins` | False | Plugin configuration of the **Consumer**. For specific Plugin configurations, please refer the [Plugins](./plugin.md). | +| Field | Required | Description | +| ----- | -------- | ----------- | +| `username` | True | Unique name of the Consumer. | +| `desc` | False | Description of the Consumer. | +| `labels` | False | Labels attached to the Consumer. | +| `group_id` | False | ID of the Consumer Group whose plugins are merged with the Consumer's plugins. | +| `plugins` | False | Plugin configuration for the Consumer. See [Plugins](./plugin.md). | ## Identifying a Consumer -The process of identifying a Consumer in APISIX is described below: - -![consumer-internal](../../../assets/images/consumer-internal.png) +The process of identifying a Consumer in APISIX works as follows: -1. The first step is Authentication. This is achieved by Authentication Plugins like [key-auth](../plugins/key-auth.md) and [JWT](../plugins/jwt-auth.md). -2. After authenticating, you can obtain the `id` of the Consumer. This `id` will be the unique identifier of a Consumer. -3. The configurations like Plugins and Upstream bound to the Consumer are then executed. +1. An authentication plugin, such as [key-auth](../plugins/key-auth.md) or [jwt-auth](../plugins/jwt-auth.md), validates the request credentials. +2. The plugin identifies the Consumer by its unique `username`. +3. APISIX merges the Consumer and Consumer Group plugin configuration with the plugin configuration from the matched Route, Plugin Config, and Service. -Consumers are useful when you have different consumers requesting the same API and you need to execute different Plugin and Upstream configurations based on the consumer. These need to be used in conjunction with the user authentication system. +Consumers are useful when different applications or users request the same API and require different plugin configuration, such as rate limits or access controls. A Consumer does not hold an Upstream configuration. -Authentication plugins that can be configured with a Consumer include `basic-auth`, `hmac-auth`, `jwt-auth`, `key-auth`, `ldap-auth`, and `wolf-rbac`. +Authentication plugins enabled in APISIX can be configured on a Consumer. Examples include `basic-auth`, `hmac-auth`, `jwt-auth`, `key-auth`, `ldap-auth`, and `wolf-rbac`. Refer to the documentation for the [key-auth](../plugins/key-auth.md) authentication Plugin to further understand the concept of a Consumer. diff --git a/docs/en/latest/terminology/credential.md b/docs/en/latest/terminology/credential.md index b0ed3bc2fd5c..594dc994c18a 100644 --- a/docs/en/latest/terminology/credential.md +++ b/docs/en/latest/terminology/credential.md @@ -29,11 +29,9 @@ description: This article describes what the Apache APISIX Credential object doe ## Description -Credential is the object that holds the [Consumer](./consumer.md) credential configuration. -A Consumer can use multiple credentials of different types. -Credentials are used when you need to configure multiple credentials for a Consumer. +A Credential stores authentication plugin configuration for a [Consumer](./consumer.md). Each Credential contains at most one enabled authentication plugin, such as `basic-auth`, `hmac-auth`, `jwt-auth`, or `key-auth`. -Currently, Credential can be configured with the authentication plugins `basic-auth`, `hmac-auth`, `jwt-auth`, and `key-auth`. +A Consumer can have Credentials for different authentication plugins. It can also have multiple Credentials for the same authentication plugin when their identifying values differ. For example, a Consumer can rotate a key by creating a second `key-auth` Credential, switching clients to the new key, and then deleting the old Credential. Credential details are stored separately and are not included when you retrieve the Consumer resource. ### Configuration options @@ -43,7 +41,7 @@ The fields for defining a Credential are defined as below. |---------|----------|---------------------------------------------------------------------------------------------------------| | desc | False | Description of the Credential. | | labels | False | Labels of the Credential. | -| plugins | False | The plugin configuration corresponding to Credential. For more information, see [Plugins](./plugin.md). | +| plugins | False | At most one authentication plugin configuration. For more information, see [Plugins](./plugin.md). | :::note diff --git a/docs/en/latest/terminology/global-rule.md b/docs/en/latest/terminology/global-rule.md index 1007f4b05ad2..13f7f636b4d2 100644 --- a/docs/en/latest/terminology/global-rule.md +++ b/docs/en/latest/terminology/global-rule.md @@ -28,7 +28,7 @@ description: This article describes how to use global rules. ## Description -A [Plugin](./plugin.md) configuration can be bound directly to a [Route](./route.md), a [Service](./service.md) or a [Consumer](./consumer.md). But what if we want a Plugin to work on all requests? This is where we register a global Plugin with Global Rule. +A [Global Rule](../admin-api.md#global-rule) configures [Plugins](./plugin.md) for incoming requests independently of Plugins bound to a [Route](./route.md), [Service](./service.md), [Consumer](./consumer.md), or [Plugin Config](./plugin-config.md). Rate-limiting and observability Plugins are often enabled globally to apply consistent behavior across APIs. Compared with the plugin configuration in Route, Service, Plugin Config, and Consumer, the plugin in the Global Rules is always executed first. diff --git a/docs/en/latest/terminology/plugin-metadata.md b/docs/en/latest/terminology/plugin-metadata.md index 93ece32a6ccc..783ffd7c9cf5 100644 --- a/docs/en/latest/terminology/plugin-metadata.md +++ b/docs/en/latest/terminology/plugin-metadata.md @@ -28,23 +28,19 @@ description: Plugin Metadata in Apache APISIX. ## Description -In this document, you will learn the basic concept of plugin metadata in APISIX and why you may need them. - -Explore additional resources at the end of the document for more information on related topics. +In this document, you will learn the basic concept of plugin metadata in APISIX and why you may need it. ## Overview -In APISIX, a plugin metadata object is used to configure the common metadata field(s) of all plugin instances sharing the same plugin name. It is useful when a plugin is enabled across multiple objects and requires a universal update to their metadata fields. - -The following diagram illustrates the concept of plugin metadata using two instances of [syslog](https://apisix.apache.org/docs/apisix/plugins/syslog/) plugins on two different routes, as well as a plugin metadata object setting a [global](https://apisix.apache.org/docs/apisix/plugins/syslog/) `log_format` for the syslog plugin: +In APISIX, a plugin metadata object configures shared settings for all instances of the same plugin. It is useful for values, such as log-format templates, that should normally remain consistent wherever the plugin is enabled. -![plugin_metadata](https://static.apiseven.com/uploads/2023/04/17/Z0OFRQhV_plugin%20metadata.svg) +APISIX stores one plugin metadata object for each plugin name. Only plugins that define a metadata schema support plugin metadata. Fields and behavior depend on the plugin, so check the documentation for the specific plugin before configuring its metadata. -Without otherwise specified, the `log_format` on plugin metadata object should apply the same log format uniformly to both `syslog` plugins. However, since the `syslog` plugin on the `/orders` route has a different `log_format`, requests visiting this route will generate logs in the `log_format` specified by the plugin in route. +For example, plugin metadata can define a shared `log_format` for every instance of the `syslog` plugin. An instance without its own `log_format` uses the metadata value, while an instance-level `log_format` takes precedence when configured. -Metadata properties set at the plugin level is more granular and has a higher priority over the "global" metadata object. +For logger plugins that support shared `log_format` metadata, this behavior also applies to plugins such as `http-logger`, `kafka-logger`, and `file-logger`. -Plugin metadata objects should only be used for plugins that have metadata fields. Check the specific plugin documentation to know more. +Plugin metadata is not merged with every plugin configuration by a universal precedence rule. Each plugin determines how its instances consume metadata and whether an instance-level field overrides a metadata field. ## Example usage @@ -78,6 +74,6 @@ With this configuration, your logs would be formatted as shown below: {"host":"localhost","@timestamp":"2020-09-23T19:05:05-04:00","client_ip":"127.0.0.1","route_id":"1"} ``` -## Additional Resource(s) +## Additional resources -Key Concepts - [Plugins](https://apisix.apache.org/docs/apisix/terminology/plugin/) +[Plugins](./plugin.md) diff --git a/docs/en/latest/terminology/secret.md b/docs/en/latest/terminology/secret.md index 94c1b8843b0a..eee43befb6d5 100644 --- a/docs/en/latest/terminology/secret.md +++ b/docs/en/latest/terminology/secret.md @@ -30,7 +30,7 @@ Secrets refer to any sensitive information required during the running process o - API key - Sensitive plugin configuration fields, typically used for authentication, hashing, signing, or encryption -APISIX Secret allows users to store secrets through some secrets management services (Vault, etc.) in APISIX, and read them according to the key when using them to ensure that **Secrets do not exist in plain text throughout the platform**. +APISIX Secret allows APISIX to retrieve values from external secret managers such as HashiCorp Vault instead of storing those values directly in resource configuration. Connection credentials can still be configured as literal values. Where supported, use environment-variable references; for GCP, use `auth_file` when the service-account key should not be embedded in resource configuration. Its working principle is shown in the figure: ![secret](../../../assets/images/secret.png) diff --git a/docs/zh/latest/terminology/consumer.md b/docs/zh/latest/terminology/consumer.md index 22f4a0fd4211..7cee94fff0bd 100644 --- a/docs/zh/latest/terminology/consumer.md +++ b/docs/zh/latest/terminology/consumer.md @@ -29,36 +29,37 @@ description: 本文介绍了 Apache APISIX Consumer 对象的作用以及如何 ## 描述 -Consumer 是某类服务的消费者，需要与用户认证配合才可以使用。当不同的消费者请求同一个 API 时，APISIX 会根据当前请求的用户信息，对应不同的 Plugin 或 Upstream 配置。如果 [Route](./route.md)、[Service](./service.md)、[Consumer](./consumer.md) 和 [Plugin Config](./plugin-config.md) 都绑定了相同的插件，只有消费者的插件配置会生效。插件配置的优先级由高到低的顺序是：Consumer > Route > Plugin Config > Service。 +在 APISIX 中，Consumer 表示通过网关发送请求并使用后端服务的用户、应用或主机。Consumer 通常与认证插件配合使用。认证插件根据请求凭证识别 Consumer，并在 APISIX 处理请求时使其插件配置生效。 -对于 API 网关而言，一般情况可以通过请求域名、客户端 IP 地址等字段识别到某类请求方，然后进行插件过滤并转发请求到指定上游。但有时候该方式达不到用户需求，因此 APISIX 支持了 Consumer 对象。 +Route 可以根据请求域名、客户端 IP 地址等属性匹配请求，但这些属性不一定能识别发起请求的应用或用户。 ![Consumer](../../../assets/images/consumer-who.png) -如上图所示，作为 API 网关，需要知道 API Consumer（消费方）具体是谁，这样就可以对不同 API Consumer 配置不同规则。 +Consumer 可以配置插件，也可以引用 Consumer Group 以共享插件配置。当多个局部对象配置了同一插件时，APISIX 会按照[插件合并优先顺序](./plugin.md#插件合并优先顺序)合并这些配置。 ## 配置选项 定义 Consumer 的字段如下： -| 名称 | 必选项 | 描述 | -| -------- | ---- | ------------------------------------------------------------------------------| -| username | 是 | Consumer 名称。 | -| plugins | 否 | Consumer 对应的插件配置。详细信息，请参考 [Plugins](./plugin.md)。 | +| 名称 | 必选项 | 描述 | +| ---- | ------ | ---- | +| `username` | 是 | Consumer 的唯一名称。 | +| `desc` | 否 | Consumer 的描述。 | +| `labels` | 否 | Consumer 的标签。 | +| `group_id` | 否 | Consumer Group 的 ID，其插件配置会与 Consumer 的插件配置合并。 | +| `plugins` | 否 | Consumer 的插件配置。详细信息请参见 [Plugins](./plugin.md)。 | ## 识别消费者 -在 APISIX 中，识别 Consumer 的过程如下图： +在 APISIX 中，识别 Consumer 的过程如下： -![Consumer Internal](../../../assets/images/consumer-internal.png) +1. 认证插件（例如 [key-auth](../plugins/key-auth.md) 或 [jwt-auth](../plugins/jwt-auth.md)）验证请求凭证。 +2. 认证插件通过唯一的 `username` 识别 Consumer。 +3. APISIX 将 Consumer 和 Consumer Group 的插件配置与匹配到的 Route、Plugin Config 和 Service 的插件配置合并。 -1. 授权认证：比如有 [key-auth](../plugins/key-auth.md)、[JWT](../plugins/jwt-auth.md) 等； -2. 获取 consumer_name：通过授权认证，即可自然获取到对应的 Consumer name，它是 Consumer 对象的唯一识别标识； -3. 获取 Consumer 上绑定的 Plugin 或 Upstream 信息：完成对不同 Consumer 做不同配置的效果。 +当不同应用或用户请求同一 API，并且需要不同的限流或访问控制等插件配置时，可以使用 Consumer。Consumer 本身不包含 Upstream 配置。 -当有不同的使用者请求相同的 API，并且需要根据使用者执行不同的插件和上游配置时，使用 Consumer 是非常合适的。需要与用户身份验证系统结合使用。 - -目前，可以与 Consumer 配置的身份验证插件包括 `basic-auth` 、`hmac-auth`、`jwt-auth`、`key-auth`、`ldap-auth` 和 `wolf-rbac`。 +在 APISIX 中启用的认证插件可以配置在 Consumer 上，例如 `basic-auth`、`hmac-auth`、`jwt-auth`、`key-auth`、`ldap-auth` 和 `wolf-rbac`。 你可以参考 [key-auth](../plugins/key-auth.md) 认证授权插件的调用逻辑，进一步理解 Consumer 概念和使用。 diff --git a/docs/zh/latest/terminology/credential.md b/docs/zh/latest/terminology/credential.md index e7b39ecd67dc..164f055286b6 100644 --- a/docs/zh/latest/terminology/credential.md +++ b/docs/zh/latest/terminology/credential.md @@ -29,11 +29,9 @@ description: 本文介绍了 Apache APISIX Credential 对象的作用以及如 ## 描述 -Credential 是存放 [Consumer](./consumer.md) 凭证配置的对象。 -一个 Consumer 可以使用不同类型的多个凭证。 -当你需要为一个 Consumer 配置不同类型的多个凭证时，就会用到 Credential。 +Credential 存储与 [Consumer](./consumer.md) 关联的认证插件配置。每个 Credential 最多包含一个已启用的认证插件，例如 `basic-auth`、`hmac-auth`、`jwt-auth` 或 `key-auth`。 -目前，Credential 可以配置的身份认证插件包括 `basic-auth`、`hmac-auth`、`jwt-auth` 以及 `key-auth`。 +一个 Consumer 可以拥有不同认证插件的 Credential，也可以为同一认证插件配置多个具有不同识别值的 Credential。例如，可以先创建第二个 `key-auth` Credential，将客户端切换到新密钥，再删除旧 Credential，以完成密钥轮换。Credential 详情独立存储，获取 Consumer 资源时不会返回这些详情。 ## 配置选项 @@ -43,7 +41,7 @@ Credential 是存放 [Consumer](./consumer.md) 凭证配置的对象。 |---------|-----|-----------------------------------------------------| | desc | 否 | Credential 描述。 | | labels | 否 | Credential 标签。 | -| plugins | 否 | Credential 对应的插件配置。详细信息，请参考 [Plugins](./plugin.md)。 | +| plugins | 否 | 最多包含一个认证插件配置。详细信息请参见 [Plugins](./plugin.md)。 | :::note diff --git a/docs/zh/latest/terminology/global-rule.md b/docs/zh/latest/terminology/global-rule.md index 8b3dc7ad4866..e9cb48cdad74 100644 --- a/docs/zh/latest/terminology/global-rule.md +++ b/docs/zh/latest/terminology/global-rule.md @@ -29,7 +29,7 @@ description: 本文介绍了全局规则的概念以及如何启用全局规则 ## 描述 -[Plugin](plugin.md) 配置可直接绑定在 [Route](route.md) 上，也可以被绑定在 [Service](service.md) 或 [Consumer](consumer.md) 上。 +[Global Rule](../admin-api.md#global-rule) 为传入请求配置 [Plugin](plugin.md)，不依赖于绑定到 [Route](route.md)、[Service](service.md)、[Consumer](consumer.md) 或 [Plugin Config](plugin-config.md) 的插件配置。限流和可观测性插件通常会全局启用，以便为所有 API 提供一致的行为。 如果你需要一个能作用于所有请求的 Plugin，可以通过 Global Rules 启用一个全局的插件配置。 diff --git a/docs/zh/latest/terminology/plugin-metadata.md b/docs/zh/latest/terminology/plugin-metadata.md index 3af77a08332f..d2f0dfa2f0c1 100644 --- a/docs/zh/latest/terminology/plugin-metadata.md +++ b/docs/zh/latest/terminology/plugin-metadata.md @@ -27,25 +27,19 @@ description: APISIX 的插件元数据 # --> -## 摘要 - -在本文档中，您将了解到 APISIX 中，插件元数据的基本概念和您可能使用到的场景。 - -浏览文档末尾的相关资源，获取与此相关的更多信息。 - ## 描述 -在 APISIX 中，配置通用的元数据属性，可以作用于包含该元数据插件的所有路由及服务中。例如为`rocketmq-logger`指定了 `log_format`，则所有绑定 rocketmq-logger 的路由或服务都将使用该日志格式。 +本文介绍 APISIX 插件元数据的基本概念和适用场景。 -下图说明了插件元数据的概念，使用两个不同路由上的 [syslog](https://apisix.apache.org/zh/docs/apisix/plugins/syslog/) 插件的实例，以及为 [syslog](https://apisix.apache.org/zh/docs/apisix/plugins/syslog/) 插件设置全局`log_format`的插件元数据对象： +在 APISIX 中，插件元数据对象为同一插件的所有实例配置共享设置，适用于日志格式模板等通常需要保持一致的配置。 -![plugin_metadata](https://static.apiseven.com/uploads/2023/04/17/Z0OFRQhV_plugin%20metadata.svg) +APISIX 为每个插件名称保存一个插件元数据对象。只有定义了元数据 Schema 的插件才支持插件元数据。字段和行为取决于具体插件，因此配置前请查看对应插件的文档。 -如果没有另外指定，插件元数据对象上的`log_format`应将相同的日志格式统一应用于两个`syslog`插件。但是，由于`/orders`路由上的`syslog`插件具有不同的`log_format`，因此访问该路由的请求将按照路由中插件指定的`log_format`生成日志。 +例如，插件元数据可以为所有 `syslog` 插件实例定义共享的 `log_format`。未配置实例级 `log_format` 时，插件使用元数据中的值；配置实例级 `log_format` 后，该值优先。 -在插件级别设置的元数据属性更加精细，并且比`全局`元数据对象具有更高的优先级。 +对于支持共享 `log_format` 元数据的日志插件，此行为也适用于 `http-logger`、`kafka-logger` 和 `file-logger` 等插件。 -插件元数据对象只能用于具有元数据属性的插件。有关哪些插件具有元数据属性的更多详细信息，请查看插件配置属性及相关信息。 +插件元数据与插件实例配置之间不存在适用于所有插件的统一优先级规则。每个插件自行决定如何使用元数据，以及实例级字段是否覆盖元数据字段。 ## 配置示例