前言

插件上架只是开始，持续迭代才是常态。每次发版，最容易被忽视却最关键的一件事就是版本号管理。版本号乱填，不仅让用户分不清"我装的是不是最新版"，还会让 Chrome 网上应用店的自动更新机制判断失误。本文用一套可运行的脚本，讲清楚语义化版本（SemVer）在 Chrome 插件里的落地方式，以及更新策略怎么定。需要说明：版本号不是给机器看的装饰，而是写给未来的自己和用户看的契约，越早规范，后期越省心。

环境准备

• Node.js >= 16（仅用于本地版本脚本，不影响插件运行）
• 项目结构：

your-extension/ ├─ manifest.json └─ scripts/ └─ bump.js

• 插件本身只需标准的 MV3manifest.json，其中version字段为"主.次.修订"三段式字符串。

实现步骤

下面这段scripts/bump.js会读取根目录的manifest.json，按你传入的级别（major/minor/patch）自增版本号并写回。复制即可用。

// scripts/bump.js// 用法: node scripts/bump.js [major|minor|patch]// 功能: 读取 manifest.json，按语义化版本规范自增版本号并写回constfs=require('fs');constpath=require('path');// manifest.json 位于上级目录constmanifestPath=path.join(__dirname,'..','manifest.json');// 允许的版本级别constLEVELS=['major','minor','patch'];constlevel=process.argv[2]||'patch';if(!LEVELS.includes(level)){console.error('用法: node scripts/bump.js [major|minor|patch]');process.exit(1);}// 读取当前 manifest（假设为合法 JSON）constmanifest=JSON.parse(fs.readFileSync(manifestPath,'utf-8'));constcurrent=manifest.version||'0.0.0';const[major,minor,patch]=current.split('.').map(Number);// 语义化版本规则: 主版本(不兼容变更).次版本(向下兼容新功能).修订(向下兼容修复)letnext;if(level==='major')next=`${major+1}.0.0`;elseif(level==='minor')next=`${major}.${minor+1}.0`;elsenext=`${major}.${minor}.${patch+1}`;// 写回文件，保留 2 空格缩进manifest.version=next;fs.writeFileSync(manifestPath,JSON.stringify(manifest,null,2)+'\n');console.log(`版本已更新:${current}->${next}`);

运行方式：

nodescripts/bump.js patch# 修订号 +1，如 1.2.3 -> 1.2.4nodescripts/bump.js minor# 次版本 +1，如 1.2.3 -> 1.3.0nodescripts/bump.js major# 主版本 +1，如 1.2.3 -> 2.0.0

为什么这样设计？Chrome 应用店以version字符串做数值比较来决定是否推送更新，所以必须严格保持三段式且只增不减。语义化版本让你和用户在看到1.3.0时，就能直观判断"这是加了新功能的小升级"，而不是"推倒重来的大改"。

脚本健壮性补充：上面的实现假设manifest.json始终是合法的三段式。在团队协作文档中，建议在 README 注明"禁止手改 version"，并把 bump 脚本接进提交前钩子（pre-commit），一旦有人直接改了数字，钩子自动用脚本重写，保证格式统一。若担心非法版本号导致脚本崩溃，可在读取后加一段正则校验^\d+\.\d+\.\d+$，不合法就报错退出，把问题拦在本地而不是提审时才发现。

运行示例与工程化建议

运行node scripts/bump.js minor后，终端会输出版本已更新: 1.2.3 -> 1.3.0，同时manifest.json被就地改写。把这个脚本接进提交钩子或 CI，就能让版本号随每次合并自动前进，避免人工遗漏。

与 CI 集成：在 GitHub Actions 里可以写一个 job，在打 tag 时根据 tag 名（如v1.3.0）调用脚本并重新打包上传，保证商店里的版本与代码仓库的 tag 永远一致，审计时一目了然。

回滚策略：万一新版本引入问题，不要试图发布更低的版本号——商店不允许降级。正确做法是发一个更高的修订号修复，或在商店后台把出问题的版本暂停分发。把"版本只增不减"当成铁律，能省掉很多排查时间。

版本与更新日志联动：每次 bump 的同时，建议在CHANGELOG.md追加一行本次变更说明，让用户清楚1.3.0相对1.2.4改了什么；这既是工程好习惯，也能直接在商店简介里引用，降低客服压力。

为什么不直接手改 manifest 里的数字：一是容易改错格式（少了段、多了空格），二是没有记录"为什么涨版本"，三是无法与 CI 联动。用脚本把规则固化后，这三个问题一次性解决。

多形态产品的统一版本：当插件与桌面客户端（Windows/Mac）协同工作时，推荐共用同一套 SemVer 并写入同一份CHANGELOG，这样用户看到插件 2.1.0、客户端 2.1.0，能立刻明白两者匹配，避免"新版插件配旧版客户端"的兼容性事故。

常见问题

1. 版本号写成了1.2两段式？应用店会拒绝，必须是三段。
2. 回退版本报错？不允许降级，version只能比已发布版本高。
3. CI 里怎么自动 bump？在合并到main的分支保护规则里加一步node scripts/bump.js $LEVEL，把$LEVEL由 PR 标签决定；例如带release:minor标签的 PR 合并时自动涨次版本。
4. 桌面客户端也要同步版本吗？若插件与桌面客户端（如 Windows/Mac 端）协作，建议共用同一套 SemVer，避免出现"插件 2.0 但客户端 1.5 不兼容"的尴尬。
5. 需要 beta 通道吗？商店支持按比例灰度发布，可先对小比例用户推高修订号验证，稳定后再全量；版本号仍然只增不减。
6. prerelease 标签怎么处理？商店version不接受1.3.0-beta.1这类带连字符的格式，beta 只能通过灰度比例实现，不要在 manifest 里写预发布后缀。

扩展阅读

• Semantic Versioning 2.0.0 官方规范
• Chrome 扩展manifest.version字段说明
• 基于chrome.alarms的插件定时任务实践

总结

版本号不是装饰，而是插件与用户、与商店更新系统之间的契约。用一段十几行的脚本把 SemVer 固化到工作流里，既能防止手抖填错，也让每次发版有据可循。对于像 MuxDesk 这样同时提供 Chrome 插件与桌面客户端（Windows/Mac）的多形态产品，统一版本语义更能降低用户的认知成本。把版本管理当成工程纪律而非琐事，插件的长线运营会从容很多。

标签：Chrome插件开发、视频下载、MuxDesk、JavaScript、版本管理