01
先确定标签来自哪里
标签映射模式读取整个对象；资源模式接受单对象、数组，以及带 items 数组的 List 或以 List 结尾的类型。只读取 metadata.labels，不会自动改读 Deployment 的 Pod 模板标签。
Kubernetes
Kubernetes 标签选择器逐条看懂匹配原因
输入标签或资源 JSON，检查标签语法并查看每个条件的判断结果。
Kubernetes 标签选择器
匹配结果
输入仅在当前浏览器处理，不连接集群、不上传，也不进行网络查询。
输入设置与支持语法
= · == · != · in · notin · key · !key。逗号连接的条件必须全部满足；空选择器匹配全部输入。
限制：JSON 500,000 字符、选择器 8,192 字符、500 个资源、64 个条件、每资源 256 个标签。
语义基线：Kubernetes 1.35 / apimachinery v0.35.0；仅支持等值、集合与存在性选择器。
输入已变化，请重新测试后导出。
排查 Service 没有选中预期 Pod 时，先用 Kubernetes 标签选择器 检查手里的标签快照。env!=prod 不仅接受其他环境，还会接受根本没有 env 键的对象；只看最终的匹配数量，很容易漏掉这个区别。
直接测试标签映射时，整个 JSON 对象就是标签；切换资源模式后才读取 metadata.labels。两种模式分别保留输入，名为 metadata 的合法标签不会被猜成资源外壳。
为什么检查 Kubernetes 标签选择器？
查清是哪一个条件没有通过
Kubernetes 标签选择器 会计算整条条件链，不会在第一个失败处停止解释。开发环境的网页 Pod 可能通过 app=web 和 !paused，却不满足环境集合；逐条结果让你知道应该复查哪个键，而不是随意删除过滤条件。
把空字符串与没有标签分开看
值为 "" 的标签依然存在；缺失键则没有值。结果明确显示实际字符串或键不存在，因此你能看清否定条件为什么通过，也能判断是否需要额外加上存在性条件。
避免误选资源的三个核对点
02
用反例检查条件含义
把示例中的 production 改成 development，再删除 environment 键，比较 in 与 notin 的结果。默认停顿 350 毫秒后更新；关闭自动测试后可用 Ctrl/Cmd + Enter 手动运行。
03
展开结果后再导出
每个资源可以展开标签快照与所有条件。长列表按每次 50 项显示，复制和下载仍包含完整批次。修改输入后旧结果立即失效，必须重新测试才能导出。
从标签合法性到批量匹配解释
键名、前缀和值分别校验
标签校验区分可选 DNS 前缀、名称部分与值。前缀必须小写且不超过 253 字符；名称是 1–63 个合法 ASCII 字符，可以含大写字母；值最长 63 字符，也允许空字符串。保留前缀不会仅因保留约定而被判成语法错误。
等值与集合条件一起计算
标签选择算符 = 和 == 判断相等，!= 判断不等；集合选择器 in 和 notin 判断值是否在集合中。不同条件以逗号连接后必须全部满足，同一键的多个可选值应放进一个 in 集合，不能靠多条等值条件表示任选其一。
批量报告保留每个对象的位置
资源模式保留输入索引、JSON 路径和提供的名称、命名空间、类型。缺少或为 null 的 metadata、labels 视为空标签集合。相同名称的对象也分别报告，不去重，不会把多条输入悄悄合成一条。
字符串不被自动转换
"01" 与 "1" 始终是不同的标签值。数字、布尔值和 null 不能自动转为字符串，重复 JSON 键也会报错。这样在核对 kubectl 标签查询之前，你看到的是输入本身的含义，而不是转换后的猜测。
支持范围与真实限制
- 只处理指定的字符串语法
- 语义以 Kubernetes 1.35 / apimachinery v0.35.0 的等值、集合及存在条件为基线。不支持跨键 OR、通配符、正则、数值 < 或 >、字段选择器和节点亲和性；不接受结构化 matchLabels 或 matchExpressions。
- 严格 JSON 与显式输入模式
- 不读取 YAML、文件或 URL，也不接受注释和尾随逗号。资源模式仅检查对象自身的 metadata.labels；List 或以 List 结尾的类型必须带 items 数组，普通对象的其他字段不会被当成资源列表。
- 超过预算或出现错误时整批停止
- 最多 500,000 个 JSON 字符、8,192 个表达式字符、500 个资源、64 个条件，以及每资源 256 个标签。字符按 UTF-16 代码单元计数。解析器另限制深度 100、节点 50,000、单个数字 1,000 字符；任一项无效都不输出可导出的部分成功报告。
- 空表达式只表示本次查询不设限制
- 本工具的空字符串选择器匹配所有合法输入对象，包括空标签集合；空 JSON 编辑框则是没有输入，必须用 {} 表示空映射。这不代表 Service 的空 selector 或结构化 null 选择器具有同样含义，不同 API 需要分别核对。
- 标签匹配不是集群验收
- 导出的是身份字段、标签快照及条件结果，不是原资源清单。工具不修改标签、不读取 Pod 模板、不检查准入策略，也不能判断 Pod 是否就绪、Service 是否有端点、路由是否通或控制器归属是否正确。
Kubernetes 标签选择器 常见问题
怎样同时按多个标签查询 Pod？
把条件写成 app=web,environment=production，逗号表示同时满足。带域名前缀的标签要写完整，例如 app.kubernetes.io/name=web；它与没有前缀的 name 是不同的键。
标签条件能用 OR 连接吗？
不支持跨键 OR。同一个键有多个候选值时，可以写 environment in (production,staging)。如果写成 environment=production,environment=staging，就是要求同一个值同时等于两者，通常不会匹配任何对象。
标签可以只有键、没有值吗？
可以在 JSON 中写成 {"maintenance":""}。maintenance 判断键是否存在，maintenance= 判断存在且为空串，!maintenance 判断键缺失。字符串语法中的 maintenance in () 也会匹配存在的空值，并不是空集合。
Service 没有端点一定是标签选择器错了吗？
不一定。先检查预期 Pod 是否满足所有标签条件，再到集群中核对命名空间、就绪状态与端点等信息。本页面只能核对粘贴进来的标签快照，匹配成功不代表 Service 已经能够转发流量。
为什么 env!=prod 会选中没有 env 标签的对象？
!= 和 notin 的否定语义包含缺失键。若要求 env 必须存在且不等于 prod，可以写 env,env!=prod。报告会把“缺少键”和“存在但值不同”分开解释，避免把它们混为同一种情况。
还有选择器问题没有解决？