那就是在封闭的会议室里面对着产品经理、测试同学甚至客户方代表的质问，而你手里没有任何证据。

那种感觉，就像是你明明走在斑马线上，却被一辆逆行的车撞了司机下车还指着你的鼻子说是你挡了道。作为一名在代码丛林里摸爬滚打多年的前端工程师，我经历过太多次这种“罗生门”。特别是当涉及到客户内网部署、多环境发布的时候，那句经典的“前端发的包有问题”，简直就是悬在头顶的达摩克利斯之剑。

那个令人窒息的下午，黑锅从天而降

事情得从去年那个令人头秃的项目说起。那时候，我们组接了一个B端大客户的定制化需求，流程走得特别长。代码经过内网测试、UAT验收，Zui后打成包发给客户方的运维去部署。本来以为发版之后Neng稍微喘口气，喝杯手冲咖啡，结果没过两天客户群里就炸了锅。

“这个功Neng怎么点没反应？你们发的什么包？”

售前同学在群里转达了客户的愤怒，紧接着，测试同学也在内部群里@我：“哥，你发的包是不是有问题？客户那边截图显示逻辑完全不对啊。”

我当时就懵了。那个功Neng我在本地测过无数遍，预发环境也跑通了怎么到了客户那儿就“灵异事件”了？我第一反应是去查Jenkins的构建时间，翻kan发版记录，甚至想找运维对一下包名。但现实是残酷的——那是客户的内网，我们进不去，他们也不会给你kan构建日志，甚至连服务器权限dou不开放。

Zui后我只Neng靠一种极其卑微的话术硬撑：“大概是上周三那版吧？或者是周四晚上的？你让那边清个缓存再试试？”

沟通成本高到离谱，而且我心里根本没底。这种“薛定谔的版本”状态，让人焦虑得想撞墙。geng绝的是后来有一次测试同学在部署时手滑，把一个旧的测试包打上去了然后报了一个Bug，言之凿凿地在会上点名：“前端发的包有问题，导致测试环境异常。”

我解释了半天说逻辑没问题，hen可Neng是部署错了。但在没有证据的情况下谁也说不清。Zui后只Neng吃了个哑巴亏，还得灰溜溜地去排查代码。从那一刻起，我就暗暗发誓：下次谁再敢说是我的包有问题，我必须Neng直接把证据拍在桌子上。

为什么“查日志”在客户现场是个伪命题

我们常说“用数据说话”，但数据是缺失的。

对于前端项目来说一旦代码打包压缩成JS文件，原本清晰的变量名变成了a、b、c，注释被剔除，文件名可Neng还带上了hash值。在客户现场，或者是在复杂的微服务架构中，想要确认“当前浏览器跑的到底是哪一次Git提交的代码”，简直难如登天。

我也试过一些土办法。比如在代码里手写版本号，在`main.js`里加一行`window.version = 'v1.0.1'`。结果呢？要么是发版太急忘了改，上线后发现版本号还是上一版的；要么是改错了分支，导致版本号和代码内容对不上。这种手动维护的方式，不仅效率低，而且极其容易出错，等于白写。

还有人提议用CI环境变量在构建时注入。这听起来是个好主意，但现实情况是公司的项目五花八门。有的用Jenkins，有的用GitLab CI，有的用GitHub Actions，还有的老项目甚至还在用脚本手动打包。配置不统一，换一个项目又得搞一遍配置，心累到极点。

我需要的是一个不依赖特定CI平台、不依赖手动修改、Neng够自动携带Git信息的“身份证”。

既然kan不见，那就给代码刻上“身份证”

痛定思痛，我开始琢磨Webpack的插件机制。Webpack本质上是一个事件流，在打包的过程中，它会触发一系列的钩子。我是不是Ke以在某个钩子里拿到当前的Git信息，然后把它“偷偷”塞进打包后的代码里？

这个想法一旦冒出来就再也压不下去了。我想要的版本信息，必须包含以下几个核心要素：

分支名确认代码来源，是master还是feature分支。

提交ID这是Zui精确的指纹，全球唯一，直接对应Git仓库里的某次改动。

标签方便对应发版记录。

构建时间精确到秒，防止同一天多次打包混淆。

只要这四样东西dou在不管包被传到哪里不管是CDN还是客户内网，只要Neng打开页面我就Neng知道它的身世。

揭秘 VersionRecord：我的防甩锅神器

查了一圈开源社区，没找到特别合胃口的工具。要么依赖太重，引入一堆库；要么配置太死板，不Neng自定义格式。于是我决定自己动手，丰衣足食。我写了一个Webpack插件，名字就叫VersionRecord。

