尧图网站建设 
Vectortag_cardinality_limit转换器实战用标签基数限制为指标存储上保险【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector本指南以 Vector 开源仓库中tag_cardinality_limit转换器为核心系统讲解如何通过限制指标事件上标签tag的基数cardinality来防止因误用高基数标签导致的指标存储稳定性问题。读完本文你将掌握该转换器的全部配置参数、三种追踪模式exact/exact_fingerprint/probabilistic的取舍、逐标签与逐指标覆盖规则、内存估算方法以及配套的内部遥测指标。为什么需要标签基数限制在可观测性数据管道中指标metric的标签是描述指标维度的键值对。当业务代码意外地把request_id、trace_id、user_id这类取值近乎无限的字段加进标签时指标序列的数量会呈爆炸式增长这种现象被称为基数爆炸cardinality explosion。它会使下游的指标存储如 Prometheus、Datadog内存与磁盘开销失控甚至拖垮整个监控系统。tag_cardinality_limit正是 Vector 为此提供的一道保险闸门。按官方描述它的职责是Limits the cardinality of tags on metric events, protecting against accidental high cardinality usage that can commonly disrupt the stability of metrics storages.即限制指标事件上标签的基数防止意外的高基数用法破坏指标存储的稳定性。它被设计为一个防护机制protection mechanism用于兜住上游的失误而不是用来替代合理的数据治理。组件定位与基本行为该组件在 Vector 中属于transform转换器类别其元数据定义在 tag_cardinality_limit.cue开发状态beta输出方式stream流式处理有状态组件stateful: true——转换器内部维护一个内存中的基数缓存跨事件保留状态输入类型仅接受metrics日志与 trace 均不支持支持的指标类型counter、distribution、gauge、histogram、set、summary 全部支持输出修改后的输入指标事件默认行为是当某个标签的新取值超过配置的value_limit时丢弃该标签drop the tag。官方文档特别提醒这种默认行为通常只对**增量计数器incremental counter**指标有意义应用到其他类型指标上可能产生意外效果。默认动作可通过limit_exceeded_action参数修改。在config.rs中该转换器的构建逻辑是Transform::event_task(TagCardinalityLimit::new(self.clone()))输入约束为Input::metric()输出为DataType::Metric核心处理逻辑位于 src/transforms/tag_cardinality_limit/mod.rs 的transform_one方法中。配置参数详解转换器在配置中的type固定为tag_cardinality_limit。完整参数定义见 generated/tag_cardinality_limit.cue 与 config.rs下表汇总了所有顶层参数参数类型默认值必填说明modestring无必填是基数追踪方式exact、exact_fingerprint、probabilisticvalue_limituint500否任意给定标签键最多接受多少个不同的值limit_exceeded_actionstringdrop_tag否超过限制时的动作drop_tag丢弃超限标签或drop_event丢弃整个事件cache_size_per_keyuint字节51205KB否仅probabilistic模式生效控制每个键的布隆过滤器大小tracking_scopestringglobal否追踪状态如何在指标间分区global或per_metricmax_tracked_keysuint未设置无上限否整个转换器最多追踪的指标, 标签键对数量per_metric_limitsobject空否按指标名覆盖基数限制配置per_tag_limitsobject空否全局的按标签键覆盖规则internal_metrics.include_extended_tagsboolfalse否是否在tag_value_limit_exceeded_total指标上附带metric_name、tag_key扩展标签mode三种基数追踪模式追踪算法在config.rs的Mode枚举中定义Exact、ExactFingerprint、Probabilistic三者对比如下exact精确模式精确追踪基数。内存需求高于probabilistic但达到限制后绝不会误放带新标签的指标通过。exact_fingerprint指纹模式与exact类似但使用标签值的64 位哈希指纹而非原始字符串进行追踪。当标签平均长度大于 8 字节时多数场景下内存占用更低代价是额外哈希运算带来的轻微吞吐下降以及极高基数下极小概率的哈希碰撞。probabilistic概率模式使用布隆过滤器概率性判定某个值是否已见过。内存占用最低但偶尔可能放行超过限制的新标签值放行概率由cache_size_per_key控制——过滤器越大误判false positive率越低。在配置中probabilistic模式需要提供cache_size_per_key默认 5120 字节。此外还有per_metric_limits作用域下的OverrideMode它在三种模式基础上额外增加excluded值完全跳过该指标的基数追踪所有标签值直通且不限制。tracking_scope追踪状态如何分区该参数控制标签追踪状态在指标之间如何划分对应config.rs中的TrackingScope枚举global默认所有指标共享一个追踪桶标签值跨指标汇聚全局value_limit约束合并后的集合。per_metric每个不同的指标拥有独立的追踪桶实现对每个指标的隔离限制代价是更高的内存占用。从mod.rs的transform_one可以看到per_metric模式以(metric_namespace, metric_name)作为追踪键而global模式下所有指标共享同一份状态。max_tracked_keys追踪键数量上限该参数限制整个转换器最多追踪的指标, 标签键对数量。达到上限后新指标上的新标签键或已有指标上的新标签键不再被追踪这些标签值将不经过检查直接放行。可通过两个内部指标检测此情况tag_cardinality_untracked_events_total计数器tag_cardinality_tracked_keys仪表当未设置时默认转换器追踪所有遇到的指标, 标签键对。即使处于global追踪作用域该上限仍然生效除非存在 per-metric 覆盖此时指标键被设为None。limit_exceeded_action超限后的两种动作对应config.rs的LimitExceededAction枚举默认DropTagdrop_tag默认丢弃会超过配置限制的那个些标签。事件本身继续流通。drop_event丢弃整个事件。完整配置示例与逐字段效果基础示例丢弃高基数标签官方 CUE 数据中提供了一个名为 Drop high-cardinality tag 的完整示例见 tag_cardinality_limit.cue 的examples字段用于演示如何丢弃名为user_id的高基数标签type: tag_cardinality_limit value_limit: 1 limit_exceeded_action: drop_tag mode: exact输入两条增量计数器指标metric: kindincremental namelogins counter.value2.0 tags.user_iduser_id_1 metric: kindincremental namelogins counter.value2.0 tags.user_iduser_id_2输出为metric: kindincremental namelogins counter.value2.0 tags.user_iduser_id_1 metric: kindincremental namelogins counter.value2.0 tags{}可以看到由于value_limit: 1第一条指标记录下user_iduser_id_1后第二个指标的user_iduser_id_2因超出限制而被移除标签集变为空这正是默认drop_tag行为的效果。生产环境的完整配置骨架综合各参数一个完整的生产级配置骨架如下transforms: tag_limit: type: tag_cardinality_limit inputs: [my_metrics] mode: exact value_limit: 500 limit_exceeded_action: drop_tag tracking_scope: global # 可选限制追踪的 (指标, 标签键) 对总数防止缓存无限膨胀 # max_tracked_keys: 10000 # 可选概率模式下的布隆过滤器大小字节 # cache_size_per_key: 5120逐标签覆盖per-tag overridesper_tag_limits允许针对单个标签键覆盖基数设置而非修改指标级别的value_limit。它支持两个作用域顶层适用于所有未匹配per_metric_limits条目的指标per_metric_limits.name块内仅适用于该指标。每个条目使用两种mode之一mode: limit_override用该标签自己的value_limit追踪此标签独立于所在指标的value_limit。可选地在probabilistic模式下还能通过cache_size_per_key为该标签单独指定更大的布隆过滤器见 PerTagConfig 定义。mode: excluded完全绕过该标签的基数追踪所有值原样通过不计入任何value_limit也不会加入缓存。官方文档给出的完整示例type: tag_cardinality_limit value_limit: 500 mode: exact # 适用于所有未匹配下方 per_metric_limits 条目的指标 per_tag_limits: kube_pod_name: # 该标签的高基数是刻意为之——永不追踪它 mode: excluded request_id: # 在不降低指标级限制的前提下收紧此标签的上限 mode: limit_override value_limit: 50 per_metric_limits: http_requests_total: value_limit: 1000 mode: exact # 该指标有自己的逐标签规则。对 http_requests_total 而言 # 上面顶层的 per_tag_limits 被忽略——该指标上的 kube_pod_name # 将按 value_limit1000 被追踪 per_tag_limits: trace_id: mode: excluded优先级规则nearest wins就近者胜出若指标匹配某个per_metric_limits条目仅参考该条目的per_tag_limits顶层per_tag_limits对该指标被忽略这与 per-metric 的value_limit遮蔽全局value_limit的规则一致否则参考顶层per_tag_limits未被适用的per_tag_limits列出的标签回退到所在指标的value_limitper-metric 或全局。此外per_metric_limits.name支持namespace字段指定指标所属命名空间并在mode上支持excluded值整个指标退出追踪。需要留意的是在非probabilistic模式下给某个标签设置了cache_size_per_key属于配置错误。config.rs中的validate_structure会在构建期通过BuildError::CacheSizeRequiresProbabilistic报错要求移除该字段或切换到probabilistic模式。工作原理与内存估算预期用途Intended Usage该转换器被定位为防护机制用于拦截上游失误例如开发者不小心在指标上加了request_id标签。一旦发生此类问题建议尽快修复上游代码。原因在于 Vector 的基数缓存保存在内存中重启 Vector 会清空缓存届时新标签值会重新放行直到再次触达基数上限。对常规部署而言这通常不是问题因为 Vector 进程一般是长寿命的。内存占用估算转换器会在内存中为每个经过它的指标事件上的每个标签键保存一份键的副本。三种模式的内存模型不同该部分出自 CUE 文档how_it_works.memory_utilizationexact模式每个键还需保存每个不同的值副本直到该键见过的不同值达到value_limit之后该键的新值被拒绝。内存估算公式(指标标签中不同字段名的数量 * 标签字段名的平均长度) (指标标签中不同字段名的数量 * value_limit * 标签值的平均长度)exact_fingerprint模式行为同exact但保存的是每个值的 8 字节哈希而非值本身所以用同一个公式、把标签值平均长度替换为8即可。probabilistic模式不为每个键保存全部值而是每个不同键对应一个布隆过滤器概率性判断某值是否已见。内存估算公式(指标标签中不同字段名的数量 * 标签字段名的平均长度) (指标标签中不同字段名的数量 * cache_size_per_key)cache_size_per_key控制单个键所用布隆过滤器的大小过滤器越大误判率越低——在我们的场景中即允许一个本应违反限制的新标签值通过的概率越低。若想精确计算某个cache_size_per_key与value_limit组合下的误判率可使用布隆过滤器在线计算器公式通常涉及n过滤器中的条目数即我们的value_limit、p误判概率要求解的目标、k内部使用的哈希函数数、m布隆过滤器位数。注意单位换算value_limit以字节计而m常以位呈现1 字节 8 位。重启影响Restarts缓存存于内存重启 Vector 即重置。此后新标签值会放行直到再次达到基数限制。部署有状态管道、或依赖该转换器持续拦截超限标签时务必把这一重启语义纳入考量。遥测指标该转换器会发出以下内部指标定义见 src/internal_events/tag_cardinality_limit.rs并经 tag_cardinality_limit.cue 的telemetry字段登记指标名类型触发时机tag_value_limit_exceeded_totalcounter某个事件/标签因超过value_limit被丢弃时可通过internal_metrics.include_extended_tags: true附带metric_name与tag_key标签帮助定位是哪些指标与标签键触顶默认关闭因为这些标签的基数可能无界value_limit_reached_totalcounter某个键达到value_limit时此后该键的新值将被拒绝tag_cardinality_untracked_events_totalcountermax_tracked_keys上限耗尽部分标签未经检查直接放行时tag_cardinality_tracked_keysgauge当前被追踪的指标, 标签键对数量在drop_event动作下被丢弃的事件还会通过ComponentEventsDroppedreason 为 Tag value limit exceeded.计入组件丢弃事件统计便于与下游的丢弃监控体系对接。小结tag_cardinality_limit是 Vector 指标管道中一道低成本、可配置的基数安全阀用exact/exact_fingerprint/probabilistic三种模式在内存占用与精确性之间权衡用per_tag_limits、per_metric_limits实现从全局到单指标、单标签的精细化管控再用value_limit_reached_total等内部指标让超限行为可观测。将其部署在指标进入存储之前并结合 示例配置 等已有配置做对照即可快速为下游指标存储建立一道可靠的基数防线。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vector `tag_cardinality_limit` 转换器实战：用标签基数限制为指标存储上保险
Vectortag_cardinality_limit转换器实战用标签基数限制为指标存储上保险【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector本指南以 Vector 开源仓库中tag_cardinality_limit转换器为核心系统讲解如何通过限制指标事件上标签tag的基数cardinality来防止因误用高基数标签导致的指标存储稳定性问题。读完本文你将掌握该转换器的全部配置参数、三种追踪模式exact/exact_fingerprint/probabilistic的取舍、逐标签与逐指标覆盖规则、内存估算方法以及配套的内部遥测指标。为什么需要标签基数限制在可观测性数据管道中指标metric的标签是描述指标维度的键值对。当业务代码意外地把request_id、trace_id、user_id这类取值近乎无限的字段加进标签时指标序列的数量会呈爆炸式增长这种现象被称为基数爆炸cardinality explosion。它会使下游的指标存储如 Prometheus、Datadog内存与磁盘开销失控甚至拖垮整个监控系统。tag_cardinality_limit正是 Vector 为此提供的一道保险闸门。按官方描述它的职责是Limits the cardinality of tags on metric events, protecting against accidental high cardinality usage that can commonly disrupt the stability of metrics storages.即限制指标事件上标签的基数防止意外的高基数用法破坏指标存储的稳定性。它被设计为一个防护机制protection mechanism用于兜住上游的失误而不是用来替代合理的数据治理。组件定位与基本行为该组件在 Vector 中属于transform转换器类别其元数据定义在 tag_cardinality_limit.cue开发状态beta输出方式stream流式处理有状态组件stateful: true——转换器内部维护一个内存中的基数缓存跨事件保留状态输入类型仅接受metrics日志与 trace 均不支持支持的指标类型counter、distribution、gauge、histogram、set、summary 全部支持输出修改后的输入指标事件默认行为是当某个标签的新取值超过配置的value_limit时丢弃该标签drop the tag。官方文档特别提醒这种默认行为通常只对**增量计数器incremental counter**指标有意义应用到其他类型指标上可能产生意外效果。默认动作可通过limit_exceeded_action参数修改。在config.rs中该转换器的构建逻辑是Transform::event_task(TagCardinalityLimit::new(self.clone()))输入约束为Input::metric()输出为DataType::Metric核心处理逻辑位于 src/transforms/tag_cardinality_limit/mod.rs 的transform_one方法中。配置参数详解转换器在配置中的type固定为tag_cardinality_limit。完整参数定义见 generated/tag_cardinality_limit.cue 与 config.rs下表汇总了所有顶层参数参数类型默认值必填说明modestring无必填是基数追踪方式exact、exact_fingerprint、probabilisticvalue_limituint500否任意给定标签键最多接受多少个不同的值limit_exceeded_actionstringdrop_tag否超过限制时的动作drop_tag丢弃超限标签或drop_event丢弃整个事件cache_size_per_keyuint字节51205KB否仅probabilistic模式生效控制每个键的布隆过滤器大小tracking_scopestringglobal否追踪状态如何在指标间分区global或per_metricmax_tracked_keysuint未设置无上限否整个转换器最多追踪的指标, 标签键对数量per_metric_limitsobject空否按指标名覆盖基数限制配置per_tag_limitsobject空否全局的按标签键覆盖规则internal_metrics.include_extended_tagsboolfalse否是否在tag_value_limit_exceeded_total指标上附带metric_name、tag_key扩展标签mode三种基数追踪模式追踪算法在config.rs的Mode枚举中定义Exact、ExactFingerprint、Probabilistic三者对比如下exact精确模式精确追踪基数。内存需求高于probabilistic但达到限制后绝不会误放带新标签的指标通过。exact_fingerprint指纹模式与exact类似但使用标签值的64 位哈希指纹而非原始字符串进行追踪。当标签平均长度大于 8 字节时多数场景下内存占用更低代价是额外哈希运算带来的轻微吞吐下降以及极高基数下极小概率的哈希碰撞。probabilistic概率模式使用布隆过滤器概率性判定某个值是否已见过。内存占用最低但偶尔可能放行超过限制的新标签值放行概率由cache_size_per_key控制——过滤器越大误判false positive率越低。在配置中probabilistic模式需要提供cache_size_per_key默认 5120 字节。此外还有per_metric_limits作用域下的OverrideMode它在三种模式基础上额外增加excluded值完全跳过该指标的基数追踪所有标签值直通且不限制。tracking_scope追踪状态如何分区该参数控制标签追踪状态在指标之间如何划分对应config.rs中的TrackingScope枚举global默认所有指标共享一个追踪桶标签值跨指标汇聚全局value_limit约束合并后的集合。per_metric每个不同的指标拥有独立的追踪桶实现对每个指标的隔离限制代价是更高的内存占用。从mod.rs的transform_one可以看到per_metric模式以(metric_namespace, metric_name)作为追踪键而global模式下所有指标共享同一份状态。max_tracked_keys追踪键数量上限该参数限制整个转换器最多追踪的指标, 标签键对数量。达到上限后新指标上的新标签键或已有指标上的新标签键不再被追踪这些标签值将不经过检查直接放行。可通过两个内部指标检测此情况tag_cardinality_untracked_events_total计数器tag_cardinality_tracked_keys仪表当未设置时默认转换器追踪所有遇到的指标, 标签键对。即使处于global追踪作用域该上限仍然生效除非存在 per-metric 覆盖此时指标键被设为None。limit_exceeded_action超限后的两种动作对应config.rs的LimitExceededAction枚举默认DropTagdrop_tag默认丢弃会超过配置限制的那个些标签。事件本身继续流通。drop_event丢弃整个事件。完整配置示例与逐字段效果基础示例丢弃高基数标签官方 CUE 数据中提供了一个名为 Drop high-cardinality tag 的完整示例见 tag_cardinality_limit.cue 的examples字段用于演示如何丢弃名为user_id的高基数标签type: tag_cardinality_limit value_limit: 1 limit_exceeded_action: drop_tag mode: exact输入两条增量计数器指标metric: kindincremental namelogins counter.value2.0 tags.user_iduser_id_1 metric: kindincremental namelogins counter.value2.0 tags.user_iduser_id_2输出为metric: kindincremental namelogins counter.value2.0 tags.user_iduser_id_1 metric: kindincremental namelogins counter.value2.0 tags{}可以看到由于value_limit: 1第一条指标记录下user_iduser_id_1后第二个指标的user_iduser_id_2因超出限制而被移除标签集变为空这正是默认drop_tag行为的效果。生产环境的完整配置骨架综合各参数一个完整的生产级配置骨架如下transforms: tag_limit: type: tag_cardinality_limit inputs: [my_metrics] mode: exact value_limit: 500 limit_exceeded_action: drop_tag tracking_scope: global # 可选限制追踪的 (指标, 标签键) 对总数防止缓存无限膨胀 # max_tracked_keys: 10000 # 可选概率模式下的布隆过滤器大小字节 # cache_size_per_key: 5120逐标签覆盖per-tag overridesper_tag_limits允许针对单个标签键覆盖基数设置而非修改指标级别的value_limit。它支持两个作用域顶层适用于所有未匹配per_metric_limits条目的指标per_metric_limits.name块内仅适用于该指标。每个条目使用两种mode之一mode: limit_override用该标签自己的value_limit追踪此标签独立于所在指标的value_limit。可选地在probabilistic模式下还能通过cache_size_per_key为该标签单独指定更大的布隆过滤器见 PerTagConfig 定义。mode: excluded完全绕过该标签的基数追踪所有值原样通过不计入任何value_limit也不会加入缓存。官方文档给出的完整示例type: tag_cardinality_limit value_limit: 500 mode: exact # 适用于所有未匹配下方 per_metric_limits 条目的指标 per_tag_limits: kube_pod_name: # 该标签的高基数是刻意为之——永不追踪它 mode: excluded request_id: # 在不降低指标级限制的前提下收紧此标签的上限 mode: limit_override value_limit: 50 per_metric_limits: http_requests_total: value_limit: 1000 mode: exact # 该指标有自己的逐标签规则。对 http_requests_total 而言 # 上面顶层的 per_tag_limits 被忽略——该指标上的 kube_pod_name # 将按 value_limit1000 被追踪 per_tag_limits: trace_id: mode: excluded优先级规则nearest wins就近者胜出若指标匹配某个per_metric_limits条目仅参考该条目的per_tag_limits顶层per_tag_limits对该指标被忽略这与 per-metric 的value_limit遮蔽全局value_limit的规则一致否则参考顶层per_tag_limits未被适用的per_tag_limits列出的标签回退到所在指标的value_limitper-metric 或全局。此外per_metric_limits.name支持namespace字段指定指标所属命名空间并在mode上支持excluded值整个指标退出追踪。需要留意的是在非probabilistic模式下给某个标签设置了cache_size_per_key属于配置错误。config.rs中的validate_structure会在构建期通过BuildError::CacheSizeRequiresProbabilistic报错要求移除该字段或切换到probabilistic模式。工作原理与内存估算预期用途Intended Usage该转换器被定位为防护机制用于拦截上游失误例如开发者不小心在指标上加了request_id标签。一旦发生此类问题建议尽快修复上游代码。原因在于 Vector 的基数缓存保存在内存中重启 Vector 会清空缓存届时新标签值会重新放行直到再次触达基数上限。对常规部署而言这通常不是问题因为 Vector 进程一般是长寿命的。内存占用估算转换器会在内存中为每个经过它的指标事件上的每个标签键保存一份键的副本。三种模式的内存模型不同该部分出自 CUE 文档how_it_works.memory_utilizationexact模式每个键还需保存每个不同的值副本直到该键见过的不同值达到value_limit之后该键的新值被拒绝。内存估算公式(指标标签中不同字段名的数量 * 标签字段名的平均长度) (指标标签中不同字段名的数量 * value_limit * 标签值的平均长度)exact_fingerprint模式行为同exact但保存的是每个值的 8 字节哈希而非值本身所以用同一个公式、把标签值平均长度替换为8即可。probabilistic模式不为每个键保存全部值而是每个不同键对应一个布隆过滤器概率性判断某值是否已见。内存估算公式(指标标签中不同字段名的数量 * 标签字段名的平均长度) (指标标签中不同字段名的数量 * cache_size_per_key)cache_size_per_key控制单个键所用布隆过滤器的大小过滤器越大误判率越低——在我们的场景中即允许一个本应违反限制的新标签值通过的概率越低。若想精确计算某个cache_size_per_key与value_limit组合下的误判率可使用布隆过滤器在线计算器公式通常涉及n过滤器中的条目数即我们的value_limit、p误判概率要求解的目标、k内部使用的哈希函数数、m布隆过滤器位数。注意单位换算value_limit以字节计而m常以位呈现1 字节 8 位。重启影响Restarts缓存存于内存重启 Vector 即重置。此后新标签值会放行直到再次达到基数限制。部署有状态管道、或依赖该转换器持续拦截超限标签时务必把这一重启语义纳入考量。遥测指标该转换器会发出以下内部指标定义见 src/internal_events/tag_cardinality_limit.rs并经 tag_cardinality_limit.cue 的telemetry字段登记指标名类型触发时机tag_value_limit_exceeded_totalcounter某个事件/标签因超过value_limit被丢弃时可通过internal_metrics.include_extended_tags: true附带metric_name与tag_key标签帮助定位是哪些指标与标签键触顶默认关闭因为这些标签的基数可能无界value_limit_reached_totalcounter某个键达到value_limit时此后该键的新值将被拒绝tag_cardinality_untracked_events_totalcountermax_tracked_keys上限耗尽部分标签未经检查直接放行时tag_cardinality_tracked_keysgauge当前被追踪的指标, 标签键对数量在drop_event动作下被丢弃的事件还会通过ComponentEventsDroppedreason 为 Tag value limit exceeded.计入组件丢弃事件统计便于与下游的丢弃监控体系对接。小结tag_cardinality_limit是 Vector 指标管道中一道低成本、可配置的基数安全阀用exact/exact_fingerprint/probabilistic三种模式在内存占用与精确性之间权衡用per_tag_limits、per_metric_limits实现从全局到单指标、单标签的精细化管控再用value_limit_reached_total等内部指标让超限行为可观测。将其部署在指标进入存储之前并结合 示例配置 等已有配置做对照即可快速为下游指标存储建立一道可靠的基数防线。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考