meta 仓库里 37 个版本号，我用一条 grep 统一了

仓库里的 meta 目录下散着 37 个版本号：有的写在 JSON 的 version 字段，有的藏在 YAML 注释里，还有几个硬编码在脚本的 VERSION= 后面。上周要确认线上跑的到底是哪一版，我翻了三层目录才确认。

我的做法是先让它们全部暴露在一份清单里，再人工核对差异。命令不复杂，关键是路径和排除规则一次写对：

cd meta && grep -rnE '(version|VERSION)["'"'"']?\s*[:=]\s*["'"'"']?[0-9]+\.[0-9]+' \
  --include='*.json' --include='*.yaml' --include='*.yml' --include='*.sh' \
  --exclude-dir=node_modules --exclude-dir=.git \
  | sort -t: -k1,1 -k2,2n > /tmp/meta-versions.txt

37 条结果，我按文件路径排序后逐条标注「这个字段被谁读」。标完发现 9 条是死字段，没有任何代码引用，另有 4 条和主版本号不一致，其中 2 条是发布脚本里的旧值，2 条是注释里的历史记录。

为什么这么做而不是直接统一：版本号散落的根因是「没有单一来源」，删字段是结果不是手段。先建清单，是为了在删之前确认每个字段的读取方，避免删掉一个被运维脚本依赖的值。代价是这次花了大概一个下午，而且清单本身会过期，所以我把它放进 CI，每次改动 meta 时重跑一次并对比上次输出。

会失效的地方：grep 只认单行，跨行的版本号或者用模板拼接的写法它抓不到；--include 漏掉的扩展名（比如 .toml 和 .env）不会出现在结果里，我第一次就漏了两个 .env 文件。另外如果 meta 目录里有符号链接指向外部仓库，默认不会跟进，需要加 -R 并自己承担循环风险。

现在的问题是：你们仓库里版本号的「单一来源」放在哪一层——构建脚本、CI 变量，还是某个 meta 文件本身？我想知道别人是怎么防止它再次散开的。