发布流程
本页是真实可执行的 SOP：每个产品从哪里构建、构建产物长什么样、怎么投递到本站、 怎么上线、什么时候需要迁 COS。
在动手前先看 安全红线，发布任何产物前都过一遍。
总览
源项目构建产物 ──► docs/public/releases/<file> ──► catalog.js 回填元数据 ──► npm run build ──► 上线
▲
│ 推荐用 `node scripts/publish-release.mjs <file>`
│ 它会算 SHA-256、复制文件、删除 .pending 占位安全红线
- 不要把 KiberCloud 的
release.tgz直接搬上来。它打包时把release/.env（含COS_SECRET_ID、COS_SECRET_KEY、JWT_SECRET、DB_PASSWORD、ADMIN_PASSWORD等真实值）一起打进去了。- 在
kibercloud/scripts/deploy.sh打包后先清掉release/.env（保留release/.env.example），再tar czf kibercloud-beta-linux-amd64.tar.gz -C kibercloud release --exclude='release/.env' - 或者改
deploy.sh让它从一开始就不打release/.env
- 在
- 不要在制品包里出现
*.keystore、*.jks。Android 签名密钥一旦随包分发就视为泄漏。 - 不要把 macOS
.app里的私有.git/或.cargo/带上来。packaging/macos/package.sh已经会过滤，但人工复制时请注意。 - 任何时候不确定，就先打开产物目录
ls -la看看有没有不该出现的文件。
KiberCloud
构建
bash
cd /path/to/kibercloud
./scripts/deploy.sh build # 产出 release/（含 Go 二进制、前端、systemd、nginx）
rm -f release/.env # ← 必做：删真实 .env
cp .env.example release/.env.example
tar -czf /tmp/kibercloud-beta-linux-amd64.tar.gz -C . release --exclude='release/.env'投递
bash
cd /path/to/kiberapp
node scripts/publish-release.mjs /tmp/kibercloud-beta-linux-amd64.tar.gz
# 把脚本打印的 sizeBytes / sha256 填到 docs/data/catalog.js
npm run build发布后该改哪些字段
catalog.js里 KiberCloud 的version与每条 artifact 的version/updatedAtdocs/kibercloud/index.md里的「当前阶段」（如果从 Beta 升级到正式版）- 三款产品的版本号必须保持一致节奏 —— 一次发版同时改三处
KiberShot
构建
bash
cd /path/to/kibershot
export JAVA_HOME=$(/usr/libexec/java_home -v 21)
./gradlew assembleDebug
# 产物：app/build/outputs/apk/debug/app-debug.apk
cp app/build/outputs/apk/debug/app-debug.apk /tmp/kibershot-0.6.0-android-universal.apk当前 KiberShot 仅产出 Debug APK，没有 Release 签名版。Debug APK 不带签名密钥风险， 但仍要在「安全红线」一节核对：APK 内嵌的
META-INF不能有你的发布 keystore。
投递
bash
node scripts/publish-release.mjs /tmp/kibershot-0.6.0-android-universal.apk
# 回填 sizeBytes / sha256Kibermod Studio
构建
bash
cd /path/to/kiberstudio
# macOS（产物：target/release/dist/）
bash packaging/macos/package.sh
# Windows（在 Windows 机器上）
powershell -File packaging/windows/package.ps1
# Linux
bash packaging/linux/package.sh
bash packaging/linux/flatpak-bundle.sh # 可选
# FreeBSD
bash packaging/freebsd/package.sh
# Web (WASM)
bash packaging/web/package.sh
packaging/macos/package.sh当前默认会把.app一起打进.dmg并（如果配置了）做签名与公证。 我们的catalog.js里给 macOS dmg 留的 note 是「Apple silicon 与 Intel 通用，要求 macOS 11.0 及以上」， 真实签名后可以在note后追加一行已 Apple 开发者签名与公证，由catalog.js驱动而非写死。
投递
bash
# 一个一个来；体积都不小，注意 repo 体积
node scripts/publish-release.mjs target/release/dist/kibermod-0.7.0-macos-universal.dmg
node scripts/publish-release.mjs target/release/dist/kibermod-cli-0.7.0-macos-universal.zip
node scripts/publish-release.mjs target/release/dist/kibermod-0.7.0-windows-x64.msi
node scripts/publish-release.mjs target/release/dist/kibermod-0.7.0-windows-x64-portable.zip
node scripts/publish-release.mjs target/release/dist/kibermod-0.7.0-linux-x86_64.AppImage
node scripts/publish-release.mjs target/release/dist/kibermod-0.7.0-linux-x86_64.deb
node scripts/publish-release.mjs target/release/dist/kibermod-web-0.7.0.zip验证
bash
# 1. 校验 catalog 完整性
npm run check:releases # 应该有 0 缺失、0 孤儿
npm run check:releases -- --strict
# 2. 重新构建
npm run build
# 3. 抽检
ls -la docs/.vitepress/dist/releases/
# 用浏览器打开 dist/releases/<filename> 应该能下载何时迁到对象存储
仓库里 docs/public/releases/ 适合：
- 总产物体积 < 100 MB
- 更新频率 < 每周一次
- 团队成员少，所有访问者都习惯 git 流程
不满足以上任一时，迁到腾讯云 COS（桶 cloud-1302494519）：
- 在 COS 里建
releases/<产品>/目录，把产物上传。 - 把
catalog.js里的url字段从/releases/<file>改为https://cloud-1302494519.cos.ap-shanghai.myqcloud.com/releases/<产品>/<file>。 - 在
deploy/nginx.conf里去掉location /releases/段。 - 在 COS 控制台配置 CORS（允许
app.kibermod.com）。
一个完整的发版日流程
bash
# 1. 三款产品各自构建 → 产出 N 个文件
# 2. 把所有文件集中到一个目录
mkdir -p /tmp/release-batch && cp <所有产物> /tmp/release-batch/
# 3. 逐个投递
for f in /tmp/release-batch/*; do
node scripts/publish-release.mjs "$f"
done
# 4. 把脚本打印的 sizeBytes / sha256 集中回填到 catalog.js
# 5. 跑校验
npm run check:releases
npm run build
# 6. 提交（不要 git add 二进制文件；如需保留，用 git add -f）
git add docs/data/catalog.js docs/public/releases/.pending # 等
git commit -m "release: 2026-10-19 三款产品同步发版"