它的原理其实非常简单粗暴：插件会自动读取本地Git仓库的信息，然后按照你定义的格式，生成一段字符串，Zui后把这段字符串注入到你指定的入口文件中。

接入姿势：三行配置，终身受益

这个插件的使用方式简单到令人发指。当然是把它装进你的项目里：

npm install version-record --save-dev

然后在你的`webpack.config.js`里进行配置。这里我特意设计得比较灵活，你Ke以控制注入哪个文件、挂载到全局对象上的名字叫什么、以及版本字符串长什么样。

const CreateVersionRecord = require;
const VersionRecord = CreateVersionRecord({
  // 核心逻辑：过滤入口文件，Vue项目一般注入main.js即可
  isFileAdd:  => fileName.includes,
  // 挂载到 window 上的全局变量名，方便控制台调用
  valueKey: 'version',
  // 自定义版本串的格式，想怎么拼就怎么拼
  getString:  => {
    return `${branchName}-${commitId}-${tag}-${date}`;
  },
  // 环境控制，true表示所有环境dou注入，也Ke以只针对production
  checkEnvironment: true,
});
module.exports = {
  // ...其他webpack配置
  plugins: ,
};

配置好之后神奇的事情发生了。当你执行`npm run build`时插件会自动工作。打包完成后的入口文件里会多出这么一行代码：

window.version = "master-a1b2c3d-v1.2.0-2023-10-27 14:30:00";

注意kan，这里的`master`是分支名，`a1b2c3d`是Commit哈希值，`v1.2.0`是Tag，后面跟着的是精确的打包时间。所有这些信息，dou是从本地Git环境自动抓取的，完全不需要你手动去改任何一个字。

真相时刻：用数据说话，而不是用嗓门

自从给项目装上了这个“黑匣子”，我的腰杆子dou硬了不少。

没过多久，熟悉的剧情又上演了。测试同学在群里大喊：“前端有问题！这个弹窗怎么关不掉？肯定是你们发的包不对！”

要是以前，我可Neng又要慌慌张张地去翻代码，或者心虚地去问运维。但这次我没慌。我淡定地回复了一句：“麻烦打开浏览器，按F12，在控制台输入`version`，把结果发给我。”

过了一会儿，测试发来了一串字符：`feature-old-fix-8f9e2a1-none-2023-10-20 09:15:00`。

我一kan，乐了。这明显是上周二在修复分支上打的一个临时包，而且根本没有打Tag。而我Zui近发给测试的包，明明是`master`分支上的Zui新代码，Commit ID也是完全不同的。

我直接把截图和我的发版记录往群里一甩，并附言：“证据在这儿，这个包是10月20号的旧包，不是我Zui近发的。这次真不是我的锅，麻烦检查一下部署路径。”

群里瞬间安静了。过了一会儿，测试同学弱弱地回了一句：“不好意思，运维那边好像覆盖错了重新部署一下。”

那一刻，感觉真是神清气爽。不用再扯皮，不用再背锅，一切用代码说话。

不仅仅是防甩锅，geng是协作的润滑剂

除了用来“怼”测试和运维，这个插件在团队协作中也起到了意想不到的作用。以前售前或者客户支持去现场排查问题，总是问我们“现在线上跑的是哪个版本？”，我们往往要查半天记录。

现在好了直接告诉他们：“您打开网页，按F12输入`version`kan一眼，把那串字符发给我们，我们就知道是哪个版本了。” 这大大降低了沟通成本，也让客户觉得我们专业、规范。

写在Zui后：技术是为了解决人的问题

hen多时候，我们写代码、Zuo架构，不仅仅是为了实现业务逻辑，geng是为了解决人与人之间的信任问题。在复杂的软件工程流程中，不确定性是Zui大的敌人。

当“谁敢把责任推给我”变成一种底气，而不是一种反问的时候，技术就真正发挥了它的价值。这个`VersionRecord`插件虽然只有几十行代码，但它解决的是开发流程中一个极其微小但又极其高频的痛点。

Ru果你也曾经因为版本对不上而吃过哑巴亏，或者正在为多环境部署的版本管理而头疼，不妨试试这个方案。零侵入、改一下Webpack配置就Neng用。我Yi经把它开源到了GitHub，欢迎各位大佬Star、提Issue，也欢迎 Fork 过去改成你自己喜欢的样子。

毕竟在这个充满“噪音”的世界里拥有一份确凿的证据，比什么dou重要。下次再有人想把锅甩给你，记得微笑着让他打开控制台。

---